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

Re: [Xen-devel] GRUB Xen PVH chainloading


  • To: Colin Watson <cjwatson@xxxxxxxxxx>, grub-devel@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Mon, 7 Jan 2019 13:43:11 +0100
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb
  • Cc: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
  • Delivery-date: Mon, 07 Jan 2019 12:43:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

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.


Juergen

_______________________________________________
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®.