On 1/25/2022 3:42 PM, Gerd Hoffmann wrote:
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.
What kind if "hack"?
For example, several pflash codes require the support of read-only
memslot from KVM. We need to absolve it for TDX guest.
And the pflash won't work as a flash device that no write induced
KVM_EXIT_MMIO will go to its callback.
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.
Yep, Daniel (Cc'ed) tried (2) recently for SEV. Didn't work due to
differences in -bios and -pflash reset handling. So that option is
out I guess.
SEV uses (1), and there is some support code which you should be able to
reuse (walker for the list of guid-sections with meta-data in the ovmf
reset vector for example).
So TDX going for (1) too is probably the best option.
Yes. With option 1), it's friendly to user that no command change.
And also compatible for future TDX/TDVF when non-volatile variable is
supported.
Next version of this series will go with option 1). Let's wait and see
if the real implementation is acceptable or not.
take care,
Gerd
