Re: [RFC PATCH v2 20/44] i386/tdx: Parse tdx metadata and store the result into TdxGuestState

[Xiaoyao Li]

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