[edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

[Laszlo Ersek]

On 04/07/21 15:22, Laszlo Ersek wrote:
> On 04/07/21 02:21, Xu, Min M wrote:
> 
>> Intel TDX also has metadata which is consumed by QEMU. We put the metadata
>> in a single file (TdxMetadata.asm) and put it at the end of ResetVectorVtf0.
>> Then a pointer is placed in a known location in ResetVector.nasm. In this way
>> QEMU can easily read the Metadata by the pointer.
>> ------------------------------------------------------------------
>> ALIGN   8
>> ;
>> ; TDX Virtual Firmware injects metadata in VTF0.
>> ; The address of the metadata is injected in this location (0xffffffe8)
>> ;
>>     DD      (OVMF_IMAGE_SIZE_IN_KB * 1024 - (fourGigabytes - TdxMetadataGuid - 16))
>> ;
>> ; The VTF signature
>> ;
>> ; VTF-0 means that the VTF (Volume Top File) code does not require
>> ; any fixups.
>> ;
>> vtfSignature:
>>     DB      'V', 'T', 'F', 0
>> ------------------------------------------------------------------
>>
>> The space in ResetVector is very precious and we all want a known location so that QEMU
>> can find the metadata easily. Putting the metadata in a single file give the developers
>> more flexible (They can put anything they want). So I think a pointer (point to a metadata
>> file) in a known location maybe a better solution.
> 
> Assuming a QEMU version has been released that looks for the chain of
> GUID-ed structs already, then I think such a change would break
> compatibility with that QEMU version.
> 
> If we definitely need a separate spot to include more information in the
> flash, for QEMU's parsing, then please introduce a new GUIDed structure,
> which contains nothing but a pointer to that spot.

Ah, upon re-reading James's earlier message which he just referenced,
namely at

https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg01063.html

it's clear that James had already proposed this:

> That's not to say we can't have a larger table ... we definitely can,
> but it can't be where it is now.  we'd have to do something different
> like make the table guid describe where the actual table is located
> (as a 32 bit offset and length) so as not to break up the 16 bit jump
> code.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73781): https://edk2.groups.io/g/devel/message/73781
Mute This Topic: https://groups.io/mt/81584577/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-