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

["Laszlo Ersek" <lersek@redhat.com>]

On 04/08/21 15:31, Tom Lendacky wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:
>> On Wednesday, April 7, 2021 11:03 PM, Laszlo wrote:
>>> On 04/07/21 02:44, James Bottomley wrote:
>>>> On Wed, 2021-04-07 at 00:21 +0000, Xu, Min M wrote:
>>>>> Hi, Laszlo
>>>>>
>>>>> For Intel TDX supported guest, all processors start in 32-bit
>>>>> protected mode, while for Non-Td guest, it starts in 16-bit real
>>>>> mode. To make the ResetVector work on both Td-guest and Non-Td guest,
>>>>> ResetVector are updated as below:
>>>>> ------------------------------------------------------------------
>>>>>   ALIGN   16
>>>>>   resetVector:
>>>>>   ;
>>>>>   ; Reset Vector
>>>>>   ;
>>>>>   ; This is where the processor will begin execution
>>>>>   ;
>>>>>       nop
>>>>>       nop
>>>>>       smsw    ax
>>>>>       test    al, 1
>>>>>       jnz     EarlyBspPmEntry
>>>>>       jmp     EarlyBspInitReal16
>>>>
>>>> Well, then use the rel8 jump like the compiler would in this situation:
>>>>
>>>>       smsw    ax
>>>>       test    al, 1
>>>>       jz      1f
>>>>       jmp     EarlyBspPmEntry
>>>> 1:
>>>>       jmp     EarlyBspInitReal16
>>>>
>>>> So now both entries can be 32k away.
>>>
>>> The problem is that we need NASM to generate such *shared* entry code that
>>> behaves correctly when executed in either 16-bit or 32-bit mode.
>>>
>>> The rel8 near jumps ("short jumps") are like that -- for example, the
>>> "74 cb" opcode decodes to the same "JZ rel8" in both modes.
>>>
>>> But the rel16 ("non-short") near jumps turn into rel32 near jumps when
>>> decoded in 32-bit mode. For example, "E9 cw" decodes to "JMP rel16" in 16-bit
>>> mode, but it gets parsed as "E9 cd" (= "JMP rel32") in 32-bit mode.
>>>
>>> So the idea is to add more BITS directives, for covering the non-short near
>>> jumps themselves:
>>
>> 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.

I agree; we have an extensible approach in place already (with the
GUIDed struct list), and QEMU already knows about one magic GPA (for
locating the head of the list). Using one conditional rel8 jump, and two
non-conditional mode-specific (rel16/rel32) jumps, doesn't cost much in
the assembly code, it's compatible with future GUID additions, and
shouldn't affect QEMU's GUIDed struct list traversal.

Thanks
Laszlo