From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 25 Sep 2019 07:45:26 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B7333162916; Wed, 25 Sep 2019 14:45:26 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-25.rdu2.redhat.com [10.10.120.25]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0288510018F8; Wed, 25 Sep 2019 14:45:23 +0000 (UTC) Subject: Re: [edk2-devel] [RFC PATCH v2 04/44] OvmfPkg/ResetVector: Add support for a 32-bit SEV check To: "Lendacky, Thomas" , "devel@edk2.groups.io" Cc: Jordan Justen , Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , "Singh, Brijesh" References: <54ebf48fe05c20a1181a3dc90496e4835912ebf2.1568922728.git.thomas.lendacky@amd.com> <4dda0b6e-c464-ef55-2745-ad6beabb98b7@amd.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 25 Sep 2019 16:45:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4dda0b6e-c464-ef55-2745-ad6beabb98b7@amd.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 25 Sep 2019 14:45:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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