On 1/10/2022 7:01 PM, Gerd Hoffmann wrote:
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".
Gerd and Laszlo,
First, thank you for your patient explanation of how pflash works in
QEMU and the clarification of usage of pflash with OVMF.
Below I want to share current situation of loading TDVF.
Restrictions from TDX architecture:
- Current TDX doesn't support read-only memory, i.e., cannot trap write.
- Current TDVF spec states that "In order to simplify the design, TDVF
does not support non-volatile variables" in chapter 8.3.3
Regarding what interface should be used to load TDVF, there are three
options:
1) pflash: the same as how we load OVMF.
Suppose TDVF support will finally get into OVMF, using this
interface, it's full compatible with normal VMs. No change required
to QEMU command line and TDVF binary is mapped to the GPA address
right below 4G, but they are actually mapped as RAM.
Of course, we need several hacks (special handling) in QEMU.
Of course, they don't work as flash, the change made to it doesn't
persist.
2) -bios
exploit "-bios" parameter to load TDVF. But again, read-only is not
supported. TDVF is mapped as RAM.
3) generic loader
Just like what this series does. Implement specific parser in generic
loader to load and parse TDVF as private RAM.
I'm nor sure if 1) is acceptable from your side. If not, we will go with
option 3, since 2) doesn't make too much sense.
