> 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"? > 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. take care, Gerd
