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

["Yao, Jiewen" <jiewen.yao@intel.com>]

Hi Laszlo
Thanks.

We did provide a separate binary in the beginning - see https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy to maintain and develop. A clean solution, definitely.

However, we got requirement to deliver one binary solution together with 1) normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
Now, we are struggling to merge them......

For DXE, we hope to isolate TDX driver whenever it is possible.
But we only have one reset vector here. Sigh...



> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Friday, April 9, 2021 9:33 PM
> To: Xu, Min M <min.m.xu@intel.com>
> Cc: devel@edk2.groups.io; thomas.lendacky@amd.com; jejb@linux.ibm.com;
> Brijesh Singh <brijesh.singh@amd.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> Justen, Jordan L <jordan.l.justen@intel.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Paolo Bonzini <pbonzini@redhat.com>
> Subject: Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and
> Cpuid page for the SEV-SNP guest
> 
> 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