Fixing update-grub to work with paravirt ops (2.6.22+) Xen kernels

[Ian Campbell]

On Sat, 2008-04-26 at 18:55 +0100, Ian Campbell wrote:
> Hi,
> 
> The current (grub1) update-grub has some special case code to handle the
> old Xen kernels which could be run only on top of the hypervisor.
> Unfortunately this code does not behave correctly in the presence of
> paravirt_ops kernels which are bootable both natively and in a Xen guest
> domain (and ultimately as a Xen domain 0 kernel but that support isn't
> available yet).
> 
> I only talk about the grub1 version of update-grub since Xen's PV
> bootloader (pygrub) currently only understands the menu.lst format.
> 
> I think the updated algorithm for determining which kernels to include
> in the menu on native, dom0 and domU is:
> 	if CONFIG_PARAVIRT then
> 		if IN_DOMU && ! CONFIG_XEN then
> 			continue (don't want non-Xen kernel in domU)
> 		endif
> 	else
> 		if ! IN_DOMU && CONFIG_XEN_PRIVILEGED_GUEST then
> 			continue
>         	elif IN_DOMU && ! CONFIG_XEN then
> 			continue
>         	endif
> 	endif
> 
> The ! CONFIG_PARAVIRT case is the same as currently to support older
> kernels.
> 
> I've attached a patch which implements this scheme against grub SVN. 

Any thoughts from the grub maintainers on this patch? (reattached as
update-grub-better-xen-support.patch).

This behaviour (along with #456776) is one of the major roadblocks
stopping d-i from working seamlessly in a Xen guest environment. It
would be really awesome to have this work for Lenny!

It seems to also be the cause of several bug reports (#455706 #442218
#479018)

> If a hypervisor is detected then the existing code will also add a
> hypervisor entry for any kernel with CONFIG_XEN_PRIVILEGED_GUEST set.
> It looks like the experimental tree
> (http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git;a=summary) doesn't
> make dom0 support optional so probably CONFIG_XEN is the correct trigger
> this behaviour now but until the support really exists I've left this
> bit alone.
> 
> However: I'd like to propose simplifying things. I don't believe that
> keying off being in a domU or not is useful anymore now that
> CONFIG_PARAVIRT exists. It interferes with constructing a guest inside a
> chroot and it is not unreasonable to assume that if the admin installs a
> kernel they intend to use it -- for example by reconfiguring the guest
> to be fully virtualised (HVM). Therefore I would suggest removing all of
> this code and simply including every kernel in menu.lst. If a hypervisor
> is found add a hypervisor entry for all CONFIG_XEN=y kernels too.
> 
> I can easily knock up this patch if it is the preferred option.

IOW something like the attached update-grub-no-xen-special-case.patch.
It doesn't remove as much code as I expected but it does address issues
such as those in #479478, is generally simpler (I think) and more
consistent with what grub2 does.

Ian.

-- 
Ian Campbell

I've finally found the perfect girl,
I couldn't ask for more,
She's deaf and dumb and over-sexed,
And owns a liquor store.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update-grub-better-xen-support.patch
Type: text/x-patch
Size: 3704 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20080506/c04b90c2/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update-grub-no-xen-special-case.patch
Type: text/x-patch
Size: 3055 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20080506/c04b90c2/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20080506/c04b90c2/attachment.pgp