Bug#759018: [PATCH RFC] Provide prebuilt grub-xen binaries for host (dom0) use

[Ian Jackson]

Colin Watson writes ("Re: Bug#759018: [PATCH RFC] Provide prebuilt grub-xen binaries for host (dom0) use"):
...
> There is also the question of whether the guest-side name should mention
> GRUB.  One might argue that it shouldn't because all that matters is
> that it uses the Multiboot protocol.  Then there is the question of who
> gets to own the architecture names ...

The general scheme seems sound.


Ian Campbell:

> > I'm not sure what the best way to promulgate the spec is -- I
> > think a patch to add xen.git/docs/misc/pvgrub2.markdown would be
> > sufficient (it would end up under http://xenbits.xen.org/docs/).

Since this path is in /boot/xen and contains an executable which
expects to run in the Xen PV environment, it could also use Xen names
for the architectures.  I don't know whether a GNU config triplet arch
name as you suggest is easier or harder than that.


I have a question about the spec's wording about bitness:

+It is not in general possible under Xen for a bootloader to boot a
+kernel of a different width from itself, and this extends to
+chainloading from a stage one. Therefore it is permissible to have
+both `/boot/xen/pvboot-i386.elf` and `/boot/xen/pvboot-x86\_64.elf`
+present in a guest to be used by the appropriate stage 1 (e.g. for
+systems with 32-bit userspace and an optional 64-bit kernel).

Is it therefore expected that the host admin will be told out of band
what bitness the guest would prefer ?  And that then the host
toolstack will set up that bitness of guest, load its pvgrub for that
bitness, and hope that the guest has an appropriate-bitness core image
load in the canonical place ?

I wonder if we might, in the future, want this to be more automatic.

I guess we could have a feature in the host's 64-bit pvgrub which
would look for and load 64-bit guest pvgrub if it exists, and
alternatively check for 32-bit guest pvgrub and if found exit
signalling somehow to the host toolstack to restart the domain with
the other bitness.

But what if the host has both 64- and 32-bit pvgrub but in fact only
has one bitness of kernel ?  Signalling this back to the host by
somehow hiding or renaming one of the bitnesses of guest pvgrub seems
unpleasant.

I mention this just in case there's a better way of organising this
which might depend on a refinement to the host/guest interface.


Thanks,
Ian.