> > 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. 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
