[edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

James Bottomley jejb at linux.ibm.com
Wed Jun 9 14:28:05 UTC 2021

On Wed, 2021-06-09 at 02:01 +0000, Xu, Min M wrote:
> On 06/09/2021 12:01 AM, James Bottomley wrote:
> > On slide 19, the mucking with the reset vector really worries me
> > because we don't have that much space to play with.  Given that
> > you're starting in 32 bit mode and can thus enter anywhere in the
> > lower 4GB, why not simply use a different and TDX specific entry
> > point?
> > 
> If TDVF has a separate DSF/FDF, this is not a problem.
> I once think about below solution, that different mode goes to its
> specific entry point.
> For example:
>     real-mode goes to 0xfffffff0, 
>     protected-mode goes to 0xffffffe0, 
>     long-mode goes to 0xffffffd0. 

That would cut across the ApEntrypoint and the guidedStructureEnd. 
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code.  That means we can do
guid based entries that contain the 32 bit real and 64 bit entry
points.  This would also come with the added advantage that we can scan
the OVMF binary to see what entry points it supports.


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

More information about the edk2-devel-archive mailing list