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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
