On 1/10/2022 7:01 PM, Gerd Hoffmann wrote:
If you go without pflash, then you likely will not have a
standards-conformant UEFI variable store. (Unless you reimplement the
variable arch protocols in edk2 on top of something else than the Fault
Tolerant Write and Firmware Volume Block protocols.) Whether a
conformant UEFI varstore matters to you (or to TDX in general) is
something I can't comment on.
Thanks for your reply! Laszlo
regarding "standards-conformant UEFI variable store", I guess you mean the
change to UEFI non-volatile variables needs to be synced back to the
OVMF_VARS.fd file. right?
Yes. UEFI variables are expected to be persistent, and syncing to
OVMF_VARS.fd handles that.
Further question.
Is it achieved via read-only memslot that when UEFI variable gets
changed, it exits to QEMU with KVM_EXIT_MMIO due to read-only memslot so
QEMU can sync the change to OVMF_VAR.fd?
Not fully sure whenever that expectation holds up in the CC world. At
least the AmdSev variant has just OVMF.fd, i.e. no CODE/VARS split.
Regarding pflash itself, the read-only KVM memslot is required for it.
Otherwise pflash cannot work as a "ROMD device" (= you can't flip it
back and forth between ROM mode and programming (MMIO) mode).
We don't need Read-only mode for TDVF so far. If for this purpose, is it
acceptable that allowing a pflash without KVM readonly memslot support if
read-only is not required for the specific pflash device?
In case you don't want/need persistent VARS (which strictly speaking is
a UEFI spec violation) you should be able to go for a simple "-bios
OVMF.fd".
take care,
Gerd
