On Thu, 06 Mar 2014 10:46:22 +0100, Paolo Bonzini pbonzini@redhat.com wrote:
Il 06/03/2014 09:52, Robie Basak ha scritto:
On Sat, Mar 01, 2014 at 03:27:56PM +0000, Grant Likely wrote:
I would also reference section 3.3 (Boot Option Variables Default Boot Behavior) and 3.4.1.1 (Removable Media Boot Behavior) here. It's fine to restate the meaning of the requirement in this spec, but the UEFI spec is the authoritative source. Distributed VM disk images fall under the same scenario as the firmware not having any valid boot variables.
What happens when the VM is first booted without boot variables, but then the OS expects to be able to set boot variables and see them on next boot?
UEFI scans the devices; looks for an EFI system partition on the disks; and builds a default boot order.
If possible, I would prefer to mandate that the host implementation is permitted to no-op (or otherwise disable) boot variable write operations altogether to avoid having to deal with this. In the common case, I don't see why an OS installation shipped via a VM disk image would need to write boot variables anyway.
Would there be any adverse consequences to doing this?
Given the experience on x86 UEFI, no.
Unlike bare metal, it is common to run UEFI VMs without persistent flash storage. In this case the boot variables and boot order are rebuilt on the fly on every boot, and it just works for both Windows and Linux; there's no reason why it should be any different for ARM.
My reason is that this would save us from blocking a general OpenStack implementation on ARM by requiring that these pieces are implemented further up the stack first, when it would bring actual gain to doing so.
This would not preclude host implementations from implementing writeable variables, or guests from using them. Just that for a _portable VM disk image_, the OS on it cannot assume that this functionality is present.
This is already the case for most OSes. Otherwise you wouldn't be able to move a hard disk from a (physical) machine to another.
I strongly suggest that you take a look at the work done in Tiano Core's OvmfPkg, which has support for almost every QEMU feature thanks to the work of Laszlo Ersek and Jordan Justen.
In particular, OvmfPkg has support for specifying a boot order in the VM configuration (which maps to the "-boot" option in QEMU). In this case, the UEFI boot order is overridden by a variable that is placed in some architecture-specific firmware configuration mechanism (on x86 we have one called fw_cfg, on ARM you could look at the fdt). This predates UEFI and is not a UEFI variable; in fact is is a list of OpenFirmware device paths. UEFI will match the OF paths to UEFI paths, and use the result to build a UEFI boot order.
I don't know why we wouldn't want to make the UEFI variable the mechanism for exposing VM boot order to UEFI and the OS. I do completely agree that the boot order should be owned by the VM and be able to be manipulated from the config file and command line.
g.