Re: [Xen-devel] pvgrub2 is merged

[Ian Campbell]

On Tue, 2013-12-03 at 17:27 +0000, Colin Watson wrote:
> On Mon, Dec 02, 2013 at 09:48:07AM +0000, Ian Campbell wrote:
> > On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote:
> > > В Fri, 29 Nov 2013 13:24:22 +0000
> > > Colin Watson <address@hidden> пишет:
> > > > Could anyone offer packaging advice for which ports should be built
> > > > here?  Is it reasonable to assume that a 32-bit userspace only needs the
> > > > 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port,
> > > > or is it possible that there could be cross-architecture combinations
> > > > here?  Does the architecture of the GRUB port have to match the
> > > > architecture of the Xen hypervisor?
> > > 
> > > I guess this question is better asked on xen-devel. Assuming we have 64
> > > bit dom0 and try to boot 32 bit domU. Is it possible to start with
> > > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes
> > > (and in other direction too) situation becomes relatively simple.
> > 
> > AIUI it is not in general possible for a 32-bit PV guest to convert
> > itself to 64-bit or vice versa, which is essentially what would have to
> > happen to boot the other type of kernel. So once you have selected the
> > grub binary to use it cannot boot the other type of kernel. (Yes, this
> > is an annoying technical restriction...)
> > 
> > It is however possible to run 32-bit and 64-bit guests on a 32-bit dom0
> > with a 64-bit underlying hypervisor. It is also possible to run both
> > types of guest on a 64-bit kernel and 64-bit underlying hypervisor.
> > 
> > So, for packaging purposes it would be best to provide both 32- and
> > 64-bit grub binaries for both 32- and 64-bit userspace.
> 
> Thanks for the feedback.
> 
> I'm inclined, then, to just ship both in the same grub-xen binary
> package (actually the pattern is grub-xen{,-bin,-dbg} but never mind
> that for now).  It's a bit different from the usual case since you might
> well want to actively use both on the same system, and I don't think we
> would get much out of the two ports being in separate packages.

Yes, that makes sense to me.

Ian.