Re: [Xen-devel] [RFC] ARM VM System Sepcification

[Grant Likely <grant.likely@xxxxxxxxxx>]

On Fri, 21 Mar 2014 19:29:50 -0700, Christoffer Dall 
<christoffer.dall@xxxxxxxxxx> wrote:
> On Fri, Mar 07, 2014 at 08:24:18PM +0800, Grant Likely wrote:
> > On Thu, 6 Mar 2014 12:04:50 +0000, Robie Basak <robie.basak@xxxxxxxxxxxxx> 
> > wrote:
> > > On Thu, Mar 06, 2014 at 12:44:57PM +0100, Laszlo Ersek wrote:
> > > > If I understand correctly, the question is this:
> > > > 
> > > >   Given a hypervisor that doesn't support non-volatile UEFI variables
> > > >   (including BootOrder and Boot####), is it possible to automatically
> > > >   boot a carefully prepared VM image, made available as a fixed media
> > > >   device?
> > > > 
> > > > The answer is "yes". See
> > > 
> > > Right, but I think there is a subsequent problem.
> > > 
> > > >   It is expected that this default boot will load an operating system or
> > > >   a maintenance utility. If this is an operating system setup program it
> > > >   is then responsible for setting the requisite environment variables
> > > >   for subsequent boots. The platform firmware may also decide to recover
> > >         ^^^^^^^^^^^^^^^^
> > > >   or set to a known set of boot options.
> > > 
> > > It seems to me that the guest OS is permitted to assume that persistent
> > > boot variables will work after first boot, for subsequent boots.
> > > 
> > > So, for example, the guest OS might, on bootloader or kernel upgrade,
> > > completely replace the boot mechanism, dropping the removable path and
> > > replacing it with a fixed disk arrangement, setting boot variables
> > > appropriately, and assume that it can reboot and everything will
> > > continue to work.
> > > 
> > > But if the host does not support non-volatile variables, then this will
> > > break.
> > 
> > Correct
> > 
> > > This is why I'm suggesting that the specification mandate that the guest
> > > OS shipped in a "portable disk image" as defined by the spec must not
> > > make this assumption.
> > 
> > Also correct... the installer must be aware of this constraint which is
> > why it is part of the draft spec.
> > 
> > > It's either this, or mandate that all hosts must support persistent
> > > variables. I have no objection to that in principle, but since we have
> > > no implementation currently, it seems easier to avoid this particular
> > > roadblock by tweaking the spec in a way that nobody seems to care about
> > > anyway.
> > 
> > Right. I guess my position is that if persistent storage is not
> > implemented then there are a number of install/upgrade scenarios that
> > won't work. Regardless, portable images must assume an empty boot list
> > and we can build that into the spec.
> > 
> 
> Sorry for the delay in responding - all sorts of unexpected things
> happened when I returned from LCA14.
> 
> I agree on the technical discussion going on here.  My conclusion is
> that we have two options:
> 
> 1. Simply mandate that VM implementations support persistent variables
>    for their UEFI implementation - with whatever constraints that may
>    put on higher level tools.
> 
> 2. Require that OSes shipped as part of compliant VM images make no
>    assumption that changes to the UEFI environment will be stored.
> 
> I feel that option number two will break in all sorts of cases, just
> like Grant stated above, and it is fundamentally not practical; if a
> distribution ships Linux with a UEFI stub that expects to be able to do
> something, distributions must modify Linux to conform to this spec.  I
> think imagining that this spec controls how UEFI support in Linux/Grub
> is done in general would be overreaching.  Additionally, Michael brought
> up the fact that it would be non-UEFI compliant.

That isn't actually my position. I absolutely think that VMs /should/
implement persistent variables, but the variables are a property of a VM
instance, not of the disk image. As far as this spec is concerned, I
think portable disk images should operate under the assumption of an
empty set of variables, and therefore follow the removable disk
requirements in the UEFI spec.

I would propose a modification to option 1:

VM implementations SHOULD to implement persistent variables for
their UEFI implementation - with whatever constraints that may be put on
higher level tools. Variable storage SHALL be a property of a VM
instance, but SHALL NOT be stored as part of a portable disk image.
Portable disk images SHALL conform to the UEFI removable disk
requirements from the UEFI spec.

g.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel