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

[Garland Key]

I always appreciate when someone with the knowledge takes the time to
explain why a specific solution works - thank you, Laszlo.

On Fri, Apr 15, 2016 at 6:08 AM, Laszlo Ersek <lersek at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160415/3a5a3190/attachment.htm>