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? AIUI, we don't have an implementation of this right now, and even if we did, there are implications for persistent storage of this data further up the stack (a required implementation in libvirt, OpenStack nova providing a storage area for it, etc). 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? 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.
Attachment:
signature.asc
Description: Digital signature
