* [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 12:59 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 02/16] MdePkg/Register/Amd: Define the SVSM related information Lendacky, Thomas via groups.io
` (15 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
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.
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.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
MdePkg/Include/Register/Amd/Ghcb.h | 9 +-
OvmfPkg/Include/WorkArea.h | 7 +
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h | 4 +-
OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 16 ++-
OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c | 25 +++-
OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c | 20 ++-
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c | 14 +-
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c | 151 +++++++++++++-------
8 files changed, 183 insertions(+), 63 deletions(-)
diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
index dab396f3ede8..29b2e45d0163 100644
--- a/MdePkg/Include/Register/Amd/Ghcb.h
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -4,7 +4,7 @@
Provides data types allowing an SEV-ES guest to interact with the hypervisor
using the GHCB protocol.
- Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@par Specification Reference:
@@ -195,13 +195,14 @@ typedef struct {
UINT32 Reserved;
} SNP_PAGE_STATE_HEADER;
-#define SNP_PAGE_STATE_MAX_ENTRY 253
-
typedef struct {
SNP_PAGE_STATE_HEADER Header;
- SNP_PAGE_STATE_ENTRY Entry[SNP_PAGE_STATE_MAX_ENTRY];
+ SNP_PAGE_STATE_ENTRY Entry[];
} SNP_PAGE_STATE_CHANGE_INFO;
+#define SNP_PAGE_STATE_MAX_ENTRY \
+ ((sizeof (((GHCB *)0)->SharedBuffer) - sizeof (SNP_PAGE_STATE_HEADER)) / sizeof (SNP_PAGE_STATE_ENTRY))
+
//
// SEV-ES save area mapping structures used for SEV-SNP AP Creation.
// Only the fields required to be set to a non-zero value are defined.
diff --git a/OvmfPkg/Include/WorkArea.h b/OvmfPkg/Include/WorkArea.h
index b1c7045ce18c..87d2063f6d13 100644
--- a/OvmfPkg/Include/WorkArea.h
+++ b/OvmfPkg/Include/WorkArea.h
@@ -54,6 +54,13 @@ typedef struct _SEC_SEV_ES_WORK_AREA {
// detection in OvmfPkg/ResetVector/Ia32/AmdSev.c
//
UINT8 ReceivedVc;
+ UINT8 Reserved[7];
+
+ // Used by SEC to generate Page State Change requests. This should be
+ // sized less than an equal to the GHCB shared buffer area to allow a
+ // single call to the hypervisor.
+ //
+ UINT8 WorkBuffer[1024];
} SEC_SEV_ES_WORK_AREA;
//
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
index 43319cc9ed17..516d0eae91d7 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
@@ -24,7 +24,9 @@ InternalSetPageState (
IN EFI_PHYSICAL_ADDRESS BaseAddress,
IN UINTN NumPages,
IN SEV_SNP_PAGE_STATE State,
- IN BOOLEAN UseLargeEntry
+ IN BOOLEAN UseLargeEntry,
+ IN VOID *PscBuffer,
+ IN UINTN PscBufferSize
);
VOID
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
index cbcdd46f528f..c8e8478a30d4 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
@@ -16,6 +16,8 @@
#include "SnpPageStateChange.h"
#include "VirtualMemory.h"
+STATIC VOID *mPscBuffer = NULL;
+
/**
Pre-validate the system RAM when SEV-SNP is enabled in the guest VM.
@@ -52,5 +54,17 @@ MemEncryptSevSnpPreValidateSystemRam (
}
}
- InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE);
+ if (mPscBuffer == NULL) {
+ mPscBuffer = AllocateReservedPages (1);
+ ASSERT (mPscBuffer != NULL);
+ }
+
+ InternalSetPageState (
+ BaseAddress,
+ NumPages,
+ SevSnpPagePrivate,
+ TRUE,
+ mPscBuffer,
+ EFI_PAGE_SIZE
+ );
}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
index dee3fb8914ca..df367341d1ac 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
@@ -23,6 +23,8 @@ STATIC BOOLEAN mAddressEncMaskChecked = FALSE;
STATIC UINT64 mAddressEncMask;
STATIC PAGE_TABLE_POOL *mPageTablePool = NULL;
+STATIC VOID *mPscBuffer = NULL;
+
typedef enum {
SetCBit,
ClearCBit
@@ -786,7 +788,19 @@ SetMemoryEncDec (
// The InternalSetPageState() is used for setting the page state in the RMP table.
//
if (!Mmio && (Mode == ClearCBit) && MemEncryptSevSnpIsEnabled ()) {
- InternalSetPageState (PhysicalAddress, EFI_SIZE_TO_PAGES (Length), SevSnpPageShared, FALSE);
+ if (mPscBuffer == NULL) {
+ mPscBuffer = AllocateReservedPages (1);
+ ASSERT (mPscBuffer != NULL);
+ }
+
+ InternalSetPageState (
+ PhysicalAddress,
+ EFI_SIZE_TO_PAGES (Length),
+ SevSnpPageShared,
+ FALSE,
+ mPscBuffer,
+ EFI_PAGE_SIZE
+ );
}
//
@@ -975,11 +989,18 @@ SetMemoryEncDec (
// The InternalSetPageState() is used for setting the page state in the RMP table.
//
if ((Mode == SetCBit) && MemEncryptSevSnpIsEnabled ()) {
+ if (mPscBuffer == NULL) {
+ mPscBuffer = AllocateReservedPages (1);
+ ASSERT (mPscBuffer != NULL);
+ }
+
InternalSetPageState (
OrigPhysicalAddress,
EFI_SIZE_TO_PAGES (OrigLength),
SevSnpPagePrivate,
- FALSE
+ FALSE,
+ mPscBuffer,
+ EFI_PAGE_SIZE
);
}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
index 497016544482..46fc4994bfa4 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
@@ -17,6 +17,8 @@
#include "SnpPageStateChange.h"
#include "VirtualMemory.h"
+STATIC UINT8 mPscBufferPage[EFI_PAGE_SIZE];
+
typedef struct {
UINT64 StartAddress;
UINT64 EndAddress;
@@ -113,7 +115,14 @@ MemEncryptSevSnpPreValidateSystemRam (
if (BaseAddress < OverlapRange.StartAddress) {
NumPages = EFI_SIZE_TO_PAGES (OverlapRange.StartAddress - BaseAddress);
- InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE);
+ InternalSetPageState (
+ BaseAddress,
+ NumPages,
+ SevSnpPagePrivate,
+ TRUE,
+ mPscBufferPage,
+ sizeof (mPscBufferPage)
+ );
}
BaseAddress = OverlapRange.EndAddress;
@@ -122,7 +131,14 @@ MemEncryptSevSnpPreValidateSystemRam (
// Validate the remaining pages.
NumPages = EFI_SIZE_TO_PAGES (EndAddress - BaseAddress);
- InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE);
+ InternalSetPageState (
+ BaseAddress,
+ NumPages,
+ SevSnpPagePrivate,
+ TRUE,
+ mPscBufferPage,
+ sizeof (mPscBufferPage)
+ );
BaseAddress = EndAddress;
}
}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
index 7797febb8ac6..86af2ba0356e 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
@@ -10,6 +10,7 @@
#include <Uefi/UefiBaseType.h>
#include <Library/BaseLib.h>
+#include <Library/DebugLib.h>
#include <Library/MemEncryptSevLib.h>
#include "SnpPageStateChange.h"
@@ -65,6 +66,8 @@ MemEncryptSevSnpPreValidateSystemRam (
IN UINTN NumPages
)
{
+ SEC_SEV_ES_WORK_AREA *SevEsWorkArea;
+
if (!MemEncryptSevSnpIsEnabled ()) {
return;
}
@@ -78,5 +81,14 @@ MemEncryptSevSnpPreValidateSystemRam (
SnpPageStateFailureTerminate ();
}
- InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE);
+ SevEsWorkArea = (SEC_SEV_ES_WORK_AREA *)FixedPcdGet32 (PcdSevEsWorkAreaBase);
+
+ InternalSetPageState (
+ BaseAddress,
+ NumPages,
+ SevSnpPagePrivate,
+ TRUE,
+ SevEsWorkArea->WorkBuffer,
+ sizeof (SevEsWorkArea->WorkBuffer)
+ );
}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
index 46c6682760d5..f8bbe4d6f46b 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
@@ -72,14 +72,19 @@ SnpPageStateFailureTerminate (
STATIC
VOID
PvalidateRange (
- IN SNP_PAGE_STATE_CHANGE_INFO *Info,
- IN UINTN StartIndex,
- IN UINTN EndIndex,
- IN BOOLEAN Validate
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
)
{
- UINTN RmpPageSize, Ret, i;
+ UINTN RmpPageSize;
+ UINTN StartIndex;
+ UINTN EndIndex;
+ UINTN Index;
+ UINTN Ret;
EFI_PHYSICAL_ADDRESS Address;
+ BOOLEAN Validate;
+
+ StartIndex = Info->Header.CurrentEntry;
+ EndIndex = Info->Header.EndEntry;
for ( ; StartIndex <= EndIndex; StartIndex++) {
//
@@ -87,6 +92,7 @@ PvalidateRange (
//
Address = ((EFI_PHYSICAL_ADDRESS)Info->Entry[StartIndex].GuestFrameNumber) << EFI_PAGE_SHIFT;
RmpPageSize = Info->Entry[StartIndex].PageSize;
+ Validate = Info->Entry[StartIndex].Operation == SNP_PAGE_STATE_PRIVATE;
Ret = AsmPvalidate (RmpPageSize, Validate, Address);
@@ -96,7 +102,7 @@ PvalidateRange (
// the RMP entry is 4K and we are validating it as a 2MB.
//
if ((Ret == PVALIDATE_RET_SIZE_MISMATCH) && (RmpPageSize == PvalidatePageSize2MB)) {
- for (i = 0; i < PAGES_PER_LARGE_ENTRY; i++) {
+ for (Index = 0; Index < PAGES_PER_LARGE_ENTRY; Index++) {
Ret = AsmPvalidate (PvalidatePageSize4K, Validate, Address);
if (Ret) {
break;
@@ -131,22 +137,37 @@ BuildPageStateBuffer (
IN EFI_PHYSICAL_ADDRESS EndAddress,
IN SEV_SNP_PAGE_STATE State,
IN BOOLEAN UseLargeEntry,
- IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info,
+ IN UINTN InfoSize
)
{
EFI_PHYSICAL_ADDRESS NextAddress;
- UINTN i, RmpPageSize;
+ UINTN Index;
+ UINTN IndexMax;
+ UINTN PscIndexMax;
+ UINTN RmpPageSize;
// Clear the page state structure
- SetMem (Info, sizeof (*Info), 0);
+ SetMem (Info, InfoSize, 0);
- i = 0;
+ Index = 0;
+ IndexMax = (InfoSize - sizeof (Info->Header)) / sizeof (Info->Entry[0]);
NextAddress = EndAddress;
+ //
+ // Make the use of the work area as efficient as possible relative to
+ // exiting from the guest to the hypervisor. Maximize the number of entries
+ // that can be processed per exit.
+ //
+ PscIndexMax = (IndexMax / SNP_PAGE_STATE_MAX_ENTRY) * SNP_PAGE_STATE_MAX_ENTRY;
+ if (PscIndexMax > 0) {
+ IndexMax = MIN (IndexMax, PscIndexMax);
+ }
+
//
// Populate the page state entry structure
//
- while ((BaseAddress < EndAddress) && (i < SNP_PAGE_STATE_MAX_ENTRY)) {
+ while ((BaseAddress < EndAddress) && (Index < IndexMax)) {
//
// Is this a 2MB aligned page? Check if we can use the Large RMP entry.
//
@@ -160,14 +181,14 @@ BuildPageStateBuffer (
NextAddress = BaseAddress + EFI_PAGE_SIZE;
}
- Info->Entry[i].GuestFrameNumber = BaseAddress >> EFI_PAGE_SHIFT;
- Info->Entry[i].PageSize = RmpPageSize;
- Info->Entry[i].Operation = MemoryStateToGhcbOp (State);
- Info->Entry[i].CurrentPage = 0;
- Info->Header.EndEntry = (UINT16)i;
+ Info->Entry[Index].GuestFrameNumber = BaseAddress >> EFI_PAGE_SHIFT;
+ Info->Entry[Index].PageSize = RmpPageSize;
+ Info->Entry[Index].Operation = MemoryStateToGhcbOp (State);
+ Info->Entry[Index].CurrentPage = 0;
+ Info->Header.EndEntry = (UINT16)Index;
BaseAddress = NextAddress;
- i++;
+ Index++;
}
return NextAddress;
@@ -176,11 +197,29 @@ BuildPageStateBuffer (
STATIC
VOID
PageStateChangeVmgExit (
- IN GHCB *Ghcb,
- IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ IN GHCB *Ghcb,
+ IN SNP_PAGE_STATE_ENTRY *Start,
+ IN UINT16 Count
)
{
- EFI_STATUS Status;
+ SNP_PAGE_STATE_CHANGE_INFO *GhcbInfo;
+ EFI_STATUS Status;
+ BOOLEAN InterruptState;
+
+ ASSERT (Count <= SNP_PAGE_STATE_MAX_ENTRY);
+ if (Count > SNP_PAGE_STATE_MAX_ENTRY) {
+ SnpPageStateFailureTerminate ();
+ }
+
+ //
+ // Initialize the GHCB
+ //
+ CcExitVmgInit (Ghcb, &InterruptState);
+
+ GhcbInfo = (SNP_PAGE_STATE_CHANGE_INFO *)Ghcb->SharedBuffer;
+ GhcbInfo->Header.CurrentEntry = 0;
+ GhcbInfo->Header.EndEntry = Count - 1;
+ CopyMem (GhcbInfo->Entry, Start, sizeof (*Start) * Count);
//
// As per the GHCB specification, the hypervisor can resume the guest before
@@ -191,7 +230,7 @@ PageStateChangeVmgExit (
// page state was not successful, then later memory access will result
// in the crash.
//
- while (Info->Header.CurrentEntry <= Info->Header.EndEntry) {
+ while (GhcbInfo->Header.CurrentEntry <= GhcbInfo->Header.EndEntry) {
Ghcb->SaveArea.SwScratch = (UINT64)Ghcb->SharedBuffer;
CcExitVmgSetOffsetValid (Ghcb, GhcbSwScratch);
@@ -205,6 +244,34 @@ PageStateChangeVmgExit (
SnpPageStateFailureTerminate ();
}
}
+
+ CcExitVmgDone (Ghcb, InterruptState);
+}
+
+STATIC
+VOID
+PageStateChange (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ )
+{
+ GHCB *Ghcb;
+ MSR_SEV_ES_GHCB_REGISTER Msr;
+ SNP_PAGE_STATE_HEADER *Header;
+ UINT16 Index;
+ UINT16 Count;
+
+ Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+ Ghcb = Msr.Ghcb;
+
+ Header = &Info->Header;
+
+ for (Index = Header->CurrentEntry; Index <= Header->EndEntry;) {
+ Count = MIN (Header->EndEntry - Index + 1, SNP_PAGE_STATE_MAX_ENTRY);
+
+ PageStateChangeVmgExit (Ghcb, &Info->Entry[Index], Count);
+
+ Index += Count;
+ }
}
/**
@@ -220,18 +287,14 @@ InternalSetPageState (
IN EFI_PHYSICAL_ADDRESS BaseAddress,
IN UINTN NumPages,
IN SEV_SNP_PAGE_STATE State,
- IN BOOLEAN UseLargeEntry
+ IN BOOLEAN UseLargeEntry,
+ IN VOID *PscBuffer,
+ IN UINTN PscBufferSize
)
{
- GHCB *Ghcb;
EFI_PHYSICAL_ADDRESS NextAddress, EndAddress;
- MSR_SEV_ES_GHCB_REGISTER Msr;
- BOOLEAN InterruptState;
SNP_PAGE_STATE_CHANGE_INFO *Info;
- Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
- Ghcb = Msr.Ghcb;
-
EndAddress = BaseAddress + EFI_PAGES_TO_SIZE (NumPages);
DEBUG ((
@@ -245,56 +308,40 @@ InternalSetPageState (
UseLargeEntry
));
- while (BaseAddress < EndAddress) {
- UINTN CurrentEntry, EndEntry;
-
- //
- // Initialize the GHCB
- //
- CcExitVmgInit (Ghcb, &InterruptState);
+ Info = (SNP_PAGE_STATE_CHANGE_INFO *)PscBuffer;
+ for (NextAddress = BaseAddress; NextAddress < EndAddress;) {
//
// Build the page state structure
//
- Info = (SNP_PAGE_STATE_CHANGE_INFO *)Ghcb->SharedBuffer;
NextAddress = BuildPageStateBuffer (
- BaseAddress,
+ NextAddress,
EndAddress,
State,
UseLargeEntry,
- Info
+ PscBuffer,
+ PscBufferSize
);
- //
- // Save the current and end entry from the page state structure. We need
- // it later.
- //
- CurrentEntry = Info->Header.CurrentEntry;
- EndEntry = Info->Header.EndEntry;
-
//
// If the caller requested to change the page state to shared then
// invalidate the pages before making the page shared in the RMP table.
//
if (State == SevSnpPageShared) {
- PvalidateRange (Info, CurrentEntry, EndEntry, FALSE);
+ PvalidateRange (Info);
}
//
// Invoke the page state change VMGEXIT.
//
- PageStateChangeVmgExit (Ghcb, Info);
+ PageStateChange (Info);
//
// If the caller requested to change the page state to private then
// validate the pages after it has been added in the RMP table.
//
if (State == SevSnpPagePrivate) {
- PvalidateRange (Info, CurrentEntry, EndEntry, TRUE);
+ PvalidateRange (Info);
}
-
- CcExitVmgDone (Ghcb, InterruptState);
-
- BaseAddress = NextAddress;
}
}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114627): https://edk2.groups.io/g/devel/message/114627
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
2024-01-26 22:13 ` [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support Lendacky, Thomas via groups.io
@ 2024-01-29 12:59 ` Gerd Hoffmann
2024-01-29 15:39 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 12:59 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
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)?
> 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.
> - 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 (#114700): https://edk2.groups.io/g/devel/message/114700
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
2024-01-29 12:59 ` Gerd Hoffmann
@ 2024-01-29 15:39 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 15:39 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
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]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 02/16] MdePkg/Register/Amd: Define the SVSM related information
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
2024-01-26 22:13 ` [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 13:12 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM Lendacky, Thomas via groups.io
` (14 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The Secure VM Service Module specification defines the interfaces needed
to allow multi-VMPL level execution of an SEV-SNP guest.
Define the SVSM related structures for the SVSM Calling Area as well as
the SVSM CAA MSR. The SVSM CAA MSR is an MSR register that is reserved for
software use and will not be implemented in hardware.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +++-
MdePkg/Include/Register/Amd/Msr.h | 3 +-
MdePkg/Include/Register/Amd/Svsm.h | 101 ++++++++++++++++++++
MdePkg/Include/Register/Amd/SvsmMsr.h | 35 +++++++
4 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
index bb4e143e2456..f2d5ccb39dc7 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -6,7 +6,7 @@
returned is a single 32-bit or 64-bit value, then a data structure is not
provided for that MSR.
- Copyright (c) 2017, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2017 - 2024, Advanced Micro Devices. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@par Specification Reference:
@@ -71,9 +71,24 @@ typedef union {
UINT32 ErrorCode;
} SnpPageStateChangeResponse;
+ struct {
+ UINT64 Function : 12;
+ UINT64 Reserved1 : 20;
+ UINT64 Vmpl : 8;
+ UINT64 Reserved2 : 56;
+ } SnpVmplRequest;
+
+ struct {
+ UINT32 Function : 12;
+ UINT32 Reserved : 20;
+ UINT32 ErrorCode;
+ } SnpVmplResponse;
+
VOID *Ghcb;
UINT64 GhcbPhysicalAddress;
+
+ UINT64 Uint64;
} MSR_SEV_ES_GHCB_REGISTER;
#define GHCB_INFO_SEV_INFO 1
@@ -84,6 +99,8 @@ typedef union {
#define GHCB_INFO_GHCB_GPA_REGISTER_RESPONSE 19
#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_REQUEST 20
#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_RESPONSE 21
+#define GHCB_INFO_SNP_VMPL_REQUEST 22
+#define GHCB_INFO_SNP_VMPL_RESPONSE 23
#define GHCB_HYPERVISOR_FEATURES_REQUEST 128
#define GHCB_HYPERVISOR_FEATURES_RESPONSE 129
#define GHCB_INFO_TERMINATE_REQUEST 256
diff --git a/MdePkg/Include/Register/Amd/Msr.h b/MdePkg/Include/Register/Amd/Msr.h
index 084eb892cdd9..04a3cbeb4315 100644
--- a/MdePkg/Include/Register/Amd/Msr.h
+++ b/MdePkg/Include/Register/Amd/Msr.h
@@ -6,7 +6,7 @@
returned is a single 32-bit or 64-bit value, then a data structure is not
provided for that MSR.
- Copyright (c) 2017 - 2019, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2017 - 2024, Advanced Micro Devices. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@par Specification Reference:
@@ -19,5 +19,6 @@
#include <Register/Intel/ArchitecturalMsr.h>
#include <Register/Amd/Fam17Msr.h>
+#include <Register/Amd/SvsmMsr.h>
#endif
diff --git a/MdePkg/Include/Register/Amd/Svsm.h b/MdePkg/Include/Register/Amd/Svsm.h
new file mode 100644
index 000000000000..9a989f803107
--- /dev/null
+++ b/MdePkg/Include/Register/Amd/Svsm.h
@@ -0,0 +1,101 @@
+/** @file
+ Secure VM Service Module (SVSM) Definition.
+
+ Provides data types allowing an SEV-SNP guest to interact with the SVSM.
+
+ Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Specification Reference:
+ Secure VM Service Module Specification
+
+**/
+
+#ifndef SVSM_H_
+#define SVSM_H_
+
+#include <Base.h>
+#include <Uefi.h>
+#include <Library/BaseLib.h>
+
+//
+// The SVSM definitions are part of the SNP Secrets Page:
+// An SVSM is considered present if the SvsmSize field is non-zero.
+//
+typedef PACKED struct {
+ UINT8 Reserved1[320];
+
+ UINT64 SvsmBase;
+ UINT64 SvsmSize;
+ UINT64 SvsmCaa;
+ UINT32 SvsmMaxVersion;
+ UINT8 SvsmGuestVmpl;
+ UINT8 Reserved2[3];
+} SVSM_INFORMATION;
+
+typedef PACKED struct {
+ UINT8 SvsmCallPending;
+ UINT8 SvsmMemAvailable;
+ UINT8 Reserved1[6];
+
+ //
+ // The remainder of the CAA 4KB area can be used for argument
+ // passing to the SVSM.
+ //
+ UINT8 SvsmBuffer[SIZE_4KB - 8];
+} SVSM_CAA;
+
+#define SVSM_SUCCESS 0x00000000
+#define SVSM_ERR_INCOMPLETE 0x80000000
+#define SVSM_ERR_UNSUPPORTED_PROTOCOL 0x80000001
+#define SVSM_ERR_UNSUPPORTED_CALL 0x80000002
+#define SVSM_ERR_INVALID_ADDRESS 0x80000003
+#define SVSM_ERR_INVALID_FORMAT 0x80000004
+#define SVSM_ERR_INVALID_PARAMETER 0x80000005
+#define SVSM_ERR_INVALID_REQUEST 0x80000006
+#define SVSM_ERR_BUSY 0x80000007
+
+#define SVSM_ERR_PVALIDATE_FAIL_INPUT 0x80001001
+#define SVSM_ERR_PVALIDATE_FAIL_SIZE_MISMATCH 0x80001006
+#define SVSM_ERR_PVALIDATE_FAIL_NO_CHANGE 0x80001010
+
+typedef PACKED struct {
+ UINT16 Entries;
+ UINT16 Next;
+
+ UINT8 Reserved[4];
+} SVSM_PVALIDATE_HEADER;
+
+typedef union {
+ struct {
+ UINT64 PageSize : 2;
+ UINT64 Action : 1;
+ UINT64 IgnoreCf : 1;
+ UINT64 Reserved_2 : 8;
+ UINT64 Address : 52;
+ } Bits;
+ UINT64 Uint64;
+} SVSM_PVALIDATE_ENTRY;
+
+typedef PACKED struct {
+ SVSM_PVALIDATE_HEADER Header;
+ SVSM_PVALIDATE_ENTRY Entry[];
+} SVSM_PVALIDATE_REQUEST;
+
+#define SVSM_PVALIDATE_MAX_ENTRY \
+ ((sizeof (((SVSM_CAA *)0)->SvsmBuffer) - sizeof (SVSM_PVALIDATE_HEADER)) / sizeof (SVSM_PVALIDATE_ENTRY))
+
+typedef union {
+ SVSM_PVALIDATE_REQUEST PvalidateRequest;
+} SVSM_REQUEST;
+
+typedef union {
+ struct {
+ UINT32 CallId;
+ UINT32 Protocol;
+ } Id;
+
+ UINT64 Uint64;
+} SVSM_FUNCTION;
+
+#endif
diff --git a/MdePkg/Include/Register/Amd/SvsmMsr.h b/MdePkg/Include/Register/Amd/SvsmMsr.h
new file mode 100644
index 000000000000..9e7fca880ba5
--- /dev/null
+++ b/MdePkg/Include/Register/Amd/SvsmMsr.h
@@ -0,0 +1,35 @@
+/** @file
+ MSR Definitions.
+
+ Provides defines for Machine Specific Registers(MSR) indexes. Data structures
+ are provided for MSRs that contain one or more bit fields. If the MSR value
+ returned is a single 32-bit or 64-bit value, then a data structure is not
+ provided for that MSR.
+
+ Copyright (c) 2024, Advanced Micro Devices. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef SVSM_MSR_H_
+#define SVSM_MSR_H_
+
+/**
+ Secure VM Service Module CAA register
+
+**/
+#define MSR_SVSM_CAA 0xc001f000
+
+/**
+ MSR information returned for #MSR_SVSM_CAA
+**/
+typedef union {
+ struct {
+ UINT32 Lower32Bits;
+ UINT32 Upper32Bits;
+ } Bits;
+
+ UINT64 Uint64;
+} MSR_SVSM_CAA_REGISTER;
+
+#endif
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114628): https://edk2.groups.io/g/devel/message/114628
Mute This Topic: https://groups.io/mt/103986439/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 02/16] MdePkg/Register/Amd: Define the SVSM related information
2024-01-26 22:13 ` [edk2-devel] [PATCH 02/16] MdePkg/Register/Amd: Define the SVSM related information Lendacky, Thomas via groups.io
@ 2024-01-29 13:12 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 13:12 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:01PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> The Secure VM Service Module specification defines the interfaces needed
> to allow multi-VMPL level execution of an SEV-SNP guest.
>
> Define the SVSM related structures for the SVSM Calling Area as well as
> the SVSM CAA MSR. The SVSM CAA MSR is an MSR register that is reserved for
> software use and will not be implemented in hardware.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114701): https://edk2.groups.io/g/devel/message/114701
Mute This Topic: https://groups.io/mt/103986439/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
2024-01-26 22:13 ` [edk2-devel] [PATCH 01/16] OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support Lendacky, Thomas via groups.io
2024-01-26 22:13 ` [edk2-devel] [PATCH 02/16] MdePkg/Register/Amd: Define the SVSM related information Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 13:22 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM Lendacky, Thomas via groups.io
` (13 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The SVSM specification relies on a specific register calling convention to
hold the parameters that are associated with the SVSM request. The SVSM is
invoked by requesting the hypervisor to run the VMPL0 VMSA of the guest
using the GHCB MSR Protocol or a GHCB NAE event.
Create a new version of the VMGEXIT instruction that will adhere to this
calling convention and load the SVSM function arguments into the proper
register before invoking the VMGEXIT instruction. On return, perform the
atomic exchange on the SVSM call pending value as specified in the SVSM
specification.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
MdePkg/Library/BaseLib/BaseLib.inf | 2 +
MdePkg/Include/Library/BaseLib.h | 39 ++++++++
MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++++++++
MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++++++++++++++++++
4 files changed, 174 insertions(+)
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf
index 6b46949be332..2b3d9af36706 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -187,6 +187,7 @@ [Sources.Ia32]
Ia32/XGetBv.nasm
Ia32/XSetBv.nasm
Ia32/VmgExit.nasm
+ Ia32/VmgExitSvsm.nasm
Ia32/DivS64x64Remainder.c
Ia32/InternalSwitchStack.c | MSFT
@@ -328,6 +329,7 @@ [Sources.X64]
X64/XGetBv.nasm
X64/XSetBv.nasm
X64/VmgExit.nasm
+ X64/VmgExitSvsm.nasm
ChkStkGcc.c | GCC
[Sources.EBC]
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index ca0d06c7f335..149519d85233 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7655,6 +7655,45 @@ AsmVmgExit (
VOID
);
+///
+/// The structure used to supply and return data to and from the SVSM.
+///
+typedef struct {
+ VOID *Caa;
+ UINT64 RaxIn;
+ UINT64 RcxIn;
+ UINT64 RdxIn;
+ UINT64 R8In;
+ UINT64 R9In;
+ UINT64 RaxOut;
+ UINT64 RcxOut;
+ UINT64 RdxOut;
+ UINT64 R8Out;
+ UINT64 R9Out;
+ UINT8 *CallPending;
+} SVSM_CALL_DATA;
+
+/**
+ Executes a VMGEXIT instruction (VMMCALL with a REP prefix) with arguments
+ and return code
+
+ Executes a VMGEXIT instruction placing the specified arguments in the
+ corresponding registers before invocation. Upon return an XCHG is done to
+ atomically clear and retrieve the SVSM call pending value. The returned RAX
+ register value becomes the function return code. This function is intended
+ for use with an SVSM. This function is only available on IA-32 and x64.
+
+ @param[in,out] SvsmCallPending Pointer to the location of the SVSM call data
+
+ @return Value of the RAX register on return
+
+**/
+UINT32
+EFIAPI
+AsmVmgExitSvsm (
+ IN OUT SVSM_CALL_DATA *SvsmCallData
+ );
+
/**
Patch the immediate operand of an IA32 or X64 instruction such that the byte,
word, dword or qword operand is encoded at the end of the instruction's
diff --git a/MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm b/MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
new file mode 100644
index 000000000000..14717bd1af02
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
@@ -0,0 +1,39 @@
+;------------------------------------------------------------------------------
+;
+; Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+; VmgExitSvsm.Asm
+;
+; Abstract:
+;
+; AsmVmgExitSvsm function
+;
+; Notes:
+;
+;------------------------------------------------------------------------------
+
+ DEFAULT REL
+ SECTION .text
+
+;------------------------------------------------------------------------------
+; UINT32
+; EFIAPI
+; AsmVmgExitSvsm (
+; SVSM_CALL_DATA *SvsmCallData
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(AsmVmgExitSvsm)
+ASM_PFX(AsmVmgExitSvsm):
+;
+; NASM doesn't support the vmmcall instruction in 32-bit mode and NASM versions
+; before 2.12 cannot translate the 64-bit "rep vmmcall" instruction into elf32
+; format. Given that VMGEXIT does not make sense on IA32, provide a stub
+; implementation that is identical to CpuBreakpoint(). In practice,
+; AsmVmgExitSvsm() should never be called on IA32.
+;
+ int 3
+ ret
+
diff --git a/MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm b/MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
new file mode 100644
index 000000000000..b8af78890611
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
@@ -0,0 +1,94 @@
+;------------------------------------------------------------------------------
+;
+; Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+; VmgExitSvsm.Asm
+;
+; Abstract:
+;
+; AsmVmgExitSvsm function
+;
+; Notes:
+;
+;------------------------------------------------------------------------------
+
+ DEFAULT REL
+ SECTION .text
+
+;------------------------------------------------------------------------------
+; typedef struct {
+; VOID *Caa;
+; UINT64 RaxIn;
+; UINT64 RcxIn;
+; UINT64 RdxIn;
+; UINT64 R8In;
+; UINT64 R9In;
+; UINT64 RaxOut;
+; UINT64 RcxOut;
+; UINT64 RdxOut;
+; UINT64 R8Out;
+; UINT64 R9Out;
+; UINT8 *CallPending;
+; } SVSM_CALL_DATA;
+;
+; UINT32
+; EFIAPI
+; AsmVmgExitSvsm (
+; SVSM_CALL_DATA *SvsmCallData
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(AsmVmgExitSvsm)
+ASM_PFX(AsmVmgExitSvsm):
+ push r10
+ push r11
+ push r12
+
+;
+; Calling convention has SvsmCallData in RCX. Move RCX to R12 in order to
+; properly populate the SVSM register state.
+;
+ mov r12, rcx
+
+ mov rax, [r12 + 8]
+ mov rcx, [r12 + 16]
+ mov rdx, [r12 + 24]
+ mov r8, [r12 + 32]
+ mov r9, [r12 + 40]
+
+;
+; Set CA call pending
+;
+ mov r10, [r12]
+ mov byte [r10], 1
+
+ rep vmmcall
+
+ mov [r12 + 48], rax
+ mov [r12 + 56], rcx
+ mov [r12 + 64], rdx
+ mov [r12 + 72], r8
+ mov [r12 + 80], r9
+
+;
+; Perform the atomic exchange and return the CA call pending value.
+; The call pending value is a one-byte field at offset 0 into the CA,
+; which is currently the value in R10.
+;
+
+ mov r11, [r12 + 88] ; Get CallPending address
+ mov cl, byte [r11]
+ xchg byte [r10], cl
+ mov byte [r11], cl ; Return the exchanged value
+
+ pop r12
+ pop r11
+ pop r10
+
+;
+; RAX has the value to be returned from the SVSM
+;
+ ret
+
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114629): https://edk2.groups.io/g/devel/message/114629
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-26 22:13 ` [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM Lendacky, Thomas via groups.io
@ 2024-01-29 13:22 ` Gerd Hoffmann
2024-01-29 15:51 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 13:22 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
> +global ASM_PFX(AsmVmgExitSvsm)
> +ASM_PFX(AsmVmgExitSvsm):
> +;
> +; NASM doesn't support the vmmcall instruction in 32-bit mode and NASM versions
> +; before 2.12 cannot translate the 64-bit "rep vmmcall" instruction into elf32
> +; format. Given that VMGEXIT does not make sense on IA32, provide a stub
> +; implementation that is identical to CpuBreakpoint(). In practice,
> +; AsmVmgExitSvsm() should never be called on IA32.
> +;
> + int 3
> + ret
Why? I assume because the calling convention is only defined for X64?
Why do we need this in the first place if this is never called on IA32?
Wouldn't it be better to have an ASSERT(FALSE) for IA32 in the code
calling this?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114702): https://edk2.groups.io/g/devel/message/114702
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-29 13:22 ` Gerd Hoffmann
@ 2024-01-29 15:51 ` Lendacky, Thomas via groups.io
2024-01-30 11:51 ` Gerd Hoffmann
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 15:51 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/29/24 07:22, Gerd Hoffmann wrote:
>> +global ASM_PFX(AsmVmgExitSvsm)
>> +ASM_PFX(AsmVmgExitSvsm):
>> +;
>> +; NASM doesn't support the vmmcall instruction in 32-bit mode and NASM versions
>> +; before 2.12 cannot translate the 64-bit "rep vmmcall" instruction into elf32
>> +; format. Given that VMGEXIT does not make sense on IA32, provide a stub
>> +; implementation that is identical to CpuBreakpoint(). In practice,
>> +; AsmVmgExitSvsm() should never be called on IA32.
>> +;
>> + int 3
>> + ret
>
> Why? I assume because the calling convention is only defined for X64?
>
> Why do we need this in the first place if this is never called on IA32?
>
> Wouldn't it be better to have an ASSERT(FALSE) for IA32 in the code
> calling this?
An ASSERT() only works for DEBUG code.
I was following in the steps of AsmVmgExit, where we did this. I suppose
we could just not have it at all for IA32 and cause a build failure if
someone was to try and call this from 32-bit code. Thoughts?
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114717): https://edk2.groups.io/g/devel/message/114717
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-29 15:51 ` Lendacky, Thomas via groups.io
@ 2024-01-30 11:51 ` Gerd Hoffmann
2024-01-31 18:30 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-30 11:51 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Mon, Jan 29, 2024 at 09:51:47AM -0600, Tom Lendacky wrote:
> On 1/29/24 07:22, Gerd Hoffmann wrote:
> > > +global ASM_PFX(AsmVmgExitSvsm)
> > > +ASM_PFX(AsmVmgExitSvsm):
> > > +;
> > > +; NASM doesn't support the vmmcall instruction in 32-bit mode and NASM versions
> > > +; before 2.12 cannot translate the 64-bit "rep vmmcall" instruction into elf32
> > > +; format. Given that VMGEXIT does not make sense on IA32, provide a stub
> > > +; implementation that is identical to CpuBreakpoint(). In practice,
> > > +; AsmVmgExitSvsm() should never be called on IA32.
> > > +;
> > > + int 3
> > > + ret
> >
> > Why? I assume because the calling convention is only defined for X64?
> >
> > Why do we need this in the first place if this is never called on IA32?
> >
> > Wouldn't it be better to have an ASSERT(FALSE) for IA32 in the code
> > calling this?
>
> An ASSERT() only works for DEBUG code.
>
> I was following in the steps of AsmVmgExit, where we did this. I suppose we
> could just not have it at all for IA32 and cause a build failure if someone
> was to try and call this from 32-bit code. Thoughts?
See also patch #13 sub-thread. Maybe just move the 32-bit build to the
Null versions of the Libraries.
SEV-SNP + SVSM apparently is 64-bit only already (there is no 32-bit
calling convention).
Over the last year Intel landed full 64-bit PEI support in edk2, which
means the pure 64-bit build (OvmfPkgX64.dsc) has feature parity with
the 32-bit PEI / 64-bit DXE build (OvmfPkgIa32X64.dsc).
So maybe we can simply leave 32-bit support behind and remove SEV
support from OvmfPkgIa32X64.dsc and OvmfPkgIa32.dsc builds ...
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114773): https://edk2.groups.io/g/devel/message/114773
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-30 11:51 ` Gerd Hoffmann
@ 2024-01-31 18:30 ` Lendacky, Thomas via groups.io
2024-02-01 8:35 ` Gerd Hoffmann
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-31 18:30 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/30/24 05:51, Gerd Hoffmann wrote:
> On Mon, Jan 29, 2024 at 09:51:47AM -0600, Tom Lendacky wrote:
>> On 1/29/24 07:22, Gerd Hoffmann wrote:
>>>> +global ASM_PFX(AsmVmgExitSvsm)
>>>> +ASM_PFX(AsmVmgExitSvsm):
>>>> +;
>>>> +; NASM doesn't support the vmmcall instruction in 32-bit mode and NASM versions
>>>> +; before 2.12 cannot translate the 64-bit "rep vmmcall" instruction into elf32
>>>> +; format. Given that VMGEXIT does not make sense on IA32, provide a stub
>>>> +; implementation that is identical to CpuBreakpoint(). In practice,
>>>> +; AsmVmgExitSvsm() should never be called on IA32.
>>>> +;
>>>> + int 3
>>>> + ret
>>>
>>> Why? I assume because the calling convention is only defined for X64?
>>>
>>> Why do we need this in the first place if this is never called on IA32?
>>>
>>> Wouldn't it be better to have an ASSERT(FALSE) for IA32 in the code
>>> calling this?
>>
>> An ASSERT() only works for DEBUG code.
>>
>> I was following in the steps of AsmVmgExit, where we did this. I suppose we
>> could just not have it at all for IA32 and cause a build failure if someone
>> was to try and call this from 32-bit code. Thoughts?
>
> See also patch #13 sub-thread. Maybe just move the 32-bit build to the
> Null versions of the Libraries.
>
> SEV-SNP + SVSM apparently is 64-bit only already (there is no 32-bit
> calling convention).
>
> Over the last year Intel landed full 64-bit PEI support in edk2, which
> means the pure 64-bit build (OvmfPkgX64.dsc) has feature parity with
> the 32-bit PEI / 64-bit DXE build (OvmfPkgIa32X64.dsc).
>
> So maybe we can simply leave 32-bit support behind and remove SEV
> support from OvmfPkgIa32X64.dsc and OvmfPkgIa32.dsc builds ...
That would break anyone that is currently using OvmfPkgIa32X64.dsc for
base SEV (not ES or SNP), but I'm not sure if that is a real concern. For
OvmfPkgIa32.dsc, no version of SEV will work, so that is doable.
Can we look at doing that cleanup after this series?
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114913): https://edk2.groups.io/g/devel/message/114913
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
2024-01-31 18:30 ` Lendacky, Thomas via groups.io
@ 2024-02-01 8:35 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-02-01 8:35 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Wed, Jan 31, 2024 at 12:30:35PM -0600, Tom Lendacky wrote:
> On 1/30/24 05:51, Gerd Hoffmann wrote:
> >
> > See also patch #13 sub-thread. Maybe just move the 32-bit build to the
> > Null versions of the Libraries.
> >
> > SEV-SNP + SVSM apparently is 64-bit only already (there is no 32-bit
> > calling convention).
> >
> > Over the last year Intel landed full 64-bit PEI support in edk2, which
> > means the pure 64-bit build (OvmfPkgX64.dsc) has feature parity with
> > the 32-bit PEI / 64-bit DXE build (OvmfPkgIa32X64.dsc).
> >
> > So maybe we can simply leave 32-bit support behind and remove SEV
> > support from OvmfPkgIa32X64.dsc and OvmfPkgIa32.dsc builds ...
>
> That would break anyone that is currently using OvmfPkgIa32X64.dsc for base
> SEV (not ES or SNP), but I'm not sure if that is a real concern. For
> OvmfPkgIa32.dsc, no version of SEV will work, so that is doable.
>
> Can we look at doing that cleanup after this series?
I thought maybe removing 32-bit support first is easier, because you
don't have to add 32-bit dummy code then. I'd leave that do you do
decide though, doing the 32-bit cleanup as separate series is fine
with me too.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114937): https://edk2.groups.io/g/devel/message/114937
Mute This Topic: https://groups.io/mt/103986440/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (2 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 03/16] MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-02-02 6:06 ` Ni, Ray
2024-01-26 22:13 ` [edk2-devel] [PATCH 05/16] Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services Lendacky, Thomas via groups.io
` (12 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
In order to support an SEV-SNP guest running under an SVSM at VMPL1 or
lower, the CcExitLib library must be extended with new intefaces.
This includes an interface to detect if running under an SVSM, an
interface to return the current VMPL, an interface to perform memory
validation and an interface to set or clear the attribute that allows a
page to be used as a VMSA.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++++++++++++++++-
UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 +++++++++++++++++++-
2 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/UefiCpuPkg/Include/Library/CcExitLib.h b/UefiCpuPkg/Include/Library/CcExitLib.h
index 3381d583691f..2a9de5d5e8e7 100644
--- a/UefiCpuPkg/Include/Library/CcExitLib.h
+++ b/UefiCpuPkg/Include/Library/CcExitLib.h
@@ -6,7 +6,7 @@
#VC exceptions.
- Handle #VE exception in TDX.
- Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
Copyright (c) 2020 - 2022, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -147,6 +147,75 @@ CcExitHandleVc (
IN OUT EFI_SYSTEM_CONTEXT SystemContext
);
+/**
+ Report the presence of an Secure Virtual Services Module (SVSM).
+
+ Determines the presence of an SVSM.
+
+ @retval TRUE An SVSM is present
+ @retval FALSE An SVSM is not present
+
+**/
+BOOLEAN
+EFIAPI
+CcExitSnpSvsmPresent (
+ VOID
+ );
+
+/**
+ Report the VMPL level at which the SEV-SNP guest is running.
+
+ Determines the VMPL level at which the guest is running. If an SVSM is
+ not present, then it must be VMPL0, otherwise return what is reported
+ by the SVSM.
+
+ @return The VMPL level
+
+**/
+UINT8
+EFIAPI
+CcExitSnpGetVmpl (
+ VOID
+ );
+
+/**
+ Perform a PVALIDATE operation for the page ranges specified.
+
+ Validate or rescind the validation of the specified pages.
+
+ @param[in] Info Pointer to a page state change structure
+
+**/
+VOID
+EFIAPI
+CcExitSnpPvalidate (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ );
+
+/**
+ Perform an RMPADJUST operation to alter the VMSA setting of a page.
+
+ Add or remove the VMSA attribute for a page.
+
+ @param[in] Vmsa Pointer to an SEV-ES save area page
+ @param[in] ApicId APIC ID associated with the VMSA
+ @param[in] SetVmsa Boolean indicator as to whether to set or
+ or clear the VMSA setting for the page
+
+ @retval EFI_SUCCESS RMPADJUST operation successful
+ @retval EFI_UNSUPPORTED Operation is not supported
+ @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
+ parameter was supplied
+
+**/
+EFI_STATUS
+EFIAPI
+CcExitSnpVmsaRmpAdjust (
+ IN SEV_ES_SAVE_AREA *Vmsa,
+ IN UINT32 ApicId,
+ IN BOOLEAN SetVmsa
+ );
+
/**
Handle a #VE exception.
diff --git a/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c b/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
index 230e50705b4a..60b19c0433c7 100644
--- a/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
+++ b/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
@@ -1,7 +1,7 @@
/** @file
CcExit Base Support Library.
- Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
Copyright (c) 2020 - 2022, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -165,6 +165,86 @@ CcExitHandleVc (
return EFI_UNSUPPORTED;
}
+/**
+ Report the presence of an Secure Virtual Services Module (SVSM).
+
+ Determines the presence of an SVSM.
+
+ @retval TRUE An SVSM is present
+ @retval FALSE An SVSM is not present
+
+**/
+BOOLEAN
+EFIAPI
+CcExitSnpSvsmPresent (
+ VOID
+ )
+{
+ return FALSE;
+}
+
+/**
+ Report the VMPL level at which the SEV-SNP guest is running.
+
+ Determines the VMPL level at which the guest is running. If an SVSM is
+ not present, then it must be VMPL0, otherwise return what is reported
+ by the SVSM.
+
+ @return The VMPL level
+
+**/
+UINT8
+EFIAPI
+CcExitSnpGetVmpl (
+ VOID
+ )
+{
+ return 0;
+}
+
+/**
+ Perform a PVALIDATE operation for the page ranges specified.
+
+ Validate or rescind the validation of the specified pages.
+
+ @param[in] Info Pointer to a page state change structure
+
+**/
+VOID
+EFIAPI
+CcExitSnpPvalidate (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ )
+{
+}
+
+/**
+ Perform an RMPADJUST operation to alter the VMSA setting of a page.
+
+ Add or remove the VMSA attribute for a page.
+
+ @param[in] Vmsa Pointer to an SEV-ES save area page
+ @param[in] ApicId APIC ID associated with the VMSA
+ @param[in] SetVmsa Boolean indicator as to whether to set or
+ or clear the VMSA setting for the page
+
+ @retval EFI_SUCCESS RMPADJUST operation successful
+ @retval EFI_UNSUPPORTED Operation is not supported
+ @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
+ parameter was supplied
+
+**/
+EFI_STATUS
+EFIAPI
+CcExitSnpVmsaRmpAdjust (
+ IN SEV_ES_SAVE_AREA *Vmsa,
+ IN UINT32 ApicId,
+ IN BOOLEAN SetVmsa
+ )
+{
+ return EFI_UNSUPPORTED;
+}
+
/**
Handle a #VE exception.
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114630): https://edk2.groups.io/g/devel/message/114630
Mute This Topic: https://groups.io/mt/103986445/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
2024-01-26 22:13 ` [edk2-devel] [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM Lendacky, Thomas via groups.io
@ 2024-02-02 6:06 ` Ni, Ray
0 siblings, 0 replies; 56+ messages in thread
From: Ni, Ray @ 2024-02-02 6:06 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
Acked-by: Ray Ni <ray.ni@intel.com>
Thanks,
Ray
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael Roth
> <michael.roth@amd.com>
> Subject: [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to
> support an SVSM
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> In order to support an SEV-SNP guest running under an SVSM at VMPL1 or
> lower, the CcExitLib library must be extended with new intefaces.
>
> This includes an interface to detect if running under an SVSM, an
> interface to return the current VMPL, an interface to perform memory
> validation and an interface to set or clear the attribute that allows a
> page to be used as a VMSA.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++++++++++++++++-
> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82
> +++++++++++++++++++-
> 2 files changed, 151 insertions(+), 2 deletions(-)
>
> diff --git a/UefiCpuPkg/Include/Library/CcExitLib.h
> b/UefiCpuPkg/Include/Library/CcExitLib.h
> index 3381d583691f..2a9de5d5e8e7 100644
> --- a/UefiCpuPkg/Include/Library/CcExitLib.h
> +++ b/UefiCpuPkg/Include/Library/CcExitLib.h
> @@ -6,7 +6,7 @@
> #VC exceptions.
> - Handle #VE exception in TDX.
>
> - Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
> + Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights
> reserved.<BR>
> Copyright (c) 2020 - 2022, Intel Corporation. All rights reserved.<BR>
> SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -147,6 +147,75 @@ CcExitHandleVc (
> IN OUT EFI_SYSTEM_CONTEXT SystemContext
> );
>
> +/**
> + Report the presence of an Secure Virtual Services Module (SVSM).
> +
> + Determines the presence of an SVSM.
> +
> + @retval TRUE An SVSM is present
> + @retval FALSE An SVSM is not present
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +CcExitSnpSvsmPresent (
> + VOID
> + );
> +
> +/**
> + Report the VMPL level at which the SEV-SNP guest is running.
> +
> + Determines the VMPL level at which the guest is running. If an SVSM is
> + not present, then it must be VMPL0, otherwise return what is reported
> + by the SVSM.
> +
> + @return The VMPL level
> +
> +**/
> +UINT8
> +EFIAPI
> +CcExitSnpGetVmpl (
> + VOID
> + );
> +
> +/**
> + Perform a PVALIDATE operation for the page ranges specified.
> +
> + Validate or rescind the validation of the specified pages.
> +
> + @param[in] Info Pointer to a page state change structure
> +
> +**/
> +VOID
> +EFIAPI
> +CcExitSnpPvalidate (
> + IN SNP_PAGE_STATE_CHANGE_INFO *Info
> + );
> +
> +/**
> + Perform an RMPADJUST operation to alter the VMSA setting of a page.
> +
> + Add or remove the VMSA attribute for a page.
> +
> + @param[in] Vmsa Pointer to an SEV-ES save area page
> + @param[in] ApicId APIC ID associated with the VMSA
> + @param[in] SetVmsa Boolean indicator as to whether to set or
> + or clear the VMSA setting for the page
> +
> + @retval EFI_SUCCESS RMPADJUST operation successful
> + @retval EFI_UNSUPPORTED Operation is not supported
> + @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
> + parameter was supplied
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CcExitSnpVmsaRmpAdjust (
> + IN SEV_ES_SAVE_AREA *Vmsa,
> + IN UINT32 ApicId,
> + IN BOOLEAN SetVmsa
> + );
> +
> /**
> Handle a #VE exception.
>
> diff --git a/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
> b/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
> index 230e50705b4a..60b19c0433c7 100644
> --- a/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
> +++ b/UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c
> @@ -1,7 +1,7 @@
> /** @file
> CcExit Base Support Library.
>
> - Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
> + Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights
> reserved.<BR>
> Copyright (c) 2020 - 2022, Intel Corporation. All rights reserved.<BR>
> SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -165,6 +165,86 @@ CcExitHandleVc (
> return EFI_UNSUPPORTED;
> }
>
> +/**
> + Report the presence of an Secure Virtual Services Module (SVSM).
> +
> + Determines the presence of an SVSM.
> +
> + @retval TRUE An SVSM is present
> + @retval FALSE An SVSM is not present
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +CcExitSnpSvsmPresent (
> + VOID
> + )
> +{
> + return FALSE;
> +}
> +
> +/**
> + Report the VMPL level at which the SEV-SNP guest is running.
> +
> + Determines the VMPL level at which the guest is running. If an SVSM is
> + not present, then it must be VMPL0, otherwise return what is reported
> + by the SVSM.
> +
> + @return The VMPL level
> +
> +**/
> +UINT8
> +EFIAPI
> +CcExitSnpGetVmpl (
> + VOID
> + )
> +{
> + return 0;
> +}
> +
> +/**
> + Perform a PVALIDATE operation for the page ranges specified.
> +
> + Validate or rescind the validation of the specified pages.
> +
> + @param[in] Info Pointer to a page state change structure
> +
> +**/
> +VOID
> +EFIAPI
> +CcExitSnpPvalidate (
> + IN SNP_PAGE_STATE_CHANGE_INFO *Info
> + )
> +{
> +}
> +
> +/**
> + Perform an RMPADJUST operation to alter the VMSA setting of a page.
> +
> + Add or remove the VMSA attribute for a page.
> +
> + @param[in] Vmsa Pointer to an SEV-ES save area page
> + @param[in] ApicId APIC ID associated with the VMSA
> + @param[in] SetVmsa Boolean indicator as to whether to set or
> + or clear the VMSA setting for the page
> +
> + @retval EFI_SUCCESS RMPADJUST operation successful
> + @retval EFI_UNSUPPORTED Operation is not supported
> + @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
> + parameter was supplied
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CcExitSnpVmsaRmpAdjust (
> + IN SEV_ES_SAVE_AREA *Vmsa,
> + IN UINT32 ApicId,
> + IN BOOLEAN SetVmsa
> + )
> +{
> + return EFI_UNSUPPORTED;
> +}
> +
> /**
> Handle a #VE exception.
>
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115019): https://edk2.groups.io/g/devel/message/115019
Mute This Topic: https://groups.io/mt/103986445/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 05/16] Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (3 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 04/16] UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-26 22:13 ` [edk2-devel] [PATCH 06/16] OvmfPkg: Create a calling area used to communicate with the SVSM Lendacky, Thomas via groups.io
` (11 subsequent siblings)
16 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Add initial support for the new CcExitLib interfaces to the OvmfPkg
version of the library. The initial implementation will fully implement
the SVSM presence check API and the SVSM VMPL API, with later patches
fully implementing the other interfaces.
The SVSM presence check, CcExitSnpSvsmPresent(), determines the presence
of an SVSM by checking if an SVSM has been advertised in the SEV-SNP
Secrets Page. The SVSM VMPL API, CcExitSnpGetVmpl(), returns the VMPL
level at which the OVMF is currently running.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 102 ++++++++++++++++++++
3 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/CcExitLib/CcExitLib.inf b/OvmfPkg/Library/CcExitLib/CcExitLib.inf
index bc75cd5f5a04..2e68b12bb4e2 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitLib.inf
+++ b/OvmfPkg/Library/CcExitLib/CcExitLib.inf
@@ -1,7 +1,7 @@
## @file
# CcExitLib Library.
#
-# Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+# Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
# Copyright (C) 2020 - 2022, Intel Corporation. All rights reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -23,6 +23,7 @@ [Defines]
[Sources.common]
CcExitLib.c
+ CcExitSvsm.c
CcExitVcHandler.c
CcExitVcHandler.h
CcInstruction.c
@@ -45,3 +46,5 @@ [LibraryClasses]
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
diff --git a/OvmfPkg/Library/CcExitLib/SecCcExitLib.inf b/OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
index 811269dd2c06..7b81900a11d4 100644
--- a/OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
+++ b/OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
@@ -1,7 +1,7 @@
## @file
# VMGEXIT Support Library.
#
-# Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+# Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -22,6 +22,7 @@ [Defines]
[Sources.common]
CcExitLib.c
+ CcExitSvsm.c
CcExitVcHandler.c
CcExitVcHandler.h
CcInstruction.c
@@ -45,5 +46,7 @@ [LibraryClasses]
[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
diff --git a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
new file mode 100644
index 000000000000..fb8b762caadc
--- /dev/null
+++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
@@ -0,0 +1,102 @@
+/** @file
+ SVSM Support Library.
+
+ Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <Base.h>
+#include <Uefi.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/CcExitLib.h>
+#include <Register/Amd/Msr.h>
+#include <Register/Amd/Svsm.h>
+
+/**
+ Report the presence of an Secure Virtual Services Module (SVSM).
+
+ Determines the presence of an SVSM.
+
+ @retval TRUE An SVSM is present
+ @retval FALSE An SVSM is not present
+
+**/
+BOOLEAN
+EFIAPI
+CcExitSnpSvsmPresent (
+ VOID
+ )
+{
+ SVSM_INFORMATION *SvsmInfo;
+
+ SvsmInfo = (SVSM_INFORMATION *)(UINTN)PcdGet32 (PcdOvmfSnpSecretsBase);
+
+ return (SvsmInfo != NULL && SvsmInfo->SvsmSize != 0);
+}
+
+/**
+ Report the VMPL level at which the SEV-SNP guest is running.
+
+ Determines the VMPL level at which the guest is running. If an SVSM is
+ not present, then it must be VMPL0, otherwise return what is reported
+ by the SVSM.
+
+ @return The VMPL level
+
+**/
+UINT8
+EFIAPI
+CcExitSnpGetVmpl (
+ VOID
+ )
+{
+ SVSM_INFORMATION *SvsmInfo;
+
+ SvsmInfo = (SVSM_INFORMATION *)(UINTN)PcdGet32 (PcdOvmfSnpSecretsBase);
+
+ return CcExitSnpSvsmPresent () ? SvsmInfo->SvsmGuestVmpl : 0;
+}
+
+/**
+ Perform a PVALIDATE operation for the page ranges specified.
+
+ Validate or rescind the validation of the specified pages.
+
+ @param[in] Info Pointer to a page state change structure
+
+**/
+VOID
+EFIAPI
+CcExitSnpPvalidate (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ )
+{
+}
+
+/**
+ Perform an RMPADJUST operation to alter the VMSA setting of a page.
+
+ Add or remove the VMSA attribute for a page.
+
+ @param[in] Vmsa Pointer to an SEV-ES save area page
+ @param[in] ApicId APIC ID associated with the VMSA
+ @param[in] SetVmsa Boolean indicator as to whether to set or
+ or clear the VMSA setting for the page
+
+ @retval EFI_SUCCESS RMPADJUST operation successful
+ @retval EFI_UNSUPPORTED Operation is not supported
+ @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
+ parameter was supplied
+
+**/
+EFI_STATUS
+EFIAPI
+CcExitSnpVmsaRmpAdjust (
+ IN SEV_ES_SAVE_AREA *Vmsa,
+ IN UINT32 ApicId,
+ IN BOOLEAN SetVmsa
+ )
+{
+ return EFI_UNSUPPORTED;
+}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114631): https://edk2.groups.io/g/devel/message/114631
Mute This Topic: https://groups.io/mt/103986446/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* [edk2-devel] [PATCH 06/16] OvmfPkg: Create a calling area used to communicate with the SVSM
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (4 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 05/16] Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-26 22:13 ` [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call Lendacky, Thomas via groups.io
` (10 subsequent siblings)
16 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
An SVSM requires a calling area page whose address (CAA) is used by the
SVSM to communicate and process the SVSM request.
Add a pre-defined page area to the OvmfPkg and AmdSev packages and define
corresponding PCDs used to communicate the location and size of the area.
Keep the AmdSev package in sync with the OvmfPkg and adjust the AmdSev
launch and hash area memory locations.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/OvmfPkg.dec | 4 ++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 9 ++++++---
OvmfPkg/OvmfPkgX64.fdf | 3 +++
OvmfPkg/PlatformPei/PlatformPei.inf | 2 ++
OvmfPkg/ResetVector/ResetVector.inf | 2 ++
OvmfPkg/PlatformPei/AmdSev.c | 13 ++++++++++++-
OvmfPkg/ResetVector/ResetVector.nasmb | 6 ++++--
OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +++++++++
8 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index b44fa039f76c..f208d048ca12 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -334,6 +334,10 @@ [PcdsFixedAtBuild]
## Restrict boot to EFI applications in firmware volumes.
gUefiOvmfPkgTokenSpaceGuid.PcdBootRestrictToFirmware|FALSE|BOOLEAN|0x6c
+ ## The base address and size of the initial SVSM Calling Area.
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaBase|0|UINT32|0x6e
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaSize|0|UINT32|0x6f
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index 9dd409596780..dafa5ebacbaf 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -68,13 +68,16 @@ [FD.MEMFD]
0x00E000|0x001000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
-0x00F000|0x000C00
+0x00F000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaSize
+
+0x010000|0x000C00
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
-0x00FC00|0x000400
+0x010C00|0x000400
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
-0x010000|0x010000
+0x011000|0x00F000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
0x020000|0x0E0000
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f47ab1727e4c..f12844f674e7 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -94,6 +94,9 @@ [FD.MEMFD]
0x00E000|0x001000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
+0x00F000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf
index ad52be306560..6907cc72669e 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -127,6 +127,8 @@ [FixedPcd]
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf
index a4154ca90c28..0f5f8fec0b77 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -62,5 +62,7 @@ [FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecSvsmCaaSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index e6b602d79a05..af832d3e535e 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -1,7 +1,7 @@
/**@file
Initialize Secure Encrypted Virtualization (SEV) support
- Copyright (c) 2017 - 2020, Advanced Micro Devices. All rights reserved.<BR>
+ Copyright (c) 2017 - 2024, Advanced Micro Devices. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -465,5 +465,16 @@ SevInitializeRam (
(UINT64)(UINTN)PcdGet32 (PcdOvmfCpuidSize),
EfiReservedMemoryType
);
+
+ //
+ // The calling area memory needs to be protected until the OS can create
+ // its own calling area. Mark it as EfiReservedMemoryType so that the
+ // guest firmware and OS do not use it as a system memory.
+ //
+ BuildMemoryAllocationHob (
+ (EFI_PHYSICAL_ADDRESS)(UINTN)PcdGet32 (PcdOvmfSecSvsmCaaBase),
+ (UINT64)(UINTN)PcdGet32 (PcdOvmfSecSvsmCaaSize),
+ EfiReservedMemoryType
+ );
}
}
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5832aaa8abf7..503f81eb7025 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -3,7 +3,7 @@
; This file includes all other code files to assemble the reset vector code
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
-; Copyright (c) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+; Copyright (c) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
;------------------------------------------------------------------------------
@@ -64,6 +64,8 @@
%define SEV_SNP_SECRETS_SIZE (FixedPcdGet32 (PcdOvmfSnpSecretsSize))
%define CPUID_BASE (FixedPcdGet32 (PcdOvmfCpuidBase))
%define CPUID_SIZE (FixedPcdGet32 (PcdOvmfCpuidSize))
+%define SVSM_CAA_BASE (FixedPcdGet32 (PcdOvmfSecSvsmCaaBase))
+%define SVSM_CAA_SIZE (FixedPcdGet32 (PcdOvmfSecSvsmCaaSize))
%if (FixedPcdGet32 (PcdSevLaunchSecretBase) > 0)
; There's a reserved page for SEV secrets and hashes; the VMM will fill and
; validate the page, or mark it as a zero page.
@@ -84,7 +86,7 @@
;
%define SNP_SEC_MEM_BASE_DESC_2 (GHCB_BASE + 0x1000)
%define SNP_SEC_MEM_SIZE_DESC_2 (SEV_SNP_SECRETS_BASE - SNP_SEC_MEM_BASE_DESC_2)
-%define SNP_SEC_MEM_BASE_DESC_3 (CPUID_BASE + CPUID_SIZE + SEV_SNP_KERNEL_HASHES_SIZE)
+%define SNP_SEC_MEM_BASE_DESC_3 (SVSM_CAA_BASE + SVSM_CAA_SIZE + SEV_SNP_KERNEL_HASHES_SIZE)
%define SNP_SEC_MEM_SIZE_DESC_3 (FixedPcdGet32 (PcdOvmfPeiMemFvBase) - SNP_SEC_MEM_BASE_DESC_3)
%ifdef ARCH_X64
diff --git a/OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm b/OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm
index 8aa77d870123..cb813bdbc5a2 100644
--- a/OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm
+++ b/OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm
@@ -26,6 +26,9 @@ BITS 64
;
%define OVMF_SECTION_TYPE_CPUID 0x3
+; The SVSM Calling Area Address (CAA)
+%define OVMF_SECTION_TYPE_SVSM_CAA 0x4
+
; Kernel hashes section for measured direct boot
%define OVMF_SECTION_TYPE_KERNEL_HASHES 0x10
@@ -67,6 +70,12 @@ CpuidSec:
DD CPUID_SIZE
DD OVMF_SECTION_TYPE_CPUID
+; SVSM CAA page
+SvsmCaa:
+ DD SVSM_CAA_BASE
+ DD SVSM_CAA_SIZE
+ DD OVMF_SECTION_TYPE_SVSM_CAA
+
%if (SEV_SNP_KERNEL_HASHES_BASE > 0)
; Kernel hashes for measured direct boot, or zero page if
; there are no kernel hashes / SEV secrets
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114632): https://edk2.groups.io/g/devel/message/114632
Mute This Topic: https://groups.io/mt/103986449/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (5 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 06/16] OvmfPkg: Create a calling area used to communicate with the SVSM Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 14:40 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls Lendacky, Thomas via groups.io
` (9 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The PVALIDATE instruction can only be performed at VMPL0. An SVSM will
be present when running at VMPL1 or higher.
When an SVSM is present, use the SVSM_CORE_PVALIDATE call to perform
memory validation instead of issuing the PVALIDATE instruction directly.
This moves the current PVALIDATE functionality into the CcExitLib library,
where it can be determined whether an SVSM is present and perform the
proper operation.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c | 82 +-----
OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 311 ++++++++++++++++++++
2 files changed, 321 insertions(+), 72 deletions(-)
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
index f8bbe4d6f46b..60d47ce090fe 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
@@ -17,11 +17,10 @@
#include <Register/Amd/Ghcb.h>
#include <Register/Amd/Msr.h>
+#include <Register/Amd/Svsm.h>
#include "SnpPageStateChange.h"
-#define PAGES_PER_LARGE_ENTRY 512
-
STATIC
UINTN
MemoryStateToGhcbOp (
@@ -63,73 +62,6 @@ SnpPageStateFailureTerminate (
CpuDeadLoop ();
}
-/**
- This function issues the PVALIDATE instruction to validate or invalidate the memory
- range specified. If PVALIDATE returns size mismatch then it retry validating with
- smaller page size.
-
- */
-STATIC
-VOID
-PvalidateRange (
- IN SNP_PAGE_STATE_CHANGE_INFO *Info
- )
-{
- UINTN RmpPageSize;
- UINTN StartIndex;
- UINTN EndIndex;
- UINTN Index;
- UINTN Ret;
- EFI_PHYSICAL_ADDRESS Address;
- BOOLEAN Validate;
-
- StartIndex = Info->Header.CurrentEntry;
- EndIndex = Info->Header.EndEntry;
-
- for ( ; StartIndex <= EndIndex; StartIndex++) {
- //
- // Get the address and the page size from the Info.
- //
- Address = ((EFI_PHYSICAL_ADDRESS)Info->Entry[StartIndex].GuestFrameNumber) << EFI_PAGE_SHIFT;
- RmpPageSize = Info->Entry[StartIndex].PageSize;
- Validate = Info->Entry[StartIndex].Operation == SNP_PAGE_STATE_PRIVATE;
-
- Ret = AsmPvalidate (RmpPageSize, Validate, Address);
-
- //
- // If we fail to validate due to size mismatch then try with the
- // smaller page size. This senario will occur if the backing page in
- // the RMP entry is 4K and we are validating it as a 2MB.
- //
- if ((Ret == PVALIDATE_RET_SIZE_MISMATCH) && (RmpPageSize == PvalidatePageSize2MB)) {
- for (Index = 0; Index < PAGES_PER_LARGE_ENTRY; Index++) {
- Ret = AsmPvalidate (PvalidatePageSize4K, Validate, Address);
- if (Ret) {
- break;
- }
-
- Address = Address + EFI_PAGE_SIZE;
- }
- }
-
- //
- // If validation failed then do not continue.
- //
- if (Ret) {
- DEBUG ((
- DEBUG_ERROR,
- "%a:%a: Failed to %a address 0x%Lx Error code %d\n",
- gEfiCallerBaseName,
- __func__,
- Validate ? "Validate" : "Invalidate",
- Address,
- Ret
- ));
- SnpPageStateFailureTerminate ();
- }
- }
-}
-
STATIC
EFI_PHYSICAL_ADDRESS
BuildPageStateBuffer (
@@ -145,6 +77,7 @@ BuildPageStateBuffer (
UINTN Index;
UINTN IndexMax;
UINTN PscIndexMax;
+ UINTN SvsmIndexMax;
UINTN RmpPageSize;
// Clear the page state structure
@@ -159,11 +92,16 @@ BuildPageStateBuffer (
// exiting from the guest to the hypervisor. Maximize the number of entries
// that can be processed per exit.
//
- PscIndexMax = (IndexMax / SNP_PAGE_STATE_MAX_ENTRY) * SNP_PAGE_STATE_MAX_ENTRY;
+ PscIndexMax = (IndexMax / SNP_PAGE_STATE_MAX_ENTRY) * SNP_PAGE_STATE_MAX_ENTRY;
+ SvsmIndexMax = (IndexMax / SVSM_PVALIDATE_MAX_ENTRY) * SVSM_PVALIDATE_MAX_ENTRY;
if (PscIndexMax > 0) {
IndexMax = MIN (IndexMax, PscIndexMax);
}
+ if (SvsmIndexMax > 0) {
+ IndexMax = MIN (IndexMax, SvsmIndexMax);
+ }
+
//
// Populate the page state entry structure
//
@@ -328,7 +266,7 @@ InternalSetPageState (
// invalidate the pages before making the page shared in the RMP table.
//
if (State == SevSnpPageShared) {
- PvalidateRange (Info);
+ CcExitSnpPvalidate (Info);
}
//
@@ -341,7 +279,7 @@ InternalSetPageState (
// validate the pages after it has been added in the RMP table.
//
if (State == SevSnpPagePrivate) {
- PvalidateRange (Info);
+ CcExitSnpPvalidate (Info);
}
}
}
diff --git a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
index fb8b762caadc..43e0a357efa5 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
@@ -13,6 +13,312 @@
#include <Register/Amd/Msr.h>
#include <Register/Amd/Svsm.h>
+#define PAGES_PER_2MB_ENTRY 512
+
+/**
+ Terminate the guest using the GHCB MSR protocol.
+
+ Uses the GHCB MSR protocol to request that the guest be termiated.
+
+**/
+STATIC
+VOID
+SvsmTerminate (
+ VOID
+ )
+{
+ MSR_SEV_ES_GHCB_REGISTER Msr;
+
+ //
+ // Use the GHCB MSR Protocol to request termination by the hypervisor
+ //
+ Msr.Uint64 = 0;
+ Msr.GhcbTerminate.Function = GHCB_INFO_TERMINATE_REQUEST;
+ Msr.GhcbTerminate.ReasonCodeSet = GHCB_TERMINATE_GHCB;
+ Msr.GhcbTerminate.ReasonCode = GHCB_TERMINATE_GHCB_GENERAL;
+ AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.Uint64);
+
+ AsmVmgExit ();
+
+ ASSERT (FALSE);
+ CpuDeadLoop ();
+}
+
+/**
+ Return the address of SVSM Call Area (CAA).
+
+ Determines the address of the SVSM CAA.
+
+ @return The address of the SVSM CAA
+
+**/
+STATIC
+SVSM_CAA *
+SvsmGetCaa (
+ VOID
+ )
+{
+ SVSM_INFORMATION *SvsmInfo;
+
+ SvsmInfo = (SVSM_INFORMATION *)(UINTN)PcdGet32 (PcdOvmfSnpSecretsBase);
+
+ return CcExitSnpSvsmPresent () ? (SVSM_CAA *)SvsmInfo->SvsmCaa : NULL;
+}
+
+/**
+ Issue an SVSM request.
+
+ Invokes the SVSM to process a request on behalf of the guest.
+
+ @param[in,out] SvsmCallData Pointer to the SVSM call data
+
+ @return Contents of RAX upon return from VMGEXIT
+**/
+STATIC
+UINTN
+SvsmMsrProtocol (
+ IN OUT SVSM_CALL_DATA *SvsmCallData
+ )
+{
+ MSR_SEV_ES_GHCB_REGISTER Msr;
+ UINT64 CurrentMsr;
+ UINT8 Pending;
+ BOOLEAN InterruptState;
+ UINTN Ret;
+
+ do {
+ //
+ // Be sure that an interrupt can't cause a #VC while the GHCB MSR protocol
+ // is being used (#VC handler will ASSERT if lower 12-bits are not zero).
+ //
+ InterruptState = GetInterruptState ();
+ if (InterruptState) {
+ DisableInterrupts ();
+ }
+
+ Pending = 0;
+ SvsmCallData->CallPending = &Pending;
+
+ CurrentMsr = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+
+ Msr.Uint64 = 0;
+ Msr.SnpVmplRequest.Function = GHCB_INFO_SNP_VMPL_REQUEST;
+ Msr.SnpVmplRequest.Vmpl = 0;
+ AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.Uint64);
+
+ //
+ // Guest memory is used for the guest-SVSM communication, so fence the
+ // invocation of the VMGEXIT instruction to ensure VMSA accesses are
+ // synchronized properly.
+ //
+ MemoryFence ();
+ Ret = AsmVmgExitSvsm (SvsmCallData);
+ MemoryFence ();
+
+ Msr.Uint64 = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+
+ AsmWriteMsr64 (MSR_SEV_ES_GHCB, CurrentMsr);
+
+ if (InterruptState) {
+ EnableInterrupts ();
+ }
+
+ if (Pending != 0) {
+ SvsmTerminate ();
+ }
+
+ if ((Msr.SnpVmplResponse.Function != GHCB_INFO_SNP_VMPL_RESPONSE) ||
+ (Msr.SnpVmplResponse.ErrorCode != 0))
+ {
+ SvsmTerminate ();
+ }
+ } while (Ret == SVSM_ERR_INCOMPLETE || Ret == SVSM_ERR_BUSY);
+
+ return Ret;
+}
+
+/**
+ Issue an SVSM request to perform the PVALIDATE instruction.
+
+ Invokes the SVSM to process the PVALIDATE instruction on behalf of the
+ guest to validate or invalidate the memory range specified.
+
+ @param[in] Info Pointer to a page state change structure
+
+**/
+STATIC
+VOID
+SvsmPvalidate (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ )
+{
+ SVSM_CALL_DATA SvsmCallData;
+ SVSM_CAA *Caa;
+ SVSM_PVALIDATE_REQUEST *Request;
+ SVSM_FUNCTION Function;
+ BOOLEAN Validate;
+ UINTN Entry;
+ UINTN EntryLimit;
+ UINTN Index;
+ UINTN EndIndex;
+ UINT64 Gfn;
+ UINT64 GfnEnd;
+ UINTN Ret;
+
+ Caa = SvsmGetCaa ();
+ SetMem (Caa->SvsmBuffer, sizeof (Caa->SvsmBuffer), 0);
+
+ Function.Id.Protocol = 0;
+ Function.Id.CallId = 1;
+
+ Request = (SVSM_PVALIDATE_REQUEST *)Caa->SvsmBuffer;
+ EntryLimit = ((sizeof (Caa->SvsmBuffer) - sizeof (*Request)) /
+ sizeof (Request->Entry[0])) - 1;
+
+ SvsmCallData.Caa = Caa;
+ SvsmCallData.RaxIn = Function.Uint64;
+ SvsmCallData.RcxIn = (UINT64)(UINTN)Request;
+
+ Entry = 0;
+ Index = Info->Header.CurrentEntry;
+ EndIndex = Info->Header.EndEntry;
+
+ while (Index <= EndIndex) {
+ Validate = Info->Entry[Index].Operation == SNP_PAGE_STATE_PRIVATE;
+
+ Request->Header.Entries++;
+ Request->Entry[Entry].Bits.PageSize = Info->Entry[Index].PageSize;
+ Request->Entry[Entry].Bits.Action = (Validate == TRUE) ? 1 : 0;
+ Request->Entry[Entry].Bits.IgnoreCf = 0;
+ Request->Entry[Entry].Bits.Address = Info->Entry[Index].GuestFrameNumber;
+
+ Entry++;
+ if ((Entry > EntryLimit) || (Index == EndIndex)) {
+ Ret = SvsmMsrProtocol (&SvsmCallData);
+ if ((Ret == SVSM_ERR_PVALIDATE_FAIL_SIZE_MISMATCH) &&
+ (Request->Entry[Request->Header.Next].Bits.PageSize != 0))
+ {
+ // Calculate the Index of the entry after the entry that failed
+ // before clearing the buffer so that processing can continue
+ // from that point
+ Index = Index - (Entry - Request->Header.Next) + 2;
+
+ // Obtain the failing GFN before clearing the buffer
+ Gfn = Request->Entry[Request->Header.Next].Bits.Address;
+
+ // Clear the buffer in prep for creating all new entries
+ SetMem (Caa->SvsmBuffer, sizeof (Caa->SvsmBuffer), 0);
+ Entry = 0;
+
+ GfnEnd = Gfn + 511;
+ for ( ; Gfn <= GfnEnd; Gfn++) {
+ Request->Header.Entries++;
+ Request->Entry[Entry].Bits.PageSize = 0;
+ Request->Entry[Entry].Bits.Action = (Validate == TRUE) ? 1 : 0;
+ Request->Entry[Entry].Bits.IgnoreCf = 0;
+ Request->Entry[Entry].Bits.Address = Gfn;
+
+ Entry++;
+ if ((Entry > EntryLimit) || (Gfn == GfnEnd)) {
+ Ret = SvsmMsrProtocol (&SvsmCallData);
+ if (Ret != 0) {
+ SvsmTerminate ();
+ }
+
+ SetMem (Caa->SvsmBuffer, sizeof (Caa->SvsmBuffer), 0);
+ Entry = 0;
+ }
+ }
+
+ continue;
+ }
+
+ if (Ret != 0) {
+ SvsmTerminate ();
+ }
+
+ SetMem (Caa->SvsmBuffer, sizeof (Caa->SvsmBuffer), 0);
+ Entry = 0;
+ }
+
+ Index++;
+ }
+}
+
+/**
+ Perform the PVALIDATE instruction.
+
+ Performs the PVALIDATE instruction to validate or invalidate the memory
+ range specified.
+
+ @param[in] Info Pointer to a page state change structure
+
+**/
+STATIC
+VOID
+BasePvalidate (
+ IN SNP_PAGE_STATE_CHANGE_INFO *Info
+ )
+{
+ UINTN Index;
+ UINTN EndIndex;
+ UINTN Address;
+ UINTN RmpPageSize;
+ BOOLEAN Validate;
+ UINTN Ret;
+
+ Index = Info->Header.CurrentEntry;
+ EndIndex = Info->Header.EndEntry;
+ while (Index <= EndIndex) {
+ //
+ // Get the address and the page size from the Info.
+ //
+ Address = Info->Entry[Index].GuestFrameNumber << EFI_PAGE_SHIFT;
+ RmpPageSize = Info->Entry[Index].PageSize;
+ Validate = Info->Entry[Index].Operation == SNP_PAGE_STATE_PRIVATE;
+
+ Ret = AsmPvalidate (RmpPageSize, Validate, Address);
+
+ //
+ // If PVALIDATE of a 2M page fails due to a size mismatch, then retry
+ // the full 2M range using a page size of 4K. This can occur if RMP entry
+ // has a page size of 4K.
+ //
+ if ((Ret == PVALIDATE_RET_SIZE_MISMATCH) && (RmpPageSize == PvalidatePageSize2MB)) {
+ UINTN EndAddress;
+
+ EndAddress = Address + (PAGES_PER_2MB_ENTRY * SIZE_4KB);
+ while (Address < EndAddress) {
+ Ret = AsmPvalidate (PvalidatePageSize4K, Validate, Address);
+ if (Ret) {
+ break;
+ }
+
+ Address += SIZE_4KB;
+ }
+ }
+
+ //
+ // If validation failed then do not continue.
+ //
+ if (Ret) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a:%a: Failed to %a address 0x%Lx Error code %d\n",
+ gEfiCallerBaseName,
+ __func__,
+ Validate ? "Validate" : "Invalidate",
+ Address,
+ Ret
+ ));
+
+ SvsmTerminate ();
+ }
+
+ Index++;
+ }
+}
+
/**
Report the presence of an Secure Virtual Services Module (SVSM).
@@ -72,6 +378,11 @@ CcExitSnpPvalidate (
IN SNP_PAGE_STATE_CHANGE_INFO *Info
)
{
+ if (CcExitSnpSvsmPresent ()) {
+ SvsmPvalidate (Info);
+ } else {
+ BasePvalidate (Info);
+ }
}
/**
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114633): https://edk2.groups.io/g/devel/message/114633
Mute This Topic: https://groups.io/mt/103986455/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
2024-01-26 22:13 ` [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call Lendacky, Thomas via groups.io
@ 2024-01-29 14:40 ` Gerd Hoffmann
2024-01-29 17:34 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 14:40 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
> -/**
> - This function issues the PVALIDATE instruction to validate or invalidate the memory
> - range specified. If PVALIDATE returns size mismatch then it retry validating with
> - smaller page size.
> -
> - */
> -STATIC
> -VOID
> -PvalidateRange (
> - IN SNP_PAGE_STATE_CHANGE_INFO *Info
> - )
> --- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
> +++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
> +#define PAGES_PER_2MB_ENTRY 512
> +SvsmTerminate (
> +SvsmGetCaa (
> +SvsmMsrProtocol (
Adding these three funcions can go to a separate patch.
> +SvsmPvalidate (
> + GfnEnd = Gfn + 511;
Use PAGES_PER_2MB_ENTRY here?
> +BasePvalidate (
> + IN SNP_PAGE_STATE_CHANGE_INFO *Info
> + )
So you rename PvalidateRange() to BasePvalidate() and move it to this
place. Moving code without functional change should be done as separate
patch.
Also I'm wondering why you move the vmpl0 version of the function (which
does *not* call into the SVSM) into the CcExitSvsm.c file. The old
place looks like a better fit to me.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114706): https://edk2.groups.io/g/devel/message/114706
Mute This Topic: https://groups.io/mt/103986455/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
2024-01-29 14:40 ` Gerd Hoffmann
@ 2024-01-29 17:34 ` Lendacky, Thomas via groups.io
2024-01-31 18:40 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 17:34 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/29/24 08:40, Gerd Hoffmann wrote:
>> -/**
>> - This function issues the PVALIDATE instruction to validate or invalidate the memory
>> - range specified. If PVALIDATE returns size mismatch then it retry validating with
>> - smaller page size.
>> -
>> - */
>> -STATIC
>> -VOID
>> -PvalidateRange (
>> - IN SNP_PAGE_STATE_CHANGE_INFO *Info
>> - )
>
>> --- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>> +++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>
>> +#define PAGES_PER_2MB_ENTRY 512
>
>> +SvsmTerminate (
>> +SvsmGetCaa (
>> +SvsmMsrProtocol (
>
> Adding these three funcions can go to a separate patch.
Ok.
>
>> +SvsmPvalidate (
>
>> + GfnEnd = Gfn + 511;
>
> Use PAGES_PER_2MB_ENTRY here?
Ok.
>
>> +BasePvalidate (
>> + IN SNP_PAGE_STATE_CHANGE_INFO *Info
>> + )
>
> So you rename PvalidateRange() to BasePvalidate() and move it to this
> place. Moving code without functional change should be done as separate
> patch.
>
> Also I'm wondering why you move the vmpl0 version of the function (which
> does *not* call into the SVSM) into the CcExitSvsm.c file. The old
> place looks like a better fit to me.
Ok. Let me look at that again. That shouldn't be an issue to leave it
where it is and do a pre-patch to rename it.
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114720): https://edk2.groups.io/g/devel/message/114720
Mute This Topic: https://groups.io/mt/103986455/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
2024-01-29 17:34 ` Lendacky, Thomas via groups.io
@ 2024-01-31 18:40 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-31 18:40 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/29/24 11:34, Tom Lendacky wrote:
> On 1/29/24 08:40, Gerd Hoffmann wrote:
>>> -/**
>>> - This function issues the PVALIDATE instruction to validate or
>>> invalidate the memory
>>> - range specified. If PVALIDATE returns size mismatch then it retry
>>> validating with
>>> - smaller page size.
>>> -
>>> - */
>>> -STATIC
>>> -VOID
>>> -PvalidateRange (
>>> - IN SNP_PAGE_STATE_CHANGE_INFO *Info
>>> - )
>>
>>> --- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>>> +++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>>
>>> +#define PAGES_PER_2MB_ENTRY 512
>>
>>> +SvsmTerminate (
>>> +SvsmGetCaa (
>>> +SvsmMsrProtocol (
>>
>> Adding these three funcions can go to a separate patch.
>
> Ok.
>
>>
>>> +SvsmPvalidate (
>>
>>> + GfnEnd = Gfn + 511;
>>
>> Use PAGES_PER_2MB_ENTRY here?
>
> Ok.
>
>>
>>> +BasePvalidate (
>>> + IN SNP_PAGE_STATE_CHANGE_INFO *Info
>>> + )
>>
>> So you rename PvalidateRange() to BasePvalidate() and move it to this
>> place. Moving code without functional change should be done as separate
>> patch.
>>
>> Also I'm wondering why you move the vmpl0 version of the function (which
>> does *not* call into the SVSM) into the CcExitSvsm.c file. The old
>> place looks like a better fit to me.
>
> Ok. Let me look at that again. That shouldn't be an issue to leave it
> where it is and do a pre-patch to rename it.
I'm inclined to keep it in the new file, just because it puts the decision
making of whether to directly invoke the instruction or call the SVSM in a
single place. Take a look at the next version of the series when it comes
out and see what you think based on how I've rearranged things.
Thanks,
Tom
>
> Thanks,
> Tom
>
>>
>> take care,
>> Gerd
>>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114914): https://edk2.groups.io/g/devel/message/114914
Mute This Topic: https://groups.io/mt/103986455/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (6 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 07/16] OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 14:46 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 09/16] UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA Lendacky, Thomas via groups.io
` (8 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The RMPADJUST instruction is used to alter the VMSA attribute of a page,
but the VMSA attribute can only be changed when running at VMPL0. When
an SVSM is present, use the SVSM_CORE_CREATE_VCPU and SVSM_CORE_DELTE_VCPU
calls to add or remove the VMSA attribute on a page instead of issuing
the RMPADJUST instruction directly.
Implement the CcExitSnpVmsaRmpAdjust() API to perform the proper operation
to update the VMSA attribute.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 100 +++++++++++++++++++-
1 file changed, 99 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
index 43e0a357efa5..3459338b2033 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
@@ -137,6 +137,103 @@ SvsmMsrProtocol (
return Ret;
}
+/**
+ Perform an RMPADJUST operation to alter the VMSA setting of a page.
+
+ Add or remove the VMSA attribute for a page.
+
+ @param[in] Vmsa Pointer to an SEV-ES save area page
+ @param[in] ApicId APIC ID associated with the VMSA
+ @param[in] SetVmsa Boolean indicator as to whether to set or
+ or clear the VMSA setting for the page
+
+ @retval EFI_SUCCESS RMPADJUST operation successful
+ @retval EFI_UNSUPPORTED Operation is not supported
+ @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
+ parameter was supplied
+
+**/
+EFI_STATUS
+EFIAPI
+SvsmVmsaRmpAdjust (
+ IN SEV_ES_SAVE_AREA *Vmsa,
+ IN UINT32 ApicId,
+ IN BOOLEAN SetVmsa
+ )
+{
+ SVSM_CALL_DATA SvsmCallData;
+ SVSM_FUNCTION Function;
+ UINTN Ret;
+
+ SvsmCallData.Caa = SvsmGetCaa ();
+
+ Function.Id.Protocol = 0;
+
+ if (SetVmsa) {
+ Function.Id.CallId = 2;
+
+ SvsmCallData.RaxIn = Function.Uint64;
+ SvsmCallData.RcxIn = (UINT64)(UINTN)Vmsa;
+ SvsmCallData.RdxIn = (UINT64)(UINTN)Vmsa + SIZE_4KB;
+ SvsmCallData.R8In = ApicId;
+ } else {
+ Function.Id.CallId = 3;
+
+ SvsmCallData.RaxIn = Function.Uint64;
+ SvsmCallData.RcxIn = (UINT64)(UINTN)Vmsa;
+ }
+
+ Ret = SvsmMsrProtocol (&SvsmCallData);
+
+ return (Ret == 0) ? EFI_SUCCESS : EFI_INVALID_PARAMETER;
+}
+
+/**
+ Perform an RMPADJUST operation to alter the VMSA setting of a page.
+
+ Add or remove the VMSA attribute for a page.
+
+ @param[in] Vmsa Pointer to an SEV-ES save area page
+ @param[in] ApicId APIC ID associated with the VMSA
+ @param[in] SetVmsa Boolean indicator as to whether to set or
+ or clear the VMSA setting for the page
+
+ @retval EFI_SUCCESS RMPADJUST operation successful
+ @retval EFI_UNSUPPORTED Operation is not supported
+ @retval EFI_INVALID_PARAMETER RMPADJUST operation failed, an invalid
+ parameter was supplied
+
+**/
+EFI_STATUS
+EFIAPI
+BaseVmsaRmpAdjust (
+ IN SEV_ES_SAVE_AREA *Vmsa,
+ IN UINT32 ApicId,
+ IN BOOLEAN SetVmsa
+ )
+{
+ UINT64 Rdx;
+ UINT32 Ret;
+
+ //
+ // The RMPADJUST instruction is used to set or clear the VMSA bit for a
+ // page. The VMSA change is only made when running at VMPL0 and is ignored
+ // otherwise. If too low a target VMPL is specified, the instruction can
+ // succeed without changing the VMSA bit when not running at VMPL0. Using a
+ // target VMPL level of 1, RMPADJUST will return a FAIL_PERMISSION error if
+ // not running at VMPL0, thus ensuring that the VMSA bit is set appropriately
+ // when no error is returned.
+ //
+ Rdx = 1;
+ if (SetVmsa) {
+ Rdx |= RMPADJUST_VMSA_PAGE_BIT;
+ }
+
+ Ret = AsmRmpAdjust ((UINT64)(UINTN)Vmsa, 0, Rdx);
+
+ return (Ret == 0) ? EFI_SUCCESS : EFI_INVALID_PARAMETER;
+}
+
/**
Issue an SVSM request to perform the PVALIDATE instruction.
@@ -409,5 +506,6 @@ CcExitSnpVmsaRmpAdjust (
IN BOOLEAN SetVmsa
)
{
- return EFI_UNSUPPORTED;
+ return CcExitSnpSvsmPresent () ? SvsmVmsaRmpAdjust (Vmsa, ApicId, SetVmsa)
+ : BaseVmsaRmpAdjust (Vmsa, ApicId, SetVmsa);
}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114634): https://edk2.groups.io/g/devel/message/114634
Mute This Topic: https://groups.io/mt/103986458/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
2024-01-26 22:13 ` [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls Lendacky, Thomas via groups.io
@ 2024-01-29 14:46 ` Gerd Hoffmann
2024-01-29 17:37 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 14:46 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
> +EFIAPI
> +BaseVmsaRmpAdjust (
> + IN SEV_ES_SAVE_AREA *Vmsa,
> + IN UINT32 ApicId,
> + IN BOOLEAN SetVmsa
> + )
Replaces SevSnpRmpAdjust removed in patch #9.
Moving the code should be a separate patch, or don't move the code
(simliat to patch #7).
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114707): https://edk2.groups.io/g/devel/message/114707
Mute This Topic: https://groups.io/mt/103986458/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
2024-01-29 14:46 ` Gerd Hoffmann
@ 2024-01-29 17:37 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 17:37 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/29/24 08:46, Gerd Hoffmann wrote:
>> +EFIAPI
>> +BaseVmsaRmpAdjust (
>> + IN SEV_ES_SAVE_AREA *Vmsa,
>> + IN UINT32 ApicId,
>> + IN BOOLEAN SetVmsa
>> + )
>
> Replaces SevSnpRmpAdjust removed in patch #9.
> Moving the code should be a separate patch, or don't move the code
> (simliat to patch #7).
Ok, let me look into it some more.
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114721): https://edk2.groups.io/g/devel/message/114721
Mute This Topic: https://groups.io/mt/103986458/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 09/16] UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (7 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 08/16] OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-02-02 6:07 ` Ni, Ray
2024-01-26 22:13 ` [edk2-devel] [PATCH 10/16] MdePkg: GHCB APIC ID retrieval support definitions Lendacky, Thomas via groups.io
` (7 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The RMPADJUST instruction is used to change the VMSA attribute of a page,
but the VMSA attribute can only be changed when running at VMPL0. When an
SVSM is present, use the SVSM_CORE_CREATE_VCPU and SVSM_CORE_DELTE_VCPU
calls to change the VMSA attribute on a page instead of issuing the
RMPADJUST instruction directly.
Implement the CcExitSnpVmsaRmpAdjust() API to perform the appropriate
operation to change the VMSA attribute based on the presence of an SVSM.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
UefiCpuPkg/Library/MpInitLib/MpLib.h | 14 ------
UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 20 --------
UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 53 +++-----------------
3 files changed, 6 insertions(+), 81 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index a96a6389c17d..6e2137cb17cd 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -870,20 +870,6 @@ FillExchangeInfoDataSevEs (
IN volatile MP_CPU_EXCHANGE_INFO *ExchangeInfo
);
-/**
- Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
-
- @param[in] PageAddress
- @param[in] VmsaPage
-
- @return RMPADJUST return value
-**/
-UINT32
-SevSnpRmpAdjust (
- IN EFI_PHYSICAL_ADDRESS PageAddress,
- IN BOOLEAN VmsaPage
- );
-
/**
Create an SEV-SNP AP save area (VMSA) for use in running the vCPU.
diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
index c83144285b68..a2b8a5b3f516 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
@@ -48,23 +48,3 @@ SevSnpCreateAP (
//
ASSERT (FALSE);
}
-
-/**
- Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
-
- @param[in] PageAddress
- @param[in] VmsaPage
-
- @return RMPADJUST return value
-**/
-UINT32
-SevSnpRmpAdjust (
- IN EFI_PHYSICAL_ADDRESS PageAddress,
- IN BOOLEAN VmsaPage
- )
-{
- //
- // RMPADJUST is not supported in 32-bit mode
- //
- return RETURN_UNSUPPORTED;
-}
diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
index c9f0984f41a2..db9a37fbbd19 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
@@ -38,20 +38,15 @@ SevSnpPerformApAction (
BOOLEAN InterruptState;
UINT64 ExitInfo1;
UINT64 ExitInfo2;
- UINT32 RmpAdjustStatus;
UINT64 VmgExitStatus;
+ EFI_STATUS VmsaStatus;
if (Action == SVM_VMGEXIT_SNP_AP_CREATE) {
//
- // To turn the page into a recognized VMSA page, issue RMPADJUST:
- // Target VMPL but numerically higher than current VMPL
- // Target PermissionMask is not used
+ // Turn the page into a recognized VMSA page.
//
- RmpAdjustStatus = SevSnpRmpAdjust (
- (EFI_PHYSICAL_ADDRESS)(UINTN)SaveArea,
- TRUE
- );
- if (RmpAdjustStatus != 0) {
+ VmsaStatus = CcExitSnpVmsaRmpAdjust (SaveArea, ApicId, TRUE);
+ if (EFI_ERROR (VmsaStatus)) {
DEBUG ((DEBUG_INFO, "SEV-SNP: RMPADJUST failed for VMSA creation\n"));
ASSERT (FALSE);
@@ -94,11 +89,8 @@ SevSnpPerformApAction (
// Make the current VMSA not runnable and accessible to be
// reprogrammed.
//
- RmpAdjustStatus = SevSnpRmpAdjust (
- (EFI_PHYSICAL_ADDRESS)(UINTN)SaveArea,
- FALSE
- );
- if (RmpAdjustStatus != 0) {
+ VmsaStatus = CcExitSnpVmsaRmpAdjust (SaveArea, ApicId, FALSE);
+ if (EFI_ERROR (VmsaStatus)) {
DEBUG ((DEBUG_INFO, "SEV-SNP: RMPADJUST failed for VMSA reset\n"));
ASSERT (FALSE);
@@ -292,36 +284,3 @@ SevSnpCreateAP (
SevSnpCreateSaveArea (CpuMpData, CpuData, ApicId);
}
}
-
-/**
- Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
-
- @param[in] PageAddress
- @param[in] VmsaPage
-
- @return RMPADJUST return value
-**/
-UINT32
-SevSnpRmpAdjust (
- IN EFI_PHYSICAL_ADDRESS PageAddress,
- IN BOOLEAN VmsaPage
- )
-{
- UINT64 Rdx;
-
- //
- // The RMPADJUST instruction is used to set or clear the VMSA bit for a
- // page. The VMSA change is only made when running at VMPL0 and is ignored
- // otherwise. If too low a target VMPL is specified, the instruction can
- // succeed without changing the VMSA bit when not running at VMPL0. Using a
- // target VMPL level of 1, RMPADJUST will return a FAIL_PERMISSION error if
- // not running at VMPL0, thus ensuring that the VMSA bit is set appropriately
- // when no error is returned.
- //
- Rdx = 1;
- if (VmsaPage) {
- Rdx |= RMPADJUST_VMSA_PAGE_BIT;
- }
-
- return AsmRmpAdjust ((UINT64)PageAddress, 0, Rdx);
-}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114635): https://edk2.groups.io/g/devel/message/114635
Mute This Topic: https://groups.io/mt/103986460/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 09/16] UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
2024-01-26 22:13 ` [edk2-devel] [PATCH 09/16] UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA Lendacky, Thomas via groups.io
@ 2024-02-02 6:07 ` Ni, Ray
0 siblings, 0 replies; 56+ messages in thread
From: Ni, Ray @ 2024-02-02 6:07 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
Acked-by: Ray Ni <ray.ni@INtel.com>
Thanks,
Ray
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael Roth
> <michael.roth@amd.com>
> Subject: [PATCH 09/16] UefiCpuPkg/MpInitLib: Use
> CcExitSnpVmsaRmpAdjust() to set/clear VMSA
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> The RMPADJUST instruction is used to change the VMSA attribute of a page,
> but the VMSA attribute can only be changed when running at VMPL0. When
> an
> SVSM is present, use the SVSM_CORE_CREATE_VCPU and
> SVSM_CORE_DELTE_VCPU
> calls to change the VMSA attribute on a page instead of issuing the
> RMPADJUST instruction directly.
>
> Implement the CcExitSnpVmsaRmpAdjust() API to perform the appropriate
> operation to change the VMSA attribute based on the presence of an SVSM.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> UefiCpuPkg/Library/MpInitLib/MpLib.h | 14 ------
> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 20 --------
> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 53 +++-----------------
> 3 files changed, 6 insertions(+), 81 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index a96a6389c17d..6e2137cb17cd 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -870,20 +870,6 @@ FillExchangeInfoDataSevEs (
> IN volatile MP_CPU_EXCHANGE_INFO *ExchangeInfo
> );
>
> -/**
> - Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
> -
> - @param[in] PageAddress
> - @param[in] VmsaPage
> -
> - @return RMPADJUST return value
> -**/
> -UINT32
> -SevSnpRmpAdjust (
> - IN EFI_PHYSICAL_ADDRESS PageAddress,
> - IN BOOLEAN VmsaPage
> - );
> -
> /**
> Create an SEV-SNP AP save area (VMSA) for use in running the vCPU.
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
> b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
> index c83144285b68..a2b8a5b3f516 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
> @@ -48,23 +48,3 @@ SevSnpCreateAP (
> //
> ASSERT (FALSE);
> }
> -
> -/**
> - Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
> -
> - @param[in] PageAddress
> - @param[in] VmsaPage
> -
> - @return RMPADJUST return value
> -**/
> -UINT32
> -SevSnpRmpAdjust (
> - IN EFI_PHYSICAL_ADDRESS PageAddress,
> - IN BOOLEAN VmsaPage
> - )
> -{
> - //
> - // RMPADJUST is not supported in 32-bit mode
> - //
> - return RETURN_UNSUPPORTED;
> -}
> diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> index c9f0984f41a2..db9a37fbbd19 100644
> --- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> +++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> @@ -38,20 +38,15 @@ SevSnpPerformApAction (
> BOOLEAN InterruptState;
> UINT64 ExitInfo1;
> UINT64 ExitInfo2;
> - UINT32 RmpAdjustStatus;
> UINT64 VmgExitStatus;
> + EFI_STATUS VmsaStatus;
>
> if (Action == SVM_VMGEXIT_SNP_AP_CREATE) {
> //
> - // To turn the page into a recognized VMSA page, issue RMPADJUST:
> - // Target VMPL but numerically higher than current VMPL
> - // Target PermissionMask is not used
> + // Turn the page into a recognized VMSA page.
> //
> - RmpAdjustStatus = SevSnpRmpAdjust (
> - (EFI_PHYSICAL_ADDRESS)(UINTN)SaveArea,
> - TRUE
> - );
> - if (RmpAdjustStatus != 0) {
> + VmsaStatus = CcExitSnpVmsaRmpAdjust (SaveArea, ApicId, TRUE);
> + if (EFI_ERROR (VmsaStatus)) {
> DEBUG ((DEBUG_INFO, "SEV-SNP: RMPADJUST failed for VMSA
> creation\n"));
> ASSERT (FALSE);
>
> @@ -94,11 +89,8 @@ SevSnpPerformApAction (
> // Make the current VMSA not runnable and accessible to be
> // reprogrammed.
> //
> - RmpAdjustStatus = SevSnpRmpAdjust (
> - (EFI_PHYSICAL_ADDRESS)(UINTN)SaveArea,
> - FALSE
> - );
> - if (RmpAdjustStatus != 0) {
> + VmsaStatus = CcExitSnpVmsaRmpAdjust (SaveArea, ApicId, FALSE);
> + if (EFI_ERROR (VmsaStatus)) {
> DEBUG ((DEBUG_INFO, "SEV-SNP: RMPADJUST failed for VMSA reset\n"));
> ASSERT (FALSE);
>
> @@ -292,36 +284,3 @@ SevSnpCreateAP (
> SevSnpCreateSaveArea (CpuMpData, CpuData, ApicId);
> }
> }
> -
> -/**
> - Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
> -
> - @param[in] PageAddress
> - @param[in] VmsaPage
> -
> - @return RMPADJUST return value
> -**/
> -UINT32
> -SevSnpRmpAdjust (
> - IN EFI_PHYSICAL_ADDRESS PageAddress,
> - IN BOOLEAN VmsaPage
> - )
> -{
> - UINT64 Rdx;
> -
> - //
> - // The RMPADJUST instruction is used to set or clear the VMSA bit for a
> - // page. The VMSA change is only made when running at VMPL0 and is
> ignored
> - // otherwise. If too low a target VMPL is specified, the instruction can
> - // succeed without changing the VMSA bit when not running at VMPL0.
> Using a
> - // target VMPL level of 1, RMPADJUST will return a FAIL_PERMISSION error
> if
> - // not running at VMPL0, thus ensuring that the VMSA bit is set
> appropriately
> - // when no error is returned.
> - //
> - Rdx = 1;
> - if (VmsaPage) {
> - Rdx |= RMPADJUST_VMSA_PAGE_BIT;
> - }
> -
> - return AsmRmpAdjust ((UINT64)PageAddress, 0, Rdx);
> -}
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115020): https://edk2.groups.io/g/devel/message/115020
Mute This Topic: https://groups.io/mt/103986460/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 10/16] MdePkg: GHCB APIC ID retrieval support definitions
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (8 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 09/16] UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 14:52 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD Lendacky, Thomas via groups.io
` (6 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
When an SVSM is present, starting the APs requires knowledge of the APIC
IDs. Create the definitions required to retrieve and hold the APIC ID
information of all the vCPUs present in the guest.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
MdePkg/Include/Register/Amd/Ghcb.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
index 29b2e45d0163..cb581b14723d 100644
--- a/MdePkg/Include/Register/Amd/Ghcb.h
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -56,6 +56,7 @@
#define SVM_EXIT_AP_JUMP_TABLE 0x80000005ULL
#define SVM_EXIT_SNP_PAGE_STATE_CHANGE 0x80000010ULL
#define SVM_EXIT_SNP_AP_CREATION 0x80000013ULL
+#define SVM_EXIT_GET_APIC_IDS 0x80000017ULL
#define SVM_EXIT_HYPERVISOR_FEATURES 0x8000FFFDULL
#define SVM_EXIT_UNSUPPORTED 0x8000FFFFULL
@@ -170,6 +171,7 @@ typedef union {
#define GHCB_HV_FEATURES_SNP_AP_CREATE (GHCB_HV_FEATURES_SNP | BIT1)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION (GHCB_HV_FEATURES_SNP_AP_CREATE | BIT2)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION_TIMER (GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION | BIT3)
+#define GHCB_HV_FEATURES_APIC_ID_LIST BIT4
//
// SNP Page State Change.
@@ -203,6 +205,14 @@ typedef struct {
#define SNP_PAGE_STATE_MAX_ENTRY \
((sizeof (((GHCB *)0)->SharedBuffer) - sizeof (SNP_PAGE_STATE_HEADER)) / sizeof (SNP_PAGE_STATE_ENTRY))
+//
+// Get APIC IDs
+//
+typedef struct {
+ UINT32 NumEntries;
+ UINT32 ApicIds[];
+} GHCB_APIC_IDS;
+
//
// SEV-ES save area mapping structures used for SEV-SNP AP Creation.
// Only the fields required to be set to a non-zero value are defined.
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114636): https://edk2.groups.io/g/devel/message/114636
Mute This Topic: https://groups.io/mt/103986461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 10/16] MdePkg: GHCB APIC ID retrieval support definitions
2024-01-26 22:13 ` [edk2-devel] [PATCH 10/16] MdePkg: GHCB APIC ID retrieval support definitions Lendacky, Thomas via groups.io
@ 2024-01-29 14:52 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 14:52 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:09PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> When an SVSM is present, starting the APs requires knowledge of the APIC
> IDs. Create the definitions required to retrieve and hold the APIC ID
> information of all the vCPUs present in the guest.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> MdePkg/Include/Register/Amd/Ghcb.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
> index 29b2e45d0163..cb581b14723d 100644
> --- a/MdePkg/Include/Register/Amd/Ghcb.h
> +++ b/MdePkg/Include/Register/Amd/Ghcb.h
> @@ -56,6 +56,7 @@
> #define SVM_EXIT_AP_JUMP_TABLE 0x80000005ULL
> #define SVM_EXIT_SNP_PAGE_STATE_CHANGE 0x80000010ULL
> #define SVM_EXIT_SNP_AP_CREATION 0x80000013ULL
> +#define SVM_EXIT_GET_APIC_IDS 0x80000017ULL
> #define SVM_EXIT_HYPERVISOR_FEATURES 0x8000FFFDULL
> #define SVM_EXIT_UNSUPPORTED 0x8000FFFFULL
>
> @@ -170,6 +171,7 @@ typedef union {
> #define GHCB_HV_FEATURES_SNP_AP_CREATE (GHCB_HV_FEATURES_SNP | BIT1)
> #define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION (GHCB_HV_FEATURES_SNP_AP_CREATE | BIT2)
> #define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION_TIMER (GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION | BIT3)
> +#define GHCB_HV_FEATURES_APIC_ID_LIST BIT4
>
> //
> // SNP Page State Change.
> @@ -203,6 +205,14 @@ typedef struct {
> #define SNP_PAGE_STATE_MAX_ENTRY \
> ((sizeof (((GHCB *)0)->SharedBuffer) - sizeof (SNP_PAGE_STATE_HEADER)) / sizeof (SNP_PAGE_STATE_ENTRY))
>
> +//
> +// Get APIC IDs
> +//
> +typedef struct {
> + UINT32 NumEntries;
> + UINT32 ApicIds[];
> +} GHCB_APIC_IDS;
So with GHCB being one page in size this interface
can handle at most 1023 vCPUs, right?
Any plans to handle guest larger than that?
Given this just adds the interface defined by the spec so this is a
concern for the spec not the patch:
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114708): https://edk2.groups.io/g/devel/message/114708
Mute This Topic: https://groups.io/mt/103986461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (9 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 10/16] MdePkg: GHCB APIC ID retrieval support definitions Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 14:57 ` Gerd Hoffmann
2024-02-02 6:08 ` Ni, Ray
2024-01-26 22:13 ` [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor Lendacky, Thomas via groups.io
` (5 subsequent siblings)
16 siblings, 2 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Create a PCD that can be used to set and get the APIC ID information that
is required for starting APs when an SVSM is present.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
UefiCpuPkg/UefiCpuPkg.dec | 7 ++++++-
UefiCpuPkg/UefiCpuPkg.uni | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 571b59b36f0a..5ffab58189d9 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -2,7 +2,7 @@
# This Package provides UEFI compatible CPU modules and libraries.
#
# Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.<BR>
-# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.<BR>
+# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -477,5 +477,10 @@ [PcdsDynamic, PcdsDynamicEx]
# @Prompt GHCB Hypervisor Features
gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures|0x0|UINT64|0x60000018
+ ## This dynamic PCD contains the address of the APIC ID list obtained through the GHCB GET APIC IDS
+ # VMGEXIT defined in the version 3 of GHCB spec.
+ # @Prompt SEV-ES CPU APIC ID List
+ gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds|0x0|UINT64|0x6000001A
+
[UserExtensions.TianoCore."ExtraFiles"]
UefiCpuPkgExtra.uni
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index d17bcfd10c7a..329255a0efd4 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -301,3 +301,6 @@
#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_PROMPT #language en-US "Specify the size of the SEV-ES work area"
#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_HELP #language en-US "Specifies the size of the work area used by an SEV-ES guest."
+
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_PROMPT #language en-US "Specifies the address of the APIC ID list."
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_HELP #language en-US "Set to the address of the APIC ID list retrieved from the hypervisor, zero if unavailable."
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114637): https://edk2.groups.io/g/devel/message/114637
Mute This Topic: https://groups.io/mt/103986462/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
2024-01-26 22:13 ` [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD Lendacky, Thomas via groups.io
@ 2024-01-29 14:57 ` Gerd Hoffmann
2024-02-02 6:08 ` Ni, Ray
1 sibling, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 14:57 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:10PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> Create a PCD that can be used to set and get the APIC ID information that
> is required for starting APs when an SVSM is present.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114710): https://edk2.groups.io/g/devel/message/114710
Mute This Topic: https://groups.io/mt/103986462/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
2024-01-26 22:13 ` [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD Lendacky, Thomas via groups.io
2024-01-29 14:57 ` Gerd Hoffmann
@ 2024-02-02 6:08 ` Ni, Ray
2024-02-02 22:56 ` Lendacky, Thomas via groups.io
1 sibling, 1 reply; 56+ messages in thread
From: Ni, Ray @ 2024-02-02 6:08 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
Can the APIC ID list be defined by a GUIDed HOB?
I prefer that we do not use dynamic PCDs to pass the information from other components to MP code.
Thanks,
Ray
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael Roth
> <michael.roth@amd.com>
> Subject: [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> Create a PCD that can be used to set and get the APIC ID information that
> is required for starting APs when an SVSM is present.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> UefiCpuPkg/UefiCpuPkg.dec | 7 ++++++-
> UefiCpuPkg/UefiCpuPkg.uni | 3 +++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index 571b59b36f0a..5ffab58189d9 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -2,7 +2,7 @@
> # This Package provides UEFI compatible CPU modules and libraries.
> #
> # Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.<BR>
> -# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.<BR>
> +# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights
> reserved.<BR>
> #
> # SPDX-License-Identifier: BSD-2-Clause-Patent
> #
> @@ -477,5 +477,10 @@ [PcdsDynamic, PcdsDynamicEx]
> # @Prompt GHCB Hypervisor Features
>
> gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures|0x0|UINT64|0x60
> 000018
>
> + ## This dynamic PCD contains the address of the APIC ID list obtained
> through the GHCB GET APIC IDS
> + # VMGEXIT defined in the version 3 of GHCB spec.
> + # @Prompt SEV-ES CPU APIC ID List
> +
> gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds|0x0|UINT64|0x6000001A
> +
> [UserExtensions.TianoCore."ExtraFiles"]
> UefiCpuPkgExtra.uni
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
> index d17bcfd10c7a..329255a0efd4 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -301,3 +301,6 @@
> #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_PROMPT
> #language en-US "Specify the size of the SEV-ES work area"
>
> #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_HELP
> #language en-US "Specifies the size of the work area used by an SEV-ES
> guest."
> +
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_PROMPT
> #language en-US "Specifies the address of the APIC ID list."
> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_HELP
> #language en-US "Set to the address of the APIC ID list retrieved from the
> hypervisor, zero if unavailable."
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115021): https://edk2.groups.io/g/devel/message/115021
Mute This Topic: https://groups.io/mt/103986462/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
2024-02-02 6:08 ` Ni, Ray
@ 2024-02-02 22:56 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-02-02 22:56 UTC (permalink / raw)
To: Ni, Ray, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
On 2/2/24 00:08, Ni, Ray wrote:
> Can the APIC ID list be defined by a GUIDed HOB?
> I prefer that we do not use dynamic PCDs to pass the information from other components to MP code.
Yes, I can create a GUIDed data HOB.
Thanks,
Tom
>
> Thanks,
> Ray
>> -----Original Message-----
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>> Sent: Saturday, January 27, 2024 6:13 AM
>> To: devel@edk2.groups.io
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
>> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
>> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
>> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
>> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
>> <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael Roth
>> <michael.roth@amd.com>
>> Subject: [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> Create a PCD that can be used to set and get the APIC ID information that
>> is required for starting APs when an SVSM is present.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> UefiCpuPkg/UefiCpuPkg.dec | 7 ++++++-
>> UefiCpuPkg/UefiCpuPkg.uni | 3 +++
>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>> index 571b59b36f0a..5ffab58189d9 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>> @@ -2,7 +2,7 @@
>> # This Package provides UEFI compatible CPU modules and libraries.
>> #
>> # Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.<BR>
>> -# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.<BR>
>> +# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights
>> reserved.<BR>
>> #
>> # SPDX-License-Identifier: BSD-2-Clause-Patent
>> #
>> @@ -477,5 +477,10 @@ [PcdsDynamic, PcdsDynamicEx]
>> # @Prompt GHCB Hypervisor Features
>>
>> gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures|0x0|UINT64|0x60
>> 000018
>>
>> + ## This dynamic PCD contains the address of the APIC ID list obtained
>> through the GHCB GET APIC IDS
>> + # VMGEXIT defined in the version 3 of GHCB spec.
>> + # @Prompt SEV-ES CPU APIC ID List
>> +
>> gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds|0x0|UINT64|0x6000001A
>> +
>> [UserExtensions.TianoCore."ExtraFiles"]
>> UefiCpuPkgExtra.uni
>> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
>> index d17bcfd10c7a..329255a0efd4 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.uni
>> +++ b/UefiCpuPkg/UefiCpuPkg.uni
>> @@ -301,3 +301,6 @@
>> #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_PROMPT
>> #language en-US "Specify the size of the SEV-ES work area"
>>
>> #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaSize_HELP
>> #language en-US "Specifies the size of the work area used by an SEV-ES
>> guest."
>> +
>> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_PROMPT
>> #language en-US "Specifies the address of the APIC ID list."
>> +#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevSnpApicIds_HELP
>> #language en-US "Set to the address of the APIC ID list retrieved from the
>> hypervisor, zero if unavailable."
>> --
>> 2.42.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115071): https://edk2.groups.io/g/devel/message/115071
Mute This Topic: https://groups.io/mt/103986462/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (10 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 11/16] UefiCpuPkg: Create APIC ID list PCD Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 15:00 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set Lendacky, Thomas via groups.io
` (4 subsequent siblings)
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
If the hypervisor supports retrieval of the vCPU APIC IDs, retrieve
them before any APs are actually started. The APIC IDs can be used
to start the APs for any SEV-SNP guest, but is a requirement for an
SEV-SNP guest that is running under an SVSM.
After retrieving the APIC IDs, save the address of the APIC ID data
structure in the PcdSevSnpApicIds PCD.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/PlatformPei/PlatformPei.inf | 1 +
OvmfPkg/PlatformPei/AmdSev.c | 87 ++++++++++++++++++++
2 files changed, 88 insertions(+)
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf
index 6907cc72669e..6379f66b627d 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -116,6 +116,7 @@ [Pcd]
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures
gEfiMdeModulePkgTokenSpaceGuid.PcdTdxSharedBitMask
+ gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds
[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index af832d3e535e..d8a30b6e1613 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -31,6 +31,85 @@ GetHypervisorFeature (
VOID
);
+/**
+ Retrieve APIC IDs from the hypervisor.
+
+**/
+STATIC
+VOID
+AmdSevSnpGetApicIds (
+ VOID
+ )
+{
+ MSR_SEV_ES_GHCB_REGISTER Msr;
+ GHCB *Ghcb;
+ BOOLEAN InterruptState;
+ UINT64 VmgExitStatus;
+ UINT64 PageCount;
+ BOOLEAN PageCountValid;
+ VOID *ApicIds;
+ RETURN_STATUS Status;
+
+ Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+ Ghcb = Msr.Ghcb;
+
+ PageCount = 0;
+ PageCountValid = FALSE;
+
+ CcExitVmgInit (Ghcb, &InterruptState);
+ Ghcb->SaveArea.Rax = PageCount;
+ CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
+ VmgExitStatus = CcExitVmgExit (Ghcb, SVM_EXIT_GET_APIC_IDS, 0, 0);
+ if (CcExitVmgIsOffsetValid (Ghcb, GhcbRax)) {
+ PageCount = Ghcb->SaveArea.Rax;
+ PageCountValid = TRUE;
+ }
+
+ CcExitVmgDone (Ghcb, InterruptState);
+
+ ASSERT (VmgExitStatus == 0);
+ ASSERT (PageCountValid);
+ if ((VmgExitStatus != 0) || !PageCountValid) {
+ return;
+ }
+
+ //
+ // Allocate the memory for the APIC IDs
+ //
+ ApicIds = AllocateReservedPages ((UINTN)PageCount);
+ ASSERT (ApicIds != NULL);
+
+ Status = MemEncryptSevClearPageEncMask (
+ 0,
+ (UINTN)ApicIds,
+ (UINTN)PageCount
+ );
+ ASSERT_RETURN_ERROR (Status);
+
+ ZeroMem (ApicIds, EFI_PAGES_TO_SIZE ((UINTN)PageCount));
+
+ PageCountValid = FALSE;
+
+ CcExitVmgInit (Ghcb, &InterruptState);
+ Ghcb->SaveArea.Rax = PageCount;
+ CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
+ VmgExitStatus = CcExitVmgExit (Ghcb, SVM_EXIT_GET_APIC_IDS, (UINTN)ApicIds, 0);
+ if (CcExitVmgIsOffsetValid (Ghcb, GhcbRax) && (Ghcb->SaveArea.Rax == PageCount)) {
+ PageCountValid = TRUE;
+ }
+
+ CcExitVmgDone (Ghcb, InterruptState);
+
+ ASSERT (VmgExitStatus == 0);
+ ASSERT (PageCountValid);
+ if ((VmgExitStatus != 0) || !PageCountValid) {
+ FreePages (ApicIds, (UINTN)PageCount);
+ return;
+ }
+
+ Status = PcdSet64S (PcdSevSnpApicIds, (UINTN)ApicIds);
+}
+
/**
Initialize SEV-SNP support if running as an SEV-SNP guest.
@@ -78,6 +157,14 @@ AmdSevSnpInitialize (
}
}
}
+
+ //
+ // Retrieve the APIC IDs if the hypervisor supports it. These will be used
+ // to always start APs using SNP AP Create.
+ //
+ if ((HvFeatures & GHCB_HV_FEATURES_APIC_ID_LIST) == GHCB_HV_FEATURES_APIC_ID_LIST) {
+ AmdSevSnpGetApicIds ();
+ }
}
/**
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114638): https://edk2.groups.io/g/devel/message/114638
Mute This Topic: https://groups.io/mt/103986465/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
2024-01-26 22:13 ` [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor Lendacky, Thomas via groups.io
@ 2024-01-29 15:00 ` Gerd Hoffmann
2024-01-29 17:49 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 15:00 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:11PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> If the hypervisor supports retrieval of the vCPU APIC IDs, retrieve
> them before any APs are actually started. The APIC IDs can be used
> to start the APs for any SEV-SNP guest, but is a requirement for an
> SEV-SNP guest that is running under an SVSM.
> + ApicIds = AllocateReservedPages ((UINTN)PageCount);
> + VmgExitStatus = CcExitVmgExit (Ghcb, SVM_EXIT_GET_APIC_IDS, (UINTN)ApicIds, 0);
Ah, you pass a pointer to GHCB_APIC_IDS instead of storing the data
directly in the GHCB. Scratch the patch #10 comment then.
> + // Retrieve the APIC IDs if the hypervisor supports it. These will be used
> + // to always start APs using SNP AP Create.
> + //
> + if ((HvFeatures & GHCB_HV_FEATURES_APIC_ID_LIST) == GHCB_HV_FEATURES_APIC_ID_LIST) {
> + AmdSevSnpGetApicIds ();
> + }
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This looks like it does not depend on the SVSM being present,
is this correct?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114711): https://edk2.groups.io/g/devel/message/114711
Mute This Topic: https://groups.io/mt/103986465/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
2024-01-29 15:00 ` Gerd Hoffmann
@ 2024-01-29 17:49 ` Lendacky, Thomas via groups.io
2024-01-30 11:25 ` Gerd Hoffmann
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 17:49 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/29/24 09:00, Gerd Hoffmann wrote:
> On Fri, Jan 26, 2024 at 04:13:11PM -0600, Tom Lendacky wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> If the hypervisor supports retrieval of the vCPU APIC IDs, retrieve
>> them before any APs are actually started. The APIC IDs can be used
>> to start the APs for any SEV-SNP guest, but is a requirement for an
>> SEV-SNP guest that is running under an SVSM.
>
>> + ApicIds = AllocateReservedPages ((UINTN)PageCount);
>
>> + VmgExitStatus = CcExitVmgExit (Ghcb, SVM_EXIT_GET_APIC_IDS, (UINTN)ApicIds, 0);
>
> Ah, you pass a pointer to GHCB_APIC_IDS instead of storing the data
> directly in the GHCB. Scratch the patch #10 comment then.
>
>> + // Retrieve the APIC IDs if the hypervisor supports it. These will be used
>> + // to always start APs using SNP AP Create.
>> + //
>> + if ((HvFeatures & GHCB_HV_FEATURES_APIC_ID_LIST) == GHCB_HV_FEATURES_APIC_ID_LIST) {
>> + AmdSevSnpGetApicIds ();
>> + }
>
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
>
> This looks like it does not depend on the SVSM being present,
> is this correct?
Correct, this doesn't require the SVSM to be used. But when running under
an SVSM, the SVSM requires this.
I could move this to the start of the series if you think that makes more
sense.
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114722): https://edk2.groups.io/g/devel/message/114722
Mute This Topic: https://groups.io/mt/103986465/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
2024-01-29 17:49 ` Lendacky, Thomas via groups.io
@ 2024-01-30 11:25 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-30 11:25 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
> > This looks like it does not depend on the SVSM being present,
> > is this correct?
>
> Correct, this doesn't require the SVSM to be used. But when running under an
> SVSM, the SVSM requires this.
>
> I could move this to the start of the series if you think that makes more
> sense.
Yes, moving to the start of the series (and mentioning it in the cover
letter) would be nice.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114771): https://edk2.groups.io/g/devel/message/114771
Mute This Topic: https://groups.io/mt/103986465/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (11 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 12/16] OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 15:21 ` Gerd Hoffmann
2024-02-02 6:20 ` Ni, Ray
2024-01-26 22:13 ` [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM Lendacky, Thomas via groups.io
` (3 subsequent siblings)
16 siblings, 2 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Currently, the first time an AP is started for an SEV-SNP guest, it relies
on the VMSA as set by the hypervisor. If the list of APIC IDs has been
retrieved, this is not necessary. Instead, use the SEV-SNP AP Create
protocol to start the AP for the first time and thereafter using the VMPL
at which the BSP is running.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
UefiCpuPkg/Library/MpInitLib/MpLib.h | 13 ++++
UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +++++
UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 79 +++++++++++++++++++-
6 files changed, 116 insertions(+), 6 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index 55e46d4a1fad..1ec50481f0d4 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -82,6 +82,7 @@ [Pcd]
gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures ## CONSUMES
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase ## SOMETIMES_CONSUMES
gUefiCpuPkgTokenSpaceGuid.PcdFirstTimeWakeUpAPsBySipi ## CONSUMES
+ gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase ## CONSUMES
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr ## CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
index bc3d716aa951..f0af07d3bdfb 100644
--- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
@@ -66,7 +66,8 @@ [Pcd]
gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate ## SOMETIMES_CONSUMES
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase ## SOMETIMES_CONSUMES
gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures ## CONSUMES
- gUefiCpuPkgTokenSpaceGuid.PcdFirstTimeWakeUpAPsBySipi ## CONSUMES
+ gUefiCpuPkgTokenSpaceGuid.PcdFirstTimeWakeUpAPsBySipi ## CONSUMES
+ gUefiCpuPkgTokenSpaceGuid.PcdSevSnpApicIds ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase ## CONSUMES
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr ## CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index 6e2137cb17cd..f1a5fa98d425 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -897,6 +897,19 @@ SevSnpCreateAP (
IN INTN ProcessorNumber
);
+/**
+ Determine if the SEV-SNP AP Create protocol should be used.
+
+ @param[in] CpuMpData Pointer to CPU MP Data
+
+ @retval TRUE Use SEV-SNP AP Create protocol
+ @retval FALSE Do not use SEV-SNP AP Create protocol
+**/
+BOOLEAN
+SevSnpUseCreateAP (
+ IN CPU_MP_DATA *CpuMpData
+ );
+
/**
Get pointer to CPU MP Data structure from GUIDed HOB.
diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
index a2b8a5b3f516..f9f24bee09de 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
@@ -48,3 +48,22 @@ SevSnpCreateAP (
//
ASSERT (FALSE);
}
+
+/**
+ Determine if the SEV-SNP AP Create protocol should be used.
+
+ @param[in] CpuMpData Pointer to CPU MP Data
+
+ @retval TRUE Use SEV-SNP AP Create protocol
+ @retval FALSE Do not use SEV-SNP AP Create protocol
+**/
+BOOLEAN
+SevSnpUseCreateAP (
+ IN CPU_MP_DATA *CpuMpData
+ )
+{
+ //
+ // SEV-SNP is not supported on 32-bit build.
+ //
+ return FALSE;
+}
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index cdfb570e61a0..5e017bcf9018 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1302,9 +1302,10 @@ WakeUpAP (
//
// Wakeup all APs
// Must use the INIT-SIPI-SIPI method for initial configuration in
- // order to obtain the APIC ID.
+ // order to obtain the APIC ID if not an SEV-SNP guest and the
+ // list of APIC IDs is not available.
//
- if (CpuMpData->SevSnpIsEnabled && (CpuMpData->InitFlag != ApInitConfig)) {
+ if (SevSnpUseCreateAP (CpuMpData)) {
SevSnpCreateAP (CpuMpData, -1);
} else {
if ((CpuMpData->InitFlag == ApInitConfig) && FixedPcdGetBool (PcdFirstTimeWakeUpAPsBySipi)) {
@@ -1414,7 +1415,7 @@ WakeUpAP (
SetSevEsJumpTable (ExchangeInfo->BufferStart);
}
- if (CpuMpData->SevSnpIsEnabled && (CpuMpData->InitFlag != ApInitConfig)) {
+ if (SevSnpUseCreateAP (CpuMpData)) {
SevSnpCreateAP (CpuMpData, (INTN)ProcessorNumber);
} else {
SendInitSipiSipi (
diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
index db9a37fbbd19..6186a8d71521 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
@@ -263,17 +263,63 @@ SevSnpCreateAP (
CPU_INFO_IN_HOB *CpuInfoInHob;
CPU_AP_DATA *CpuData;
UINTN Index;
+ UINTN MaxIndex;
UINT32 ApicId;
+ GHCB_APIC_IDS *GhcbApicIds;
ASSERT (CpuMpData->MpCpuExchangeInfo->BufferStart < 0x100000);
CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
if (ProcessorNumber < 0) {
- for (Index = 0; Index < CpuMpData->CpuCount; Index++) {
+ GhcbApicIds = (GHCB_APIC_IDS *)(UINTN)PcdGet64 (PcdSevSnpApicIds);
+
+ if (CpuMpData->InitFlag == ApInitConfig) {
+ //
+ // APs have not been started, so CpuCount is not "known" yet.
+ // Use the retrieved APIC IDs to start the APs and fill out the
+ // MpLib CPU information properly.
+ //
+ ASSERT (GhcbApicIds != NULL);
+ if (GhcbApicIds == NULL) {
+ return;
+ }
+
+ MaxIndex = MIN (GhcbApicIds->NumEntries, PcdGet32 (PcdCpuMaxLogicalProcessorNumber));
+ } else {
+ //
+ // APs have been previously started.
+ //
+ MaxIndex = CpuMpData->CpuCount;
+ }
+
+ for (Index = 0; Index < MaxIndex; Index++) {
if (Index != CpuMpData->BspNumber) {
CpuData = &CpuMpData->CpuData[Index];
- ApicId = CpuInfoInHob[Index].ApicId,
+
+ if (CpuMpData->InitFlag == ApInitConfig) {
+ //
+ // CodeQL doesn't understand that a check for NULL was already done
+ // above, so check again.
+ //
+ if (GhcbApicIds == NULL) {
+ return;
+ }
+
+ ApicId = GhcbApicIds->ApicIds[Index];
+
+ //
+ // For the first boot, use the BSP register information.
+ //
+ CopyMem (
+ &CpuData->VolatileRegisters,
+ &CpuMpData->CpuData[0].VolatileRegisters,
+ sizeof (CpuData->VolatileRegisters)
+ );
+ } else {
+ ApicId = CpuInfoInHob[Index].ApicId;
+ }
+
SevSnpCreateSaveArea (CpuMpData, CpuData, ApicId);
}
}
@@ -284,3 +330,32 @@ SevSnpCreateAP (
SevSnpCreateSaveArea (CpuMpData, CpuData, ApicId);
}
}
+
+/**
+ Determine if the SEV-SNP AP Create protocol should be used.
+
+ @param[in] CpuMpData Pointer to CPU MP Data
+
+ @retval TRUE Use SEV-SNP AP Create protocol
+ @retval FALSE Do not use SEV-SNP AP Create protocol
+**/
+BOOLEAN
+SevSnpUseCreateAP (
+ IN CPU_MP_DATA *CpuMpData
+ )
+{
+ //
+ // The AP Create protocol is used for an SEV-SNP guest if
+ // - The initial configuration has been performed already or
+ // - PcdSevSnpApicIds is non-zero.
+ //
+ if (!CpuMpData->SevSnpIsEnabled) {
+ return FALSE;
+ }
+
+ if ((CpuMpData->InitFlag == ApInitConfig) && (PcdGet64 (PcdSevSnpApicIds) == 0)) {
+ return FALSE;
+ }
+
+ return TRUE;
+}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114639): https://edk2.groups.io/g/devel/message/114639
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-01-26 22:13 ` [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set Lendacky, Thomas via groups.io
@ 2024-01-29 15:21 ` Gerd Hoffmann
2024-01-29 18:00 ` Lendacky, Thomas via groups.io
2024-02-02 6:20 ` Ni, Ray
1 sibling, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 15:21 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:12PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> Currently, the first time an AP is started for an SEV-SNP guest, it relies
> on the VMSA as set by the hypervisor. If the list of APIC IDs has been
> retrieved, this is not necessary. Instead, use the SEV-SNP AP Create
> protocol to start the AP for the first time and thereafter using the VMPL
> at which the BSP is running.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> +BOOLEAN
> +SevSnpUseCreateAP (
> + IN CPU_MP_DATA *CpuMpData
> + )
> +{
> + //
> + // SEV-SNP is not supported on 32-bit build.
> + //
> + return FALSE;
> +}
Hmm. Should the 32-bit build just use the NULL versions of the
Libraries?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114713): https://edk2.groups.io/g/devel/message/114713
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-01-29 15:21 ` Gerd Hoffmann
@ 2024-01-29 18:00 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 18:00 UTC (permalink / raw)
To: devel, kraxel
Cc: Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek, Liming Gao,
Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar, Ray Ni,
Michael Roth
On 1/29/24 09:21, Gerd Hoffmann via groups.io wrote:
> On Fri, Jan 26, 2024 at 04:13:12PM -0600, Tom Lendacky wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> Currently, the first time an AP is started for an SEV-SNP guest, it relies
>> on the VMSA as set by the hypervisor. If the list of APIC IDs has been
>> retrieved, this is not necessary. Instead, use the SEV-SNP AP Create
>> protocol to start the AP for the first time and thereafter using the VMPL
>> at which the BSP is running.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>
>> +BOOLEAN
>> +SevSnpUseCreateAP (
>> + IN CPU_MP_DATA *CpuMpData
>> + )
>> +{
>> + //
>> + // SEV-SNP is not supported on 32-bit build.
>> + //
>> + return FALSE;
>> +}
>
> Hmm. Should the 32-bit build just use the NULL versions of the
> Libraries?
That would mean moving the functions into the CcExitLib library. Right
now, these functions are part of MpInitLib.
I can investigate that and submit a series afterwards.
Thanks,
Tom
>
> take care,
> Gerd
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114723): https://edk2.groups.io/g/devel/message/114723
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-01-26 22:13 ` [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set Lendacky, Thomas via groups.io
2024-01-29 15:21 ` Gerd Hoffmann
@ 2024-02-02 6:20 ` Ni, Ray
2024-02-02 22:58 ` Lendacky, Thomas via groups.io
1 sibling, 1 reply; 56+ messages in thread
From: Ni, Ray @ 2024-02-02 6:20 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
> + if (SevSnpUseCreateAP (CpuMpData)) {
1. Is it possible to rename "SevSnpUseCreateAP" to some name starting
with "IsXXX"?
I originally mixed it with SevSnpCreateAP() and thought you created a
bug.
> + GhcbApicIds = (GHCB_APIC_IDS *)(UINTN)PcdGet64 (PcdSevSnpApicIds);
2. Can you define a GUIDed HOB to hold the contents instead of dynamic PCDs?
Dynamic PCDs cannot tell whether the value is updated in earlier code or still
holds the default value.
Also, I prefer to minimize the dynamic PCD usage in CPU code.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115022): https://edk2.groups.io/g/devel/message/115022
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-02-02 6:20 ` Ni, Ray
@ 2024-02-02 22:58 ` Lendacky, Thomas via groups.io
2024-02-05 5:06 ` Ni, Ray
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-02-02 22:58 UTC (permalink / raw)
To: Ni, Ray, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
On 2/2/24 00:20, Ni, Ray wrote:
>
>> + if (SevSnpUseCreateAP (CpuMpData)) {
>
> 1. Is it possible to rename "SevSnpUseCreateAP" to some name starting
> with "IsXXX"?
> I originally mixed it with SevSnpCreateAP() and thought you created a
> bug.
"Is" doesn't really fit for this, how about UseSevSnpCreateAP() or
CanUseSevSnpCreateAP()?
>
>
>> + GhcbApicIds = (GHCB_APIC_IDS *)(UINTN)PcdGet64 (PcdSevSnpApicIds);
>
> 2. Can you define a GUIDed HOB to hold the contents instead of dynamic PCDs?
> Dynamic PCDs cannot tell whether the value is updated in earlier code or still
> holds the default value.
> Also, I prefer to minimize the dynamic PCD usage in CPU code.
Yep, will do.
Thanks,
Tom
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115072): https://edk2.groups.io/g/devel/message/115072
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
2024-02-02 22:58 ` Lendacky, Thomas via groups.io
@ 2024-02-05 5:06 ` Ni, Ray
0 siblings, 0 replies; 56+ messages in thread
From: Ni, Ray @ 2024-02-05 5:06 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
Thanks,
Ray
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, February 3, 2024 6:58 AM
> To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; Michael Roth <michael.roth@amd.com>
> Subject: Re: [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if
> PcdSevSnpApicIds is set
>
> On 2/2/24 00:20, Ni, Ray wrote:
> >
> >> + if (SevSnpUseCreateAP (CpuMpData)) {
> >
> > 1. Is it possible to rename "SevSnpUseCreateAP" to some name starting
> > with "IsXXX"?
> > I originally mixed it with SevSnpCreateAP() and thought you created a
> > bug.
>
> "Is" doesn't really fit for this, how about UseSevSnpCreateAP() or
> CanUseSevSnpCreateAP()?
Thank you. I prefer the 2nd "Canxxx".
>
> >
> >
> >> + GhcbApicIds = (GHCB_APIC_IDS *)(UINTN)PcdGet64
> (PcdSevSnpApicIds);
> >
> > 2. Can you define a GUIDed HOB to hold the contents instead of dynamic
> PCDs?
> > Dynamic PCDs cannot tell whether the value is updated in earlier code or
> still
> > holds the default value.
> > Also, I prefer to minimize the dynamic PCD usage in CPU code.
>
> Yep, will do.
Thanks!
>
> Thanks,
> Tom
>
> >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115095): https://edk2.groups.io/g/devel/message/115095
Mute This Topic: https://groups.io/mt/103986469/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (12 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 13/16] UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 15:21 ` Gerd Hoffmann
2024-02-02 6:48 ` Ni, Ray
2024-01-26 22:13 ` [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support Lendacky, Thomas via groups.io
` (2 subsequent siblings)
16 siblings, 2 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
When running under an SVSM, the VMPL level of the APs that are started
must match the VMPL level provided by the SVSM. Additionally, each AP
must have a Calling Area for use with the SVSM protocol. Update the AP
creation to properly support running under an SVSM.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
index 6186a8d71521..9b00c945e13d 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
@@ -55,6 +55,7 @@ SevSnpPerformApAction (
}
ExitInfo1 = (UINT64)ApicId << 32;
+ ExitInfo1 |= (UINT64)SaveArea->Vmpl << 16;
ExitInfo1 |= Action;
ExitInfo2 = (UINT64)(UINTN)SaveArea;
@@ -115,6 +116,7 @@ SevSnpCreateSaveArea (
UINT32 ApicId
)
{
+ UINTN PageCount;
UINT8 *Pages;
SEV_ES_SAVE_AREA *SaveArea;
IA32_CR0 ApCr0;
@@ -124,13 +126,18 @@ SevSnpCreateSaveArea (
UINTN StartIp;
UINT8 SipiVector;
+ //
+ // When running under an SVSM, a Calling Area page is also needed
+ //
+ PageCount = CcExitSnpSvsmPresent () ? 2 : 1;
+
if (CpuData->SevEsSaveArea == NULL) {
//
// Allocate a page for the SEV-ES Save Area and initialize it. Due to AMD
// erratum #1467 (VMSA cannot be on a 2MB boundary), allocate an extra page
// to choose from to work around the issue.
//
- Pages = AllocateReservedPages (2);
+ Pages = AllocateReservedPages (PageCount + 1);
if (!Pages) {
return;
}
@@ -139,12 +146,12 @@ SevSnpCreateSaveArea (
// Since page allocation works by allocating downward in the address space,
// try to always free the first (lower address) page to limit possible holes
// in the memory map. So, if the address of the second page is 2MB aligned,
- // then use the first page and free the second page. Otherwise, free the
+ // then use the first page and free the last page. Otherwise, free the
// first page and use the second page.
//
if (_IS_ALIGNED (Pages + EFI_PAGE_SIZE, SIZE_2MB)) {
SaveArea = (SEV_ES_SAVE_AREA *)Pages;
- FreePages (Pages + EFI_PAGE_SIZE, 1);
+ FreePages (Pages + (EFI_PAGE_SIZE * PageCount), 1);
} else {
SaveArea = (SEV_ES_SAVE_AREA *)(Pages + EFI_PAGE_SIZE);
FreePages (Pages, 1);
@@ -162,7 +169,7 @@ SevSnpCreateSaveArea (
}
}
- ZeroMem (SaveArea, EFI_PAGE_SIZE);
+ ZeroMem (SaveArea, EFI_PAGE_SIZE * PageCount);
//
// Propogate the CR0.NW and CR0.CD setting to the AP
@@ -238,10 +245,10 @@ SevSnpCreateSaveArea (
//
// Set the SEV-SNP specific fields for the save area:
- // VMPL - always VMPL0
+ // VMPL - based on current mode
// SEV_FEATURES - equivalent to the SEV_STATUS MSR right shifted 2 bits
//
- SaveArea->Vmpl = 0;
+ SaveArea->Vmpl = CcExitSnpGetVmpl ();
SaveArea->SevFeatures = AsmReadMsr64 (MSR_SEV_STATUS) >> 2;
SevSnpPerformApAction (SaveArea, ApicId, SVM_VMGEXIT_SNP_AP_CREATE);
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114640): https://edk2.groups.io/g/devel/message/114640
Mute This Topic: https://groups.io/mt/103986475/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM
2024-01-26 22:13 ` [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM Lendacky, Thomas via groups.io
@ 2024-01-29 15:21 ` Gerd Hoffmann
2024-02-02 6:48 ` Ni, Ray
1 sibling, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 15:21 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:13PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> When running under an SVSM, the VMPL level of the APs that are started
> must match the VMPL level provided by the SVSM. Additionally, each AP
> must have a Calling Area for use with the SVSM protocol. Update the AP
> creation to properly support running under an SVSM.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114712): https://edk2.groups.io/g/devel/message/114712
Mute This Topic: https://groups.io/mt/103986475/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM
2024-01-26 22:13 ` [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM Lendacky, Thomas via groups.io
2024-01-29 15:21 ` Gerd Hoffmann
@ 2024-02-02 6:48 ` Ni, Ray
1 sibling, 0 replies; 56+ messages in thread
From: Ni, Ray @ 2024-02-02 6:48 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Yao, Jiewen,
Laszlo Ersek, Liming Gao, Kinney, Michael D, Xu, Min M,
Liu, Zhiguang, Kumar, Rahul R, Michael Roth
Acked-by: Ray Ni <ray.ni@intel.com>
Thanks,
Ray
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming
> Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael Roth
> <michael.roth@amd.com>
> Subject: [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an
> SVSM
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> When running under an SVSM, the VMPL level of the APs that are started
> must match the VMPL level provided by the SVSM. Additionally, each AP
> must have a Calling Area for use with the SVSM protocol. Update the AP
> creation to properly support running under an SVSM.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> index 6186a8d71521..9b00c945e13d 100644
> --- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> +++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
> @@ -55,6 +55,7 @@ SevSnpPerformApAction (
> }
>
> ExitInfo1 = (UINT64)ApicId << 32;
> + ExitInfo1 |= (UINT64)SaveArea->Vmpl << 16;
> ExitInfo1 |= Action;
> ExitInfo2 = (UINT64)(UINTN)SaveArea;
>
> @@ -115,6 +116,7 @@ SevSnpCreateSaveArea (
> UINT32 ApicId
> )
> {
> + UINTN PageCount;
> UINT8 *Pages;
> SEV_ES_SAVE_AREA *SaveArea;
> IA32_CR0 ApCr0;
> @@ -124,13 +126,18 @@ SevSnpCreateSaveArea (
> UINTN StartIp;
> UINT8 SipiVector;
>
> + //
> + // When running under an SVSM, a Calling Area page is also needed
> + //
> + PageCount = CcExitSnpSvsmPresent () ? 2 : 1;
> +
> if (CpuData->SevEsSaveArea == NULL) {
> //
> // Allocate a page for the SEV-ES Save Area and initialize it. Due to AMD
> // erratum #1467 (VMSA cannot be on a 2MB boundary), allocate an extra
> page
> // to choose from to work around the issue.
> //
> - Pages = AllocateReservedPages (2);
> + Pages = AllocateReservedPages (PageCount + 1);
> if (!Pages) {
> return;
> }
> @@ -139,12 +146,12 @@ SevSnpCreateSaveArea (
> // Since page allocation works by allocating downward in the address space,
> // try to always free the first (lower address) page to limit possible holes
> // in the memory map. So, if the address of the second page is 2MB aligned,
> - // then use the first page and free the second page. Otherwise, free the
> + // then use the first page and free the last page. Otherwise, free the
> // first page and use the second page.
> //
> if (_IS_ALIGNED (Pages + EFI_PAGE_SIZE, SIZE_2MB)) {
> SaveArea = (SEV_ES_SAVE_AREA *)Pages;
> - FreePages (Pages + EFI_PAGE_SIZE, 1);
> + FreePages (Pages + (EFI_PAGE_SIZE * PageCount), 1);
> } else {
> SaveArea = (SEV_ES_SAVE_AREA *)(Pages + EFI_PAGE_SIZE);
> FreePages (Pages, 1);
> @@ -162,7 +169,7 @@ SevSnpCreateSaveArea (
> }
> }
>
> - ZeroMem (SaveArea, EFI_PAGE_SIZE);
> + ZeroMem (SaveArea, EFI_PAGE_SIZE * PageCount);
>
> //
> // Propogate the CR0.NW and CR0.CD setting to the AP
> @@ -238,10 +245,10 @@ SevSnpCreateSaveArea (
>
> //
> // Set the SEV-SNP specific fields for the save area:
> - // VMPL - always VMPL0
> + // VMPL - based on current mode
> // SEV_FEATURES - equivalent to the SEV_STATUS MSR right shifted 2 bits
> //
> - SaveArea->Vmpl = 0;
> + SaveArea->Vmpl = CcExitSnpGetVmpl ();
> SaveArea->SevFeatures = AsmReadMsr64 (MSR_SEV_STATUS) >> 2;
>
> SevSnpPerformApAction (SaveArea, ApicId,
> SVM_VMGEXIT_SNP_AP_CREATE);
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115025): https://edk2.groups.io/g/devel/message/115025
Mute This Topic: https://groups.io/mt/103986475/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (13 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 14/16] UefiCpuPkg/MpInitLib: AP creation support under an SVSM Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 15:23 ` Gerd Hoffmann
2024-01-26 22:13 ` [edk2-devel] [PATCH 16/16] OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0 Lendacky, Thomas via groups.io
2024-01-27 4:04 ` [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Yao, Jiewen
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The SVSM specification documents an alternative method of discovery for
the SVSM using a reserved CPUID bit and a reserved MSR.
For the CPUID support, the #VC handler of an SEV-SNP guest should modify
the returned value in the EAX register for the 0x8000001f CPUID function
by setting bit 28 when an SVSM is present.
For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
should be generated when accessing this MSR. The #VC handler is expected
to ignore writes to this MSR and return the physical calling area address
(CAA) on reads of this MSR.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++++++++++++++++++++
OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 21 ++++++++++++++
OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 ++++++++++++++++++--
3 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Library/CcExitLib/CcExitSvsm.h b/OvmfPkg/Library/CcExitLib/CcExitSvsm.h
new file mode 100644
index 000000000000..2325e7a98910
--- /dev/null
+++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.h
@@ -0,0 +1,29 @@
+/** @file
+ Secure VM Service Module (SVSM) functions.
+
+ Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Specification Reference:
+ Secure VM Service Module Specification
+
+**/
+
+#ifndef __CCEXITLIB_CCEXITSVSM_H__
+#define __CCEXITLIB_CCEXITSVSM_H__
+
+/**
+ Return the physical address of SVSM Call Area (CAA).
+
+ Determines the physical address of the SVSM CAA.
+
+ @return The physical address of the SVSM CAA
+
+**/
+UINT64
+EFIAPI
+SvsmGetCaaPa (
+ VOID
+ );
+
+#endif
diff --git a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
index 3459338b2033..e4c600d2a46b 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitSvsm.c
@@ -44,6 +44,27 @@ SvsmTerminate (
CpuDeadLoop ();
}
+/**
+ Return the physical address of SVSM Call Area (CAA).
+
+ Determines the physical address of the SVSM CAA.
+
+ @return The physical address of the SVSM CAA
+
+**/
+UINT64
+EFIAPI
+SvsmGetCaaPa (
+ VOID
+ )
+{
+ SVSM_INFORMATION *SvsmInfo;
+
+ SvsmInfo = (SVSM_INFORMATION *)(UINTN)PcdGet32 (PcdOvmfSnpSecretsBase);
+
+ return CcExitSnpSvsmPresent () ? SvsmInfo->SvsmCaa : 0;
+}
+
/**
Return the address of SVSM Call Area (CAA).
diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
index 0fc30f7bc4f6..950e7c34e37f 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
@@ -1,7 +1,7 @@
/** @file
X64 #VC Exception Handler functon.
- Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+ Copyright (C) 2020 - 2024, Advanced Micro Devices, Inc. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -18,6 +18,7 @@
#include "CcExitVcHandler.h"
#include "CcInstruction.h"
+#include "CcExitSvsm.h"
//
// Non-automatic Exit function prototype
@@ -713,10 +714,29 @@ MsrExit (
IN CC_INSTRUCTION_DATA *InstructionData
)
{
- UINT64 ExitInfo1, Status;
+ MSR_SVSM_CAA_REGISTER Msr;
+ UINT64 ExitInfo1;
+ UINT64 Status;
ExitInfo1 = 0;
+ //
+ // The SVSM CAA MSR is a software implemented MSR and not supported
+ // by the hardware, handle it directly.
+ //
+ if (Regs->Rax == MSR_SVSM_CAA) {
+ // Writes to the SVSM CAA MSR are ignored
+ if (*(InstructionData->OpCodes + 1) == 0x30) {
+ return 0;
+ }
+
+ Msr.Uint64 = SvsmGetCaaPa ();
+ Regs->Rax = Msr.Bits.Lower32Bits;
+ Regs->Rdx = Msr.Bits.Upper32Bits;
+
+ return 0;
+ }
+
switch (*(InstructionData->OpCodes + 1)) {
case 0x30: // WRMSR
ExitInfo1 = 1;
@@ -1388,6 +1408,11 @@ GetCpuidFw (
*Ebx = (*Ebx & 0xFFFFFF00) | (Ebx2 & 0x000000FF);
/* node ID */
*Ecx = (*Ecx & 0xFFFFFF00) | (Ecx2 & 0x000000FF);
+ } else if (EaxIn == 0x8000001F) {
+ /* Set the SVSM feature bit if running under an SVSM */
+ if (CcExitSnpSvsmPresent ()) {
+ *Eax |= BIT28;
+ }
}
Out:
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114641): https://edk2.groups.io/g/devel/message/114641
Mute This Topic: https://groups.io/mt/103986477/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support
2024-01-26 22:13 ` [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support Lendacky, Thomas via groups.io
@ 2024-01-29 15:23 ` Gerd Hoffmann
2024-01-29 18:04 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 15:23 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:14PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> The SVSM specification documents an alternative method of discovery for
> the SVSM using a reserved CPUID bit and a reserved MSR.
>
> For the CPUID support, the #VC handler of an SEV-SNP guest should modify
> the returned value in the EAX register for the 0x8000001f CPUID function
> by setting bit 28 when an SVSM is present.
>
> For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
> should be generated when accessing this MSR. The #VC handler is expected
> to ignore writes to this MSR and return the physical calling area address
> (CAA) on reads of this MSR.
I'm wondering why this is handled by the ovmf #vc handler instead of the
svsm #vc handler?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114714): https://edk2.groups.io/g/devel/message/114714
Mute This Topic: https://groups.io/mt/103986477/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support
2024-01-29 15:23 ` Gerd Hoffmann
@ 2024-01-29 18:04 ` Lendacky, Thomas via groups.io
2024-01-30 11:38 ` Gerd Hoffmann
0 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-29 18:04 UTC (permalink / raw)
To: devel, kraxel
Cc: Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek, Liming Gao,
Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar, Ray Ni,
Michael Roth
On 1/29/24 09:23, Gerd Hoffmann via groups.io wrote:
> On Fri, Jan 26, 2024 at 04:13:14PM -0600, Tom Lendacky wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> The SVSM specification documents an alternative method of discovery for
>> the SVSM using a reserved CPUID bit and a reserved MSR.
>>
>> For the CPUID support, the #VC handler of an SEV-SNP guest should modify
>> the returned value in the EAX register for the 0x8000001f CPUID function
>> by setting bit 28 when an SVSM is present.
>>
>> For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
>> should be generated when accessing this MSR. The #VC handler is expected
>> to ignore writes to this MSR and return the physical calling area address
>> (CAA) on reads of this MSR.
>
> I'm wondering why this is handled by the ovmf #vc handler instead of the
> svsm #vc handler?
OVMF will be running in guest VMPL1 context, not SVSM VMPL0 context, when
the CPUID instruction / MSR access is performed. In that case, it is the
guest VMPL1 #VC handler that will get control and have to respond.
Thanks,
Tom
>
> take care,
> Gerd
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114724): https://edk2.groups.io/g/devel/message/114724
Mute This Topic: https://groups.io/mt/103986477/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support
2024-01-29 18:04 ` Lendacky, Thomas via groups.io
@ 2024-01-30 11:38 ` Gerd Hoffmann
2024-01-30 16:13 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-30 11:38 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Mon, Jan 29, 2024 at 12:04:51PM -0600, Tom Lendacky wrote:
> On 1/29/24 09:23, Gerd Hoffmann via groups.io wrote:
> > On Fri, Jan 26, 2024 at 04:13:14PM -0600, Tom Lendacky wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> > >
> > > The SVSM specification documents an alternative method of discovery for
> > > the SVSM using a reserved CPUID bit and a reserved MSR.
> > >
> > > For the CPUID support, the #VC handler of an SEV-SNP guest should modify
> > > the returned value in the EAX register for the 0x8000001f CPUID function
> > > by setting bit 28 when an SVSM is present.
> > >
> > > For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
> > > should be generated when accessing this MSR. The #VC handler is expected
> > > to ignore writes to this MSR and return the physical calling area address
> > > (CAA) on reads of this MSR.
> >
> > I'm wondering why this is handled by the ovmf #vc handler instead of the
> > svsm #vc handler?
>
> OVMF will be running in guest VMPL1 context, not SVSM VMPL0 context, when
> the CPUID instruction / MSR access is performed. In that case, it is the
> guest VMPL1 #VC handler that will get control and have to respond.
IIRC vmpl0 can handle #vc exceptions for vmpl1.
But maybe only in case vmpl1 hasn't a #vc handler, i.e. vmpl1 can't
cherry-pick which exceptions it handles itself and which it delegates
to the SVSM.
What happens once the linux kernel called ExitBootServices? Will the
edk2 #vc handler stay alive? Or will the linux kernel install its own
handler?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114772): https://edk2.groups.io/g/devel/message/114772
Mute This Topic: https://groups.io/mt/103986477/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support
2024-01-30 11:38 ` Gerd Hoffmann
@ 2024-01-30 16:13 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-30 16:13 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On 1/30/24 05:38, Gerd Hoffmann wrote:
> On Mon, Jan 29, 2024 at 12:04:51PM -0600, Tom Lendacky wrote:
>> On 1/29/24 09:23, Gerd Hoffmann via groups.io wrote:
>>> On Fri, Jan 26, 2024 at 04:13:14PM -0600, Tom Lendacky wrote:
>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>>>
>>>> The SVSM specification documents an alternative method of discovery for
>>>> the SVSM using a reserved CPUID bit and a reserved MSR.
>>>>
>>>> For the CPUID support, the #VC handler of an SEV-SNP guest should modify
>>>> the returned value in the EAX register for the 0x8000001f CPUID function
>>>> by setting bit 28 when an SVSM is present.
>>>>
>>>> For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
>>>> should be generated when accessing this MSR. The #VC handler is expected
>>>> to ignore writes to this MSR and return the physical calling area address
>>>> (CAA) on reads of this MSR.
>>>
>>> I'm wondering why this is handled by the ovmf #vc handler instead of the
>>> svsm #vc handler?
>>
>> OVMF will be running in guest VMPL1 context, not SVSM VMPL0 context, when
>> the CPUID instruction / MSR access is performed. In that case, it is the
>> guest VMPL1 #VC handler that will get control and have to respond.
>
> IIRC vmpl0 can handle #vc exceptions for vmpl1.
>
> But maybe only in case vmpl1 hasn't a #vc handler, i.e. vmpl1 can't
> cherry-pick which exceptions it handles itself and which it delegates
> to the SVSM.
Correct. The Reflect-VC feature says that all #VCs in the guest will cause
an exit to the hypervisor. It is then up to the hypervisor to schedule the
proper VMPL level to handle the #VC. This is the paravisor concept where
you can run an unenlightened guest.
>
> What happens once the linux kernel called ExitBootServices? Will the
> edk2 #vc handler stay alive? Or will the linux kernel install its own
> handler?
Once Linux installs its own IDT entry, then the Linux #VC handler is
invoked for any #VCs that occur.
Thanks,
Tom
>
> take care,
> Gerd
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114793): https://edk2.groups.io/g/devel/message/114793
Mute This Topic: https://groups.io/mt/103986477/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* [edk2-devel] [PATCH 16/16] OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (14 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 15/16] Ovmfpkg/CcExitLib: Provide SVSM discovery support Lendacky, Thomas via groups.io
@ 2024-01-26 22:13 ` Lendacky, Thomas via groups.io
2024-01-29 15:24 ` Gerd Hoffmann
2024-01-27 4:04 ` [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Yao, Jiewen
16 siblings, 1 reply; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-26 22:13 UTC (permalink / raw)
To: devel
Cc: Ard Biesheuvel, Erdem Aktas, Gerd Hoffmann, Jiewen Yao,
Laszlo Ersek, Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu,
Rahul Kumar, Ray Ni, Michael Roth
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Currently, an SEV-SNP guest will terminate if it is not running at VMPL0.
The requirement for running at VMPL0 is removed if an SVSM is present.
Update the current VMPL0 check to additionally check for the presence of
an SVSM is the guest is not running at VMPL0.
Additionally, fix an error in SevSnpIsVmpl0() where the Status variable
should be compared to 0 and not use the EFI_ERROR() function to determine
if an error occurred during AsmRmpAdjust().
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
index 86af2ba0356e..803c835680e0 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
@@ -12,6 +12,7 @@
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/MemEncryptSevLib.h>
+#include <Library/CcExitLib.h>
#include "SnpPageStateChange.h"
@@ -45,7 +46,7 @@ SevSnpIsVmpl0 (
Rdx = 1;
Status = AsmRmpAdjust ((UINT64)gVmpl0Data, 0, Rdx);
- if (EFI_ERROR (Status)) {
+ if (Status != 0) {
return FALSE;
}
@@ -74,10 +75,12 @@ MemEncryptSevSnpPreValidateSystemRam (
//
// The page state change uses the PVALIDATE instruction. The instruction
- // can be run on VMPL-0 only. If its not VMPL-0 guest then terminate
- // the boot.
+ // can be run at VMPL-0 only. If its not a VMPL-0 guest, then an SVSM must
+ // be present to perform the operation on behalf of the guest. If the guest
+ // is not running at VMPL-0 and an SVSM is not present, then terminate the
+ // boot.
//
- if (!SevSnpIsVmpl0 ()) {
+ if (!SevSnpIsVmpl0 () && !CcExitSnpSvsmPresent ()) {
SnpPageStateFailureTerminate ();
}
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114642): https://edk2.groups.io/g/devel/message/114642
Mute This Topic: https://groups.io/mt/103986479/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply related [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 16/16] OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0
2024-01-26 22:13 ` [edk2-devel] [PATCH 16/16] OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0 Lendacky, Thomas via groups.io
@ 2024-01-29 15:24 ` Gerd Hoffmann
0 siblings, 0 replies; 56+ messages in thread
From: Gerd Hoffmann @ 2024-01-29 15:24 UTC (permalink / raw)
To: Tom Lendacky
Cc: devel, Ard Biesheuvel, Erdem Aktas, Jiewen Yao, Laszlo Ersek,
Liming Gao, Michael D Kinney, Min Xu, Zhiguang Liu, Rahul Kumar,
Ray Ni, Michael Roth
On Fri, Jan 26, 2024 at 04:13:15PM -0600, Tom Lendacky wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> Currently, an SEV-SNP guest will terminate if it is not running at VMPL0.
> The requirement for running at VMPL0 is removed if an SVSM is present.
>
> Update the current VMPL0 check to additionally check for the presence of
> an SVSM is the guest is not running at VMPL0.
>
> Additionally, fix an error in SevSnpIsVmpl0() where the Status variable
> should be compared to 0 and not use the EFI_ERROR() function to determine
> if an error occurred during AsmRmpAdjust().
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114715): https://edk2.groups.io/g/devel/message/114715
Mute This Topic: https://groups.io/mt/103986479/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
2024-01-26 22:12 [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Lendacky, Thomas via groups.io
` (15 preceding siblings ...)
2024-01-26 22:13 ` [edk2-devel] [PATCH 16/16] OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0 Lendacky, Thomas via groups.io
@ 2024-01-27 4:04 ` Yao, Jiewen
2024-01-27 17:48 ` Lendacky, Thomas via groups.io
16 siblings, 1 reply; 56+ messages in thread
From: Yao, Jiewen @ 2024-01-27 4:04 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Laszlo Ersek,
Liming Gao, Kinney, Michael D, Xu, Min M, Liu, Zhiguang,
Kumar, Rahul R, Ni, Ray, Michael Roth, Yao, Jiewen
Thanks Tom.
Please give me some time to digest this patch set before I can give some feedback.
One quick question to you:
With this patch, we need to support multiple SEV modes:
1. SEV guest firmware
2. SEV-ES guest firmware
3. SEV-SNP guest firmware
4. SEV-SNP SVSM guest firmware
And all these mode requires runtime detection. Am I right?
If so, where is the flag to set those mode?
Please correct me if my understanding is wrong.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming Gao
> <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>;
> Xu, Min M <min.m.xu@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
> Kumar, Rahul R <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael
> Roth <michael.roth@amd.com>
> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
>
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>
> This series adds SEV-SNP support for running OVMF under an Secure VM
> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> By running at a less priviledged VMPL, the SVSM can be used to provide
> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> confidential VM (CVM) rather than trust such services from the hypervisor.
>
> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> certain SNP related operations that require that VMPL level. Specifically,
> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> the VMSA attribute of a page (used when starting APs).
>
> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> use an SVSM (which is running at VMPL0) to perform the operations that
> it is no longer able to perform.
>
> How OVMF interacts with and uses the SVSM is documented in the SVSM
> specification [1] and the GHCB specification [2].
>
> This series introduces support to run OVMF under an SVSM. It consists
> of:
> - Reorganize the page state change support to not directly use the
> GHCB buffer since an SVSM will use the calling area buffer, instead
> - Detecting the presence of an SVSM
> - When not running at VMPL0, invoking the SVSM for page validation and
> VMSA page creation/deletion
> - Retrieving the list of vCPU APIC IDs and starting up all APs without
> performing a broadcast SIPI
> - Detecting and allowing OVMF to run in a VMPL other than 0 when an
> SVSM is present
>
> The series is based off of commit:
>
> 7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
>
> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/58019.pdf
> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/56421.pdf
>
> ---
>
> Tom Lendacky (16):
> OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
> MdePkg/Register/Amd: Define the SVSM related information
> MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
> UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
> Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
> OvmfPkg: Create a calling area used to communicate with the SVSM
> OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
> OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
> UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
> MdePkg: GHCB APIC ID retrieval support definitions
> UefiCpuPkg: Create APIC ID list PCD
> OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
> UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
> UefiCpuPkg/MpInitLib: AP creation support under an SVSM
> Ovmfpkg/CcExitLib: Provide SVSM discovery support
> OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at
> VMPL0
>
> OvmfPkg/OvmfPkg.dec | 4 +
> UefiCpuPkg/UefiCpuPkg.dec | 7 +-
> OvmfPkg/AmdSev/AmdSevX64.fdf | 9 +-
> OvmfPkg/OvmfPkgX64.fdf | 3 +
> MdePkg/Library/BaseLib/BaseLib.inf | 2 +
> OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
> OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
> OvmfPkg/ResetVector/ResetVector.inf | 2 +
> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
> MdePkg/Include/Library/BaseLib.h | 39 ++
> MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +-
> MdePkg/Include/Register/Amd/Ghcb.h | 19 +-
> MdePkg/Include/Register/Amd/Msr.h | 3 +-
> MdePkg/Include/Register/Amd/Svsm.h | 101 ++++
> MdePkg/Include/Register/Amd/SvsmMsr.h | 35 ++
> OvmfPkg/Include/WorkArea.h | 7 +
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h | 4
> +-
> OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++
> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++-
> UefiCpuPkg/Library/MpInitLib/MpLib.h | 27 +-
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c |
> 16 +-
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c | 25
> +-
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c |
> 20 +-
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c |
> 25 +-
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c |
> 203 ++++----
> OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 532
> ++++++++++++++++++++
> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 +-
> OvmfPkg/PlatformPei/AmdSev.c | 100 +++-
> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 ++-
> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +-
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 127 +++--
> MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++
> MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++
> OvmfPkg/ResetVector/ResetVector.nasmb | 6 +-
> OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +
> UefiCpuPkg/UefiCpuPkg.uni | 3 +
> 39 files changed, 1524 insertions(+), 210 deletions(-)
> create mode 100644 MdePkg/Include/Register/Amd/Svsm.h
> create mode 100644 MdePkg/Include/Register/Amd/SvsmMsr.h
> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.h
> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.c
> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
>
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114647): https://edk2.groups.io/g/devel/message/114647
Mute This Topic: https://groups.io/mt/103986434/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
2024-01-27 4:04 ` [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM Yao, Jiewen
@ 2024-01-27 17:48 ` Lendacky, Thomas via groups.io
2024-01-28 4:11 ` Yao, Jiewen
[not found] ` <17AE677D909D4A42.23935@groups.io>
0 siblings, 2 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-01-27 17:48 UTC (permalink / raw)
To: Yao, Jiewen, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Laszlo Ersek,
Liming Gao, Kinney, Michael D, Xu, Min M, Liu, Zhiguang,
Kumar, Rahul R, Ni, Ray, Michael Roth
On 1/26/24 22:04, Yao, Jiewen wrote:
> Thanks Tom.
> Please give me some time to digest this patch set before I can give some feedback.
>
> One quick question to you:
> With this patch, we need to support multiple SEV modes:
> 1. SEV guest firmware
> 2. SEV-ES guest firmware
> 3. SEV-SNP guest firmware
> 4. SEV-SNP SVSM guest firmware
This last mode is still an SNP guest, it just requires invoking an API to
perform operations that require VMPL0 permissions. I'm not sure what you
mean by having firmware at the end of each mode. The same firmware is used
for all SEV guest modes as well as non-SEV guests.
> And all these mode requires runtime detection. Am I right?
Yes
> If so, where is the flag to set those mode?
There are function calls available to detect the SEV mode. See the
implementation of MemEncryptSevIsEnabled(), MemEncryptSevEsIsEnabled() and
MemEncryptSevSnpIsEnabled().
OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
(OvmfPkg/Sec/AmdSev.c also has some early detection support)
Note:
- An SEV-SNP guest is also considered an SEV-ES and SEV guest.
- An SEV-ES guest is also considered an SEV guest.
Within the CcExitLib library, the decision to use the SVSM API will be
based on the VMPL level at which OVMF is running.
Thanks,
Tom
>
> Please correct me if my understanding is wrong.
>
> Thank you
> Yao, Jiewen
>
>> -----Original Message-----
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>> Sent: Saturday, January 27, 2024 6:13 AM
>> To: devel@edk2.groups.io
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
>> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao, Jiewen
>> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming Gao
>> <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>;
>> Xu, Min M <min.m.xu@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
>> Kumar, Rahul R <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>; Michael
>> Roth <michael.roth@amd.com>
>> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
>>
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> This series adds SEV-SNP support for running OVMF under an Secure VM
>> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
>> By running at a less priviledged VMPL, the SVSM can be used to provide
>> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
>> confidential VM (CVM) rather than trust such services from the hypervisor.
>>
>> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
>> certain SNP related operations that require that VMPL level. Specifically,
>> the PVALIDATE instruction and the RMPADJUST instruction when setting the
>> the VMSA attribute of a page (used when starting APs).
>>
>> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
>> use an SVSM (which is running at VMPL0) to perform the operations that
>> it is no longer able to perform.
>>
>> How OVMF interacts with and uses the SVSM is documented in the SVSM
>> specification [1] and the GHCB specification [2].
>>
>> This series introduces support to run OVMF under an SVSM. It consists
>> of:
>> - Reorganize the page state change support to not directly use the
>> GHCB buffer since an SVSM will use the calling area buffer, instead
>> - Detecting the presence of an SVSM
>> - When not running at VMPL0, invoking the SVSM for page validation and
>> VMSA page creation/deletion
>> - Retrieving the list of vCPU APIC IDs and starting up all APs without
>> performing a broadcast SIPI
>> - Detecting and allowing OVMF to run in a VMPL other than 0 when an
>> SVSM is present
>>
>> The series is based off of commit:
>>
>> 7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
>>
>> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
>> docs/specifications/58019.pdf
>> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
>> docs/specifications/56421.pdf
>>
>> ---
>>
>> Tom Lendacky (16):
>> OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
>> MdePkg/Register/Amd: Define the SVSM related information
>> MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
>> UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
>> Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
>> OvmfPkg: Create a calling area used to communicate with the SVSM
>> OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
>> OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
>> UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
>> MdePkg: GHCB APIC ID retrieval support definitions
>> UefiCpuPkg: Create APIC ID list PCD
>> OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
>> UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
>> UefiCpuPkg/MpInitLib: AP creation support under an SVSM
>> Ovmfpkg/CcExitLib: Provide SVSM discovery support
>> OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at
>> VMPL0
>>
>> OvmfPkg/OvmfPkg.dec | 4 +
>> UefiCpuPkg/UefiCpuPkg.dec | 7 +-
>> OvmfPkg/AmdSev/AmdSevX64.fdf | 9 +-
>> OvmfPkg/OvmfPkgX64.fdf | 3 +
>> MdePkg/Library/BaseLib/BaseLib.inf | 2 +
>> OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
>> OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
>> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
>> OvmfPkg/ResetVector/ResetVector.inf | 2 +
>> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
>> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
>> MdePkg/Include/Library/BaseLib.h | 39 ++
>> MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +-
>> MdePkg/Include/Register/Amd/Ghcb.h | 19 +-
>> MdePkg/Include/Register/Amd/Msr.h | 3 +-
>> MdePkg/Include/Register/Amd/Svsm.h | 101 ++++
>> MdePkg/Include/Register/Amd/SvsmMsr.h | 35 ++
>> OvmfPkg/Include/WorkArea.h | 7 +
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h | 4
>> +-
>> OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++
>> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++-
>> UefiCpuPkg/Library/MpInitLib/MpLib.h | 27 +-
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c |
>> 16 +-
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c | 25
>> +-
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c |
>> 20 +-
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c |
>> 25 +-
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c |
>> 203 ++++----
>> OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 532
>> ++++++++++++++++++++
>> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 +-
>> OvmfPkg/PlatformPei/AmdSev.c | 100 +++-
>> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 ++-
>> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +-
>> UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
>> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 127 +++--
>> MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++
>> MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++
>> OvmfPkg/ResetVector/ResetVector.nasmb | 6 +-
>> OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +
>> UefiCpuPkg/UefiCpuPkg.uni | 3 +
>> 39 files changed, 1524 insertions(+), 210 deletions(-)
>> create mode 100644 MdePkg/Include/Register/Amd/Svsm.h
>> create mode 100644 MdePkg/Include/Register/Amd/SvsmMsr.h
>> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.h
>> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
>> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
>>
>> --
>> 2.42.0
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114650): https://edk2.groups.io/g/devel/message/114650
Mute This Topic: https://groups.io/mt/103986434/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
2024-01-27 17:48 ` Lendacky, Thomas via groups.io
@ 2024-01-28 4:11 ` Yao, Jiewen
[not found] ` <17AE677D909D4A42.23935@groups.io>
1 sibling, 0 replies; 56+ messages in thread
From: Yao, Jiewen @ 2024-01-28 4:11 UTC (permalink / raw)
To: Tom Lendacky, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Laszlo Ersek,
Liming Gao, Kinney, Michael D, Xu, Min M, Liu, Zhiguang,
Kumar, Rahul R, Ni, Ray, Michael Roth
Thanks Tom. Below is exactly what I am looking for:
"the decision to use the SVSM API will be based on the VMPL level at which OVMF is running."
OVMF needs to detect SEV-SNP, then make next level decision on VMPL.
Makes sense to me.
Thank you
Yao, Jiewen
> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Sent: Sunday, January 28, 2024 1:49 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek
> <lersek@redhat.com>; Liming Gao <gaoliming@byosoft.com.cn>; Kinney, Michael
> D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>;
> Ni, Ray <ray.ni@intel.com>; Michael Roth <michael.roth@amd.com>
> Subject: Re: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
>
> On 1/26/24 22:04, Yao, Jiewen wrote:
> > Thanks Tom.
> > Please give me some time to digest this patch set before I can give some
> feedback.
> >
> > One quick question to you:
> > With this patch, we need to support multiple SEV modes:
> > 1. SEV guest firmware
> > 2. SEV-ES guest firmware
> > 3. SEV-SNP guest firmware
> > 4. SEV-SNP SVSM guest firmware
>
> This last mode is still an SNP guest, it just requires invoking an API to
> perform operations that require VMPL0 permissions. I'm not sure what you
> mean by having firmware at the end of each mode. The same firmware is used
> for all SEV guest modes as well as non-SEV guests.
>
> > And all these mode requires runtime detection. Am I right?
>
> Yes
>
> > If so, where is the flag to set those mode?
>
> There are function calls available to detect the SEV mode. See the
> implementation of MemEncryptSevIsEnabled(), MemEncryptSevEsIsEnabled() and
> MemEncryptSevSnpIsEnabled().
>
> OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
> OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
> OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
>
> (OvmfPkg/Sec/AmdSev.c also has some early detection support)
>
> Note:
> - An SEV-SNP guest is also considered an SEV-ES and SEV guest.
> - An SEV-ES guest is also considered an SEV guest.
>
> Within the CcExitLib library, the decision to use the SVSM API will be
> based on the VMPL level at which OVMF is running.
>
> Thanks,
> Tom
>
> >
> > Please correct me if my understanding is wrong.
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -----Original Message-----
> >> From: Tom Lendacky <thomas.lendacky@amd.com>
> >> Sent: Saturday, January 27, 2024 6:13 AM
> >> To: devel@edk2.groups.io
> >> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> >> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> Jiewen
> >> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming Gao
> >> <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>;
> >> Xu, Min M <min.m.xu@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
> >> Kumar, Rahul R <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>;
> Michael
> >> Roth <michael.roth@amd.com>
> >> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> >>
> >>
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> >>
> >> This series adds SEV-SNP support for running OVMF under an Secure VM
> >> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> >> By running at a less priviledged VMPL, the SVSM can be used to provide
> >> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> >> confidential VM (CVM) rather than trust such services from the hypervisor.
> >>
> >> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> >> certain SNP related operations that require that VMPL level. Specifically,
> >> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> >> the VMSA attribute of a page (used when starting APs).
> >>
> >> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> >> use an SVSM (which is running at VMPL0) to perform the operations that
> >> it is no longer able to perform.
> >>
> >> How OVMF interacts with and uses the SVSM is documented in the SVSM
> >> specification [1] and the GHCB specification [2].
> >>
> >> This series introduces support to run OVMF under an SVSM. It consists
> >> of:
> >> - Reorganize the page state change support to not directly use the
> >> GHCB buffer since an SVSM will use the calling area buffer, instead
> >> - Detecting the presence of an SVSM
> >> - When not running at VMPL0, invoking the SVSM for page validation and
> >> VMSA page creation/deletion
> >> - Retrieving the list of vCPU APIC IDs and starting up all APs without
> >> performing a broadcast SIPI
> >> - Detecting and allowing OVMF to run in a VMPL other than 0 when an
> >> SVSM is present
> >>
> >> The series is based off of commit:
> >>
> >> 7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
> >>
> >> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> >> docs/specifications/58019.pdf
> >> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> >> docs/specifications/56421.pdf
> >>
> >> ---
> >>
> >> Tom Lendacky (16):
> >> OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
> >> MdePkg/Register/Amd: Define the SVSM related information
> >> MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
> >> UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
> >> Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
> >> OvmfPkg: Create a calling area used to communicate with the SVSM
> >> OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
> >> OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
> >> UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
> >> MdePkg: GHCB APIC ID retrieval support definitions
> >> UefiCpuPkg: Create APIC ID list PCD
> >> OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
> >> UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
> >> UefiCpuPkg/MpInitLib: AP creation support under an SVSM
> >> Ovmfpkg/CcExitLib: Provide SVSM discovery support
> >> OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at
> >> VMPL0
> >>
> >> OvmfPkg/OvmfPkg.dec | 4 +
> >> UefiCpuPkg/UefiCpuPkg.dec | 7 +-
> >> OvmfPkg/AmdSev/AmdSevX64.fdf | 9 +-
> >> OvmfPkg/OvmfPkgX64.fdf | 3 +
> >> MdePkg/Library/BaseLib/BaseLib.inf | 2 +
> >> OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
> >> OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
> >> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
> >> OvmfPkg/ResetVector/ResetVector.inf | 2 +
> >> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
> >> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
> >> MdePkg/Include/Library/BaseLib.h | 39 ++
> >> MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +-
> >> MdePkg/Include/Register/Amd/Ghcb.h | 19 +-
> >> MdePkg/Include/Register/Amd/Msr.h | 3 +-
> >> MdePkg/Include/Register/Amd/Svsm.h | 101 ++++
> >> MdePkg/Include/Register/Amd/SvsmMsr.h | 35 ++
> >> OvmfPkg/Include/WorkArea.h | 7 +
> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h |
> 4
> >> +-
> >> OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++
> >> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++-
> >> UefiCpuPkg/Library/MpInitLib/MpLib.h | 27 +-
> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
> |
> >> 16 +-
> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c |
> 25
> >> +-
> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
> |
> >> 20 +-
> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
> |
> >> 25 +-
> >>
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c |
> >> 203 ++++----
> >> OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 532
> >> ++++++++++++++++++++
> >> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 +-
> >> OvmfPkg/PlatformPei/AmdSev.c | 100 +++-
> >> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 ++-
> >> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +-
> >> UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
> >> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 127 +++--
> >> MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++
> >> MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++
> >> OvmfPkg/ResetVector/ResetVector.nasmb | 6 +-
> >> OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +
> >> UefiCpuPkg/UefiCpuPkg.uni | 3 +
> >> 39 files changed, 1524 insertions(+), 210 deletions(-)
> >> create mode 100644 MdePkg/Include/Register/Amd/Svsm.h
> >> create mode 100644 MdePkg/Include/Register/Amd/SvsmMsr.h
> >> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.h
> >> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.c
> >> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
> >> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
> >>
> >> --
> >> 2.42.0
> >
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114652): https://edk2.groups.io/g/devel/message/114652
Mute This Topic: https://groups.io/mt/103986434/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread[parent not found: <17AE677D909D4A42.23935@groups.io>]
* Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
[not found] ` <17AE677D909D4A42.23935@groups.io>
@ 2024-02-09 8:11 ` Yao, Jiewen
2024-02-09 16:17 ` Lendacky, Thomas via groups.io
0 siblings, 1 reply; 56+ messages in thread
From: Yao, Jiewen @ 2024-02-09 8:11 UTC (permalink / raw)
To: devel@edk2.groups.io, Yao, Jiewen, Tom Lendacky
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Laszlo Ersek,
Liming Gao, Kinney, Michael D, Xu, Min M, Liu, Zhiguang,
Kumar, Rahul R, Ni, Ray, Michael Roth
Some initial feedback:
Patch 1 - OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
Please split MdePkg update, since it requires different reviewer.
Patch 4 - UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
I am not sure why we need to expose SVSM API in CcExitLib. Why the Exception handle need to aware of SVSM?
If other library need SVSM API, then why not create a SvsmLib?
Patch 11 - UefiCpuPkg: Create APIC ID list PCD
Why use PCD? Why not use HOB?
Thank you
Yao, Jiewen
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
> Sent: Sunday, January 28, 2024 12:11 PM
> To: Tom Lendacky <thomas.lendacky@amd.com>; devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek
> <lersek@redhat.com>; Liming Gao <gaoliming@byosoft.com.cn>; Kinney, Michael
> D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>;
> Ni, Ray <ray.ni@intel.com>; Michael Roth <michael.roth@amd.com>
> Subject: Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running
> under an SVSM
>
> Thanks Tom. Below is exactly what I am looking for:
> "the decision to use the SVSM API will be based on the VMPL level at which
> OVMF is running."
>
> OVMF needs to detect SEV-SNP, then make next level decision on VMPL.
> Makes sense to me.
>
> Thank you
> Yao, Jiewen
>
> > -----Original Message-----
> > From: Tom Lendacky <thomas.lendacky@amd.com>
> > Sent: Sunday, January 28, 2024 1:49 AM
> > To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io
> > Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> > <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo
> Ersek
> > <lersek@redhat.com>; Liming Gao <gaoliming@byosoft.com.cn>; Kinney,
> Michael
> > D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
> > Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>;
> > Ni, Ray <ray.ni@intel.com>; Michael Roth <michael.roth@amd.com>
> > Subject: Re: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> >
> > On 1/26/24 22:04, Yao, Jiewen wrote:
> > > Thanks Tom.
> > > Please give me some time to digest this patch set before I can give some
> > feedback.
> > >
> > > One quick question to you:
> > > With this patch, we need to support multiple SEV modes:
> > > 1. SEV guest firmware
> > > 2. SEV-ES guest firmware
> > > 3. SEV-SNP guest firmware
> > > 4. SEV-SNP SVSM guest firmware
> >
> > This last mode is still an SNP guest, it just requires invoking an API to
> > perform operations that require VMPL0 permissions. I'm not sure what you
> > mean by having firmware at the end of each mode. The same firmware is used
> > for all SEV guest modes as well as non-SEV guests.
> >
> > > And all these mode requires runtime detection. Am I right?
> >
> > Yes
> >
> > > If so, where is the flag to set those mode?
> >
> > There are function calls available to detect the SEV mode. See the
> > implementation of MemEncryptSevIsEnabled(), MemEncryptSevEsIsEnabled()
> and
> > MemEncryptSevSnpIsEnabled().
> >
> > OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
> > OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
> > OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
> >
> > (OvmfPkg/Sec/AmdSev.c also has some early detection support)
> >
> > Note:
> > - An SEV-SNP guest is also considered an SEV-ES and SEV guest.
> > - An SEV-ES guest is also considered an SEV guest.
> >
> > Within the CcExitLib library, the decision to use the SVSM API will be
> > based on the VMPL level at which OVMF is running.
> >
> > Thanks,
> > Tom
> >
> > >
> > > Please correct me if my understanding is wrong.
> > >
> > > Thank you
> > > Yao, Jiewen
> > >
> > >> -----Original Message-----
> > >> From: Tom Lendacky <thomas.lendacky@amd.com>
> > >> Sent: Saturday, January 27, 2024 6:13 AM
> > >> To: devel@edk2.groups.io
> > >> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
> > >> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
> > Jiewen
> > >> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming Gao
> > >> <gaoliming@byosoft.com.cn>; Kinney, Michael D
> > <michael.d.kinney@intel.com>;
> > >> Xu, Min M <min.m.xu@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
> > >> Kumar, Rahul R <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>;
> > Michael
> > >> Roth <michael.roth@amd.com>
> > >> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> > >>
> > >>
> > >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> > >>
> > >> This series adds SEV-SNP support for running OVMF under an Secure VM
> > >> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> > >> By running at a less priviledged VMPL, the SVSM can be used to provide
> > >> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> > >> confidential VM (CVM) rather than trust such services from the hypervisor.
> > >>
> > >> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> > >> certain SNP related operations that require that VMPL level. Specifically,
> > >> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> > >> the VMSA attribute of a page (used when starting APs).
> > >>
> > >> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> > >> use an SVSM (which is running at VMPL0) to perform the operations that
> > >> it is no longer able to perform.
> > >>
> > >> How OVMF interacts with and uses the SVSM is documented in the SVSM
> > >> specification [1] and the GHCB specification [2].
> > >>
> > >> This series introduces support to run OVMF under an SVSM. It consists
> > >> of:
> > >> - Reorganize the page state change support to not directly use the
> > >> GHCB buffer since an SVSM will use the calling area buffer, instead
> > >> - Detecting the presence of an SVSM
> > >> - When not running at VMPL0, invoking the SVSM for page validation and
> > >> VMSA page creation/deletion
> > >> - Retrieving the list of vCPU APIC IDs and starting up all APs without
> > >> performing a broadcast SIPI
> > >> - Detecting and allowing OVMF to run in a VMPL other than 0 when an
> > >> SVSM is present
> > >>
> > >> The series is based off of commit:
> > >>
> > >> 7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
> > >>
> > >> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-
> technical-
> > >> docs/specifications/58019.pdf
> > >> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-
> technical-
> > >> docs/specifications/56421.pdf
> > >>
> > >> ---
> > >>
> > >> Tom Lendacky (16):
> > >> OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
> > >> MdePkg/Register/Amd: Define the SVSM related information
> > >> MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
> > >> UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
> > >> Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
> > >> OvmfPkg: Create a calling area used to communicate with the SVSM
> > >> OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
> > >> OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
> > >> UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
> > >> MdePkg: GHCB APIC ID retrieval support definitions
> > >> UefiCpuPkg: Create APIC ID list PCD
> > >> OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
> > >> UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
> > >> UefiCpuPkg/MpInitLib: AP creation support under an SVSM
> > >> Ovmfpkg/CcExitLib: Provide SVSM discovery support
> > >> OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not
> at
> > >> VMPL0
> > >>
> > >> OvmfPkg/OvmfPkg.dec | 4 +
> > >> UefiCpuPkg/UefiCpuPkg.dec | 7 +-
> > >> OvmfPkg/AmdSev/AmdSevX64.fdf | 9 +-
> > >> OvmfPkg/OvmfPkgX64.fdf | 3 +
> > >> MdePkg/Library/BaseLib/BaseLib.inf | 2 +
> > >> OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
> > >> OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
> > >> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
> > >> OvmfPkg/ResetVector/ResetVector.inf | 2 +
> > >> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
> > >> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
> > >> MdePkg/Include/Library/BaseLib.h | 39 ++
> > >> MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +-
> > >> MdePkg/Include/Register/Amd/Ghcb.h | 19 +-
> > >> MdePkg/Include/Register/Amd/Msr.h | 3 +-
> > >> MdePkg/Include/Register/Amd/Svsm.h | 101 ++++
> > >> MdePkg/Include/Register/Amd/SvsmMsr.h | 35 ++
> > >> OvmfPkg/Include/WorkArea.h | 7 +
> > >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
> |
> > 4
> > >> +-
> > >> OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++
> > >> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++-
> > >> UefiCpuPkg/Library/MpInitLib/MpLib.h | 27 +-
> > >>
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
> > |
> > >> 16 +-
> > >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
> |
> > 25
> > >> +-
> > >>
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
> > |
> > >> 20 +-
> > >>
> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
> > |
> > >> 25 +-
> > >>
> > OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
> |
> > >> 203 ++++----
> > >> OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 532
> > >> ++++++++++++++++++++
> > >> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 +-
> > >> OvmfPkg/PlatformPei/AmdSev.c | 100 +++-
> > >> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 ++-
> > >> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +-
> > >> UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
> > >> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 127 +++--
> > >> MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++
> > >> MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++
> > >> OvmfPkg/ResetVector/ResetVector.nasmb | 6 +-
> > >> OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +
> > >> UefiCpuPkg/UefiCpuPkg.uni | 3 +
> > >> 39 files changed, 1524 insertions(+), 210 deletions(-)
> > >> create mode 100644 MdePkg/Include/Register/Amd/Svsm.h
> > >> create mode 100644 MdePkg/Include/Register/Amd/SvsmMsr.h
> > >> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.h
> > >> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.c
> > >> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
> > >> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
> > >>
> > >> --
> > >> 2.42.0
> > >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115289): https://edk2.groups.io/g/devel/message/115289
Mute This Topic: https://groups.io/mt/103986434/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
2024-02-09 8:11 ` Yao, Jiewen
@ 2024-02-09 16:17 ` Lendacky, Thomas via groups.io
0 siblings, 0 replies; 56+ messages in thread
From: Lendacky, Thomas via groups.io @ 2024-02-09 16:17 UTC (permalink / raw)
To: Yao, Jiewen, devel@edk2.groups.io
Cc: Ard Biesheuvel, Aktas, Erdem, Gerd Hoffmann, Laszlo Ersek,
Liming Gao, Kinney, Michael D, Xu, Min M, Liu, Zhiguang,
Kumar, Rahul R, Ni, Ray, Michael Roth
On 2/9/24 02:11, Yao, Jiewen wrote:
> Some initial feedback:
>
> Patch 1 - OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
> Please split MdePkg update, since it requires different reviewer.
Yes, I had noticed this also and have split this out separately.
>
> Patch 4 - UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
> I am not sure why we need to expose SVSM API in CcExitLib. Why the Exception handle need to aware of SVSM?
> If other library need SVSM API, then why not create a SvsmLib?
I chose the CcExitLib library because of the issuance of GHCB requests /
VMGEXIT and the guarding of the GHCB from that library today. I can
certainly look at creating a separate library if that is truly
required/preferred, but to me it made sense to put that function in that
library. Please let me know your thoughts.
>
> Patch 11 - UefiCpuPkg: Create APIC ID list PCD
> Why use PCD? Why not use HOB?
Yes, Ray had the same request and it will be converted to a HOB in the
next version.
Thanks,
Tom
>
> Thank you
> Yao, Jiewen
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
>> Sent: Sunday, January 28, 2024 12:11 PM
>> To: Tom Lendacky <thomas.lendacky@amd.com>; devel@edk2.groups.io
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
>> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo Ersek
>> <lersek@redhat.com>; Liming Gao <gaoliming@byosoft.com.cn>; Kinney, Michael
>> D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
>> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>;
>> Ni, Ray <ray.ni@intel.com>; Michael Roth <michael.roth@amd.com>
>> Subject: Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running
>> under an SVSM
>>
>> Thanks Tom. Below is exactly what I am looking for:
>> "the decision to use the SVSM API will be based on the VMPL level at which
>> OVMF is running."
>>
>> OVMF needs to detect SEV-SNP, then make next level decision on VMPL.
>> Makes sense to me.
>>
>> Thank you
>> Yao, Jiewen
>>
>>> -----Original Message-----
>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>> Sent: Sunday, January 28, 2024 1:49 AM
>>> To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io
>>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
>>> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Laszlo
>> Ersek
>>> <lersek@redhat.com>; Liming Gao <gaoliming@byosoft.com.cn>; Kinney,
>> Michael
>>> D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com>; Liu,
>>> Zhiguang <zhiguang.liu@intel.com>; Kumar, Rahul R
>> <rahul.r.kumar@intel.com>;
>>> Ni, Ray <ray.ni@intel.com>; Michael Roth <michael.roth@amd.com>
>>> Subject: Re: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
>>>
>>> On 1/26/24 22:04, Yao, Jiewen wrote:
>>>> Thanks Tom.
>>>> Please give me some time to digest this patch set before I can give some
>>> feedback.
>>>>
>>>> One quick question to you:
>>>> With this patch, we need to support multiple SEV modes:
>>>> 1. SEV guest firmware
>>>> 2. SEV-ES guest firmware
>>>> 3. SEV-SNP guest firmware
>>>> 4. SEV-SNP SVSM guest firmware
>>>
>>> This last mode is still an SNP guest, it just requires invoking an API to
>>> perform operations that require VMPL0 permissions. I'm not sure what you
>>> mean by having firmware at the end of each mode. The same firmware is used
>>> for all SEV guest modes as well as non-SEV guests.
>>>
>>>> And all these mode requires runtime detection. Am I right?
>>>
>>> Yes
>>>
>>>> If so, where is the flag to set those mode?
>>>
>>> There are function calls available to detect the SEV mode. See the
>>> implementation of MemEncryptSevIsEnabled(), MemEncryptSevEsIsEnabled()
>> and
>>> MemEncryptSevSnpIsEnabled().
>>>
>>> OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
>>> OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
>>> OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
>>>
>>> (OvmfPkg/Sec/AmdSev.c also has some early detection support)
>>>
>>> Note:
>>> - An SEV-SNP guest is also considered an SEV-ES and SEV guest.
>>> - An SEV-ES guest is also considered an SEV guest.
>>>
>>> Within the CcExitLib library, the decision to use the SVSM API will be
>>> based on the VMPL level at which OVMF is running.
>>>
>>> Thanks,
>>> Tom
>>>
>>>>
>>>> Please correct me if my understanding is wrong.
>>>>
>>>> Thank you
>>>> Yao, Jiewen
>>>>
>>>>> -----Original Message-----
>>>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>>>> Sent: Saturday, January 27, 2024 6:13 AM
>>>>> To: devel@edk2.groups.io
>>>>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Aktas, Erdem
>>>>> <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; Yao,
>>> Jiewen
>>>>> <jiewen.yao@intel.com>; Laszlo Ersek <lersek@redhat.com>; Liming Gao
>>>>> <gaoliming@byosoft.com.cn>; Kinney, Michael D
>>> <michael.d.kinney@intel.com>;
>>>>> Xu, Min M <min.m.xu@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
>>>>> Kumar, Rahul R <rahul.r.kumar@intel.com>; Ni, Ray <ray.ni@intel.com>;
>>> Michael
>>>>> Roth <michael.roth@amd.com>
>>>>> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
>>>>>
>>>>>
>>>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>>>>
>>>>> This series adds SEV-SNP support for running OVMF under an Secure VM
>>>>> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
>>>>> By running at a less priviledged VMPL, the SVSM can be used to provide
>>>>> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
>>>>> confidential VM (CVM) rather than trust such services from the hypervisor.
>>>>>
>>>>> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
>>>>> certain SNP related operations that require that VMPL level. Specifically,
>>>>> the PVALIDATE instruction and the RMPADJUST instruction when setting the
>>>>> the VMSA attribute of a page (used when starting APs).
>>>>>
>>>>> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
>>>>> use an SVSM (which is running at VMPL0) to perform the operations that
>>>>> it is no longer able to perform.
>>>>>
>>>>> How OVMF interacts with and uses the SVSM is documented in the SVSM
>>>>> specification [1] and the GHCB specification [2].
>>>>>
>>>>> This series introduces support to run OVMF under an SVSM. It consists
>>>>> of:
>>>>> - Reorganize the page state change support to not directly use the
>>>>> GHCB buffer since an SVSM will use the calling area buffer, instead
>>>>> - Detecting the presence of an SVSM
>>>>> - When not running at VMPL0, invoking the SVSM for page validation and
>>>>> VMSA page creation/deletion
>>>>> - Retrieving the list of vCPU APIC IDs and starting up all APs without
>>>>> performing a broadcast SIPI
>>>>> - Detecting and allowing OVMF to run in a VMPL other than 0 when an
>>>>> SVSM is present
>>>>>
>>>>> The series is based off of commit:
>>>>>
>>>>> 7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
>>>>>
>>>>> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-
>> technical-
>>>>> docs/specifications/58019.pdf
>>>>> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-
>> technical-
>>>>> docs/specifications/56421.pdf
>>>>>
>>>>> ---
>>>>>
>>>>> Tom Lendacky (16):
>>>>> OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
>>>>> MdePkg/Register/Amd: Define the SVSM related information
>>>>> MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
>>>>> UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
>>>>> Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
>>>>> OvmfPkg: Create a calling area used to communicate with the SVSM
>>>>> OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
>>>>> OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
>>>>> UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
>>>>> MdePkg: GHCB APIC ID retrieval support definitions
>>>>> UefiCpuPkg: Create APIC ID list PCD
>>>>> OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
>>>>> UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
>>>>> UefiCpuPkg/MpInitLib: AP creation support under an SVSM
>>>>> Ovmfpkg/CcExitLib: Provide SVSM discovery support
>>>>> OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not
>> at
>>>>> VMPL0
>>>>>
>>>>> OvmfPkg/OvmfPkg.dec | 4 +
>>>>> UefiCpuPkg/UefiCpuPkg.dec | 7 +-
>>>>> OvmfPkg/AmdSev/AmdSevX64.fdf | 9 +-
>>>>> OvmfPkg/OvmfPkgX64.fdf | 3 +
>>>>> MdePkg/Library/BaseLib/BaseLib.inf | 2 +
>>>>> OvmfPkg/Library/CcExitLib/CcExitLib.inf | 5 +-
>>>>> OvmfPkg/Library/CcExitLib/SecCcExitLib.inf | 5 +-
>>>>> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
>>>>> OvmfPkg/ResetVector/ResetVector.inf | 2 +
>>>>> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
>>>>> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 3 +-
>>>>> MdePkg/Include/Library/BaseLib.h | 39 ++
>>>>> MdePkg/Include/Register/Amd/Fam17Msr.h | 19 +-
>>>>> MdePkg/Include/Register/Amd/Ghcb.h | 19 +-
>>>>> MdePkg/Include/Register/Amd/Msr.h | 3 +-
>>>>> MdePkg/Include/Register/Amd/Svsm.h | 101 ++++
>>>>> MdePkg/Include/Register/Amd/SvsmMsr.h | 35 ++
>>>>> OvmfPkg/Include/WorkArea.h | 7 +
>>>>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChange.h
>> |
>>> 4
>>>>> +-
>>>>> OvmfPkg/Library/CcExitLib/CcExitSvsm.h | 29 ++
>>>>> UefiCpuPkg/Include/Library/CcExitLib.h | 71 ++-
>>>>> UefiCpuPkg/Library/MpInitLib/MpLib.h | 27 +-
>>>>>
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
>>> |
>>>>> 16 +-
>>>>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
>> |
>>> 25
>>>>> +-
>>>>>
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiSnpSystemRamValidate.c
>>> |
>>>>> 20 +-
>>>>>
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SecSnpSystemRamValidate.c
>>> |
>>>>> 25 +-
>>>>>
>>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/SnpPageStateChangeInternal.c
>> |
>>>>> 203 ++++----
>>>>> OvmfPkg/Library/CcExitLib/CcExitSvsm.c | 532
>>>>> ++++++++++++++++++++
>>>>> OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 29 +-
>>>>> OvmfPkg/PlatformPei/AmdSev.c | 100 +++-
>>>>> UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.c | 82 ++-
>>>>> UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c | 19 +-
>>>>> UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
>>>>> UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 127 +++--
>>>>> MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm | 39 ++
>>>>> MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm | 94 ++++
>>>>> OvmfPkg/ResetVector/ResetVector.nasmb | 6 +-
>>>>> OvmfPkg/ResetVector/X64/OvmfSevMetadata.asm | 9 +
>>>>> UefiCpuPkg/UefiCpuPkg.uni | 3 +
>>>>> 39 files changed, 1524 insertions(+), 210 deletions(-)
>>>>> create mode 100644 MdePkg/Include/Register/Amd/Svsm.h
>>>>> create mode 100644 MdePkg/Include/Register/Amd/SvsmMsr.h
>>>>> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.h
>>>>> create mode 100644 OvmfPkg/Library/CcExitLib/CcExitSvsm.c
>>>>> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExitSvsm.nasm
>>>>> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExitSvsm.nasm
>>>>>
>>>>> --
>>>>> 2.42.0
>>>>
>>
>>
>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115308): https://edk2.groups.io/g/devel/message/115308
Mute This Topic: https://groups.io/mt/103986434/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 56+ messages in thread