[vfio-users] UEFI & virt-manager on Arch

[Laszlo Ersek]

On 04/15/16 10:45, Philip Abernethy wrote:
> I'm using extra/ovmf on my machine and just had to add
>
> nvram = [
>    "/usr/share/ovmf/ovmf_x64.bin:/usr/share/ovmf/ovmf_x64.bin"
> ]

Ouch. That hurt. A lot.

- Elements in the nvram list are pairs.

- Each pair has a first component, and a second component.

- The first component is a firmware binary.

- The second component is a variable store template that is compatible
  with the firmware binary in the first component.

- When you create a new virtual machine with libvirt, you specify the
  firmware binary that you want to use. This is a selection from the
  first column.

- Libvirt will map your selection to the second component (the varstore
  template that is compatible with the firmware binary that you
  selected).

- For the new VM, it will create a copy of that varstore template.

- This copy is called the VM's own private variable store. Generally, it
  lives under /var/lib/libvirt/qemu/nvram/.

- The VM will use the firmware binary (= first component) directly.

- The VM will never use the varstore template (= second component). It
  will use its own private varstore, which came into existence as a copy
  of the varstore template (= second component).

- When you upgrade your OVMF package, the VM will pick up the upgraded
  firmware binary the next time it is shut down and relaunched. The VM's
  private varstore will not be affected by the package upgrade in any
  way. That's the *entire point* of the split files scheme.

For example, on my laptop, I have

  nvram = [
    "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
    "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",
    "/home/virt-images/OVMF_CODE.32.fd:/home/virt-images/OVMF_VARS.fd",
    "/home/virt-images/OVMF_CODE.3264.fd:/home/virt-images/OVMF_VARS.fd",
    "/home/virt-images/OVMF_CODE.fd:/home/virt-images/OVMF_VARS.fd",
    "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd",
    "/usr/share/AAVMF/AAVMF_CODE.verbose.fd:/usr/share/AAVMF/AAVMF_VARS.fd"
  ]

* If I pick the

    /home/virt-images/OVMF_CODE.3264.fd

  firmware binary (which is the first component of the 4th element),
  then libvirt will map it to the

    /home/virt-images/OVMF_VARS.fd

  variable store template (which is the second component of the 4th
  element). Then the new VM's own varstore will be created as a copy of

    /home/virt-images/OVMF_VARS.fd

* If I pick

    /usr/share/AAVMF/AAVMF_CODE.verbose.fd

  (1st component of the 7th element) then libvirt will map it to the

    /usr/share/AAVMF/AAVMF_VARS.fd

  varstore template (2nd component of the 7th element). The new VM's own
  varstore will be then created as a copy of this latter file.

* Assuming that on an ArchLinux host, you have the following two files:

    /usr/share/ovmf/x64/ovmf_code_x64.bin -- firmware binary
    /usr/share/ovmf/x64/ovmf_vars_x64.bin -- varstore template that is
                                             compatible with the above

  Your nvram list should look like:

    nvram = [
      "/usr/share/ovmf/x64/ovmf_code_x64.bin:/usr/share/ovmf/x64/ovmf_vars_x64.bin"
    ]

* If you use Gerd's "edk2.git-ovmf-x64" package, then:

    nvram = [
      "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd"
      "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-need-smm.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-need-smm.fd"
      "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-with-csm.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-with-csm.fd"
    ]

  and when you create a new VM, you should pick the first one:

    /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd

  unless you have specific reasons for picking the second or the third.

Laszlo