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 <ler...@redhat.com> > Sent: Friday, April 9, 2021 9:33 PM > To: Xu, Min M <min.m...@intel.com> > Cc: devel@edk2.groups.io; thomas.lenda...@amd.com; j...@linux.ibm.com; > Brijesh Singh <brijesh.si...@amd.com>; Yao, Jiewen <jiewen....@intel.com>; > Justen, Jordan L <jordan.l.jus...@intel.com>; Ard Biesheuvel > <ardb+tianoc...@kernel.org>; Paolo Bonzini <pbonz...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#73905): https://edk2.groups.io/g/devel/message/73905 Mute This Topic: https://groups.io/mt/81584577/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
