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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#48035): https://edk2.groups.io/g/devel/message/48035 Mute This Topic: https://groups.io/mt/34203539/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
