Re: [edk2-devel] [RFC PATCH v2 04/44] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

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

On 09/24/19 20:57, Lendacky, Thomas wrote:
> On 9/24/19 8:42 AM, Laszlo Ersek wrote:
>> On 09/19/19 21:52, Lendacky, Thomas wrote:

>>> +    mov       esp, SEV_TOP_OF_STACK
>>
>> (2) Can we %define SEV_TOP_OF_STACK in this file, or does it have to be
>> in "ResetVector.nasmb"?
> 
> It looks like it has to be in ResetVector.nasmb for some reason. If I move
> it into this file, it fails:
> 
> Ia32/PageTables64.asm:76: error: expecting `)'

Huh. Strange. Not a problem to lose sleep over, though.


>>> +SevEsIdtCommon:
>>> +    hlt
>>> +    jmp     SevEsIdtCommon
>>> +    iret
>>> +
>>> +SevEsIdtVmmComm:
>>> +    ;
>>> +    ; If we're here, then we are an SEV-ES guest and this
>>> +    ; was triggered by a CPUID instruction
>>> +    ;
>>> +    pop     ecx                     ; Error code
>>> +    cmp     ecx, 0x72               ; Be sure it was CPUID
>>> +    jne     SevEsIdtCommon
>>
>> (4) Can you steal the DebugLog / PrintStringSi code from
>> "OvmfPkg/QemuVideoDxe/VbeShim.asm", and print a simple message to the
>> QEMU debug port, whenever you jump to SevEsIdtCommon?
>>
>> This is basically an ASSERT(). It should have a message, if possible.
>> (I'm not sure if the OUT instruction will work with SEV-ES at this
>> stage, i.e. in 32-bit mode.)
> 
> Right, there isn't a way to share the OUT instruction information with
> the hypervisor at this point because we are running in 32-bit mode (this
> might be nice to add to the GHCB protocol, similar to the CPUID support,
> I'll have to think about that).
> 
> Since we can't output a message, I can do something along the line of
> using the GHCB protocol to request the hypervisor to terminate the guest.
> Would that be better?

I think that would be great; from publication#56421, it looks like the
guest can pass a (reason code set, reason code) pair along with the
termination request, and QEMU could display that.

We could assign reason code set 1 to QEMU (if a reason code set has not
been assigned yet), and then we could use different reason codes (in
code set 1) for the various SevEsIdtCommon jumps. (I don't think we need
to distinguish the exception vectors from each other -- as long as a
user can tell us that the guest died due to *some* exception, we can
write debug patches to tell those apart; we'll know where to start.)

Thanks!
Laszlo