Re: [PATCH 3/4] Build grub.xen.

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.12.2013 12:56, Colin Watson wrote:
> On Thu, Dec 12, 2013 at 03:37:41PM +0000, Colin Watson wrote:
>> +if [ -z "$grub_xen_guest" ]; then
>> +    # This is the copy of grub.xen installed in the dom0's filesystem.
>> +    # Look for a copy in the domU's filesystem and chainload that.  This
>> +    # allows us to guarantee that GRUB will be in sync with the
>> +    # configuration file in the domU.  The file locations here must not
>> +    # have any configure-generated substitutions applied, as the intent
>> +    # is that a single grub.xen should be able to cope with a variety of
>> +    # domU systems.
>> +    if search --set=root --file /boot/grub/grub.xen; then
>> +            linux /boot/grub/grub.xen grub_xen_guest=1
>> +            boot
> [...]
> 
> I talked about this with Ian Jackson in the pub last night.

>  We came to
> the same conclusion more or less at the same time, that this is in fact
> a new boot protocol; since it essentially just expects a bzImage here,
Not a bzimage but ELF, optionally compressed/wrapped in bzimage.
> there's nothing to stop somebody for example putting a bare kernel
> there.
Yes, this is a possibility. You'd have to comile the options in it though.
> We'd like people to be able to set up PV-GRUB2 in their dom0s
> even for domUs that aren't new enough to have PV-GRUB2 inside them.
Yes, that's why I spoke about compatibility. But it's good that this
subject is explicitly discussed.
The main problem with this is security, as discussed in unprivileged
partition subthread. The best way is to replicate pvgrub1 behaviour for
such systems.
> Furthermore we'd like to be able to arrange that PV-GRUB (Legacy) and
> PyGRUB can at least in principle use the same boot protocol; in the case
> of PV-GRUB that would presumably involve a stub menu.lst, but it
> shouldn't take much more than that.
The legacy_configfile would need adjustments for that. PVGRUB1 used hdX
notation for virtual disks which legacy_configfile just maps to hdX.
This is a mess because even on runtime it's not obvious how disks are
mapped, it may even differ between pvgrub1 versions.
>  As such the file name in the domU's
> filesystem shouldn't be GRUB-specific, although per Vladimir it'd be
> good for it to be distinct for each architecture.
> 
Agreed. But if we save it, it should contain full xen device name,
partition specification (beware that partition numbering is ambiguous
and if you use partition number you have to specify how it's counted.
Otherwise you may opt to have some kind of static specification where to
locate the file. Using a special partition for this is an option and if
so, IMO, it's better to share it with EFI system partition.
> I'll put this patch series on hold for the time being (with the possible
> exception of "search --exclude", which I think has been uncontroversial
> so far and could perhaps be merged as a generally-useful gadget?)
I didn't review it for the reasons of clarifying intended usage. It has
problems, I'll answer in its thread.
> and
> write this up as a proper protocol document for inclusion in xen.git.
> Ian said he'd like to get this into Xen 4.4's documentation.  No changes
> to Xen code are required as far as I know.
>
Ok, could we be kept in the loop on the drafts? I'd hate to have to cope
with yet another ambiguous protocol specification.

signature.asc
Description: OpenPGP digital signature