[Top][All Lists]

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

Re: [Xen-devel] pvgrub2 is merged

From: Colin Watson
Subject: Re: [Xen-devel] pvgrub2 is merged
Date: Tue, 3 Dec 2013 17:27:28 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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.

Colin Watson                                       address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]