[libvirt] [PATCH v1 3/3] qemu: Automatically create NVRAM store

[Laszlo Ersek]

On 08/08/14 14:05, Paolo Bonzini wrote:

> Il 08/08/2014 12:17, Michal Privoznik ha scritto:
>> When using split UEFI image, it may come handy if libvirt manages per
>> domain _VARS file automatically. While the _CODE file is RO and can
>> be shared among multiple domains, you certainly don't want to do that
>> on the _VARS file. This latter one needs to be per domain. So at the
>> domain startup process, if it's determined that domain needs _VARS
>> file it's copied from this master _VARS file. The location of the
>> master file is configurable in qemu.conf and the default path can be
>> compiled in via --with-qemu-nvram-file configure option.
>
> The only problem I see with this series is in this patch.
>
> The master _VARS file can be different for different machine types,
> for different architectures, and even for different _CODE files.

(I wasn't CC'd on the patch series, and I'm not a subscriber either, but
I now imported the set from the archive and hopefully can reply
in-thread.)

So, my suggestion was, for "src/qemu/qemu.conf":

# Locations of master nvram files
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# using this master file as image.
#
# Different firmware binaries can have different nvram templates;
# the following list specifies the mapping. Separate the
# nvram template from the firmware binary with a colon (":").
#
# nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]

Michal then asked if we should maybe even say:

nvram = [ "x86_64:/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
          "i686:/usr/share/OVMF32/OVMF_CODE.fd:/usr/share/OVMF32/OVMF_VARS.fd" ]

I don't think so. "x86_64:/usr/share/OVMF/OVMF_CODE.fd" does not carry
more information than just "/usr/share/OVMF/OVMF_CODE.fd".

The firmware binary itself determines the valid architectures and the
nvram template; there's no additional "degree of freedom" in that
selection. That is, we do NOT have:

  (guest architecture, firmware binary) --> nvram template

instead we have:

    firmware binary --> (
                           { set of valid architectures / machtypes },
                           nvram template
                        )

It is the user's responsibility to match architecture (machine type) and
firmware binary in the domain XML against each other.

- If they specify a firmware binary that is wrong for the architecture,
  the firmware simply won't run. (No different from trying to boot an OS
  that doesn't match the architecture.)

- If they specify the correct firmware binary, then it's *only* the
  firmware binary that libvirt needs to look at, in order to determine
  the nvram template.

Thanks,
Laszlo