* Laszlo Ersek (ler...@redhat.com) wrote: > On 06/07/18 12:54, Andrea Bolognani wrote: > > On Thu, 2018-06-07 at 11:36 +0100, Daniel P. Berrangé wrote: > >> On Thu, Jun 07, 2018 at 11:32:18AM +0100, Richard W.M. Jones wrote: > >>> Another problem which Laszlo mentioned is the varstore isn't portable > >>> between UEFI implementations, or if the UEFI is compiled with > >>> different options. You can even imagine shipping multiple > >>> varstores(!) which argues for a tar-like format. > >> > >> Could we perhaps imagine shipping the actual UEFI bios, rather > >> than only the varstore. The bios blob runs in guest context, > >> so there shouldn't be able security concerns from hosting > >> vendors with running user provided bios. Mostly its a matter > >> of confidence that the interface between bios & qemu is stable > >> which feels easier than assuming varstore vs different bios is > >> portable. > > > > That sounds sensible, and further reinforces the idea that we > > need way more than a single string baked into the qcow2 file. > > > > Sorry for arriving late (thanks Rich for the Fwd). > > The contents of the non-volatile UEFI variables should be considered > part of (permanent) guest state, such as disk contents. Therefore I'd > argue for bundling the varstore file with the disk image(s). > > In turn, the best way to ensure comaptibility between varstore and > firmware binary is to just bundle the firmware binary as well. It's > generally not large (x86) or if it is, it compresses extremely well > (aarch64). For extra politeness, image providers can bundle a text file > with their firmware build options (like a kernel config), possibly even > a JSON document conforming to the new firmware schema (qemu commit > 3a0adfc9bfcf), but that's not a hard requirement I guess. > > If such a VM is to be migrated between hosts, I'd expect the host admin > to take care of installing the fw binary on all eligible hosts.
There's no way they can do that if they're just importing VMs from templates that include the image; who is going to keep track of which BIOSs are needed where? Dave > Regarding compat between QEMU and firmware binary, I see three cases: > > (1) Static requirements presented by the firmware for the QEMU > configuration. (Such as -D SMM_REQUIRE.) With the domain configuration > captured one way or another alongside the disk image anyway, this should > not be a problem. > > (2) New firmware launched on old QEMU. The firmware generally detects or > negotiates features with QEMU, so this should be safe. > > (Discounting firmware regressions, of course -- for example, search > <https://www.mail-archive.com/qemu-devel@nongnu.org/msg471901.html> for > the string "I messed up".) > > (3) Old firmware launched on new QEMU. This scenario has given us a lot > more grief than (2), but I think for the appliance distribution use > case, it can be folded into case (1) above -- specify the machine type > too in the domain config, and that should be compatible with the old > firmware. > > (The handling of (3) is not uniform between upstream QEMU and various > downstreams. For example, consider > <https://bugs.launchpad.net/qemu/+bug/1715700>. This was a latent bug in > OVMF that got exposed by a new QEMU (due to a valid QEMU change), even > when using old machine types. The upstream solution was to fix edk2 and > stick with QEMU as-was (although the agreement around that hadn't been > universal). Conversely, one downstream solution was to restrict the > otherwise valid QEMU change to new machine types > <https://bugzilla.redhat.com/show_bug.cgi?id=1489800#c5>.) > > > All in all I agree with Daniel's proposal; it seems to be the most > robust one. > > And, I too recall that, under AMD SEV, users will be supposed to, or > allowed to, provide their own firmware binaries. > > Thanks! > Laszlo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK