Why pflash rather than rom?

[SimonF]

Hi, I am looking to add virsh VM backups to my Snapshot plugin.

 

@jonp  @eschultz @ljm42there a reason why pflash is used over rom for the loader, Changing for windows 10 works, Windows 11 doesnt if using TPM.

 

<type arch='x86_64' machine='pc-i440fx-5.1'>hvm</type>
    <loader readonly='yes' type='rom'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/66df6809-0988-a5d7-f0cd-8b859f39c0dc_VARS-pure-efi.fd</nvram>

 

 

Change to rom allows virsh internal snapshots. Not looked at live snapshots as yet.

root@computenode:/usr/local/emhttp/plugins/snapshots# virsh list
 Id   Name                State
-----------------------------------
 6    Windows 10 test 5   running


root@computenode:/usr/local/emhttp/plugins/snapshots# virsh snapshot-list "Windows 10 test 5"
 Name   Creation Time   State
-------------------------------

root@computenode:/usr/local/emhttp/plugins/snapshots# virsh snapshot-create-as  --domain "Windows 10 test 5" -name test
error: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported

root@computenode:/usr/local/emhttp/plugins/snapshots# virsh snapshot-create-as  --domain "Windows 10 test 5" test
Domain snapshot test created

root@computenode:/usr/local/emhttp/plugins/snapshots# virsh snapshot-list "Windows 10 test 5"
 Name   Creation Time               State
---------------------------------------------
 test   2021-12-07 20:07:17 +0000   shutoff

 

I will look into external snapshots also.

Edited December 8, 2021 by SimonF

[arturovf]

related question... Is snapshots of Vm's with passed through PCIe devices supported?

 

In the past I was able to make snapshots with virt-manager (changing loader to rom), but recently I got an error related to PCIe devices when trying to do one

[scorcho99]

@SimonF Did you ever find any issues with this backdoor way of allowing UEFI VMs to internal snapshot? I gather it did not work with with TPM Windows 11 but I don't need that, just windows 10 and linux VMs. I don't expect it will save and restore the virtual bios settings (which I think was the main reason this was initially disabled, ugh) but I don't care much about those.

 

It is very frustrating that they didn't leave an override option for this.

[SimonF]

15 hours ago, scorcho99 said:

@SimonF Did you ever find any issues with this backdoor way of allowing UEFI VMs to internal snapshot? I gather it did not work with with TPM Windows 11 but I don't need that, just windows 10 and linux VMs. I don't expect it will save and restore the virtual bios settings (which I think was the main reason this was initially disabled, ugh) but I don't care much about those.

 

It is very frustrating that they didn't leave an override option for this.

Not looked at it any further at present, my main question was for adding VM snapshots to my plugin which I have not added as yet.

[ghost82]

Hi, this is a reply from Laszlo, one of the most important maintainers of the edk2 firmware.

Question:

>> My question is, what happens from a firmware initialisation perspective if >> edk2 is passed as a bios rom instead of as pflash?

 

Reply:

Quote

Sure.

The OvmfPkg/README file has a section called "OVMF Flash Layout". It
explains where / how the unified (OVMF.fd) image is mapped just under
4GB in guest-phys address space.

(1) If you map the unified image with -bios, all of that becomes ROM --
read-only memory.

(2) If you map the unified image with -pflash, all of that becomes
read-write MMIO.

(3) If you use the split images (OVMF_CODE.fd and a copy of
OVMF_VARS.fd), and map then as flash chips, then the top part
(OVMF_CODE.fd, consisting of SECFV and FVMAIN_COMPACT) becomes read-only
flash (MMIO), and the bottom part (copy of OVMF_VARS.fd, consisting of
FTW Spare, FTW Work, Event log, and NV store) becomes read-write flash
(MMIO).

(4) If you use -bios with OVMF_CODE.fd only, then the top part will be
ROM, and the bottom part will be "black hole" MMIO.

Option (4) is totally invalid.

Option (3) is the best solution and it is what everybody should use (the
virt stack / libvirt already uses that).

Option (2) is acceptable, but it's suboptimal from a firmware binary
update POV -- you cannot replace your binary without losing your variables.

Option (1) is the ancient relic that once (before qemu-1.6) used to be
the only option. When you use Xen, this is the only option still today.

OVMF contains detection code that tells apart case (1) from the set {
case (2), case (3) }. (Cases (2) and (3) in the latter set look
indistinguishable to the firmware, by design.) If pflash is detected,
then you get a UEFI variable service implementation that conforms to the
UEFI spec, and everything will work fine. If, however, case (1) is
detected, then OVMF switches to a kind of variable store "emulation", where:
- variables (even non-volatile variables) primarily live in RAM only,
- a file called \NvVars on the EFI System Partition (a FAT filesystem)
  contains a serialized image of the variables,
- when booting the VM, \NvVars is de-serialized into RAM,
- until the OS is launched, variable changes (initiated from the
  firmware), are synched out to \NvVars at once,
- after the OS is launched, variable changes remain only in memory,
- if you gracefully reboot the VM into the firmware, then OS-initiated
  variable changes are synched out to \NvVars,
- if you power down the VM from within the OS, you'll lose any
  OS-initiated variable changes
- Another limitation is that some kinds of variables cannot be
  serialized and de-serialized like this; in particular variables
  related to Secure Boot.

Unfortunately this detection logic is extremely prone to mis-use (and
esp. it was never meant to deal with case (4)) and to causing confusion.
For this reason, I have had patches for a long time now that allow the
user to compile "-bios" support out of OVMF, with a build flag
(-DMEM_VARSTORE_EMU_ENABLE=FALSE). Then you will simply become unable to
boot with "-bios" -- the firmware will just hang with a black screen.
(If you capture the debug log (see OvmfPkg/README), you'll know what's
up though.) Note that this would not be the default -- the default build
wouldn't change.

Firmware built like this is much better to use on QEMU (much less room
for error, and there are some firmware features that become possible --
the UEFI memmap will be de-fragmented over time, and the foundation for
S4 support, i.e., suspend to disk, is laid).

In particular if you build OVMF with -DSMM_REQUIRE, then "-bios" support
is *already* compiled out. (If you use OVMF on Xen, then your only
choice is option (1) (because Xen does not implement flash), so OVMF
binaries built with either -DSMM_REQUIRE, or my (proposed)
-DMEM_VARSTORE_EMU_ENABLE=FALSE flag, will not run on Xen.)

My work related to -DMEM_VARSTORE_EMU_ENABLE=FALSE can be seen in
<https://bugzilla.tianocore.org/show_bug.cgi?id=386>.

You might be curious why these patches aren't upstream (despite me
having run them on my end for more than a year now). Well, both times I
posted them, they were blocked for non-technical reasons that make zero
sense to me. They boil down to, "we shouldn't enable the user to build
an OVMF binary that cannot run on Xen; instead we should implement a
fake PEI-phase r/o variable service for Xen too, *even though* that
service could *never* report valid variable contents". Thus, I'm not
allowed to improve the situation on QEMU, even conditionally, without
working a bunch more on a shim for Xen that *would not work* anyway,
functionally speaking.

So there you have it. Just be sure to use flash, or -- even better --
use libvirt to start QEMU for you. That's what I do anyway (beyond using
my patches for TianoCore BZ#386, obviously).

We could perhaps ask Gerd to incorporate my patches, for TianoCore
BZ#386, into a new firmware image at kraxel.org/repos; then users
interested in this feature -- deterministic failure to boot with -bios,
and a defragmented UEFI memmap -- could switch to that new image.

Thanks
Laszlo

 

In particular, I think this is the reason:

If pflash is detected, then you get a UEFI variable service implementation that conforms to the UEFI spec, and everything will work fine. If, however, case (1) is detected, then OVMF switches to a kind of variable store "emulation"

 

So, just a matter of compatibility to be in conformity with uefi specifications.

[scorcho99]

Thanks @ghost82 that is kind of a headache to parse but I feel I understand the structure a bit better now.

 

I actually think based on reading this that provided the VM is off (nothing mapped to memory in that case) that there is no negative effect, provided I restore pflash before startup. (I actually never tried actually booting with the 'rom' value set. Maybe it works fine? It seems like an invalid, or at least not covered config based on the above) That is acceptable for my use anyway, I generally do all my snapshots with the VM off anyway to avoid the restores being in a crash state.

Edited November 18, 2022 by scorcho99