This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: PV-Grub and PXE

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Steven Maresca <steve.maresca@xxxxxxxxx>
Subject: [Xen-devel] Re: PV-Grub and PXE
From: Steven Maresca <steve.maresca@xxxxxxxxx>
Date: Wed, 15 Jul 2009 21:52:40 -0400
Delivery-date: Wed, 15 Jul 2009 18:53:10 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ax5P4MP94iBr6u0u1iNOCCzCZo+3rvPjAHO2o+cRmoQ=; b=Dpo7vpNept0vIvsXlestmYs4YMMn72bJzOlfVkfTQDJTuiAIeFCKMRkKATK3YEPK9U g2McJPWGRa7E82vnHQD8Lb+dA0NVDJXmiulVdQ+Ka/QaCGuj2V6ZIfpATuxZw6ZtrnuF 0h1Tw5Yd7PtfKay78yD5eDw8WduU1gPNxXY+o=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=wa1sbsjLSsolhugolNKUaDA87qUWoXgjwP09nLDenu27CQfIbGRN96JmAKcsznqwjP TuwjCp4husk1sRJV3YP/Gr2ZSxzJo/gbWJ7AmdPFhb8z4hHhoFBtMSuYGi/YKMRPgnV+ 4h59CV6WTqb1v9hwys3lOS8Psg/MX9Xtg/New=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090715223331.GA5075@const>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <7e9718f20907150839h1e194bc0wd3741c66824727a1@xxxxxxxxxxxxxx> <20090715173604.GE4903@xxxxxxxxxxxxxxxxxxxxxxxx> <7e9718f20907151133r3469f3cjde86cd45f4fb65fe@xxxxxxxxxxxxxx> <20090715223331.GA5075@const>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Wed, Jul 15, 2009 at 6:33 PM, Samuel
Thibault<samuel.thibault@xxxxxxxxxxxx> wrote:
> (Sending to xen-devel as it may find volunteers)
> Steven Maresca, le Wed 15 Jul 2009 14:33:45 -0400, a écrit :
>> While I would be satisfied with a grub menu.lst pulled via tftp, many
>> many others would rather rely upon established mechanisms [PXE].
> Well, that means two things:
> - using the existing PXE payloads. As I said in my previous private
> mails, that'd need a PV-bios stubdom for the software interrupt requests
> from the PXE payload, but now I think about it again, a PXE loader would
> also have to know how to load a PV kernel. This is quite a blocker
> actually. Unless porting all the existing PXE payloads, one won't be
> able to have them boot PV kernels. Only pv-grub knows at the moment,
> so it'd be a bit odd to implement a PV-bios stubdom just to load a PXE
> PV-grub, while we could directly start a PV-grub :) FV kernels is not a
> problem of course, just boot a FV Xen domain with net boot :)
> - using the existing PXE configurations. There are several kinds of
> them, quite often pxelinux config, which is like syslinux config.
> It may be not be so hard, we'd just need to add e.g. a syslinux
> parser in pv-grub. Or port syslinux to PV. That'd mean using just the
> configuration part of the existing PXE infrastructures, not its binary
> payload.
> Samuel

As you say, in the PV case we certainly cannot utilize native pxe loaders.

For full virt: boot='n' in the domU config and qemu's embedded ROM
does all of the heavy lifting.
Older versions of qemu lacking that ability can certainly boot a
gPXE/Etherboot image and move along happily.

For PV, we can cheat and skip most of that pain. In my mind - and as
you suggested - that means just parsing PXE configurations.

For the most basic case, all we need is:
1) access to the network device
2) ability to pull a lease from dhcp (with next-server and filename options set)
3) tftp to $next-server to grab not the pxelinux.0 binary (or its
equivalent) but the configuration alone
4) mechanism for presenting the configuration and emulating the (text) menu
5) acting upon the choice

Assumption: no more graphical menu is employed.

Please note: I'm not necessarily advocating that pv-grub should be
bent and twisted to this task, though that was the topic that led us
to this discussion.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>