[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] GRUB Xen PVH chainloading



On Mon, Jan 07, 2019 at 01:43:11PM +0100, Juergen Gross wrote:
> On 07/01/2019 12:41, Colin Watson wrote:
> > Hi,
> >
> > I'm working on integrating the recently-merged PVH support for GRUB into
> > the Debian packages.  As a result I find myself thinking about how to
> > handle the two-stage boot loader scheme that our packages currently
> > implement for PV.  I think that it would not be very hard to do this for
> > PVH in the manner outlined below, but my x86 asm skills aren't quite up
> > to some of the work needed in GRUB.  Assuming that nobody sees any
> > obvious holes in this, does anyone fancy giving it a go?
>
> Seems to be a very good idea.
>
> > Background
> > ----------
> >
> > Around the time PV support was implemented in GRUB 2, we put together a
> > scheme to minimise the coupling between the guest configuration file on
> > the host and the boot loader configuration in the guest.  The scheme and
> > its rationale are described here:
> >
> >   
> > https://wiki.xen.org/wiki/PvGrub2#Chainloading_guest_pvgrub2_from_domain_0_pvgrub2
> >
> > Essentially the same rationale applies to the PVH case: it should be
> > possible for the guest to declare its own booting arrangements (though
> > of course some hosts may wish to just provide a grub.cfg and handle all
> > that on the host side), and this should be decoupled from the GRUB image
> > provided by the host as far as possible in order to minimise
> > compatibility issues.
> >
> > There seems to be no obstacle to this in principle: just as a PV boot
> > loader can chainload another one from the guest's disk, so too could a
> > PVH boot loader chainload another one from the guest's disk.
> >
> > What needs to be done
> > ---------------------
> >
> > GRUB needs to support chainloading another PVH boot loader.  I think
> > this involves observing the existence of the XEN_ELFNOTE_PHYS32_ENTRY
> > note and following the machine state rules for the domain builder here:
> >
> >   https://xenbits.xen.org/docs/unstable-staging/misc/pvh.html
> >
> > (I had a brief go at implementing this, but foundered on my fairly
> > minimal understanding of GRUB's relocator/boot code.)
>
> The needed effort should indeed be rather small.
>
> In the moment I have no idea when I'll be able to do it, as I have
> plenty of other things to do. In case you want to try it and need some
> hints, please feel free to ask (maybe I'm able to give an answer
> without having to try to implement it myself ;-) ).
>
> > We need to define a modification to
> > https://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html
> > for PVH boot loaders.  I suggest the obvious: a second-stage PVH boot
> > loader should be installed into the guest filesystem as
> > /boot/xen/pvhboot-<ARCH>.elf, and otherwise things generally behave the
> > same way.  I'd be happy to draft a patch to the protocol specification
> > once a proof-of-concept exists.
> >
> > The as-yet-unmerged GRUB patch to support the existing PV boot protocol
> > (https://salsa.debian.org/grub-team/grub/blob/master/debian/patches/grub-install-pvxen-paths.patch)
> > needs to be extended to support the amended protocol.  This is trivial
> > given the above.
>
> Would you mind trying to upstream this patch? I have CC-ed Daniel Kiper
> one of the grub2 maintainers), as I guess with his Xen skills he will be
> the one looking at the patch.

Yes, I am happy to help in development, e.g. give some hints if needed,
and review the patches. Sadly I am not able to do development myself
because I am busy with other stuff right now.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.