public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Lendacky, Thomas" <thomas.lendacky@amd.com>
To: Laszlo Ersek <lersek@redhat.com>, devel@edk2.groups.io
Cc: Brijesh Singh <brijesh.singh@amd.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@arm.com>
Subject: Re: [PATCH 2/9] OvmfPkg/VmgExitLib: Set the SW exit fields when performing VMGEXIT
Date: Thu, 15 Oct 2020 09:33:43 -0500	[thread overview]
Message-ID: <74720266-1b2a-8be1-2a3f-e0e9ee0e63ed@amd.com> (raw)
In-Reply-To: <b08f04fd-a9d0-209c-e7da-03c9db3ef972@amd.com>

On 10/15/20 9:10 AM, Tom Lendacky wrote:
> On 10/15/20 4:19 AM, Laszlo Ersek wrote:
>> On 10/15/20 10:50, Laszlo Ersek wrote:
>>> On 10/15/20 10:47, Laszlo Ersek wrote:
>>>> On 10/10/20 18:07, Tom Lendacky wrote:
>>>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>>>>
>>>>> All fields that are set in the GHCB should have their associated bit in
>>>>> the GHCB ValidBitmap field set. Add support to set the bits for the
>>>>> software exit information fields when performing a VMGEXIT (SwExitCode,
>>>>> SwExitInfo1, SwExitInfo2).
>>>>>
>>>>> Fixes: 61bacc0fa16f ("OvmfPkg/VmgExitLib: Implement library support 
>>>>> for VmgExitLib in OVMF")
>>>>> 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>
>>>>> ---
>>>>>   OvmfPkg/Library/VmgExitLib/VmgExitLib.c | 30 ++++++++++++++++++++
>>>>>   1 file changed, 30 insertions(+)
>>>>>
>>>>> diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitLib.c 
>>>>> b/OvmfPkg/Library/VmgExitLib/VmgExitLib.c
>>>>> index 53040cc6f649..6cf649c6101b 100644
>>>>> --- a/OvmfPkg/Library/VmgExitLib/VmgExitLib.c
>>>>> +++ b/OvmfPkg/Library/VmgExitLib/VmgExitLib.c
>>>>> @@ -78,6 +78,32 @@ VmgExitErrorCheck (
>>>>>     return Status;
>>>>>   }
>>>>> +/**
>>>>> +  Marks a field at the specified offset as valid in the GHCB.
>>>>> +
>>>>> +  The ValidBitmap area represents the areas of the GHCB that have 
>>>>> been marked
>>>>> +  valid. Set the area of the GHCB at the specified offset as valid.
>>>>> +
>>>>> +  @param[in, out] Ghcb    Pointer to the Guest-Hypervisor 
>>>>> Communication Block
>>>>> +  @param[in] Offset       Offset in the GHCB to mark valid
>>>>> +
>>>>> +**/
>>>>> +STATIC
>>>>> +VOID
>>>>> +GhcbSetOffsetValid (
>>>>> +  IN OUT GHCB               *Ghcb,
>>>>> +  IN     GHCB_QWORD_OFFSET  Offset
>>>>> +  )
>>>>> +{
>>>>> +  UINT32  OffsetIndex;
>>>>> +  UINT32  OffsetBit;
>>>>> +
>>>>> +  OffsetIndex = Offset / 8;
>>>>> +  OffsetBit   = Offset & 0x07;
>>>>
>>>> (1) I suggest improving the consistency of operators -- please either
>>>> use division and remainder ("Offset / 8" and "Offset % 8"), or bit shift
>>>> and masking ("Offset >> 3" and "Offset & 0x7")
>>>>
>>>> With that:
>>>>
>>>> Acked-by: Laszlo Ersek <lersek@redhat.com>
>>>
>>> ... I realize I didn't make the same comment for GhcbIsRegValid(), so
>>> I'm taking back the above -- consistency with GhcbIsRegValid() is more
>>> important. No change needed here.
>>>
>>> Acked-by: Laszlo Ersek <lersek@redhat.com>
>>
>> Wow, I'm needing *a lot* of time for getting back into this. Sorry about
>> that. :/
>>
>> So, as I'm slowly grasping the idea behind this series (--> wherever we
>> make a VmgExit() call, having populated some fields in the GHCB, make
>> sure the "valid bitmap" is set correctly too), it's becoming clear that
>> we need a new "VmgExitLib.h" API.
>>
>> Because, (a) VmgExit() is declared in that lib class header anyway, and
>> the new helper function effectively helps us set up the (thick)
>> parameters for that call, (b) at the end of this v1 series, we have the
>> "valid bitmap" setting logic triplicated (not counting the assembly code
>> logic in patch #5):
>>
>> - GhcbSetRegValid() -- existent function in
>> "OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c"
>>
>> - GhcbSetOffsetValid() -- function basically identical to
>> GhcbSetRegValid(), added in this patch to
>> "OvmfPkg/Library/VmgExitLib/VmgExitLib.c". (This means that the same
>> library instance will have two copies of the same logic.)
>>
>> - QemuFlashPtrWrite() -- from patch #6
>>
>> So I think we should first replace the GhcbSetRegValid() function with a
>> public (UefiCpuPkg VmgExitLib) API called VmgSetOffsetValid(). This
>> would likely take two patches -- first patch, introduce the API and add
>> the VmgExitLibNull implementation under UefiCpuPkg; second patch, add
>> the real implementation, replacing GhcbSetRegValid(), under OvmfPkg.
>> Then, in the rest of the series, call VmgSetOffsetValid() wherever
>> needed (in C code, of course; in assembly, the open-coded stuff is OK I
>> guess).
> 
> Yup, I was toying with the idea of adding a new function to the library, 
> too. I'll do that, using the approach you outlined.

Also, I'll add an interface, VmgIsOffsetValid(), so that all the 
ValidBitmap manipulation and examination is contained in the library. I'll 
replace the GhcbIsRegValid() implementation with calls to this interface.

Thanks,
Tom

> 
> Thanks,
> Tom
> 
>>
>> Thanks,
>> Laszlo
>>

  reply	other threads:[~2020-10-15 14:33 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
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 [this message]
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=74720266-1b2a-8be1-2a3f-e0e9ee0e63ed@amd.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