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 <[email protected]> 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 >
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
