[RFC] ARM VM System Sepcification

[Christoffer Dall]

On Sat, Mar 22, 2014 at 12:23:54PM +0000, Grant Likely wrote:
> On Fri, 21 Mar 2014 19:29:50 -0700, Christoffer Dall <christoffer.dall at linaro.org> 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 at canonical.com> 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 think we may have misunderstood each other a bit here, I didn't mean
anything in my statement above that contradicts what you say.

I am only saying that mandating what OSes do and don't do, once they've
been booted, is beyond the scope of this spec.

Portable VM images should absolutely boot with an empty set of variables
and I completely agree that the persistent variable storage is a
property of the VM.

> 
> 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.
> 
I agree with all of the above.

(For the record I wasn't proposing this text as something that should go
verbatim in the spec, but I may borrow from your wording here).

Thanks,
-Christoffer