From: "Laszlo Ersek" <lersek@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, devel@edk2.groups.io
Cc: Brijesh Singh <brijesh.singh@amd.com>,
Michael D Kinney <michael.d.kinney@intel.com>,
Liming Gao <gaoliming@byosoft.com.cn>,
Zhiguang Liu <zhiguang.liu@intel.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Ard Biesheuvel <ard.biesheuvel@arm.com>
Subject: Re: [PATCH 1/9] OvmfPkg/VmgExitLib: Update ValidBitmap settings
Date: Thu, 15 Oct 2020 10:40:07 +0200 [thread overview]
Message-ID: <b4906e28-b729-bac2-1b6d-2a0b12ac4096@redhat.com> (raw)
In-Reply-To: <2f5fbbbe7183109a3ec28f17f0810032476ddbc3.1602346027.git.thomas.lendacky@amd.com>
Hi Tom,
On 10/10/20 18:06, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> 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 <michael.d.kinney@intel.com>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>
> Cc: Zhiguang Liu <zhiguang.liu@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Brijesh Singh <brijesh.singh@amd.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> 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
next prev parent reply other threads:[~2020-10-15 8:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-10 16:06 [PATCH 0/9] SEV-ES guest support fixes and cleanup Lendacky, Thomas
2020-10-10 16:06 ` [PATCH 1/9] OvmfPkg/VmgExitLib: Update ValidBitmap settings Lendacky, Thomas
2020-10-15 8:40 ` Laszlo Ersek [this message]
2020-10-15 13:37 ` Lendacky, Thomas
2020-10-10 16:07 ` [PATCH 2/9] OvmfPkg/VmgExitLib: Set the SW exit fields when performing VMGEXIT Lendacky, Thomas
2020-10-15 8:47 ` Laszlo Ersek
2020-10-15 8:50 ` Laszlo Ersek
2020-10-15 9:19 ` Laszlo Ersek
2020-10-15 14:10 ` Lendacky, Thomas
2020-10-15 14:33 ` Lendacky, Thomas
2020-10-15 16:26 ` Laszlo Ersek
2020-10-15 15:27 ` Lendacky, Thomas
2020-10-15 16:28 ` Laszlo Ersek
2020-10-10 16:07 ` [PATCH 3/9] OvmfPkg/VmgExitLib: Set the SwScratch valid bit for IOIO events Lendacky, Thomas
2020-10-15 8:47 ` Laszlo Ersek
2020-10-10 16:07 ` [PATCH 4/9] OvmfPkg/VmgExitLib: Set the SwScratch valid bit for MMIO events Lendacky, Thomas
2020-10-15 8:52 ` Laszlo Ersek
2020-10-10 16:07 ` [PATCH 5/9] UefiCpuPkg/MpInitLib: Set the SW exit fields when performing VMGEXIT Lendacky, Thomas
2020-10-12 5:11 ` Ni, Ray
2020-10-10 16:07 ` [PATCH 6/9] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Set the SwScratch valid bit Lendacky, Thomas
2020-10-15 9:25 ` Laszlo Ersek
2020-10-10 16:07 ` [PATCH 7/9] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix erase blocks for SEV-ES Lendacky, Thomas
2020-10-15 9:27 ` Laszlo Ersek
2020-10-10 16:07 ` [PATCH 8/9] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Disable interrupts when using GHCB Lendacky, Thomas
2020-10-15 9:45 ` Laszlo Ersek
2020-10-15 17:39 ` Lendacky, Thomas
2020-10-10 16:07 ` [PATCH 9/9] UefiCpuPkg/MpInitLib: For SEV-ES guest set stack based on processor number Lendacky, Thomas
2020-10-12 5:11 ` Ni, Ray
2020-10-15 9:49 ` Laszlo Ersek
2020-10-15 7:43 ` [PATCH 0/9] SEV-ES guest support fixes and cleanup Laszlo Ersek
2020-10-15 13:26 ` Lendacky, Thomas
2020-10-15 16:20 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4906e28-b729-bac2-1b6d-2a0b12ac4096@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox