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

["James Bottomley" <jejb@linux.ibm.com>]

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.

James