Hello all,
I have been tasked with the issue of UEFI NVRAM variable retention
with Xen HVM/OVMF based guests and wanted to consult the experts before
I undertake any significant coding effort. I am new to Xen so any
help/direction would be appreciated.
What I hope to gain from this RFC inquiry is the following:
1. Has there been any significant past discussion regarding this
issue? If so, can somebody kindly point me to these discussion(s) and/or
give me an overview of the findings?
2. Is there any current coding effort going on in this area?
3. Any suggestions or proposals on how to fix the issue including any
issues or caveats that I should be aware of?
Issue details:
In a nutshell, if a Xen guest which has been configured to use OVMF is
destroyed and re-created, the UEFI NVRAM variables are not retained.
This seems to be a well-known issue to which there is no resolution. The
issue seems to center around the fact that these Xen guests are not
configured to use a file-backed backing store for the NVRAM variables
(such as is commonly used with QEMU/KVM guests).
This issue can cause OVMF OS boot option(s) to be lost preventing the
ability to boot the OS after a guest is destroyed/re-created. It also
has implications on secure boot (which require NVRAM variables to be
retained).
Some key observations:
1. OVMF currently supports memory-mapped, file-backed 'pflash' devices
from Qemu. i.e. Qemu can map varstore files into memory for use by OVMF
via -drive parameters such as:
-drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd \
-drive if=pflash,format=raw,file=OVMF_VARS.fd
OVMF scans the flash device (i.e. the Non-volatile data storage FV)
for a mapped varstore and if found will use it store NVRAM variables
(via its QemuFlashFvbServicesRuntimeDxe driver)
This is outlined well in the OVMF whitepaper
(http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt)
2. When Xen HVM/OVMF guests are created, the qemu process that is
executed (from xl) does not contain these -drive arguments. Thus qemu
does not map a varstore for use by OVMF causing OVMF to fallback and use
a simple memory buffer for NVRAM variables (if I'm not mistaken here).
This causes the variables to not be retained across destroy/create
operations on the VM.
3. Unlike qemu/kvm guests where both OVMF and the varstore file are
loaded/mapped into memory and executed directly by qemu, Xen appears to
only use qemu as a "device model" and OVMF is not mapped/loaded directly
by qemu. Instead, under Xen, OVMF is loaded indirectly by hvmloader
(which is loaded by qemu). This could complicate the fix idea below.
Possible idea for fix:
Since OVMF currently has support for QEMU mapped varstore files, it
seems the most straightforward way to fix this issue would be for Xen
(i.e. xl) to pass a -drive argument to qemu to specify a varstore file
and to enhance the Xen memory init code in qemu (i.e.
xen_hvm.c:xen_[hvm|ram]_init()) to map this file into memory for use by
OVMF (possibly taking advantage of the already present qemu code to do
such a mapping (i.e. code out of pc_memory_init()). As mentioned above,
this would have to (somehow) be compatible with how OVMF is loaded
indirectly by hvmloader.
Any comments/suggestions/opinions/caveats on this approach?
Or any other suggested approaches on how to fix this issue?
Thank you very much!
-Aaron Young
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
