From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web12.7858.1602751219319631975 for ; Thu, 15 Oct 2020 01:40:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NtVPMgFE; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602751218; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NcEt5BlRXEP26Nyg9jaPszJH35R0IMeS93C6Vwu2M24=; b=NtVPMgFEQzcYNkdC12JWuya7L8cKkoFqPpmuRlvHRvZ9XdoaOFGZ4sByj6PXsKAyg1mGca wKQZGjkgRkrBn/PYtohvnokWX/0Jld1+cbKIhhKrdIP9R3nkNz3gqvPUen8r21HDizZmNP +2e3Rk0dQUGrQV1QjtTyibZRfbLtNoE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-100--IWhCOaGMquBpKYiIgaccQ-1; Thu, 15 Oct 2020 04:40:12 -0400 X-MC-Unique: -IWhCOaGMquBpKYiIgaccQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8776C1018F7C; Thu, 15 Oct 2020 08:40:10 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-119.ams2.redhat.com [10.36.113.119]) by smtp.corp.redhat.com (Postfix) with ESMTP id 543636EF68; Thu, 15 Oct 2020 08:40:08 +0000 (UTC) Subject: Re: [PATCH 1/9] OvmfPkg/VmgExitLib: Update ValidBitmap settings To: Tom Lendacky , devel@edk2.groups.io Cc: Brijesh Singh , Michael D Kinney , Liming Gao , Zhiguang Liu , Jordan Justen , Ard Biesheuvel References: <2f5fbbbe7183109a3ec28f17f0810032476ddbc3.1602346027.git.thomas.lendacky@amd.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 15 Oct 2020 10:40:07 +0200 MIME-Version: 1.0 In-Reply-To: <2f5fbbbe7183109a3ec28f17f0810032476ddbc3.1602346027.git.thomas.lendacky@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Tom, On 10/10/20 18:06, Tom Lendacky wrote: > From: Tom Lendacky > > Use OFFSET_OF () and sizeof () to calculate the GHCB register field > offsets instead of hardcoding the values in the GHCB_REGISTER enum. > Rename GHCB_REGISTER to GHCB_QWORD_OFFSET to more appropriately describe > the enum. While redefing the values, only include (and add) fields that > are used per the GHCB specification. > > Also, remove the DR7 field from the GHCB_SAVE_AREA structure since it is > not used/defined in the GHCB specification and then rename the reserved > fields as appropriate. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Zhiguang Liu > Cc: Jordan Justen > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Tom Lendacky > Cc: Brijesh Singh > Signed-off-by: Tom Lendacky > --- > MdePkg/Include/Register/Amd/Ghcb.h | 48 ++++++++------------ > OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 4 +- > 2 files changed, 20 insertions(+), 32 deletions(-) This patch modifies both MdePkg and OvmfPkg. I agree that, as an exception, this is the right thing to do. That's because we are not changing the identifiers of the enumeration constants (such as GhcbCpl). Because those identifiers are declared at file scope, having both GHCB_REGISTER and GHCB_QWORD_OFFSET declare (e.g.) GhcbCpl would cause a compilation failure. Therefore we can't implement this in multiple stages (first introduce GHCB_QWORD_OFFSET, then remove GHCB_REGISTER separately). (1) However, the subject line doesn't look correct. It should mention both MdePkg and OvmfPkg. Also, we're not updating ValidBitmap settings just yet. I suggest: MdePkg, OvmfPkg: clean up GHCB field offsets and save area > > diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h > index 54a80da0f6d7..33c7e8939a28 100644 > --- a/MdePkg/Include/Register/Amd/Ghcb.h > +++ b/MdePkg/Include/Register/Amd/Ghcb.h > @@ -82,50 +82,25 @@ > #define IOIO_SEG_DS (BIT11 | BIT10) > > > -typedef enum { > - GhcbCpl = 25, > - GhcbRflags = 46, > - GhcbRip, > - GhcbRsp = 59, > - GhcbRax = 63, > - GhcbRcx = 97, > - GhcbRdx, > - GhcbRbx, > - GhcbRbp = 101, > - GhcbRsi, > - GhcbRdi, > - GhcbR8, > - GhcbR9, > - GhcbR10, > - GhcbR11, > - GhcbR12, > - GhcbR13, > - GhcbR14, > - GhcbR15, > - GhcbXCr0 = 125, > -} GHCB_REGISTER; > - > typedef PACKED struct { > UINT8 Reserved1[203]; > UINT8 Cpl; > - UINT8 Reserved2[148]; > - UINT64 Dr7; > - UINT8 Reserved3[144]; > + UINT8 Reserved2[300]; > UINT64 Rax; > - UINT8 Reserved4[264]; > + UINT8 Reserved3[264]; > UINT64 Rcx; > UINT64 Rdx; > UINT64 Rbx; > - UINT8 Reserved5[112]; > + UINT8 Reserved4[112]; > UINT64 SwExitCode; > UINT64 SwExitInfo1; > UINT64 SwExitInfo2; > UINT64 SwScratch; > - UINT8 Reserved6[56]; > + UINT8 Reserved5[56]; > UINT64 XCr0; > UINT8 ValidBitmap[16]; > UINT64 X87StateGpa; > - UINT8 Reserved7[1016]; > + UINT8 Reserved6[1016]; > } GHCB_SAVE_AREA; (2) The meaning of a field called "ReservedN" must never change (it must describe the same offset range in the structure, after introduction). If we need to change the structure incompatibly, then please remove the old ReservedN field name altogether. If a new reserved field has to be introduced, in addition, then please find the largest N used with Reserved fields in the structure currently, and use (N+1) in the name of the new field. This practice makes sure that any (out of tree) code that refers to a ReservedN field in MdePkg will cleanly break during compilation after this change. Changing the meaning of a ReservedN field could otherwise cause misbehavior that could be harder to track down. I realize this is somewhat unusual -- after all, if someone deliberately accessed a field called "Reserved", any subsequent breakage is *their* fault. However, the reason for this practice is that sometimes MdePkg headers lag behind industry specs (meaning, non-UEFI specs), but drivers or libs (outside of MdePkg or even edk2) already need to refer to newly-specified fields. Even edk2 used to have code similar to the example Reserved3[12] = 1; Normally I don't advocate accommodating out-of-tree code, but following this ReservedN scheme isn't hard. > > typedef PACKED struct { > @@ -136,6 +111,19 @@ typedef PACKED struct { > UINT32 GhcbUsage; > } GHCB; > > +typedef enum { > + GhcbCpl = OFFSET_OF (GHCB, SaveArea.Cpl) / sizeof (UINT64), > + GhcbRax = OFFSET_OF (GHCB, SaveArea.Rax) / sizeof (UINT64), > + GhcbRbx = OFFSET_OF (GHCB, SaveArea.Rbx) / sizeof (UINT64), > + GhcbRcx = OFFSET_OF (GHCB, SaveArea.Rcx) / sizeof (UINT64), > + GhcbRdx = OFFSET_OF (GHCB, SaveArea.Rdx) / sizeof (UINT64), > + GhcbXCr0 = OFFSET_OF (GHCB, SaveArea.XCr0) / sizeof (UINT64), > + GhcbSwExitCode = OFFSET_OF (GHCB, SaveArea.SwExitCode) / sizeof (UINT64), > + GhcbSwExitInfo1 = OFFSET_OF (GHCB, SaveArea.SwExitInfo1) / sizeof (UINT64), > + GhcbSwExitInfo2 = OFFSET_OF (GHCB, SaveArea.SwExitInfo2) / sizeof (UINT64), > + GhcbSwScratch = OFFSET_OF (GHCB, SaveArea.SwScratch) / sizeof (UINT64), > +} GHCB_QWORD_OFFSET; > + > typedef union { > struct { > UINT32 Lower32Bits; > diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c > index 8e42b305e83c..c5484a3f478c 100644 > --- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c > +++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c > @@ -153,7 +153,7 @@ STATIC > BOOLEAN > GhcbIsRegValid ( > IN GHCB *Ghcb, > - IN GHCB_REGISTER Reg > + IN GHCB_QWORD_OFFSET Reg > ) > { > UINT32 RegIndex; > @@ -179,7 +179,7 @@ STATIC > VOID > GhcbSetRegValid ( > IN OUT GHCB *Ghcb, > - IN GHCB_REGISTER Reg > + IN GHCB_QWORD_OFFSET Reg > ) > { > UINT32 RegIndex; > Thanks, Laszlo