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

[Laszlo Ersek]

Hi Min,

On 04/08/21 15:31, Lendacky, Thomas wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:

>> Yes this is the root cause. TDX requires the startup mode to be 32-bit
>> protected mode while the legacy VM startup mode is 16-bit real mode.
>> Add more BITS directives can work round this. I have tried it and it works.
>>
>> So my initial solution is to use *jmp rel8* because it works in both 16-bit
>> and 32-bit mode. But *jmp rel8* depends on the distance which should
>> be less than 128 bytes. If more metadata is added in the ResetVector.asm
>> then we have to use the BITS solution. 
> 
> To me, it sounds like the BITS solution should be the approach you use
> from the start.

BTW, have you considered using a separate ResetVector module for TDX?
That would obviate this multi-mode trickery. (Most recently raised by
Paolo.)

I think TDX will need a separate platform DSC / FDF / fw binary anyway.
I realize that's not a done deal yet; it may depend on who provides the
firmware binary (guest owner or cloud owner) -- of course the guest
owner will have to perform the attestation in either case, but the
"provenance" question remains open, IIUC.

And even if TDX gets its own firmware platform, it's a separate question
whether the ResetVector module itself should be split. I'm inclined to
think a separation at that level would make development and maintenance
easier.

(FWIW, Xen PVH has its own reset vector module, in OvmfPkg/XenResetVector.)

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73903): https://edk2.groups.io/g/devel/message/73903
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]
-=-=-=-=-=-=-=-=-=-=-=-