public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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