Re: [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support

["Lendacky, Thomas via groups.io" <thomas.lendacky=amd.com@groups.io>]

On 1/29/24 06:59, Gerd Hoffmann wrote:
> On Fri, Jan 26, 2024 at 04:13:00PM -0600, Tom Lendacky wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> In preparation for running under an SVSM at VMPL1 or higher (higher
>> numerically, lower privilege), re-organize the way a page state change
>> is performed in order to free up the GHCB for use by the SVSM support.
>>
>> Currently, the page state change logic directly uses the GHCB shared
>> buffer to build the page state change structures. However, this will be
>> in conflict with the use of the GHCB should an SVSM call be required.
>>
>> Instead, use a separate buffer (an area in the workarea during SEC and
>> an allocated page during PEI/DXE) to hold the page state change request
>> and only update the GHCB shared buffer as needed.
> 
> So the idea is that the lowlevel code takes the "page state change
> request", then either writes the request to the GHCB when running in
> vmpl == 0 (this patch), or submits a SVSM call when running in
> vmpl > 0 (somewhere later in this series I guess)?

Right, when VMPL == 0:
   - a1: PVALIDATE directly issued (if making shared)
   - b1: Page State Change via GHCB call
   - c1: PVALIDATE directly issued (if making private)

when VMPL != 0:
   - a2: PVALIDATE via SVSM via GHCB call (if making shared)
   - b2: Page State Change via GHCB call
   - c2: PVALIDATE via SVSM via GHCB call (if making private)

With an SVSM, there is a need to build the PVALIDATE call in the Calling 
Area (CA) and invoke the SVSM via GHCB call. We can't rely on the GHCB
shared buffer area remaining untouched between a2 and b2 (though it likely 
would), so a common structure is created that can be used to build the 
entities in both the SVSM Calling Area (a2) and the GHCB shared buffer (b2).

> 
>> Since the information is copied to, and operated on, in the GHCB shared
>> buffer this has the added benefit of not requiring to save the start and
>> end entries for use when validating the memory during the page state
>> change sequence.
> 
> The patch is pretty large, I'm not sure it is possible to make it much
> smaller though.

Yes, let me see if it is possible to split this up into a smaller set of 
patches.

Thanks,
Tom

> 
>> -  i           = 0;
>> +  Index       = 0;
> 
> That rename can be splitted.  Will be a rather small chunk though.
> 
> take care,
>    Gerd
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114716): https://edk2.groups.io/g/devel/message/114716
Mute This Topic: https://groups.io/mt/103986437/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-