[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |