Re: [edk2-devel] [PATCH v12 07/46] MdePkg/BaseLib: Add support for the VMGEXIT instruction

[Lendacky, Thomas]

On 7/27/20 8:34 PM, Gao, Liming wrote:

Tom:


Hi Liming,


   I meet with GCC failure on this patch. Can you help check it? If nasm 
doesn't support the vmmcall instruction in 32-bit mode, you have to use inline 
assembly to support it.


What version of GCC are you using. I was able to successfully build the  
Ia32 version with my GCC level. The Ia32 version uses a trick to do switch  
to 64-bit just to encode the instruction. Looks like that doesn't work  
with your version of GCC.


I can probably switch to defining the instruction as bytes. Let me look  
into that and possibly send you a patch to test.


Thanks,
Tom



Edk2/Build/IntelFsp2Pkg/DEBUG_GCC5/IA32/MdePkg/Library/BaseLib/BaseLib/OUTPUT/Ia32/VmgExit.iii:33:
 error: elf32 output format does not support 64-bit code
GNUmakefile:741: recipe for target

Thanks
Liming
-Original Message-
From: Tom Lendacky 
Sent: 2020年7月27日 23:26
To: devel@edk2.groups.io
Cc: Brijesh Singh ; Ard Biesheuvel ; Dong, Eric 
; Justen, Jordan L ; Laszlo Ersek ; Gao, 
Liming ; Kinney, Michael D ; Ni, Ray 
Subject: [PATCH v12 07/46] MdePkg/BaseLib: Add support for the VMGEXIT 
instruction

From: Tom Lendacky 

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C77c8250cd9e14f2929a008d832965726%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314968570901400sdata=6zqseI3tVmaw351w9mfEymMnDcjDzjvcBrhARU6r3Ho%3Dreserved=0

VMGEXIT is a new instruction used for Hypervisor/Guest communication when 
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE) to 
occur, resulting in a #VMEXIT with an exit code value of 0x403.

Provide the necessary support to execute the VMGEXIT instruction, which is "rep; 
vmmcall".

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
  MdePkg/Library/BaseLib/BaseLib.inf   |  2 ++
  MdePkg/Include/Library/BaseLib.h | 14 +
  MdePkg/Library/BaseLib/Ia32/VmgExit.nasm | 37   
MdePkg/Library/BaseLib/X64/VmgExit.nasm  | 32 
  4 files changed, 85 insertions(+)
  create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
  create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 3b93b5db8d24..3b85c56c3c03 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -184,6 +184,7 @@ [Sources.Ia32]
Ia32/DisableCache.nasm| GCC
Ia32/RdRand.nasm
Ia32/XGetBv.nasm
+  Ia32/VmgExit.nasm
  
Ia32/DivS64x64Remainder.c

Ia32/InternalSwitchStack.c | MSFT
@@ -317,6 +318,7 @@ [Sources.X64]
X64/DisablePaging64.nasm
X64/RdRand.nasm
X64/XGetBv.nasm
+  X64/VmgExit.nasm
ChkStkGcc.c  | GCC
  
  [Sources.EBC]

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 7edf0051a0a0..04fb329eaabb 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7848,6 +7848,20 @@ AsmXGetBv (
);
  
  
+/**

+  Executes a VMGEXIT instruction (VMMCALL with a REP prefix)
+
+  Executes a VMGEXIT instruction. This function is only available on
+ IA-32 and  x64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  );
+
+
  /**
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/VmgExit.nasm 
b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
new file mode 100644
index ..a4b37385cc7a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
@@ -0,0 +1,37 @@
+;--
+
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights
+reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ; ; Module
+Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+
+SECTION .text
+
+;--
+
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+;
+; NASM doesn't support the vmmcall instruction in 32-bit mode, so work
+around ; this by temporarily switching to 64-bit mode.
+;
+BITS64
+rep vmmcall
+BITS32
+ret
+
diff --git a/MdePkg/Library/BaseLib/X64/VmgExit.nasm 
b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
new file mode 100644
index ..26f034593c67
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
@@ -0,0 +1,32 @@
+;--
+
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights
+reserved. ; SPDX-License-Identifier: 

Re: [edk2-devel] [PATCH v1 2/2] MdePkg: TimerRngLib: Added RngLib that uses TimerLib

[Ni, Ray]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Tuesday, July 28, 2020 10:06 AM
> To: devel@edk2.groups.io; matthewfcarl...@gmail.com
> Cc: Kinney, Michael D ; Gao, Liming 
> ; Liu, Zhiguang
> 
> Subject: Re: [edk2-devel] [PATCH v1 2/2] MdePkg: TimerRngLib: Added RngLib 
> that uses TimerLib
> 
> Hi Carlson
> The naming conversion for a lib instance is Lib. See 
> examples in MdePkg\Library.

Nice summary:)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63383): https://edk2.groups.io/g/devel/message/63383
Mute This Topic: https://groups.io/mt/75836598/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3] UefiCpuPkg/MtrrLib/UnitTest: Add host based unit test

[Ni, Ray]

Mike, Eric, Laszlo,
Sorry I just found that the v2 patch cannot pass the CI test because the yaml 
file is not updated to allow some modules depend on UnitTestFrameworkPkg.

So, this v3 patch doesn't change the other files but only yaml files comparing 
to v2.
I cannot separate the yaml change to a separate patch because that will still 
break the CI.
But, please just review the yaml part. I guarantee that no changes were made to 
non-yaml files.

I also added the unit test build/run to CI build step, following what 
MdePkg/MdeModulePkg did.


Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Tuesday, July 28, 2020 10:30 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Shao, Ming 
> ; Dong, Eric
> ; Laszlo Ersek ; Sean Brogan 
> ; Bret Barkelew
> ; Yao, Jiewen 
> Subject: [edk2-devel] [PATCH v3] UefiCpuPkg/MtrrLib/UnitTest: Add host based 
> unit test
> 
> Add host based unit tests for the MtrrLib services.
> The BaseLib services AsmCpuid(), AsmReadMsr64(), and
> AsmWriteMsr64() are hooked and provide simple emulation
> of the CPUID leafs and MSRs required by the MtrrLib to
> run as a host based unit test.
> 
> Test cases are developed for each of the API.
> 
> For the most important APIs MtrrSetMemoryAttributesInMtrrSettings()
> and MtrrSetMemoryAttributeInMtrrSettings(), random inputs are
> generated and fed to the APIs to make sure the implementation is
> good. The test application accepts an optional parameter which
> specifies how many iterations of feeding random inputs to the two
> APIs. The overall number of test cases increases when the iteration
> increases. Default iteration is 10 when no parameter is specified.
> 
> Signed-off-by: Ray Ni 
> Signed-off-by: Michael D Kinney 
> Signed-off-by: Ming Shao 
> Cc: Michael D Kinney 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Ming Shao 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Jiewen Yao 
> ---
>  .../MtrrLib/UnitTest/MtrrLibUnitTest.c| 1140 +
>  .../MtrrLib/UnitTest/MtrrLibUnitTest.h|  171 +++
>  .../MtrrLib/UnitTest/MtrrLibUnitTestHost.inf  |   39 +
>  UefiCpuPkg/Library/MtrrLib/UnitTest/Support.c |  913 +
>  UefiCpuPkg/Test/UefiCpuPkgHostTest.dsc|   31 +
>  UefiCpuPkg/UefiCpuPkg.ci.yaml |   12 +-
>  6 files changed, 2305 insertions(+), 1 deletion(-)
>  create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
>  create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.h
>  create mode 100644 
> UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTestHost.inf
>  create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/Support.c
>  create mode 100644 UefiCpuPkg/Test/UefiCpuPkgHostTest.dsc
> 
> diff --git a/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
> b/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
> new file mode 100644
> index 00..2eac41fc74
> --- /dev/null
> +++ b/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
> @@ -0,0 +1,1140 @@
> +/** @file
> 
> +  Unit tests of the MtrrLib instance of the MtrrLib class
> 
> +
> 
> +  Copyright (c) 2020, Intel Corporation. All rights reserved.
> 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +
> 
> +**/
> 
> +
> 
> +#include "MtrrLibUnitTest.h"
> 
> +
> 
> +STATIC CONST MTRR_LIB_SYSTEM_PARAMETER mDefaultSystemParameter = {
> 
> +  42, TRUE, TRUE, CacheUncacheable, 12
> 
> +};
> 
> +
> 
> +STATIC MTRR_LIB_SYSTEM_PARAMETER mSystemParameters[] = {
> 
> +  { 38, TRUE, TRUE, CacheUncacheable,12 },
> 
> +  { 38, TRUE, TRUE, CacheWriteBack,  12 },
> 
> +  { 38, TRUE, TRUE, CacheWriteThrough,   12 },
> 
> +  { 38, TRUE, TRUE, CacheWriteProtected, 12 },
> 
> +  { 38, TRUE, TRUE, CacheWriteCombining, 12 },
> 
> +
> 
> +  { 42, TRUE, TRUE, CacheUncacheable,12 },
> 
> +  { 42, TRUE, TRUE, CacheWriteBack,  12 },
> 
> +  { 42, TRUE, TRUE, CacheWriteThrough,   12 },
> 
> +  { 42, TRUE, TRUE, CacheWriteProtected, 12 },
> 
> +  { 42, TRUE, TRUE, CacheWriteCombining, 12 },
> 
> +
> 
> +  { 48, TRUE, TRUE, CacheUncacheable,12 },
> 
> +  { 48, TRUE, TRUE, CacheWriteBack,  12 },
> 
> +  { 48, TRUE, TRUE, CacheWriteThrough,   12 },
> 
> +  { 48, TRUE, TRUE, CacheWriteProtected, 12 },
> 
> +  { 48, TRUE, TRUE, CacheWriteCombining, 12 },
> 
> +};
> 
> +
> 
> +UINT32mFixedMtrrsIndex[] = {
> 
> +  MSR_IA32_MTRR_FIX64K_0,
> 
> +  MSR_IA32_MTRR_FIX16K_8,
> 
> +  MSR_IA32_MTRR_FIX16K_A,
> 
> +  MSR_IA32_MTRR_FIX4K_C,
> 
> +  MSR_IA32_MTRR_FIX4K_C8000,
> 
> +  MSR_IA32_MTRR_FIX4K_D,
> 
> +  MSR_IA32_MTRR_FIX4K_D8000,
> 
> +  MSR_IA32_MTRR_FIX4K_E,
> 
> +  MSR_IA32_MTRR_FIX4K_E8000,
> 
> +  MSR_IA32_MTRR_FIX4K_F,
> 
> +  MSR_IA32_MTRR_FIX4K_F8000
> 
> +};
> 
> +STATIC_ASSERT (
> 
> +  (ARRAY_SIZE (mFixedMtrrsIndex) == MTRR_NUMBER_OF_FIXED_MTRR),
> 
> +  "gFixedMtrrIndex does NOT contain all the fixed MTRRs!"
> 
> +  );
> 
> +
> 
> +//
> 
> +// Context structure to be used for most 

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Ni, Ray]

I am not sure if Robert (Cced) has the interest to be the reviewer of the 
MdePkg/Include/IndustryStandard directory.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Liming Gao
> Sent: Tuesday, July 28, 2020 10:07 AM
> To: Leif Lindholm ; Javeed, Ashraf 
> ; Laszlo Ersek ;
> Sean Brogan 
> Cc: devel@edk2.groups.io; Kinney, Michael D 
> Subject: Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 
> 1.1 Registers
> 
> Leif:
> 
> -Original Message-
> From: Leif Lindholm 
> Sent: 2020年7月28日 0:14
> To: Gao, Liming 
> Cc: devel@edk2.groups.io; Javeed, Ashraf ; Kinney, 
> Michael D 
> Subject: Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 
> 1.1 Registers
> 
> On Mon, Jul 27, 2020 at 14:55:03 +, Gao, Liming wrote:
> > > > diff --git a/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > new file mode 100644
> > > > index 00..933c1ab817
> > > > --- /dev/null
> > > > +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > @@ -0,0 +1,569 @@
> > > > +/** @file
> > > > +  CXL 1.1 Register definitions
> > > > +
> > > > +  This file contains the register definitions based on the
> > > > + Compute Express Link
> > > > +  (CXL) Specification Revision 1.1.
> > > > +
> > > > +Copyright (c) 2020, Intel Corporation. All rights reserved.
> > > > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > +
> > > > +**/
> > > > +
> > > > +#ifndef _CXL11_H_
> > > > +#define _CXL11_H_
> > >
> > > We should not be adding macros with a leading _ - these are intended
> > > for toolchain use.
> >
> > This style is align to other header file. This is the file header
> > macro to make sure the header file be included more than once.
> 
> Yes. The other headers should also be changed, but in the meantime it would 
> be good to stop adding more incorrect ones.
> https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/5_source_files/53_include_files#5-3-5-all-include-file-
> contents-must-be-protected-by-a-include-guard
> 
> [Liming] Thank for your point. I miss this one, too. Now, most cases don't 
> follow this rule. So, there is no good example for
> the reference.
> I agree the rule to apply the strict check for new adding file. I will check 
> whether ECC has this check point.
> 
> > > > +
> > > > +//
> > > > +// CXL Flex Bus Device default device and function number //
> > > > +Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1
> > > > +//
> > > > +#define CXL_DEV_DEV
> > > >  0
> > > > +#define CXL_DEV_FUNC   
> > > >  0
> > > > +
> > > > +//
> > > > +// Ensure proper structure formats // #pragma pack(1)
> > >
> > > And this pragma has no function whatsoever with regards to any of
> > > the register definition structs below. It would be much better if
> > > the structs requiring packing (_DEVICE, _PORT, ...) were grouped
> > > together and only those were given this treatment.
> > >
> > > #pragma pack(1) is *not* a safe default.
> > >
> >
> > I know pack(1) is for the compact structure layout.
> 
> Yes. And it should be used when structs need to be compacted.
> All of the bitfield structs are single-variable structs, so the packing has 
> no effect on them, other than setting the struct
> alignment requirements to 1 byte, which will not be correct (or efficient) on 
> all architectures.
> 
> [Liming] Yes. There is no effect for bitfield structure. This header file 
> still includes some structure, such as
> CXL_1_1_DVSEC_FLEX_BUS_DEVICE. They may have the compact alignment 
> requirement.
> @Javeed, Ashraf, can you conform it?
> 
> > > Now, one final comment - and this is more of a project feature
> > > suggestion:
> > > Industry standard headers is something fairly special, even in
> > > comparison with the rest of MdePkg. *I* would certainly like to
> > > ensure I don't miss changes or additions to them.
> > > Could we set up a dedicated group of reviewers for this folder only?
> > > This need not affect the actual maintainership of MdePkg, just
> > > ensure more eyeballs (or screen readers, braille terminals, ...) hit
> > > updates here?
> > >
> > > i.e. something like the below to Maintainers.txt:
> > >
> > > F: MdePkg/Include/IndustryStandard/
> > > R: Leif ...
> > > R: ...
> > > R: ...
> > >
> >
> > This is a good suggestion. IndustryStandard needs more feedback.
> > Can you send the patch to update Maintainers.txt?
> 
> Sure, I can do that. Any thoughts on others to add than me?
> 
> [Liming] Thanks. Laszlo or Sean may be added if they are also interested in 
> IndustryStandard header file.
> 
> Thanks
> Liming
> /
> Leif
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63381): https://edk2.groups.io/g/devel/message/63381
Mute This Topic: https://groups.io/mt/75823529/21656
Group Owner: 

[edk2-devel] [PATCH v3] UefiCpuPkg/MtrrLib/UnitTest: Add host based unit test

[Ni, Ray]

Add host based unit tests for the MtrrLib services.
The BaseLib services AsmCpuid(), AsmReadMsr64(), and
AsmWriteMsr64() are hooked and provide simple emulation
of the CPUID leafs and MSRs required by the MtrrLib to
run as a host based unit test.

Test cases are developed for each of the API.

For the most important APIs MtrrSetMemoryAttributesInMtrrSettings()
and MtrrSetMemoryAttributeInMtrrSettings(), random inputs are
generated and fed to the APIs to make sure the implementation is
good. The test application accepts an optional parameter which
specifies how many iterations of feeding random inputs to the two
APIs. The overall number of test cases increases when the iteration
increases. Default iteration is 10 when no parameter is specified.

Signed-off-by: Ray Ni 
Signed-off-by: Michael D Kinney 
Signed-off-by: Ming Shao 
Cc: Michael D Kinney 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Ming Shao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Jiewen Yao 
---
 .../MtrrLib/UnitTest/MtrrLibUnitTest.c| 1140 +
 .../MtrrLib/UnitTest/MtrrLibUnitTest.h|  171 +++
 .../MtrrLib/UnitTest/MtrrLibUnitTestHost.inf  |   39 +
 UefiCpuPkg/Library/MtrrLib/UnitTest/Support.c |  913 +
 UefiCpuPkg/Test/UefiCpuPkgHostTest.dsc|   31 +
 UefiCpuPkg/UefiCpuPkg.ci.yaml |   12 +-
 6 files changed, 2305 insertions(+), 1 deletion(-)
 create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
 create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.h
 create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTestHost.inf
 create mode 100644 UefiCpuPkg/Library/MtrrLib/UnitTest/Support.c
 create mode 100644 UefiCpuPkg/Test/UefiCpuPkgHostTest.dsc

diff --git a/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c 
b/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
new file mode 100644
index 00..2eac41fc74
--- /dev/null
+++ b/UefiCpuPkg/Library/MtrrLib/UnitTest/MtrrLibUnitTest.c
@@ -0,0 +1,1140 @@
+/** @file
+  Unit tests of the MtrrLib instance of the MtrrLib class
+
+  Copyright (c) 2020, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "MtrrLibUnitTest.h"
+
+STATIC CONST MTRR_LIB_SYSTEM_PARAMETER mDefaultSystemParameter = {
+  42, TRUE, TRUE, CacheUncacheable, 12
+};
+
+STATIC MTRR_LIB_SYSTEM_PARAMETER mSystemParameters[] = {
+  { 38, TRUE, TRUE, CacheUncacheable,12 },
+  { 38, TRUE, TRUE, CacheWriteBack,  12 },
+  { 38, TRUE, TRUE, CacheWriteThrough,   12 },
+  { 38, TRUE, TRUE, CacheWriteProtected, 12 },
+  { 38, TRUE, TRUE, CacheWriteCombining, 12 },
+
+  { 42, TRUE, TRUE, CacheUncacheable,12 },
+  { 42, TRUE, TRUE, CacheWriteBack,  12 },
+  { 42, TRUE, TRUE, CacheWriteThrough,   12 },
+  { 42, TRUE, TRUE, CacheWriteProtected, 12 },
+  { 42, TRUE, TRUE, CacheWriteCombining, 12 },
+
+  { 48, TRUE, TRUE, CacheUncacheable,12 },
+  { 48, TRUE, TRUE, CacheWriteBack,  12 },
+  { 48, TRUE, TRUE, CacheWriteThrough,   12 },
+  { 48, TRUE, TRUE, CacheWriteProtected, 12 },
+  { 48, TRUE, TRUE, CacheWriteCombining, 12 },
+};
+
+UINT32mFixedMtrrsIndex[] = {
+  MSR_IA32_MTRR_FIX64K_0,
+  MSR_IA32_MTRR_FIX16K_8,
+  MSR_IA32_MTRR_FIX16K_A,
+  MSR_IA32_MTRR_FIX4K_C,
+  MSR_IA32_MTRR_FIX4K_C8000,
+  MSR_IA32_MTRR_FIX4K_D,
+  MSR_IA32_MTRR_FIX4K_D8000,
+  MSR_IA32_MTRR_FIX4K_E,
+  MSR_IA32_MTRR_FIX4K_E8000,
+  MSR_IA32_MTRR_FIX4K_F,
+  MSR_IA32_MTRR_FIX4K_F8000
+};
+STATIC_ASSERT (
+  (ARRAY_SIZE (mFixedMtrrsIndex) == MTRR_NUMBER_OF_FIXED_MTRR),
+  "gFixedMtrrIndex does NOT contain all the fixed MTRRs!"
+  );
+
+//
+// Context structure to be used for most of the test cases.
+//
+typedef struct {
+  CONST MTRR_LIB_SYSTEM_PARAMETER *SystemParameter;
+} MTRR_LIB_TEST_CONTEXT;
+
+//
+// Context structure to be used for GetFirmwareVariableMtrrCount() test.
+//
+typedef struct {
+  UINT32  NumberOfReservedVariableMtrrs;
+  CONST MTRR_LIB_SYSTEM_PARAMETER *SystemParameter;
+} MTRR_LIB_GET_FIRMWARE_VARIABLE_MTRR_COUNT_CONTEXT;
+
+STATIC CHAR8 *mCacheDescription[] = { "UC", "WC", "N/A", "N/A", "WT", "WP", 
"WB" };
+
+/**
+  Compare the actual memory ranges against expected memory ranges and return 
PASS when they match.
+
+  @param ExpectedMemoryRanges Expected memory ranges.
+  @param ExpectedMemoryRangeCount Count of expected memory ranges.
+  @param ActualRanges Actual memory ranges.
+  @param ActualRangeCount Count of actual memory ranges.
+
+  @retval UNIT_TEST_PASSED  Test passed.
+  @retval othersTest failed.
+**/
+UNIT_TEST_STATUS
+VerifyMemoryRanges (
+  IN MTRR_MEMORY_RANGE  *ExpectedMemoryRanges,
+  IN UINTN  ExpectedMemoryRangeCount,
+  IN MTRR_MEMORY_RANGE  *ActualRanges,
+  IN UINTN  ActualRangeCount
+  )
+{
+  UINTN  Index;
+  UT_ASSERT_EQUAL (ExpectedMemoryRangeCount, ActualRangeCount);
+  for (Index = 0; Index < 

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Michael D Kinney]

Liming,

Pragma once is an alternative to include guards.  If we want to 
remove the use of the include guard macros that start with '_',
we can consider using pragma once everywhere.

https://en.wikipedia.org/wiki/Pragma_once

If other include files have packed structure requirements,
then they should do it in their own files.  No include file
should depend on #pragma pack from another include file.

Mike

> -Original Message-
> From: Gao, Liming 
> Sent: Monday, July 27, 2020 7:07 PM
> To: Leif Lindholm ; Javeed, Ashraf
> ; Laszlo Ersek
> ; Sean Brogan
> 
> Cc: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [PATCH V4 1/2]
> MdePkg/Include/IndustryStandard: CXL 1.1 Registers
> 
> Leif:
> 
> -Original Message-
> From: Leif Lindholm 
> Sent: 2020年7月28日 0:14
> To: Gao, Liming 
> Cc: devel@edk2.groups.io; Javeed, Ashraf
> ; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [PATCH V4 1/2]
> MdePkg/Include/IndustryStandard: CXL 1.1 Registers
> 
> On Mon, Jul 27, 2020 at 14:55:03 +, Gao, Liming
> wrote:
> > > > diff --git
> a/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > new file mode 100644
> > > > index 00..933c1ab817
> > > > --- /dev/null
> > > > +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > > @@ -0,0 +1,569 @@
> > > > +/** @file
> > > > +  CXL 1.1 Register definitions
> > > > +
> > > > +  This file contains the register definitions
> based on the
> > > > + Compute Express Link
> > > > +  (CXL) Specification Revision 1.1.
> > > > +
> > > > +Copyright (c) 2020, Intel Corporation. All
> rights reserved.
> > > > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > +
> > > > +**/
> > > > +
> > > > +#ifndef _CXL11_H_
> > > > +#define _CXL11_H_
> > >
> > > We should not be adding macros with a leading _ -
> these are intended
> > > for toolchain use.
> >
> > This style is align to other header file. This is the
> file header
> > macro to make sure the header file be included more
> than once.
> 
> Yes. The other headers should also be changed, but in
> the meantime it would be good to stop adding more
> incorrect ones.
> https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-
> specification/5_source_files/53_include_files#5-3-5-
> all-include-file-contents-must-be-protected-by-a-
> include-guard
> 
> [Liming] Thank for your point. I miss this one, too.
> Now, most cases don't follow this rule. So, there is no
> good example for the reference.
> I agree the rule to apply the strict check for new
> adding file. I will check whether ECC has this check
> point.
> 
> > > > +
> > > > +//
> > > > +// CXL Flex Bus Device default device and
> function number //
> > > > +Compute Express Link Specification Revision: 1.1
> - Chapter 7.1.1
> > > > +//
> > > > +#define CXL_DEV_DEV
> 0
> > > > +#define CXL_DEV_FUNC
> 0
> > > > +
> > > > +//
> > > > +// Ensure proper structure formats // #pragma
> pack(1)
> > >
> > > And this pragma has no function whatsoever with
> regards to any of
> > > the register definition structs below. It would be
> much better if
> > > the structs requiring packing (_DEVICE, _PORT, ...)
> were grouped
> > > together and only those were given this treatment.
> > >
> > > #pragma pack(1) is *not* a safe default.
> > >
> >
> > I know pack(1) is for the compact structure layout.
> 
> Yes. And it should be used when structs need to be
> compacted.
> All of the bitfield structs are single-variable
> structs, so the packing has no effect on them, other
> than setting the struct alignment requirements to 1
> byte, which will not be correct (or efficient) on all
> architectures.
> 
> [Liming] Yes. There is no effect for bitfield
> structure. This header file still includes some
> structure, such as CXL_1_1_DVSEC_FLEX_BUS_DEVICE. They
> may have the compact alignment requirement.
> @Javeed, Ashraf, can you conform it?
> 
> > > Now, one final comment - and this is more of a
> project feature
> > > suggestion:
> > > Industry standard headers is something fairly
> special, even in
> > > comparison with the rest of MdePkg. *I* would
> certainly like to
> > > ensure I don't miss changes or additions to them.
> > > Could we set up a dedicated group of reviewers for
> this folder only?
> > > This need not affect the actual maintainership of
> MdePkg, just
> > > ensure more eyeballs (or screen readers, braille
> terminals, ...) hit
> > > updates here?
> > >
> > > i.e. something like the below to Maintainers.txt:
> > >
> > > F: MdePkg/Include/IndustryStandard/
> > > R: Leif ...
> > > R: ...
> > > R: ...
> > >
> >
> > This is a good suggestion. IndustryStandard needs
> more feedback.
> > Can you send the patch to update Maintainers.txt?
> 
> Sure, I can do that. Any thoughts on others to add than
> me?
> 
> [Liming] Thanks. Laszlo or Sean may be added if they
> are also interested in IndustryStandard header file.
> 
> Thanks
> Liming
> /
> Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all 

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Liming Gao]

Leif:

-Original Message-
From: Leif Lindholm  
Sent: 2020年7月28日 0:14
To: Gao, Liming 
Cc: devel@edk2.groups.io; Javeed, Ashraf ; Kinney, 
Michael D 
Subject: Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 
1.1 Registers

On Mon, Jul 27, 2020 at 14:55:03 +, Gao, Liming wrote:
> > > diff --git a/MdePkg/Include/IndustryStandard/Cxl11.h 
> > > b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > new file mode 100644
> > > index 00..933c1ab817
> > > --- /dev/null
> > > +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > @@ -0,0 +1,569 @@
> > > +/** @file
> > > +  CXL 1.1 Register definitions
> > > +
> > > +  This file contains the register definitions based on the 
> > > + Compute Express Link
> > > +  (CXL) Specification Revision 1.1.
> > > +
> > > +Copyright (c) 2020, Intel Corporation. All rights reserved.
> > > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +
> > > +**/
> > > +
> > > +#ifndef _CXL11_H_
> > > +#define _CXL11_H_
> > 
> > We should not be adding macros with a leading _ - these are intended 
> > for toolchain use.
> 
> This style is align to other header file. This is the file header 
> macro to make sure the header file be included more than once.

Yes. The other headers should also be changed, but in the meantime it would be 
good to stop adding more incorrect ones.
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/5_source_files/53_include_files#5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard

[Liming] Thank for your point. I miss this one, too. Now, most cases don't 
follow this rule. So, there is no good example for the reference. 
I agree the rule to apply the strict check for new adding file. I will check 
whether ECC has this check point. 

> > > +
> > > +//
> > > +// CXL Flex Bus Device default device and function number // 
> > > +Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1 
> > > +//
> > > +#define CXL_DEV_DEV 0
> > > +#define CXL_DEV_FUNC0
> > > +
> > > +//
> > > +// Ensure proper structure formats // #pragma pack(1)
> > 
> > And this pragma has no function whatsoever with regards to any of 
> > the register definition structs below. It would be much better if 
> > the structs requiring packing (_DEVICE, _PORT, ...) were grouped 
> > together and only those were given this treatment.
> > 
> > #pragma pack(1) is *not* a safe default.
> > 
> 
> I know pack(1) is for the compact structure layout. 

Yes. And it should be used when structs need to be compacted.
All of the bitfield structs are single-variable structs, so the packing has no 
effect on them, other than setting the struct alignment requirements to 1 byte, 
which will not be correct (or efficient) on all architectures.

[Liming] Yes. There is no effect for bitfield structure. This header file still 
includes some structure, such as CXL_1_1_DVSEC_FLEX_BUS_DEVICE. They may have 
the compact alignment requirement. 
@Javeed, Ashraf, can you conform it?

> > Now, one final comment - and this is more of a project feature
> > suggestion:
> > Industry standard headers is something fairly special, even in 
> > comparison with the rest of MdePkg. *I* would certainly like to 
> > ensure I don't miss changes or additions to them.
> > Could we set up a dedicated group of reviewers for this folder only?
> > This need not affect the actual maintainership of MdePkg, just 
> > ensure more eyeballs (or screen readers, braille terminals, ...) hit 
> > updates here?
> > 
> > i.e. something like the below to Maintainers.txt:
> > 
> > F: MdePkg/Include/IndustryStandard/
> > R: Leif ...
> > R: ...
> > R: ...
> > 
> 
> This is a good suggestion. IndustryStandard needs more feedback. 
> Can you send the patch to update Maintainers.txt?

Sure, I can do that. Any thoughts on others to add than me?

[Liming] Thanks. Laszlo or Sean may be added if they are also interested in 
IndustryStandard header file. 

Thanks
Liming
/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63378): https://edk2.groups.io/g/devel/message/63378
Mute This Topic: https://groups.io/mt/75823529/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] MdePkg: TimerRngLib: Added RngLib that uses TimerLib

[Yao, Jiewen]

Hi Carlson
The naming conversion for a lib instance is Lib. See 
examples in MdePkg\Library.

I feel that we had better name it to be BaseRngLibTimer

Thank you
Yao Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Matthew
> Carlson
> Sent: Tuesday, July 28, 2020 9:53 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Matthew
> Carlson 
> Subject: [edk2-devel] [PATCH v1 2/2] MdePkg: TimerRngLib: Added RngLib that
> uses TimerLib
> 
> From: Matthew Carlson 
> 
> Added a new RngLib that provides random numbers from the TimerLib
> using the performance counter. This is meant to be used for OpenSSL
> to replicate past behavior. This should not be used in production as
> a real source of entropy.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Signed-off-by: Matthew Carlson 
> ---
>  MdePkg/Library/TimerRngLib/TimerRng.c  | 153 
>  MdePkg/Library/TimerRngLib/TimerRngLib.inf |  37 +
>  MdePkg/MdePkg.dsc  |   2 +
>  3 files changed, 192 insertions(+)
> 
> diff --git a/MdePkg/Library/TimerRngLib/TimerRng.c
> b/MdePkg/Library/TimerRngLib/TimerRng.c
> new file mode 100644
> index ..1b0f7f04c01d
> --- /dev/null
> +++ b/MdePkg/Library/TimerRngLib/TimerRng.c
> @@ -0,0 +1,153 @@
> +/** @file
> 
> +  BaseRng Library that uses the TimerLib to provide reasonably random
> numbers.
> 
> +  Do not use this on a production system.
> 
> +
> 
> +  Copyright (c) Microsoft Corporation.
> 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +**/
> 
> +
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +
> 
> +/**
> 
> +  Generates a 16-bit random number.
> 
> +
> 
> +  if Rand is NULL, then ASSERT().
> 
> +
> 
> +  @param[out] Rand Buffer pointer to store the 16-bit random value.
> 
> +
> 
> +  @retval TRUE Random number generated successfully.
> 
> +  @retval FALSEFailed to generate the random number.
> 
> +
> 
> +**/
> 
> +BOOLEAN
> 
> +EFIAPI
> 
> +GetRandomNumber16 (
> 
> +  OUT UINT16*Rand
> 
> +  )
> 
> +{
> 
> +  UINT32  Index;
> 
> +  UINT8* RandPtr;
> 
> +
> 
> +  ASSERT (Rand != NULL);
> 
> +
> 
> +  if (NULL == Rand) {
> 
> +return FALSE;
> 
> +  }
> 
> +
> 
> +  RandPtr = (UINT8 *) Rand;
> 
> +  // Get 2 bytes of random ish data
> 
> +  for (Index = 0; Index < 2; Index ++) {
> 
> +*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
> 
> +MicroSecondDelay (4);
> 
> +RandPtr++;
> 
> +  }
> 
> +  return TRUE;
> 
> +}
> 
> +
> 
> +/**
> 
> +  Generates a 32-bit random number.
> 
> +
> 
> +  if Rand is NULL, then ASSERT().
> 
> +
> 
> +  @param[out] Rand Buffer pointer to store the 32-bit random value.
> 
> +
> 
> +  @retval TRUE Random number generated successfully.
> 
> +  @retval FALSEFailed to generate the random number.
> 
> +
> 
> +**/
> 
> +BOOLEAN
> 
> +EFIAPI
> 
> +GetRandomNumber32 (
> 
> +  OUT UINT32*Rand
> 
> +  )
> 
> +{
> 
> +  UINT32  Index;
> 
> +  UINT8* RandPtr;
> 
> +
> 
> +  ASSERT (Rand != NULL);
> 
> +
> 
> +  if (NULL == Rand) {
> 
> +return FALSE;
> 
> +  }
> 
> +
> 
> +  RandPtr = (UINT8 *) Rand;
> 
> +  // Get 4 bytes of random ish data
> 
> +  for (Index = 0; Index < 4; Index ++) {
> 
> +*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
> 
> +MicroSecondDelay (2);
> 
> +RandPtr++;
> 
> +  }
> 
> +  return TRUE;
> 
> +}
> 
> +
> 
> +/**
> 
> +  Generates a 64-bit random number.
> 
> +
> 
> +  if Rand is NULL, then ASSERT().
> 
> +
> 
> +  @param[out] Rand Buffer pointer to store the 64-bit random value.
> 
> +
> 
> +  @retval TRUE Random number generated successfully.
> 
> +  @retval FALSEFailed to generate the random number.
> 
> +
> 
> +**/
> 
> +BOOLEAN
> 
> +EFIAPI
> 
> +GetRandomNumber64 (
> 
> +  OUT UINT64*Rand
> 
> +  )
> 
> +{
> 
> +  UINT32  Index;
> 
> +  UINT8* RandPtr;
> 
> +
> 
> +  ASSERT (Rand != NULL);
> 
> +
> 
> +  if (NULL == Rand) {
> 
> +return FALSE;
> 
> +  }
> 
> +
> 
> +  RandPtr = (UINT8 *) Rand;
> 
> +  // Get 8 bytes of random ish data
> 
> +  for (Index = 0; Index < 8; Index ++) {
> 
> +*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
> 
> +MicroSecondDelay (1);
> 
> +RandPtr++;
> 
> +  }
> 
> +
> 
> +  return TRUE;
> 
> +}
> 
> +
> 
> +/**
> 
> +  Generates a 128-bit random number.
> 
> +
> 
> +  if Rand is NULL, then ASSERT().
> 
> +
> 
> +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> 
> +
> 
> +  @retval TRUE Random number generated successfully.
> 
> +  @retval FALSEFailed to generate the random number.
> 
> +
> 
> +**/
> 
> +BOOLEAN
> 
> +EFIAPI
> 
> +GetRandomNumber128 (
> 
> +  OUT UINT64*Rand
> 
> +  )
> 
> +{
> 
> +  ASSERT (Rand != NULL);
> 
> +
> 
> +  //
> 
> +  // Read first 64 bits
> 
> +  //
> 
> +  if (!GetRandomNumber64 

Re: [edk2-devel] [PATCH] Maintainers.txt: Add 'Yuwei Chen' for Tools review

[Liming Gao]

Reviewed-by: Liming Gao 

-Original Message-
From: Chen, Christine  
Sent: 2020年7月24日 16:55
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: [PATCH] Maintainers.txt: Add 'Yuwei Chen' for Tools review

Add 'Yuwei Chen' as a reviewer for
Edk2-platforms\Platform\Intel\Tools and
Edk2-platforms\Silicon\Intel\Tools.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Yuwei Chen 
---
 Maintainers.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt index 9fc41187b7..01fbea5034 
100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -192,6 +192,7 @@ Platform/Intel/Tools
 F: Platform/Intel/Tools/ M: Bob Feng  M: Liming Gao 
+R: Yuwei Chen   
Silicon/Intel/IntelSiliconPkg F: Silicon/Intel/IntelSiliconPkg/@@ -230,6 +231,7 
@@ Silicon/Intel/Tools
 F: Silicon/Intel/Tools/ M: Bob Feng  M: Liming Gao 
+R: Yuwei Chen   Marvell platforms 
and silicon F: Platform/Marvell/--
2.27.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63376): https://edk2.groups.io/g/devel/message/63376
Mute This Topic: https://groups.io/mt/75762929/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] Maintainers.txt: Add 'Yuwei Chen' for BaseTools review

[Liming Gao]

Reviewed-by: Liming Gao 

-Original Message-
From: Chen, Christine  
Sent: 2020年7月24日 16:39
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: [PATCH 1/1] Maintainers.txt: Add 'Yuwei Chen' for BaseTools review

Add 'Yuwei Chen' as a reviewer for Edk2\BaseTools.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Yuwei Chen 
---
 Maintainers.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Maintainers.txt b/Maintainers.txt index 599f94d57a3d..da09b0be1b96 
100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -157,6 +157,7 @@ F: BaseTools/
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
 M: Bob Feng 
 M: Liming Gao 
+R: Yuwei Chen 
 
 CryptoPkg
 F: CryptoPkg/
--
2.27.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63375): https://edk2.groups.io/g/devel/message/63375
Mute This Topic: https://groups.io/mt/75762798/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 2/3] MdePkg/BasePciExpressLib: Support variable size MMCONF

[Liming Gao]

Thanks for your update.

This patch updates PciExpressLib library class to depend on 
PcdPciExpressBaseAddress and PcdPciExpressBaseSize both. So, all PciExpressLib 
library instances (BasePciExpressLib, DxeRuntimePciExpressLib and 
SmmPciExpressLib) should be updated. Otherwise, the developer may be confused 
when he finds PcdPciExpressBaseSize doesn't work. Can you let me know why you 
only update BasePciExpressLib library instance?

Thanks
Liming
-Original Message-
From: Marcello Sylvester Bauer  
Sent: 2020年7月27日 16:19
To: devel@edk2.groups.io
Cc: Patrick Rudolph ; Christian Walter 
; Kinney, Michael D 
; Gao, Liming 
Subject: [PATCH v4 2/3] MdePkg/BasePciExpressLib: Support variable size MMCONF

Add support for arbitrary sized MMCONF by introducing a new PCD.

Signed-off-by: Patrick Rudolph 
Signed-off-by: Marcello Sylvester Bauer 
Cc: Patrick Rudolph 
Cc: Christian Walter 
Cc: Michael D Kinney 
Cc: Liming Gao 
---
 MdePkg/MdePkg.dec  |   4 +
 MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf |   6 +-
 MdePkg/Include/Library/PciExpressLib.h |   5 +-
 MdePkg/Library/BasePciExpressLib/PciExpressLib.c   | 216 
+---
 4 files changed, 193 insertions(+), 38 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index 
73f6c2407357..812be75fb3b2 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2274,6 +2274,10 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt PCI Express Base Address.   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000|UINT64|0x000a 
+  ## This value is used to set the size of PCI express hierarchy. The default 
is 256 MB.+  # @Prompt PCI Express Base Size.+  
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x1000|UINT64|0x000f+   
## Default current ISO 639-2 language: English & French.   # @Prompt Default 
Value of LangCodes Variable.   
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangCodes|"engfraengfra"|VOID*|0x001cdiff
 --git a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf 
b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
index a7edb74cde71..12734b022ac7 100644
--- a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
+++ b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
@@ -1,7 +1,7 @@
 ## @file-#  Instance of PCI Express Library using the 256 MB PCI Express MMIO 
window.+#  Instance of PCI Express Library using the variable size PCI Express 
MMIO window. #-#  PCI Express Library that uses the 256 MB PCI Express MMIO 
window to perform+#  PCI Express Library that uses the variable size PCI 
Express MMIO window to perform #  PCI Configuration cycles. Layers on top of an 
I/O Library instance. # #  Copyright (c) 2007 - 2018, Intel Corporation. All 
rights reserved.@@ -38,4 +38,4 @@ [LibraryClasses]
  [Pcd]   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress  ## CONSUMES-+  
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize  ## CONSUMESdiff --git 
a/MdePkg/Include/Library/PciExpressLib.h 
b/MdePkg/Include/Library/PciExpressLib.h
index 826fdcf7db6c..d78193a0a352 100644
--- a/MdePkg/Include/Library/PciExpressLib.h
+++ b/MdePkg/Include/Library/PciExpressLib.h
@@ -2,8 +2,9 @@
   Provides services to access PCI Configuration Space using the MMIO PCI 
Express window.This library is identical to the PCI Library, except the 
access method for performing PCI-  configuration cycles must be through the 256 
MB PCI Express MMIO window whose base address-  is defined by 
PcdPciExpressBaseAddress.+  configuration cycles must be through the PCI 
Express MMIO window whose base address+  is defined by PcdPciExpressBaseAddress 
and size defined by PcdPciExpressBaseSize.+  Copyright (c) 2006 - 2018, Intel 
Corporation. All rights reserved. SPDX-License-Identifier: 
BSD-2-Clause-Patentdiff --git 
a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c 
b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
index 99a166c3609b..0311ecb3025f 100644
--- a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
+++ b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
@@ -22,7 +22,8 @@
  /**   Assert the validity of a PCI address. A valid PCI address should 
contain 1's-  only in the low 28 bits.+  only in the low 28 bits. 
PcdPciExpressBaseSize limits the size to the real+  number of PCI busses in 
this segment.@param  A The address to validate. @@ -79,6 +80,24 @@ 
GetPciExpressBaseAddress (
   return (VOID*)(UINTN) PcdGet64 (PcdPciExpressBaseAddress); } +/**+  Gets the 
size of PCI Express.++  This internal functions retrieves PCI Express Base Size 
via a PCD entry+  PcdPciExpressBaseSize.++  @return The base size of PCI 
Express.++**/+STATIC+UINTN+PcdPciExpressBaseSize (+  VOID+  )+{+  return 
(UINTN) PcdGet64 (PcdPciExpressBaseSize);+}+ /**   Reads an 8-bit PCI 
configuration register. @@ -91,7 +110,8 @@ GetPciExpressBaseAddress (
   @param  Address The address that encodes the PCI Bus, Device, Function and   

[edk2-devel] [PATCH v1 1/2] CryptoPkg: OpensslLib: Use RngLib to generate entropy in rand_pool

[Matthew Carlson]

From: Matthew Carlson 

Changes OpenSSL to no longer depend on TimerLib and instead use RngLib.
This allows platforms to decide for themsevles what sort of entropy source
they provide to OpenSSL and TlsLib.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Signed-off-by: Matthew Carlson 
---
 CryptoPkg/Library/OpensslLib/rand_pool.c   | 200 ++--
 CryptoPkg/Library/OpensslLib/rand_pool_noise.c |  29 ---
 CryptoPkg/Library/OpensslLib/rand_pool_noise_tsc.c |  43 -
 CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
 CryptoPkg/Library/OpensslLib/rand_pool_noise.h |  29 ---
 6 files changed, 20 insertions(+), 311 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/rand_pool.c 
b/CryptoPkg/Library/OpensslLib/rand_pool.c
index 9e0179b03490..55bf6c9c6950 100644
--- a/CryptoPkg/Library/OpensslLib/rand_pool.c
+++ b/CryptoPkg/Library/OpensslLib/rand_pool.c
@@ -11,44 +11,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 
 #include 
-#include 
+#include 
 
 #include "rand_pool_noise.h"
 
-/**
-  Get some randomness from low-order bits of GetPerformanceCounter results.
-  And combine them to the 64-bit value
-
-  @param[out] RandBuffer pointer to store the 64-bit random value.
-
-  @retval TRUERandom number generated successfully.
-  @retval FALSE   Failed to generate.
-**/
-STATIC
-BOOLEAN
-EFIAPI
-GetRandNoise64FromPerformanceCounter(
-  OUT UINT64  *Rand
-  )
-{
-  UINT32 Index;
-  UINT32 *RandPtr;
-
-  if (NULL == Rand) {
-return FALSE;
-  }
-
-  RandPtr = (UINT32 *) Rand;
-
-  for (Index = 0; Index < 2; Index ++) {
-*RandPtr = (UINT32) (GetPerformanceCounter () & 0xFF);
-MicroSecondDelay (10);
-RandPtr++;
-  }
-
-  return TRUE;
-}
-
 /**
   Calls RandomNumber64 to fill
   a buffer of arbitrary size with random bytes.
@@ -56,8 +22,8 @@ GetRandNoise64FromPerformanceCounter(
   @param[in]   LengthSize of the buffer, in bytes,  to fill with.
   @param[out]  RandBufferPointer to the buffer to store the random result.
 
-  @retval EFI_SUCCESSRandom bytes generation succeeded.
-  @retval EFI_NOT_READY  Failed to request random bytes.
+  @retval TrueRandom bytes generation succeeded.
+  @retval False   Failed to request random bytes.
 
 **/
 STATIC
@@ -73,17 +39,17 @@ RandGetBytes (
 
   Ret = FALSE;
 
+  if (RandBuffer == NULL) {
+DEBUG((DEBUG_ERROR, "[OPENSSL_RAND_POOL] NULL RandBuffer. No random 
numbers are generated and your system is not secure\n"));
+ASSERT(FALSE); // Since we can't generate random numbers, we should 
assert. Otherwise we will just blow up later.
+return Ret;
+  }
+
+
   while (Length > 0) {
-//
-// Get random noise from platform.
-// If it failed, fallback to PerformanceCounter
-// If you really care about security, you must override
-// GetRandomNoise64FromPlatform.
-//
-Ret = GetRandomNoise64 ();
-if (Ret == FALSE) {
-  Ret = GetRandNoise64FromPerformanceCounter ();
-}
+// Use RngLib to get random number
+Ret = GetRandomNumber64();
+
 if (!Ret) {
   return Ret;
 }
@@ -100,125 +66,6 @@ RandGetBytes (
   return Ret;
 }
 
-/**
-  Creates a 128bit random value that is fully forward and backward prediction 
resistant,
-  suitable for seeding a NIST SP800-90 Compliant.
-  This function takes multiple random numbers from PerformanceCounter to 
ensure reseeding
-  and performs AES-CBC-MAC over the data to compute the seed value.
-
-  @param[out]  SeedBufferPointer to a 128bit buffer to store the random 
seed.
-
-  @retval TRUERandom seed generation succeeded.
-  @retval FALSE  Failed to request random bytes.
-
-**/
-STATIC
-BOOLEAN
-EFIAPI
-RandGetSeed128 (
-  OUT UINT8*SeedBuffer
-  )
-{
-  BOOLEAN Ret;
-  UINT8   RandByte[16];
-  UINT8   Key[16];
-  UINT8   Ffv[16];
-  UINT8   Xored[16];
-  UINT32  Index;
-  UINT32  Index2;
-  AES_KEY AESKey;
-
-  //
-  // Chose an arbitrary key and zero the feed_forward_value (FFV)
-  //
-  for (Index = 0; Index < 16; Index++) {
-Key[Index] = (UINT8) Index;
-Ffv[Index] = 0;
-  }
-
-  AES_set_encrypt_key (Key, 16 * 8, );
-
-  //
-  // Perform CBC_MAC over 32 * 128 bit values, with 10us gaps between 128 bit 
value
-  // The 10us gaps will ensure multiple reseeds within the system time with a 
large
-  // design margin.
-  //
-  for (Index = 0; Index < 32; Index++) {
-MicroSecondDelay (10);
-Ret = RandGetBytes (16, RandByte);
-if (!Ret) {
-  return Ret;
-}
-
-//
-// Perform XOR operations on two 128-bit value.
-//
-for (Index2 = 0; Index2 < 16; Index2++) {
-  Xored[Index2] = RandByte[Index2] ^ Ffv[Index2];
-}
-
-AES_encrypt (Xored, Ffv, );
-  }
-
-  for (Index = 0; Index < 16; Index++) {
-SeedBuffer[Index] = Ffv[Index];
-  }
-
-  return Ret;
-}
-
-/**
-  Generate high-quality entropy source.
-
- 

[edk2-devel] [PATCH v1 2/2] MdePkg: TimerRngLib: Added RngLib that uses TimerLib

[Matthew Carlson]

From: Matthew Carlson 

Added a new RngLib that provides random numbers from the TimerLib
using the performance counter. This is meant to be used for OpenSSL
to replicate past behavior. This should not be used in production as
a real source of entropy.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Matthew Carlson 
---
 MdePkg/Library/TimerRngLib/TimerRng.c  | 153 
 MdePkg/Library/TimerRngLib/TimerRngLib.inf |  37 +
 MdePkg/MdePkg.dsc  |   2 +
 3 files changed, 192 insertions(+)

diff --git a/MdePkg/Library/TimerRngLib/TimerRng.c 
b/MdePkg/Library/TimerRngLib/TimerRng.c
new file mode 100644
index ..1b0f7f04c01d
--- /dev/null
+++ b/MdePkg/Library/TimerRngLib/TimerRng.c
@@ -0,0 +1,153 @@
+/** @file
+  BaseRng Library that uses the TimerLib to provide reasonably random numbers.
+  Do not use this on a production system.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Generates a 16-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 16-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber16 (
+  OUT UINT16*Rand
+  )
+{
+  UINT32  Index;
+  UINT8* RandPtr;
+
+  ASSERT (Rand != NULL);
+
+  if (NULL == Rand) {
+return FALSE;
+  }
+
+  RandPtr = (UINT8 *) Rand;
+  // Get 2 bytes of random ish data
+  for (Index = 0; Index < 2; Index ++) {
+*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
+MicroSecondDelay (4);
+RandPtr++;
+  }
+  return TRUE;
+}
+
+/**
+  Generates a 32-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 32-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber32 (
+  OUT UINT32*Rand
+  )
+{
+  UINT32  Index;
+  UINT8* RandPtr;
+
+  ASSERT (Rand != NULL);
+
+  if (NULL == Rand) {
+return FALSE;
+  }
+
+  RandPtr = (UINT8 *) Rand;
+  // Get 4 bytes of random ish data
+  for (Index = 0; Index < 4; Index ++) {
+*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
+MicroSecondDelay (2);
+RandPtr++;
+  }
+  return TRUE;
+}
+
+/**
+  Generates a 64-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 64-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber64 (
+  OUT UINT64*Rand
+  )
+{
+  UINT32  Index;
+  UINT8* RandPtr;
+
+  ASSERT (Rand != NULL);
+
+  if (NULL == Rand) {
+return FALSE;
+  }
+
+  RandPtr = (UINT8 *) Rand;
+  // Get 8 bytes of random ish data
+  for (Index = 0; Index < 8; Index ++) {
+*RandPtr = (UINT8) (GetPerformanceCounter () & 0xFF);
+MicroSecondDelay (1);
+RandPtr++;
+  }
+
+  return TRUE;
+}
+
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64*Rand
+  )
+{
+  ASSERT (Rand != NULL);
+
+  //
+  // Read first 64 bits
+  //
+  if (!GetRandomNumber64 (Rand)) {
+return FALSE;
+  }
+
+  //
+  // Read second 64 bits
+  //
+  return GetRandomNumber64 (++Rand);
+}
diff --git a/MdePkg/Library/TimerRngLib/TimerRngLib.inf 
b/MdePkg/Library/TimerRngLib/TimerRngLib.inf
new file mode 100644
index ..a80a89b77e72
--- /dev/null
+++ b/MdePkg/Library/TimerRngLib/TimerRngLib.inf
@@ -0,0 +1,37 @@
+## @file
+#  Instance of RNG (Random Number Generator) Library.
+#
+#  BaseRng Library that uses the TimerLib to provide reasonably random numbers.
+#  Do not use this on a production system.
+#
+#  Copyright (c) Microsoft Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BaseRngLib
+  MODULE_UNI_FILE= BaseRngLib.uni
+  FILE_GUID  = 74950C45-10FC-4AB5-B114-49C87C17409B
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = RngLib
+  CONSTRUCTOR= BaseRngLibConstructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  TimerRng.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  TimerLib
diff --git 

[edk2-devel] [PATCH v1 0/2] Use RngLib instead of TimerLib for OpensslLib

[Matthew Carlson]

From: Matthew Carlson 

This fixes bugzilla 1871.

Matthew Carlson (2):
  CryptoPkg: OpensslLib: Use RngLib to generate entropy in rand_pool
  MdePkg: TimerRngLib: Added RngLib that uses TimerLib

 CryptoPkg/Library/OpensslLib/rand_pool.c   | 200 ++--
 CryptoPkg/Library/OpensslLib/rand_pool_noise.c |  29 ---
 CryptoPkg/Library/OpensslLib/rand_pool_noise_tsc.c |  43 -
 MdePkg/Library/TimerRngLib/TimerRng.c  | 153 +++
 CryptoPkg/Library/OpensslLib/OpensslLib.inf|  15 +-
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  15 +-
 CryptoPkg/Library/OpensslLib/rand_pool_noise.h |  29 ---
 MdePkg/Library/TimerRngLib/TimerRngLib.inf |  37 
 MdePkg/MdePkg.dsc  |   2 +
 9 files changed, 212 insertions(+), 311 deletions(-)
 delete mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise.c
 delete mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise_tsc.c
 create mode 100644 MdePkg/Library/TimerRngLib/TimerRng.c
 delete mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise.h
 create mode 100644 MdePkg/Library/TimerRngLib/TimerRngLib.inf

-- 
2.27.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63371): https://edk2.groups.io/g/devel/message/63371
Mute This Topic: https://groups.io/mt/75836596/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[Masahisa Kojima]

Hi Leif,

> > Masahisa - since Ard is still on holiday, could you create a patch and
> > send out for me to review? Either one of the files needs to be
> > renamed, or we need to move the .asl files (Emmc.asl and Optee.asl)
> > into a subdirectory.

Probably I'm missing something, but my build for Developerbox platform is
successful, with the latest edk2/edk2-platforms as of today.

My build option is:
---
export TARGET=Platform/Socionext/DeveloperBox/DeveloperBox.dsc
export PROFILE=DEBUG
export ARCH=AARCH64
export TOOL_CHAIN_TAG=GCC5

build -n $NUM_CPUS -a $ARCH -b $PROFILE -t $TOOL_CHAIN_TAG -p $TARGET
-D SECURE_BOOT_ENABLE=TRUE -D X64EMU_ENABLE=TRUE -D TPM2_ENABLE=TRUE
---

GCC version is 
"gcc-linaro-6.4.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-".

Some Output directory information:
~/src/uefi/Build/DeveloperBox$ find .|grep -i emmc
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.iii
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.obj.deps
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.obj
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.aml.deps
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.aml
./DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe/OUTPUT/Emmc.i

Regards,
Masahisa

On Tue, 28 Jul 2020 at 09:40, Gao, Liming  wrote:
>
> Pierre:
>   Thanks for your investigation. For now, the module will rename source file 
> to avoid the file conflict. Can you submit one BZ for BaseTools to enhance 
> the logic for the autogen source file? This needs more discussion.
>
>   Yes. I agree to place the generated source file into $(DEBUG_DIR). You can 
> make another patch for this change.
>
> Thanks
> Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of PierreGondois
> Sent: 2020年7月28日 1:10
> To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm 
> ; Masahisa Kojima 
> Cc: Sami Mujawar ; Tomas Pilar ; 
> Feng, Bob C ; Ard Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode 
> arrays into .obj file
>
> Hello,
>
> Liming:
> I didn't find anything preventing from having a .vfr and .c file with the 
> same name in the same scope.
>
> Everybody:
> The .c files generated (from either .vfr or .asl) are generated in the 
> Build//OUTPUT/ directory, with their original subdirectory stripped. In 
> the example below, the .c, .vfr and .asl files have been placed in 
> subdirectories in edk2/edk2-platforms. The recipes that have been generated 
> are:
> $(OUTPUT_DIR)/Emmc.obj : $(OUTPUT_DIR)/AslDir/Emmc.c (from Emmc.asl) 
> $(OUTPUT_DIR)/Ip4Config2.obj : $(DEBUG_DIR)/VfrDir/Ip4Config2.c (from 
> Ip4Config2.vfr) $(OUTPUT_DIR)/CDir/Emmc.obj : 
> $(WORKSPACE)/edk2-platforms/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/CDir/Emmc.c
>  (from Emmc.c)
>
> The only subdirectory that remains is the one from the .c files. Indeed, the 
> build system might detects subdirectories from the .inf file location. As the 
> .c file is generated in the OUTPUT directory where there is no .inf file, it 
> gets stripped.
> This means that if a subdirectory is created, it is for the .c file, but I 
> don't think we should modify this.
>
> Adding a pre/postfix to the generated .c filename seems a better approach to 
> me. It would require modifying build_rule.template, and choose which 
> pre/postfix to add.
>
> Another point is that the .c file generated from the .c file is placed in the 
> $(DEBUG_DIR), when the one coming from the .asl file is placed in 
> $(OUTPUT_DIR). Maybe it should be modified to $(DEBUG_DIR) aswell.
>
> Regards,
> Pierre
>
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Liming Gao via 
> groups.io
> Sent: Monday, July 27, 2020 3:21 PM
> To: Leif Lindholm ; devel@edk2.groups.io; Pierre Gondois 
> ; Masahisa Kojima 
> Cc: Sami Mujawar ; Tomas Pilar ; 
> Feng, Bob C ; Ard Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode 
> arrays into .obj file
>
> Leif:
>   VFR file has the similar case. VFR is converted to xxx.c, then compile it 
> to obj file.
>
> Bob:
>   Has BaseTools such detection if VFR and C source file have the same file 
> name?
>
> Thanks
> Liming
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Monday, July 27, 2020 9:58 PM
> > To: devel@edk2.groups.io; pierre.gond...@arm.com; Masahisa Kojima
> > 
> > Cc: sami.muja...@arm.com; tomas.pi...@arm.com; Feng, Bob C
> > ; Gao, Liming ; Ard
> > Biesheuvel 
> > Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML
> > bytecode arrays into .obj file
> >
> > Hi Pierre, (+Masahisa)
> >
> > This commit (0a4aa20e8d44) made for an exciting start to my week.

Re: [edk2-devel] [PATCH v12 07/46] MdePkg/BaseLib: Add support for the VMGEXIT instruction

[Liming Gao]

Tom:
  I meet with GCC failure on this patch. Can you help check it? If nasm doesn't 
support the vmmcall instruction in 32-bit mode, you have to use inline assembly 
to support it. 

Edk2/Build/IntelFsp2Pkg/DEBUG_GCC5/IA32/MdePkg/Library/BaseLib/BaseLib/OUTPUT/Ia32/VmgExit.iii:33:
 error: elf32 output format does not support 64-bit code
GNUmakefile:741: recipe for target

Thanks
Liming
-Original Message-
From: Tom Lendacky  
Sent: 2020年7月27日 23:26
To: devel@edk2.groups.io
Cc: Brijesh Singh ; Ard Biesheuvel 
; Dong, Eric ; Justen, Jordan L 
; Laszlo Ersek ; Gao, Liming 
; Kinney, Michael D ; Ni, Ray 

Subject: [PATCH v12 07/46] MdePkg/BaseLib: Add support for the VMGEXIT 
instruction

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

VMGEXIT is a new instruction used for Hypervisor/Guest communication when 
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE) to 
occur, resulting in a #VMEXIT with an exit code value of 0x403.

Provide the necessary support to execute the VMGEXIT instruction, which is 
"rep; vmmcall".

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Library/BaseLib/BaseLib.inf   |  2 ++
 MdePkg/Include/Library/BaseLib.h | 14 +
 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm | 37   
MdePkg/Library/BaseLib/X64/VmgExit.nasm  | 32 
 4 files changed, 85 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 3b93b5db8d24..3b85c56c3c03 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -184,6 +184,7 @@ [Sources.Ia32]
   Ia32/DisableCache.nasm| GCC
   Ia32/RdRand.nasm
   Ia32/XGetBv.nasm
+  Ia32/VmgExit.nasm
 
   Ia32/DivS64x64Remainder.c
   Ia32/InternalSwitchStack.c | MSFT
@@ -317,6 +318,7 @@ [Sources.X64]
   X64/DisablePaging64.nasm
   X64/RdRand.nasm
   X64/XGetBv.nasm
+  X64/VmgExit.nasm
   ChkStkGcc.c  | GCC
 
 [Sources.EBC]
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 7edf0051a0a0..04fb329eaabb 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7848,6 +7848,20 @@ AsmXGetBv (
   );
 
 
+/**
+  Executes a VMGEXIT instruction (VMMCALL with a REP prefix)
+
+  Executes a VMGEXIT instruction. This function is only available on 
+ IA-32 and  x64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  );
+
+
 /**
   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/VmgExit.nasm 
b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
new file mode 100644
index ..a4b37385cc7a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
@@ -0,0 +1,37 @@
+;--
+
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights 
+reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ; ; Module 
+Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+
+SECTION .text
+
+;--
+
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+;
+; NASM doesn't support the vmmcall instruction in 32-bit mode, so work 
+around ; this by temporarily switching to 64-bit mode.
+;
+BITS64
+rep vmmcall
+BITS32
+ret
+
diff --git a/MdePkg/Library/BaseLib/X64/VmgExit.nasm 
b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
new file mode 100644
index ..26f034593c67
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
@@ -0,0 +1,32 @@
+;--
+
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights 
+reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ; ; Module 
+Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+
+DEFAULT REL
+SECTION .text
+
+;--
+
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+rep vmmcall
+ret
+
--
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63369): https://edk2.groups.io/g/devel/message/63369
Mute This Topic: 

[edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 07/28/2020 6:30pm-7:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 28 July 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=816383 )

*Organizer:* Brian Richardson brian.richard...@intel.com ( 
brian.richard...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

https://www.tianocore.org/bug-triage

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63368): https://edk2.groups.io/g/devel/message/63368
Mute This Topic: https://groups.io/mt/75836336/21656
Mute #cal-reminder: https://groups.io/g/edk2/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v8 0/9] Add new feature that evacuate temporary to permanent memory (CVE-2019-11098)

[Liming Gao]

PR https://github.com/tianocore/edk2/pull/830 is created for this patch set. 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: 2020年7月27日 11:55
To: devel@edk2.groups.io; Jiang, Guomin 
Subject: Re: [edk2-devel] [PATCH v8 0/9] Add new feature that evacuate 
temporary to permanent memory (CVE-2019-11098)

Reviewed-by: Liming Gao  for this patch set. 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Guomin Jiang
Sent: 2020年7月24日 17:55
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH v8 0/9] Add new feature that evacuate temporary to 
permanent memory (CVE-2019-11098)

The TOCTOU vulnerability allow that the physical present person to replace the 
code with the normal BootGuard check and PCR0 value.
The issue occur when BootGuard measure IBB and access flash code after NEM 
disable.
The reason why we access the flash code is that we have some pointer to flash.
To avoid this vulnerability, we need to convert those pointers, the patch 
series do this work and make sure that no code will access flash address.

v2:
Create gEdkiiMigratedFvInfoGuid HOB and add 
PcdMigrateTemporaryRamFirmwareVolumes to control whole feature.

v3:
Remove changes which is not related with the feature and disable the feature in 
virtual platform.

v4:
Disable the feature as default, Copy the Tcg2Pei behavior to TcgPei

v5:
Initialize local variable Shadow and return EFI_ABORTED when RepublishSecPpi 
not installed.

v6:
Avoid redundant shadow PEIM when enable Migrated PCD.

v7:
Change patch 10/10 to enhance the logic.

v8:
Drop the patch#10 added in v6 and v7, the optimization will be considered 
future.

Guomin Jiang (6):
  MdeModulePkg: Add new PCD to control the evacuate temporary memory
feature (CVE-2019-11098)
  MdeModulePkg/Core: Create Migrated FV Info Hob for calculating hash
(CVE-2019-11098)
  SecurityPkg/Tcg2Pei: Use Migrated FV Info Hob for calculating hash
(CVE-2019-11098)
  UefiCpuPkg/CpuMpPei: Enable paging and set NP flag to avoid TOCTOU
(CVE-2019-11098)
  UefiCpuPkg: Correct some typos.
  SecurityPkg/TcgPei: Use Migrated FV Info Hob for calculating hash
(CVE-2019-11098)

Michael Kubacki (3):
  MdeModulePkg/PeiCore: Enable T-RAM evacuation in PeiCore
(CVE-2019-11098)
  UefiCpuPkg/CpuMpPei: Add GDT migration support (CVE-2019-11098)
  UefiCpuPkg/SecMigrationPei: Add initial PEIM (CVE-2019-11098)

 MdeModulePkg/MdeModulePkg.dec |  12 +
 UefiCpuPkg/UefiCpuPkg.dec |   3 +
 UefiCpuPkg/UefiCpuPkg.dsc |   1 +
 MdeModulePkg/Core/Pei/PeiMain.inf |   3 +
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf   |   1 +
 SecurityPkg/Tcg/TcgPei/TcgPei.inf |   1 +
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf  |   4 +
 UefiCpuPkg/SecCore/SecCore.inf|   2 +
 .../SecMigrationPei/SecMigrationPei.inf   |  68 +++
 MdeModulePkg/Core/Pei/PeiMain.h   | 170 +++
 MdeModulePkg/Include/Guid/MigratedFvInfo.h|  22 +
 UefiCpuPkg/CpuMpPei/CpuMpPei.h|  14 +-
 UefiCpuPkg/Include/Ppi/RepublishSecPpi.h  |  54 +++
 .../CpuExceptionCommon.h  |   4 +-
 UefiCpuPkg/SecCore/SecMain.h  |   1 +
 UefiCpuPkg/SecMigrationPei/SecMigrationPei.h  | 158 +++  
MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 445 +-
 MdeModulePkg/Core/Pei/Image/Image.c   | 130 -
 MdeModulePkg/Core/Pei/Memory/MemoryServices.c |  82 
 MdeModulePkg/Core/Pei/PeiMain/PeiMain.c   |  22 +-
 MdeModulePkg/Core/Pei/Ppi/Ppi.c   | 286 +++
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c |  31 +-
 SecurityPkg/Tcg/TcgPei/TcgPei.c   |  29 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.c|  37 ++
 UefiCpuPkg/CpuMpPei/CpuPaging.c   |  42 +-
 .../Ia32/ArchExceptionHandler.c   |   4 +-
 .../SecPeiCpuException.c  |   2 +-
 .../X64/ArchExceptionHandler.c|   4 +-
 UefiCpuPkg/SecCore/SecMain.c  |  26 +-
 UefiCpuPkg/SecMigrationPei/SecMigrationPei.c  | 385 +++
 MdeModulePkg/MdeModulePkg.uni |   6 +
 .../SecMigrationPei/SecMigrationPei.uni   |  13 +
 32 files changed, 2032 insertions(+), 30 deletions(-)  create mode 100644 
UefiCpuPkg/SecMigrationPei/SecMigrationPei.inf
 create mode 100644 MdeModulePkg/Include/Guid/MigratedFvInfo.h
 create mode 100644 UefiCpuPkg/Include/Ppi/RepublishSecPpi.h
 create mode 100644 UefiCpuPkg/SecMigrationPei/SecMigrationPei.h
 create mode 100644 UefiCpuPkg/SecMigrationPei/SecMigrationPei.c
 create mode 100644 UefiCpuPkg/SecMigrationPei/SecMigrationPei.uni

--
2.25.1.windows.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63367): https://edk2.groups.io/g/devel/message/63367
Mute This Topic: https://groups.io/mt/75763374/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 

Re: [edk2-devel] [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for LicenseCheck

[Zhang, Shenglei]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, July 27, 2020 5:51 PM
> To: Zhang, Shenglei ; Rebecca Cran
> 
> Cc: devel@edk2.groups.io; Justen, Jordan L ;
> Ard Biesheuvel 
> Subject: Re: [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for
> LicenseCheck
> 
> On 07/27/20 08:21, Zhang, Shenglei wrote:
> > Hi Laszlo,
> >
> > VbeShim.h is existing in edk2 now. This plugin only checks the patches to
> be checked in.
> > So there's no need to add existing files to this section.
> 
> OK, thanks, we can always extend this stanza later, if needed.
> 
> Rebecca: once this patch is upstream, please post a separate patch for listing
> "OvmfPkg/Bhyve/BhyveRfbDxe/VbeShim.h" in "IgnoreFiles". Otherwise I
> won't be able to merge your patch at
> .
> 
> 
> Shenglei: I have a question regarding IgnoreFiles syntax. In
> "MdeModulePkg/MdeModulePkg.ci.yaml", there are two syntaxes:
> 
> - The IgnoreFiles stanza for "CharEncodingCheck" uses pathnames that are
> relative to the *project* root:
> 
> > ## options defined ci/Plugin/CharEncodingCheck
> > "CharEncodingCheck": {
> > "IgnoreFiles": [
> >
> "MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/test/testc.c",
> >
> "MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/windows/tes
> tc.c"
> > ]
> > },
> 
> - The IgnoreFiles stanza for "SpellCheck" uses pathnames that are relative to
> the *package* (not project) root:
> 
> > "SpellCheck": {
> > ...
> > "IgnoreFiles": [ # use gitignore syntax to ignore 
> > errors in matching
> files
> > "Library/LzmaCustomDecompressLib/Sdk/DOC/*"
> > ],
> 
> How do we know whether a particular check's IgnoreFiles stanza requires
> project-root-relative or package-root-relative pathnames?

It depends on the designing of the plugins, likes the check scope.
But looks like all checks' IgnoreFiles stanza only requires 
package-root-relative pathnames, currently.
It's recommended to use package-root-relative pathnames because a plugin must 
support this format.

Thanks,
Shenglei

> 
> Thanks!
> Laszlo
> 
> > Thanks,
> > Shenglei
> >
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Tuesday, July 21, 2020 6:01 AM
> >> To: Zhang, Shenglei ; devel@edk2.groups.io
> >> Cc: Justen, Jordan L ; Ard Biesheuvel
> >> 
> >> Subject: Re: [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration
> for
> >> LicenseCheck
> >>
> >> On 07/20/20 10:37, Shenglei Zhang wrote:
> >>> Add configuration IgnoreFiles for package config files.
> >>> So users can rely on this to skip license conflict for
> >>> some generated files.
> >>>
> >>> Cc: Jordan Justen 
> >>> Cc: Laszlo Ersek 
> >>> Cc: Ard Biesheuvel 
> >>> Signed-off-by: Shenglei Zhang 
> >>> ---
> >>>  OvmfPkg/OvmfPkg.ci.yaml | 4 
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/OvmfPkg/OvmfPkg.ci.yaml b/OvmfPkg/OvmfPkg.ci.yaml
> >>> index 98992f0429ff..ed342d7a3d08 100644
> >>> --- a/OvmfPkg/OvmfPkg.ci.yaml
> >>> +++ b/OvmfPkg/OvmfPkg.ci.yaml
> >>> @@ -8,6 +8,10 @@
> >>>  # SPDX-License-Identifier: BSD-2-Clause-Patent
> >>>  ##
> >>>  {
> >>> +## options defined .pytool/Plugin/LicenseCheck
> >>> +"LicenseCheck": {
> >>> +"IgnoreFiles": []
> >>> +},
> >>>  ## options defined .pytool/Plugin/CompilerPlugin
> >>>  "CompilerPlugin": {
> >>>  "DscPath": "" # Don't support this test
> >>>
> >>
> >> Can you list the following file at once, please:
> >>
> >>   OvmfPkg/QemuVideoDxe/VbeShim.h
> >>
> >> With that:
> >>
> >> Reviewed-by: Laszlo Ersek 
> >>
> >> Thanks
> >> Laszlo
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63366): https://edk2.groups.io/g/devel/message/63366
Mute This Topic: https://groups.io/mt/75678218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[Liming Gao]

Pierre:
  Thanks for your investigation. For now, the module will rename source file to 
avoid the file conflict. Can you submit one BZ for BaseTools to enhance the 
logic for the autogen source file? This needs more discussion. 

  Yes. I agree to place the generated source file into $(DEBUG_DIR). You can 
make another patch for this change. 

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of PierreGondois
Sent: 2020年7月28日 1:10
To: devel@edk2.groups.io; Gao, Liming ; Leif Lindholm 
; Masahisa Kojima 
Cc: Sami Mujawar ; Tomas Pilar ; 
Feng, Bob C ; Ard Biesheuvel 
Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays 
into .obj file

Hello,

Liming:
I didn't find anything preventing from having a .vfr and .c file with the same 
name in the same scope.

Everybody:
The .c files generated (from either .vfr or .asl) are generated in the 
Build//OUTPUT/ directory, with their original subdirectory stripped. In the 
example below, the .c, .vfr and .asl files have been placed in subdirectories 
in edk2/edk2-platforms. The recipes that have been generated are:
$(OUTPUT_DIR)/Emmc.obj : $(OUTPUT_DIR)/AslDir/Emmc.c (from Emmc.asl) 
$(OUTPUT_DIR)/Ip4Config2.obj : $(DEBUG_DIR)/VfrDir/Ip4Config2.c (from 
Ip4Config2.vfr) $(OUTPUT_DIR)/CDir/Emmc.obj : 
$(WORKSPACE)/edk2-platforms/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/CDir/Emmc.c
 (from Emmc.c)

The only subdirectory that remains is the one from the .c files. Indeed, the 
build system might detects subdirectories from the .inf file location. As the 
.c file is generated in the OUTPUT directory where there is no .inf file, it 
gets stripped.
This means that if a subdirectory is created, it is for the .c file, but I 
don't think we should modify this.

Adding a pre/postfix to the generated .c filename seems a better approach to 
me. It would require modifying build_rule.template, and choose which 
pre/postfix to add.

Another point is that the .c file generated from the .c file is placed in the 
$(DEBUG_DIR), when the one coming from the .asl file is placed in 
$(OUTPUT_DIR). Maybe it should be modified to $(DEBUG_DIR) aswell.

Regards,
Pierre

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao via 
groups.io
Sent: Monday, July 27, 2020 3:21 PM
To: Leif Lindholm ; devel@edk2.groups.io; Pierre Gondois 
; Masahisa Kojima 
Cc: Sami Mujawar ; Tomas Pilar ; 
Feng, Bob C ; Ard Biesheuvel 
Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays 
into .obj file

Leif:
  VFR file has the similar case. VFR is converted to xxx.c, then compile it to 
obj file.

Bob:
  Has BaseTools such detection if VFR and C source file have the same file name?

Thanks
Liming
> -Original Message-
> From: Leif Lindholm 
> Sent: Monday, July 27, 2020 9:58 PM
> To: devel@edk2.groups.io; pierre.gond...@arm.com; Masahisa Kojima 
> 
> Cc: sami.muja...@arm.com; tomas.pi...@arm.com; Feng, Bob C 
> ; Gao, Liming ; Ard 
> Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML 
> bytecode arrays into .obj file
>
> Hi Pierre, (+Masahisa)
>
> This commit (0a4aa20e8d44) made for an exciting start to my week.
>
> Socionext's Developerbox failed to build for me, with the spectacular 
> error message:
>
> /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld:
> DWARF error: could not find abbrev number 5912
> /tmp/ccKt4gaM.ltrans0.ltrans.o: in function `RegisterDevices':
> :(.text.RegisterDevices+0xb0): undefined reference to 
> `RegisterEmmc'
>
> GCC49 (without lto) and CLANG38 profiles give much the same result, 
> with slightly less esoteric messages.
>
> The reason for this turned out to be that edk2-platforms 
> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/ has both an Emmc.asl 
> and an Emmc.c file, which after this patch both generate an Emmc.obj 
> in the same output directory.
>
> I think the correct course of action is to fix this in the SynQuacer 
> driver, but I am reporting it here so we get it logged in the list 
> archives.
>
> It would of course be good if the build system could detect and warn 
> over cases like this, rather than silently overwriting existing object 
> files.
>
> Masahisa - since Ard is still on holiday, could you create a patch and 
> send out for me to review? Either one of the files needs to be 
> renamed, or we need to move the .asl files (Emmc.asl and Optee.asl) 
> into a subdirectory.
>
> Best Regards,
>
> Leif
>
> On Wed, Jul 01, 2020 at 15:06:03 +0100, PierreGondois wrote:
> > From: Pierre Gondois 
> >
> > The AmlToHex script and Posix/WindowsLike wrappers convert an AML 
> > file to a .hex file, containing a C array storing AML bytecode. This 
> > ".hex" file can then be included in a C file, allowing to access the 
> > AML bytecode from this C file.
> >
> > The EDK2 build system doesn't allow to a depict dependency orders 
> > between files of different languages. For instance, in a module 
> > 

Re: [edk2-devel] [PATCH v2] MdePkg Base.h: Delete prototype for __builtin_return_address

[Liming Gao]

PR https://github.com/tianocore/edk2/pull/829 has been created. 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: 2020年7月27日 10:18
To: Jessica Clarke ; devel@edk2.groups.io
Cc: l...@nuviainc.com; Kinney, Michael D 
Subject: Re: [edk2-devel] [PATCH v2] MdePkg Base.h: Delete prototype for 
__builtin_return_address

Reviewed-by: Liming Gao 

-Original Message-
From: Jessica Clarke  
Sent: 2020年7月27日 9:59
To: devel@edk2.groups.io
Cc: Jessica Clarke ; Gao, Liming ; 
l...@nuviainc.com; Kinney, Michael D 
Subject: [PATCH v2] MdePkg Base.h: Delete prototype for __builtin_return_address

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1004

Being a compiler builtin, the type of __builtin_return_address is already known 
to the compiler so no prototype is needed. Clang also errors out when 
redeclaring certain builtins like this[1], though currently only for ones with 
custom type checking. At the moment, __builtin_return_address does not use 
custom type checking and so does not trigger this error, however, the CHERI 
fork of LLVM, which will form the basis of the toolchain for Arm's experimental 
Morello platform, does use custom type checking for it, and so gives an error. 
Thus, simply delete the unnecessary line.

[1] llvm/llvm-project@41af97137572ad6d4dafc872e7ecf6bbb08d4984

Cc: Leif Lindholm 
Signed-off-by: Jessica Clarke 
---
Changes in v2:
 * Shortened [1] reference to fit column limit. The bug report has the
   full URL already, and this will still link correctly on GitHub.

 MdePkg/Include/Base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h index 
85a091b9d5..8e4271f6ea 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -1273,7 +1273,6 @@ typedef UINTN RETURN_STATUS;
   **/
   #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
 #elif defined (__GNUC__) || defined (__clang__)
-  void * __builtin_return_address (unsigned int level);
   /**
 Get the return address of the calling function.
 
--
2.20.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63364): https://edk2.groups.io/g/devel/message/63364
Mute This Topic: https://groups.io/mt/75819415/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Laszlo Ersek]

Just some quick remarks after a comparison with v3:

On 07/27/20 18:48, Vladimir Olovyannikov via groups.io wrote:
> Introduce an http client utilizing EDK2 HTTP protocol, to
> allow fast image downloading from http/https servers.
> HTTP download speed is usually faster than tftp.
> The client is based on the same approach as tftp dynamic command, and
> uses the same UEFI Shell command line parameters. This makes it easy
> integrating http into existing UEFI Shell scripts.
> Note that to enable HTTP download, feature Pcd
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must
> be set to TRUE.
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
>
> Signed-off-by: Vladimir Olovyannikov 
> CC: Samer El-Haj-Mahmoud 
> CC: Laszlo Ersek 

(1) These "CC" lines are not formatted correctly -- they might do the
job as far as git-send-email is concerned, but they don't satisfy
"PatchCheck.py":

> ShellPkg/DynamicCommand: add HttpDynamicCommand
> The commit message format is not valid:
>  * 'CC' should be 'Cc'
>  * 'CC' should be 'Cc'
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

The exit status is 255, so this would break the CI run again.

Please run "PatchCheck.py" locally before posting, and/or submit a
personal CI build.

[...]

> +if (UserNicName != NULL) {
> +  if (StrCmp (NicName, UserNicName) != 0) {
> +Status = EFI_NOT_FOUND;

Change is new since v4, but not documented in the v5 changelog.

(The code may be OK, but please help reviewers with the v(n) -> v(n+1)
changelogs.)

[...]

> +if (ShellCommandLineGetFlag (CheckPackage, L"-m")) {
> +  Context.Flags |= DL_FLAG_TIME;
> +}

(2) The "-m" flag has not been removed from here

[...]

> +// Download Flags
> +#define DL_FLAG_TIME BIT0 // Show elapsed time.

(3) and here

> +".SH SYNOPSIS\r\n"
> +" \r\n"
> +"HTTP [-i interface] [-l port] [-t timeout] [-s size] [-m] [-k]\r\n"

(4) and here

[...]

> +"  -m Measure and report download time (in seconds). \r\n"

(5) and here.

I suggest waiting for ShellPkg owner feedback before posting v6.

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63363): https://edk2.groups.io/g/devel/message/63363
Mute This Topic: https://groups.io/mt/75826968/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, July 27, 2020 10:40 AM
> To: Vladimir Olovyannikov ;
> devel@edk2.groups.io
> Cc: Samer El-Haj-Mahmoud ; Zhichao
> Gao ; Maciej Rabeda
> ; Jiaxin Wu ; Siyuan
> Fu ; Ray Ni ; Liming Gao
> ; Nd 
> Subject: Re: [PATCH v5 0/1] ShellPkg/DynamicCommand: add
> HttpDynamicCommand
>
> On 07/27/20 18:48, Vladimir Olovyannikov wrote:
> > Signed-off-by: Vladimir Olovyannikov
> > 
> > Cc: Samer El-Haj-Mahmoud 
> > Cc: Laszlo Ersek 
> > Cc: Zhichao Gao 
> > Cc: Maciej Rabeda 
> > Cc: Jiaxin Wu 
> > Cc: Siyuan Fu 
> > Cc: Ray Ni 
> > Cc: Liming Gao 
> > Cc: Nd 
> >
> > This patchset introduces an http client utilizing EDK2 HTTP protocol,
> > to allow fast image downloading from http/https servers.
> > HTTP download speed is usually faster than tftp.
> > The client is based on the same approach as tftp dynamic command, and
> > uses the same UEFI Shell command line parameters. This makes it easy
> > integrating http into existing UEFI Shell scripts.
> > Note that to enable HTTP download, feature Pcd
> > gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to
> TRUE.
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
> >
> > PATCH v5 changes:
> > Address Laszlo's comments on patch v4:
> >  - Remove -m option as it introduced TimerLib dependency;
> >  - Drop "Tested-by" flags.
>
> Thanks! As I mentioned under v4, I'll delay my testing until there's some
> reviewer feedback too.
Yes, this makes sense as there could be other modifications required.
I hope this patch can be reviewed by maintainers sometime soon...
>
> Cheers!
> Laszlo
Thank you,
Vladimir

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63362): https://edk2.groups.io/g/devel/message/63362
Mute This Topic: https://groups.io/mt/75826962/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 45/46] UefiCpuPkg/MpInitLib: Prepare SEV-ES guest APs for OS use

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Before UEFI transfers control to the OS, it must park the AP. This is
done using the AsmRelocateApLoop function to transition into 32-bit
non-paging mode. For an SEV-ES guest, a few additional things must be
done:
  - AsmRelocateApLoop must be updated to support SEV-ES. This means
performing a VMGEXIT AP Reset Hold instead of an MWAIT or HLT loop.
  - Since the AP must transition to real mode, a small routine is copied
to the WakeupBuffer area. Since the WakeupBuffer will be used by
the AP during OS booting, it must be placed in reserved memory.
Additionally, the AP stack must be located where it can be accessed
in real mode.
  - Once the AP is in real mode it will transfer control to the
destination specified by the OS in the SEV-ES AP Jump Table. The
SEV-ES AP Jump Table address is saved by the hypervisor for the OS
using the GHCB VMGEXIT AP Jump Table exit code.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/MpLib.h  |   8 +-
 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |  54 +++-
 UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 131 --
 3 files changed, 175 insertions(+), 18 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index b1a9d99cb3eb..267aa5201c50 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -293,7 +293,8 @@ struct _CPU_MP_DATA {
   UINT64 GhcbBase;
 };
 
-#define AP_RESET_STACK_SIZE 64
+#define AP_SAFE_STACK_SIZE  128
+#define AP_RESET_STACK_SIZE AP_SAFE_STACK_SIZE
 
 #pragma pack(1)
 
@@ -349,8 +350,11 @@ VOID
   IN BOOLEAN MwaitSupport,
   IN UINTN   ApTargetCState,
   IN UINTN   PmCodeSegment,
+  IN UINTN   Pm16CodeSegment,
   IN UINTN   TopOfApStack,
-  IN UINTN   NumberToFinish
+  IN UINTN   NumberToFinish,
+  IN UINTN   SevEsAPJumpTable,
+  IN UINTN   WakeupBuffer
   );
 
 /**
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index 9115ff9e3e30..7165bcf3124a 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -85,6 +86,13 @@ GetWakeupBuffer (
 {
   EFI_STATUS  Status;
   EFI_PHYSICAL_ADDRESSStartAddress;
+  EFI_MEMORY_TYPE MemoryType;
+
+  if (PcdGetBool (PcdSevEsIsEnabled)) {
+MemoryType = EfiReservedMemoryType;
+  } else {
+MemoryType = EfiBootServicesData;
+  }
 
   //
   // Try to allocate buffer below 1M for waking vector.
@@ -97,7 +105,7 @@ GetWakeupBuffer (
   StartAddress = 0x88000;
   Status = gBS->AllocatePages (
   AllocateMaxAddress,
-  EfiBootServicesData,
+  MemoryType,
   EFI_SIZE_TO_PAGES (WakeupBufferSize),
   
   );
@@ -159,8 +167,10 @@ GetSevEsAPMemory (
   VOID
   )
 {
-  EFI_STATUSStatus;
-  EFI_PHYSICAL_ADDRESS  StartAddress;
+  EFI_STATUSStatus;
+  EFI_PHYSICAL_ADDRESS  StartAddress;
+  MSR_SEV_ES_GHCB_REGISTER  Msr;
+  GHCB  *Ghcb;
 
   //
   // Allocate 1 page for AP jump table page
@@ -176,6 +186,16 @@ GetSevEsAPMemory (
 
   DEBUG ((DEBUG_INFO, "Dxe: SevEsAPMemory = %lx\n", (UINTN) StartAddress));
 
+  //
+  // Save the SevEsAPMemory as the AP jump table.
+  //
+  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+  Ghcb = Msr.Ghcb;
+
+  VmgInit (Ghcb);
+  VmgExit (Ghcb, SVM_EXIT_AP_JUMP_TABLE, 0, (UINT64) (UINTN) StartAddress);
+  VmgDone (Ghcb);
+
   return (UINTN) StartAddress;
 }
 
@@ -330,17 +350,26 @@ RelocateApLoop (
   BOOLEANMwaitSupport;
   ASM_RELOCATE_AP_LOOP   AsmRelocateApLoopFunc;
   UINTN  ProcessorNumber;
+  UINTN  StackStart;
 
   MpInitLibWhoAmI ();
   CpuMpData= GetCpuMpData ();
   MwaitSupport = IsMwaitSupport ();
+  if (CpuMpData->SevEsIsEnabled) {
+StackStart = CpuMpData->SevEsAPResetStackStart;
+  } else {
+StackStart = mReservedTopOfApStack;
+  }
   AsmRelocateApLoopFunc = (ASM_RELOCATE_AP_LOOP) (UINTN) mReservedApLoopFunc;
   AsmRelocateApLoopFunc (
 MwaitSupport,
 CpuMpData->ApTargetCState,
 CpuMpData->PmCodeSegment,
-mReservedTopOfApStack - ProcessorNumber * AP_SAFE_STACK_SIZE,
-(UINTN) 
+CpuMpData->Pm16CodeSegment,
+StackStart - ProcessorNumber * AP_SAFE_STACK_SIZE,
+(UINTN) ,
+CpuMpData->SevEsAPBuffer,
+CpuMpData->WakeupBuffer
 );
   //
   // It should never reach here
@@ -374,6 +403,21 @@ MpInitChangeApLoopCallback (
   while (mNumberToFinish > 0) {
 CpuPause ();
   }
+
+ 

[edk2-devel] [PATCH v12 46/46] Maintainers.txt: Add reviewers for the OvmfPkg SEV-related files

[Lendacky, Thomas]

From: Tom Lendacky 

Register reviewers for the SEV-related files in OvmfPkg.

Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Brijesh Singh 
Acked-by: Brijesh Singh 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 Maintainers.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 5504bb3d17cc..dc7ac7a5daf6 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -412,6 +412,16 @@ F: OvmfPkg/PvScsiDxe/
 R: Liran Alon 
 R: Nikita Leshenko 
 
+OvmfPkg: SEV-related modules
+F: OvmfPkg/AmdSevDxe/
+F: OvmfPkg/Include/Library/MemEncryptSevLib.h
+F: OvmfPkg/IoMmuDxe/AmdSevIoMmu.*
+F: OvmfPkg/Library/BaseMemEncryptSevLib/
+F: OvmfPkg/Library/VmgExitLib/
+F: OvmfPkg/PlatformPei/AmdSev.c
+R: Tom Lendacky 
+R: Brijesh Singh 
+
 OvmfPkg: TCG- and TPM2-related modules
 F: OvmfPkg/Include/IndustryStandard/QemuTpm.h
 F: OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63361): https://edk2.groups.io/g/devel/message/63361
Mute This Topic: https://groups.io/mt/75829491/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 44/46] OvmfPkg: Move the GHCB allocations into reserved memory

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

After having transitioned from UEFI to the OS, the OS will need to boot
the APs. For an SEV-ES guest, the APs will have been parked by UEFI using
GHCB pages allocated by UEFI. The hypervisor will write to the GHCB
SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the
GHCB pages must be marked reserved so that the OS does not attempt to use
them and experience memory corruption because of the hypervisor write.

Change the GHCB allocation from the default boot services memory to
reserved memory.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/AmdSev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index a2b38c591236..4a515a484720 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -51,9 +51,11 @@ AmdSevEsInitialize (
 
   //
   // Allocate GHCB and per-CPU variable pages.
+  //   Since the pages must survive across the UEFI to OS transition
+  //   make them reserved.
   //
   GhcbPageCount = mMaxCpuCount * 2;
-  GhcbBase = AllocatePages (GhcbPageCount);
+  GhcbBase = AllocateReservedPages (GhcbPageCount);
   ASSERT (GhcbBase != NULL);
 
   GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63359): https://edk2.groups.io/g/devel/message/63359
Mute This Topic: https://groups.io/mt/75829487/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 43/46] OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

A hypervisor is not allowed to update an SEV-ES guest's register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead an SEV-ES AP must be
re-directed from within the guest to the actual requested staring location
as specified in the INIT-SIPI-SIPI sequence.

Use the SEV-ES work area for the reset vector code that contains support
to jump to the desired RIP location after having been started. This is
required for only the very first AP reset.

This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
original file through the use of the include path order set in
OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 100 +++
 OvmfPkg/ResetVector/ResetVector.nasmb|   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm

diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
new file mode 100644
index ..980e0138e7fe
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -0,0 +1,100 @@
+;--
+; @file
+; First code executed by processor after resetting.
+; Derived from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
+;
+; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+BITS16
+
+ALIGN   16
+
+;
+; Pad the image size to 4k when page tables are in VTF0
+;
+; If the VTF0 image has page tables built in, then we need to make
+; sure the end of VTF0 is 4k above where the page tables end.
+;
+; This is required so the page tables will be 4k aligned when VTF0 is
+; located just below 0x1 (4GB) in the firmware device.
+;
+%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
+TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
+%endif
+
+;
+; SEV-ES Processor Reset support
+;
+; sevEsResetBlock:
+;   For the initial boot of an AP under SEV-ES, the "reset" RIP must be
+;   programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset
+;   and GUID will be used to locate this block in the firmware and extract
+;   the build time RIP value. The GUID must always be 48 bytes from the
+;   end of the firmware.
+;
+;   0xffca (-0x36) - IP value
+;   0xffcc (-0x34) - CS segment base [31:16]
+;   0xffce (-0x32) - Size of the SEV-ES reset block
+;   0xffd0 (-0x30) - SEV-ES reset block GUID
+;(00f771de-1a7e-4fcb-890e-68c77e2fb44e)
+;
+;   A hypervisor reads the CS segement base and IP value. The CS segment base
+;   value represents the high order 16-bits of the CS segment base, so the
+;   hypervisor must left shift the value of the CS segement base by 16 bits to
+;   form the full CS segment base for the CS segment register. It would then
+;   program the EIP register with the IP value as read.
+;
+
+TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0
+
+sevEsResetBlockStart:
+DD  SEV_ES_AP_RESET_IP
+DW  sevEsResetBlockEnd - sevEsResetBlockStart
+DB  0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F
+DB  0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E
+sevEsResetBlockEnd:
+
+ALIGN   16
+
+applicationProcessorEntryPoint:
+;
+; Application Processors entry point
+;
+; GenFv generates code aligned on a 4k boundary which will jump to this
+; location.  (0xffe0)  This allows the Local APIC Startup IPI to be
+; used to wake up the application processors.
+;
+jmp EarlyApInitReal16
+
+ALIGN   8
+
+DD  0
+
+;
+; The VTF signature
+;
+; VTF-0 means that the VTF (Volume Top File) code does not require
+; any fixups.
+;
+vtfSignature:
+DB  'V', 'T', 'F', 0
+
+ALIGN   16
+
+resetVector:
+;
+; Reset Vector
+;
+; This is where the processor will begin execution
+;
+nop
+nop
+jmp EarlyBspInitReal16
+
+ALIGN   16
+
+fourGigabytes:
+
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 762661115d50..4913b379a993 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -82,5 +82,6 @@
 
 %include "Main.asm"
 
+  %define SEV_ES_AP_RESET_IP  FixedPcdGet32 (PcdSevEsWorkAreaBase)
 %include "Ia16/ResetVectorVtf0.asm"
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63358): https://edk2.groups.io/g/devel/message/63358
Mute This Topic: https://groups.io/mt/75829481/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  

[edk2-devel] [PATCH v12 42/46] UefiCpuPkg: Allow AP booting under SEV-ES

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Typically, an AP is booted using the INIT-SIPI-SIPI sequence. This
sequence is intercepted by the hypervisor, which sets the AP's registers
to the values requested by the sequence. At that point, the hypervisor can
start the AP, which will then begin execution at the appropriate location.

Under SEV-ES, AP booting presents some challenges since the hypervisor is
not allowed to alter the AP's register state. In this situation, we have
to distinguish between the AP's first boot and AP's subsequent boots.

First boot:
 Once the AP's register state has been defined (which is before the guest
 is first booted) it cannot be altered. Should the hypervisor attempt to
 alter the register state, the change would be detected by the hardware
 and the VMRUN instruction would fail. Given this, the first boot for the
 AP is required to begin execution with this initial register state, which
 is typically the reset vector. This prevents the BSP from directing the
 AP startup location through the INIT-SIPI-SIPI sequence.

 To work around this, the firmware will provide a build time reserved area
 that can be used as the initial IP value. The hypervisor can extract this
 location value by checking for the SEV-ES reset block GUID that must be
 located 48-bytes from the end of the firmware. The format of the SEV-ES
 reset block area is:

   0x00 - 0x01 - SEV-ES Reset IP
   0x02 - 0x03 - SEV-ES Reset CS Segment Base[31:16]
   0x04 - 0x05 - Size of the SEV-ES reset block
   0x06 - 0x15 - SEV-ES Reset Block GUID
   (00f771de-1a7e-4fcb-890e-68c77e2fb44e)

   The total size is 22 bytes. Any expansion to this block must be done
   by adding new values before existing values.

 The hypervisor will use the IP and CS values obtained from the SEV-ES
 reset block to set as the AP's initial values. The CS Segment Base
 represents the upper 16 bits of the CS segment base and must be left
 shifted by 16 bits to form the complete CS segment base value.

 Before booting the AP for the first time, the BSP must initialize the
 SEV-ES reset area. This consists of programming a FAR JMP instruction
 to the contents of a memory location that is also located in the SEV-ES
 reset area. The BSP must program the IP and CS values for the FAR JMP
 based on values drived from the INIT-SIPI-SIPI sequence.

Subsequent boots:
 Again, the hypervisor cannot alter the AP register state, so a method is
 required to take the AP out of halt state and redirect it to the desired
 IP location. If it is determined that the AP is running in an SEV-ES
 guest, then instead of calling CpuSleep(), a VMGEXIT is issued with the
 AP Reset Hold exit code (0x8004). The hypervisor will put the AP in
 a halt state, waiting for an INIT-SIPI-SIPI sequence. Once the sequence
 is recognized, the hypervisor will resume the AP. At this point the AP
 must transition from the current 64-bit long mode down to 16-bit real
 mode and begin executing at the derived location from the INIT-SIPI-SIPI
 sequence.

 Another change is around the area of obtaining the (x2)APIC ID during AP
 startup. During AP startup, the AP can't take a #VC exception before the
 AP has established a stack. However, the AP stack is set by using the
 (x2)APIC ID, which is obtained through CPUID instructions. A CPUID
 instruction will cause a #VC, so a different method must be used. The
 GHCB protocol supports a method to obtain CPUID information from the
 hypervisor through the GHCB MSR. This method does not require a stack,
 so it is used to obtain the necessary CPUID information to determine the
 (x2)APIC ID.

The new 16-bit protected mode GDT entry is used in order to transition
from 64-bit long mode down to 16-bit real mode.

A new assembler routine is created that takes the AP from 64-bit long mode
to 16-bit real mode.  This is located under 1MB in memory and transitions
from 64-bit long mode to 32-bit compatibility mode to 16-bit protected
mode and finally 16-bit real mode.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |   3 +
 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |   3 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h  |  60 
 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |  70 +++-
 UefiCpuPkg/Library/MpInitLib/MpLib.c  | 336 +-
 UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   |  19 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c  |   2 +-
 UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc   |   2 +-
 .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  15 +
 UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc|   4 +-
 UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 239 +
 11 files changed, 738 insertions(+), 15 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index 583276595619..1771575c69c1 100644
--- 

[edk2-devel] [PATCH v12 40/46] UefiCpuPkg: Add a 16-bit protected mode code segment descriptor

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

A hypervisor is not allowed to update an SEV-ES guests register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead, an SEV-ES AP must be
transition from 64-bit long mode to 16-bit real mode in response to an
INIT-SIPI-SIPI sequence. This requires a 16-bit code segment descriptor.
For PEI, create this descriptor in the reset vector GDT table. For DXE,
create this descriptor from the newly reserved entry at location 0x28.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/CpuDxe/CpuGdt.h  | 4 ++--
 UefiCpuPkg/CpuDxe/CpuGdt.c  | 8 
 UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm | 9 +
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuGdt.h b/UefiCpuPkg/CpuDxe/CpuGdt.h
index 3a0210b2f172..1c94487cbee8 100644
--- a/UefiCpuPkg/CpuDxe/CpuGdt.h
+++ b/UefiCpuPkg/CpuDxe/CpuGdt.h
@@ -36,7 +36,7 @@ struct _GDT_ENTRIES {
   GDT_ENTRY LinearCode;
   GDT_ENTRY SysData;
   GDT_ENTRY SysCode;
-  GDT_ENTRY Spare4;
+  GDT_ENTRY SysCode16;
   GDT_ENTRY LinearData64;
   GDT_ENTRY LinearCode64;
   GDT_ENTRY Spare5;
@@ -49,7 +49,7 @@ struct _GDT_ENTRIES {
 #define LINEAR_CODE_SEL   OFFSET_OF (GDT_ENTRIES, LinearCode)
 #define SYS_DATA_SEL  OFFSET_OF (GDT_ENTRIES, SysData)
 #define SYS_CODE_SEL  OFFSET_OF (GDT_ENTRIES, SysCode)
-#define SPARE4_SELOFFSET_OF (GDT_ENTRIES, Spare4)
+#define SYS_CODE16_SELOFFSET_OF (GDT_ENTRIES, SysCode16)
 #define LINEAR_DATA64_SEL OFFSET_OF (GDT_ENTRIES, LinearData64)
 #define LINEAR_CODE64_SEL OFFSET_OF (GDT_ENTRIES, LinearCode64)
 #define SPARE5_SELOFFSET_OF (GDT_ENTRIES, Spare5)
diff --git a/UefiCpuPkg/CpuDxe/CpuGdt.c b/UefiCpuPkg/CpuDxe/CpuGdt.c
index 64efadeba601..a1ab543f2da5 100644
--- a/UefiCpuPkg/CpuDxe/CpuGdt.c
+++ b/UefiCpuPkg/CpuDxe/CpuGdt.c
@@ -70,14 +70,14 @@ STATIC GDT_ENTRIES GdtTemplate = {
 0x0,
   },
   //
-  // SPARE4_SEL
+  // SYS_CODE16_SEL
   //
   {
-0x0,// limit 15:0
+0x0,// limit 15:0
 0x0,// base 15:0
 0x0,// base 23:16
-0x0,// type
-0x0,// limit 19:16, flags
+0x09A,  // present, ring 0, code, execute/read
+0x08F,  // page-granular, 16-bit
 0x0,// base 31:24
   },
   //
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm 
b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
index ce4ebfffb688..0e79a3984b16 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
@@ -129,5 +129,14 @@ LINEAR_CODE64_SEL   equ $-GDT_BASE
 DB  0; base 31:24
 %endif
 
+; linear code segment descriptor
+LINEAR_CODE16_SEL equ $-GDT_BASE
+DW  0x   ; limit 15:0
+DW  0; base 15:0
+DB  0; base 23:16
+DB  PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(CODE32_TYPE)
+DB  
GRANULARITY_FLAG(1)|DEFAULT_SIZE32(0)|CODE64_FLAG(0)|UPPER_LIMIT(0xf)
+DB  0; base 31:24
+
 GDT_END:
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63355): https://edk2.groups.io/g/devel/message/63355
Mute This Topic: https://groups.io/mt/75829470/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 41/46] UefiCpuPkg/MpInitLib: Add CPU MP data flag to indicate if SEV-ES is enabled

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

When starting APs in an SMP configuration, the AP needs to know if it is
running as an SEV-ES guest in order to assign a GHCB page.

Add a field to the CPU_MP_DATA structure that will indicate if SEV-ES is
enabled. This new field is set during MP library initialization with the
PCD value PcdSevEsIsEnabled. This flag can then be used to determine if
SEV-ES is enabled.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 1 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h  | 2 ++
 UefiCpuPkg/Library/MpInitLib/MpLib.c  | 1 +
 4 files changed, 5 insertions(+)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index 9907f4157b09..583276595619 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -71,4 +71,5 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## 
CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
SOMETIMES_CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStatusCheckIntervalInMicroSeconds  ## 
CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled  ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  ## 
CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
index 89ee9a79d8c5..4b3d39fbf36c 100644
--- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
@@ -61,6 +61,7 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
SOMETIMES_CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled  ## CONSUMES
 
 [Ppis]
   gEdkiiPeiShadowMicrocodePpiGuid## SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index a8ca03efb8e3..5b46c295b6b2 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -276,6 +276,8 @@ struct _CPU_MP_DATA {
   // driver.
   //
   BOOLEANWakeUpByInitSipiSipi;
+
+  BOOLEANSevEsIsEnabled;
 };
 
 extern EFI_GUID mCpuInitMpLibHobGuid;
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 9b0660a5d4ea..2a3fbeef35f7 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1704,6 +1704,7 @@ MpInitLibInitialize (
   CpuMpData->CpuData  = (CPU_AP_DATA *) (CpuMpData + 1);
   CpuMpData->CpuInfoInHob = (UINT64) (UINTN) (CpuMpData->CpuData + 
MaxLogicalProcessorNumber);
   InitializeSpinLock(>MpLock);
+  CpuMpData->SevEsIsEnabled = PcdGetBool (PcdSevEsIsEnabled);
 
   //
   // Make sure no memory usage outside of the allocated buffer.
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63356): https://edk2.groups.io/g/devel/message/63356
Mute This Topic: https://groups.io/mt/75829472/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: fix variable services conformance test

[Heinrich Schuchardt]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2865

QueryVariableInfo() returning EFI_SUCCESS for a legal combination of
attributes is not an error.

Signed-off-by: Heinrich Schuchardt 
---
 .../BlackBoxTest/AuthVariableServicesBBTestConformance.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
index 23b00e35..f16560ff 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/AuthVariableServicesBBTestConformance.c
@@ -287,7 +287,7 @@ AuthVariableDERConfTest (

);
 
-if (Status == EFI_UNSUPPORTED) {
+if (Status == EFI_SUCCESS || Status == EFI_UNSUPPORTED) {
   Result = EFI_TEST_ASSERTION_PASSED;
 } else {
   Result = EFI_TEST_ASSERTION_FAILED;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63354): https://edk2.groups.io/g/devel/message/63354
Mute This Topic: https://groups.io/mt/75828348/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v12 00/46] SEV-ES guest support

[Lendacky, Thomas]

On 7/27/20 12:43 PM, Laszlo Ersek wrote:
> On 07/27/20 19:41, Laszlo Ersek wrote:
>> Hi Tom,

Hi Laszlo,

>>
>> On 07/27/20 17:25, Lendacky, Thomas wrote:
>>> From: Tom Lendacky 
>>>
>>> This patch series provides support for running EDK2/OVMF under SEV-ES.
>>>
>>> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
>>> SEV support to protect the guest register state from the hypervisor. See
>>> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
>>> section "15.35 Encrypted State (SEV-ES)" [1].
>>>
>>> In order to allow a hypervisor to perform functions on behalf of a guest,
>>> there is architectural support for notifying a guest's operating system
>>> when certain types of VMEXITs are about to occur. This allows the guest to
>>> selectively share information with the hypervisor to satisfy the requested
>>> function. The notification is performed using a new exception, the VMM
>>> Communication exception (#VC). The information is shared through the
>>> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
>>> The GHCB format and the protocol for using it is documented in "SEV-ES
>>> Guest-Hypervisor Communication Block Standardization" [2].
>>>
>>> The main areas of the EDK2 code that are updated to support SEV-ES are
>>> around the exception handling support and the AP boot support.
>>>
>>> Exception support is required starting in Sec, continuing through Pei
>>> and into Dxe in order to handle #VC exceptions that are generated.  Each
>>> AP requires it's own GHCB page as well as a page to hold values specific
>>> to that AP.
>>>
>>> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
>>> is typically used to boot the APs. However, the hypervisor is not allowed
>>> to update the guest registers. The GHCB document [2] talks about how SMP
>>> booting under SEV-ES is performed.
>>>
>>> Since the GHCB page must be a shared (unencrypted) page, the processor
>>> must be running in long mode in order for the guest and hypervisor to
>>> communicate with each other. As a result, SEV-ES is only supported under
>>> the X64 architecture.
>>>
>>> [1] 
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdfdata=02%7C01%7Cthomas.lendacky%40amd.com%7Cb388414fce2747ca9fef08d832549c1e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314686421485283sdata=q1XqA0IvSWYmCHqRFQ704595cECr6MH6MXIJBoKAkog%3Dreserved=0
>>> [2] 
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.amd.com%2Fwp-content%2Fresources%2F56421.pdfdata=02%7C01%7Cthomas.lendacky%40amd.com%7Cb388414fce2747ca9fef08d832549c1e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314686421485283sdata=EfLCdVJ9EcGQxBRv79NLLrZ8vyiCxepLbkNM%2FsQMOf0%3Dreserved=0
>>>
>>> ---
>>>
>>> These patches are based on commit:
>>> 6074f57e5b19 ("MdePkg/Include/IndustryStandard: Main CXL header")
>>>
>>> A version of the tree can be found at:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fovmf%2Ftree%2Fsev-es-v20data=02%7C01%7Cthomas.lendacky%40amd.com%7Cb388414fce2747ca9fef08d832549c1e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314686421485283sdata=auEp%2Fd6Ju4V3BYG5UW%2BzwJzDersXm%2BuziQnB%2FPLDnYg%3Dreserved=0
>>>
>>> Cc: Andrew Fish 
>>> Cc: Anthony Perard 
>>> Cc: Ard Biesheuvel 
>>> Cc: Benjamin You 
>>> Cc: Dandan Bi 
>>> Cc: Eric Dong 
>>> Cc: Guo Dong 
>>> Cc: Hao A Wu 
>>> Cc: Jian J Wang 
>>> Cc: Jordan Justen 
>>> Cc: Julien Grall 
>>> Cc: Laszlo Ersek 
>>> Cc: Leif Lindholm 
>>> Cc: Liming Gao 
>>> Cc: Maurice Ma 
>>> Cc: Michael D Kinney 
>>> Cc: Ray Ni 
>>>
>>> Changes since v11:
>>> - Make the XGETBV and VMGEXIT .nasm files buildable for all environments
>>>   and remove the updates that add these instructions to GccInline.c
>>
>> Patches 40-46 (inclusive) seem to be missing from my mailbox (and the
>> list archive on groups.io lacks them too, apparently).
>>
>> Did you get rate-limited by some component when sending the series, perhaps?
> 
> On a second / closer look, that seems quite likely, because my INBOX
> does have all the (directly delivered) patches; only my list folder is
> missing the tail.

Yes, I always get an error when I reach 40 emails:

Reported error: 550 5.0.350 Remote server returned an error -> 500 We have
received more than 40 messages in 30 minutes from you. To guard against
autoresponder mail loops, we must reject additional messages from you
temporarily. Please try again later.

So I usually have to wait a few hours and resend the last ones so they
make it to groups.io.

Thanks,
Tom

> 
> Thanks
> Laszlo
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63353): https://edk2.groups.io/g/devel/message/63353
Mute This Topic: https://groups.io/mt/75824926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  

Re: [edk2-devel] [PATCH v12 00/46] SEV-ES guest support

[Laszlo Ersek]

On 07/27/20 19:41, Laszlo Ersek wrote:
> Hi Tom,
> 
> On 07/27/20 17:25, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> This patch series provides support for running EDK2/OVMF under SEV-ES.
>>
>> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
>> SEV support to protect the guest register state from the hypervisor. See
>> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
>> section "15.35 Encrypted State (SEV-ES)" [1].
>>
>> In order to allow a hypervisor to perform functions on behalf of a guest,
>> there is architectural support for notifying a guest's operating system
>> when certain types of VMEXITs are about to occur. This allows the guest to
>> selectively share information with the hypervisor to satisfy the requested
>> function. The notification is performed using a new exception, the VMM
>> Communication exception (#VC). The information is shared through the
>> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
>> The GHCB format and the protocol for using it is documented in "SEV-ES
>> Guest-Hypervisor Communication Block Standardization" [2].
>>
>> The main areas of the EDK2 code that are updated to support SEV-ES are
>> around the exception handling support and the AP boot support.
>>
>> Exception support is required starting in Sec, continuing through Pei
>> and into Dxe in order to handle #VC exceptions that are generated.  Each
>> AP requires it's own GHCB page as well as a page to hold values specific
>> to that AP.
>>
>> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
>> is typically used to boot the APs. However, the hypervisor is not allowed
>> to update the guest registers. The GHCB document [2] talks about how SMP
>> booting under SEV-ES is performed.
>>
>> Since the GHCB page must be a shared (unencrypted) page, the processor
>> must be running in long mode in order for the guest and hypervisor to
>> communicate with each other. As a result, SEV-ES is only supported under
>> the X64 architecture.
>>
>> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
>> [2] https://developer.amd.com/wp-content/resources/56421.pdf
>>
>> ---
>>
>> These patches are based on commit:
>> 6074f57e5b19 ("MdePkg/Include/IndustryStandard: Main CXL header")
>>
>> A version of the tree can be found at:
>> https://github.com/AMDESE/ovmf/tree/sev-es-v20
>>
>> Cc: Andrew Fish 
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Benjamin You 
>> Cc: Dandan Bi 
>> Cc: Eric Dong 
>> Cc: Guo Dong 
>> Cc: Hao A Wu 
>> Cc: Jian J Wang 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Liming Gao 
>> Cc: Maurice Ma 
>> Cc: Michael D Kinney 
>> Cc: Ray Ni 
>>
>> Changes since v11:
>> - Make the XGETBV and VMGEXIT .nasm files buildable for all environments
>>   and remove the updates that add these instructions to GccInline.c
> 
> Patches 40-46 (inclusive) seem to be missing from my mailbox (and the
> list archive on groups.io lacks them too, apparently).
> 
> Did you get rate-limited by some component when sending the series, perhaps?

On a second / closer look, that seems quite likely, because my INBOX
does have all the (directly delivered) patches; only my list folder is
missing the tail.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63352): https://edk2.groups.io/g/devel/message/63352
Mute This Topic: https://groups.io/mt/75824926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Laszlo Ersek]

On 07/27/20 18:48, Vladimir Olovyannikov wrote:
> Signed-off-by: Vladimir Olovyannikov 
> Cc: Samer El-Haj-Mahmoud 
> Cc: Laszlo Ersek 
> Cc: Zhichao Gao 
> Cc: Maciej Rabeda 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Nd 
> 
> This patchset introduces an http client utilizing EDK2 HTTP protocol, to
> allow fast image downloading from http/https servers.
> HTTP download speed is usually faster than tftp.
> The client is based on the same approach as tftp dynamic command, and
> uses the same UEFI Shell command line parameters. This makes it easy
> integrating http into existing UEFI Shell scripts.
> Note that to enable HTTP download, feature Pcd
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
> 
> PATCH v5 changes:
> Address Laszlo's comments on patch v4:
>  - Remove -m option as it introduced TimerLib dependency;
>  - Drop "Tested-by" flags.

Thanks! As I mentioned under v4, I'll delay my testing until there's
some reviewer feedback too.

Cheers!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63350): https://edk2.groups.io/g/devel/message/63350
Mute This Topic: https://groups.io/mt/75826962/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[PierreGondois]

Hello,

Liming:
I didn't find anything preventing from having a .vfr and .c file with the same 
name in the same scope.

Everybody:
The .c files generated (from either .vfr or .asl) are generated in the 
Build//OUTPUT/ directory, with their original subdirectory stripped. In the 
example below, the .c, .vfr and .asl files have been placed in subdirectories 
in edk2/edk2-platforms. The recipes that have been generated are:
$(OUTPUT_DIR)/Emmc.obj : $(OUTPUT_DIR)/AslDir/Emmc.c (from Emmc.asl)
$(OUTPUT_DIR)/Ip4Config2.obj : $(DEBUG_DIR)/VfrDir/Ip4Config2.c (from 
Ip4Config2.vfr)
$(OUTPUT_DIR)/CDir/Emmc.obj : 
$(WORKSPACE)/edk2-platforms/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/CDir/Emmc.c
 (from Emmc.c)

The only subdirectory that remains is the one from the .c files. Indeed, the 
build system might detects subdirectories from the .inf file location. As the 
.c file is generated in the OUTPUT directory where there is no .inf file, it 
gets stripped.
This means that if a subdirectory is created, it is for the .c file, but I 
don't think we should modify this.

Adding a pre/postfix to the generated .c filename seems a better approach to 
me. It would require modifying build_rule.template, and choose which 
pre/postfix to add.

Another point is that the .c file generated from the .c file is placed in the 
$(DEBUG_DIR), when the one coming from the .asl file is placed in 
$(OUTPUT_DIR). Maybe it should be modified to $(DEBUG_DIR) aswell.

Regards,
Pierre

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao via 
groups.io
Sent: Monday, July 27, 2020 3:21 PM
To: Leif Lindholm ; devel@edk2.groups.io; Pierre Gondois 
; Masahisa Kojima 
Cc: Sami Mujawar ; Tomas Pilar ; 
Feng, Bob C ; Ard Biesheuvel 
Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays 
into .obj file

Leif:
  VFR file has the similar case. VFR is converted to xxx.c, then compile it to 
obj file.

Bob:
  Has BaseTools such detection if VFR and C source file have the same file name?

Thanks
Liming
> -Original Message-
> From: Leif Lindholm 
> Sent: Monday, July 27, 2020 9:58 PM
> To: devel@edk2.groups.io; pierre.gond...@arm.com; Masahisa Kojima
> 
> Cc: sami.muja...@arm.com; tomas.pi...@arm.com; Feng, Bob C
> ; Gao, Liming ; Ard
> Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML
> bytecode arrays into .obj file
>
> Hi Pierre, (+Masahisa)
>
> This commit (0a4aa20e8d44) made for an exciting start to my week.
>
> Socionext's Developerbox failed to build for me, with the spectacular
> error message:
>
> /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld:
> DWARF error: could not find abbrev number 5912
> /tmp/ccKt4gaM.ltrans0.ltrans.o: in function `RegisterDevices':
> :(.text.RegisterDevices+0xb0): undefined reference to
> `RegisterEmmc'
>
> GCC49 (without lto) and CLANG38 profiles give much the same result,
> with slightly less esoteric messages.
>
> The reason for this turned out to be that edk2-platforms
> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/ has both an Emmc.asl
> and an Emmc.c file, which after this patch both generate an Emmc.obj
> in the same output directory.
>
> I think the correct course of action is to fix this in the SynQuacer
> driver, but I am reporting it here so we get it logged in the list
> archives.
>
> It would of course be good if the build system could detect and warn
> over cases like this, rather than silently overwriting existing object
> files.
>
> Masahisa - since Ard is still on holiday, could you create a patch and
> send out for me to review? Either one of the files needs to be
> renamed, or we need to move the .asl files (Emmc.asl and Optee.asl)
> into a subdirectory.
>
> Best Regards,
>
> Leif
>
> On Wed, Jul 01, 2020 at 15:06:03 +0100, PierreGondois wrote:
> > From: Pierre Gondois 
> >
> > The AmlToHex script and Posix/WindowsLike wrappers convert an AML
> > file to a .hex file, containing a C array storing AML bytecode. This
> > ".hex" file can then be included in a C file, allowing to access the
> > AML bytecode from this C file.
> >
> > The EDK2 build system doesn't allow to a depict dependency orders
> > between files of different languages. For instance, in a module
> > containing a ".c" file and a ".asl", the ".c"
> > file may or may not be built prior to the ".asl" file.
> > This prevents any inclusion of a generated ".hex" in a ".c" file
> > since this later ".hex" file may or may not have been created yet.
> >
> > This patch modifies the AmlToC script to generate a C file instead
> > of a ".hex" file.
> > It also adds the generation of an intermediate ".amli" file when
> > compiling an ASL file, and adds a rule to convert this ".amli" to a
> > C file.
> >
> > This allows to generate a C file containing the AML bytecode from an
> > ASL file. This C file will then be handled by the EDK2 build system
> > to generate an object file.
> > Thus, no file inclusion will be required 

[edk2-devel] [PATCH v5 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Introduce an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must
be set to TRUE.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

Signed-off-by: Vladimir Olovyannikov 
CC: Samer El-Haj-Mahmoud 
CC: Laszlo Ersek 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 
---
 CryptoPkg/Library/OpensslLib/openssl  |2 +-
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1715 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   89 +
 .../HttpDynamicCommand/Http.uni   |  117 ++
 .../HttpDynamicCommand/HttpApp.c  |   53 +
 .../HttpDynamicCommand/HttpApp.inf|   58 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  134 ++
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 11 files changed, 2241 insertions(+), 1 deletion(-)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf

diff --git a/CryptoPkg/Library/OpensslLib/openssl 
b/CryptoPkg/Library/OpensslLib/openssl
index e2e09d9fba11..c3656cc594da 16
--- a/CryptoPkg/Library/OpensslLib/openssl
+++ b/CryptoPkg/Library/OpensslLib/openssl
@@ -1 +1 @@
-Subproject commit e2e09d9fba1187f8d6aafaa34d4172f56f1ffb72
+Subproject commit c3656cc594daac8167721dde7220f0e59ae146fc
diff --git a/ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c 
b/ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
new file mode 100644
index ..0565b07c3570
--- /dev/null
+++ b/ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
@@ -0,0 +1,1715 @@
+/** @file
+  The implementation for the 'http' Shell command.
+
+  Copyright (c) 2015, ARM Ltd. All rights reserved.
+  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. 
+  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+  Copyright (c) 2020, Broadcom. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "Http.h"
+
+#define IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH 32
+EFI_HII_HANDLE   mHttpHiiHandle;
+
+/*
+   Constant strings and definitions related to the message
+   indicating the amount of progress in the dowloading of a HTTP file.
+*/
+
+// Number of steps in the progression slider
+#define HTTP_PROGRESS_SLIDER_STEPS  \
+  ((sizeof (HTTP_PROGR_FRAME) / sizeof (CHAR16)) - 3)
+
+// Size in number of characters plus one (final zero) of the message to
+// indicate the progress of an HTTP download. The format is "[(progress slider:
+// 40 characters)] (nb of KBytes downloaded so far: 7 characters) Kb". There
+// are thus the number of characters in HTTP_PROGR_FRAME[] plus 11 characters
+// (2 // spaces, "Kb" and seven characters for the number of KBytes).
+#define HTTP_PROGRESS_MESSAGE_SIZE  \
+  ((sizeof (HTTP_PROGR_FRAME) / sizeof (CHAR16)) + 12)
+
+//
+// Buffer size. Note that larger buffer does not mean better speed!
+//
+#define DEFAULT_BUF_SIZE  SIZE_32KB
+#define MAX_BUF_SIZE  SIZE_4MB
+
+#define MIN_PARAM_COUNT   2
+#define MAX_PARAM_COUNT   4
+
+#define TIMER_MAX_TIMEOUT_S   10
+
+// File name to use when URI ends with "/"
+#define DEFAULT_HTML_FILE L"index.html"
+#define DEFAULT_HTTP_PROTOL"http"
+
+// String to delete the HTTP progress message to be able to update it :
+// (HTTP_PROGRESS_MESSAGE_SIZE-1) '\b'
+#define HTTP_PROGRESS_DEL \
+  L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\
+\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"
+
+#define HTTP_KB  L"\b\b\b\b\b\b\b\b\b\b"
+// Frame for the progression slider
+#define HTTP_PROGR_FRAME L"[]"
+
+// String descriptions for server errors
+STATIC CONST CHAR16 *ErrStatusDesc[] =
+{
+  L"400 Bad Request",
+  L"401 Unauthorized",
+  L"402 Payment required",
+  L"403 Forbidden",
+  L"404 Not Found",
+  L"405 Method not allowed",
+  L"406 Not acceptable",
+  L"407 Proxy authentication required",
+  L"408 Request time out",
+  L"409 Conflict",
+  L"410 Gone",
+  L"411 Length required",
+  

[edk2-devel] [PATCH v5 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Signed-off-by: Vladimir Olovyannikov 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 

This patchset introduces an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

PATCH v5 changes:
Address Laszlo's comments on patch v4:
 - Remove -m option as it introduced TimerLib dependency;
 - Drop "Tested-by" flags.

Vladimir Olovyannikov (1):
  ShellPkg/DynamicCommand: add HttpDynamicCommand

 CryptoPkg/Library/OpensslLib/openssl  |2 +-
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1715 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   89 +
 .../HttpDynamicCommand/Http.uni   |  117 ++
 .../HttpDynamicCommand/HttpApp.c  |   53 +
 .../HttpDynamicCommand/HttpApp.inf|   58 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  134 ++
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 11 files changed, 2241 insertions(+), 1 deletion(-)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf

-- 
2.26.2.266.ge870325ee8


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63347): https://edk2.groups.io/g/devel/message/63347
Mute This Topic: https://groups.io/mt/75826962/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Leif Lindholm]

On Mon, Jul 27, 2020 at 14:55:03 +, Gao, Liming wrote:
> > > diff --git a/MdePkg/Include/IndustryStandard/Cxl11.h 
> > > b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > new file mode 100644
> > > index 00..933c1ab817
> > > --- /dev/null
> > > +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> > > @@ -0,0 +1,569 @@
> > > +/** @file
> > > +  CXL 1.1 Register definitions
> > > +
> > > +  This file contains the register definitions based on the Compute 
> > > Express Link
> > > +  (CXL) Specification Revision 1.1.
> > > +
> > > +Copyright (c) 2020, Intel Corporation. All rights reserved.
> > > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +
> > > +**/
> > > +
> > > +#ifndef _CXL11_H_
> > > +#define _CXL11_H_
> > 
> > We should not be adding macros with a leading _ - these are intended
> > for toolchain use.
> 
> This style is align to other header file. This is the file header
> macro to make sure the header file be included more than once.

Yes. The other headers should also be changed, but in the meantime it
would be good to stop adding more incorrect ones.
https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/5_source_files/53_include_files#5-3-5-all-include-file-contents-must-be-protected-by-a-include-guard

> > > +
> > > +//
> > > +// CXL Flex Bus Device default device and function number
> > > +// Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1
> > > +//
> > > +#define CXL_DEV_DEV 0
> > > +#define CXL_DEV_FUNC0
> > > +
> > > +//
> > > +// Ensure proper structure formats
> > > +//
> > > +#pragma pack(1)
> > 
> > And this pragma has no function whatsoever with regards to any of the
> > register definition structs below. It would be much better if the
> > structs requiring packing (_DEVICE, _PORT, ...) were grouped together
> > and only those were given this treatment.
> > 
> > #pragma pack(1) is *not* a safe default.
> > 
> 
> I know pack(1) is for the compact structure layout. 

Yes. And it should be used when structs need to be compacted.
All of the bitfield structs are single-variable structs, so the
packing has no effect on them, other than setting the struct alignment
requirements to 1 byte, which will not be correct (or efficient) on all
architectures.

> > Now, one final comment - and this is more of a project feature
> > suggestion:
> > Industry standard headers is something fairly special, even in
> > comparison with the rest of MdePkg. *I* would certainly like to ensure
> > I don't miss changes or additions to them.
> > Could we set up a dedicated group of reviewers for this folder only?
> > This need not affect the actual maintainership of MdePkg, just ensure
> > more eyeballs (or screen readers, braille terminals, ...) hit updates
> > here?
> > 
> > i.e. something like the below to Maintainers.txt:
> > 
> > F: MdePkg/Include/IndustryStandard/
> > R: Leif ...
> > R: ...
> > R: ...
> > 
> 
> This is a good suggestion. IndustryStandard needs more feedback. 
> Can you send the patch to update Maintainers.txt?

Sure, I can do that. Any thoughts on others to add than me?

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63346): https://edk2.groups.io/g/devel/message/63346
Mute This Topic: https://groups.io/mt/75823529/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/3] UefiPayloadPkg: Store the size of the MMCONF window

[Guo Dong]

Reviewed-by: Guo Dong 

> -Original Message-
> From: Marcello Sylvester Bauer 
> Sent: Monday, July 27, 2020 1:19 AM
> To: devel@edk2.groups.io
> Cc: Patrick Rudolph ; Christian Walter
> ; Ma, Maurice ;
> Dong, Guo ; You, Benjamin 
> Subject: [PATCH v4 1/3] UefiPayloadPkg: Store the size of the MMCONF window
> 
> From: Patrick Rudolph 
> 
> Store the real size of the Pcie Memory Mapped Address Space.
> This change is necessary to support variable size of MMCONF spaces.
> 
> Signed-off-by: Patrick Rudolph 
> Signed-off-by: Marcello Sylvester Bauer 
> Cc: Patrick Rudolph 
> Cc: Christian Walter 
> Cc: Maurice Ma 
> Cc: Guo Dong 
> Cc: Benjamin You 
> ---
>  UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h | 1 +
>  UefiPayloadPkg/BlSupportPei/BlSupportPei.c  | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
> b/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
> index fe783fe5e14c..043b748ae4a9 100644
> --- a/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
> +++ b/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
> @@ -24,6 +24,7 @@ typedef struct {
>UINT64 PmTimerRegBase;
> 
>UINT64 ResetRegAddress;
> 
>UINT64 PcieBaseAddress;
> 
> +  UINT64 PcieBaseSize;
> 
>  } ACPI_BOARD_INFO;
> 
> 
> 
>  #endif
> 
> diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> index 22972453117a..a7e99f9ec6de 100644
> --- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> +++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
> @@ -240,8 +240,10 @@ Done:
>if (MmCfgHdr != NULL) {
> 
>  MmCfgBase =
> (EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_AD
> DRESS_ALLOCATION_STRUCTURE *)((UINT8*) MmCfgHdr + sizeof
> (*MmCfgHdr));
> 
>  AcpiBoardInfo->PcieBaseAddress = MmCfgBase->BaseAddress;
> 
> +AcpiBoardInfo->PcieBaseSize = (MmCfgBase->EndBusNumber + 1 -
> MmCfgBase->StartBusNumber) * 4096 * 32 * 8;
> 
>} else {
> 
>  AcpiBoardInfo->PcieBaseAddress = 0;
> 
> +AcpiBoardInfo->PcieBaseSize = 0;
> 
>}
> 
>DEBUG ((DEBUG_INFO, "PmCtrl  Reg 0x%lx\n",  AcpiBoardInfo-
> >PmCtrlRegBase));
> 
>DEBUG ((DEBUG_INFO, "PmTimer Reg 0x%lx\n",  AcpiBoardInfo-
> >PmTimerRegBase));
> 
> @@ -250,6 +252,7 @@ Done:
>DEBUG ((DEBUG_INFO, "PmEvt   Reg 0x%lx\n",  AcpiBoardInfo->PmEvtBase));
> 
>DEBUG ((DEBUG_INFO, "PmGpeEn Reg 0x%lx\n",  AcpiBoardInfo-
> >PmGpeEnBase));
> 
>DEBUG ((DEBUG_INFO, "PcieBaseAddr 0x%lx\n", AcpiBoardInfo-
> >PcieBaseAddress));
> 
> +  DEBUG ((DEBUG_INFO, "PcieBaseSize 0x%lx\n", AcpiBoardInfo-
> >PcieBaseSize));
> 
> 
> 
>//
> 
>// Verify values for proper operation
> 
> --
> 2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63345): https://edk2.groups.io/g/devel/message/63345
Mute This Topic: https://groups.io/mt/75818419/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Hi Laszlo,

Thank you for valuable comments, I did not realize TimerLib should not be
used at all for ShellPkg.
I will remove -m option for now and then will replace with gRT time
functions.
> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, July 27, 2020 1:39 AM
> To: vladimir.olovyanni...@broadcom.com; Zhichao Gao
> ; Ray Ni 
> Cc: devel@edk2.groups.io; Samer El-Haj-Mahmoud  mahm...@arm.com>; Maciej Rabeda ;
> Jiaxin Wu ; Siyuan Fu ; Liming
> Gao ; Nd 
> Subject: Re: [edk2-devel] [PATCH v4 0/1] ShellPkg/DynamicCommand: add
> HttpDynamicCommand
>
> Hi Vladimir,
>
> On 07/23/20 22:50, Vladimir Olovyannikov via groups.io wrote:
> > Signed-off-by: Vladimir Olovyannikov
> > 
> > Tested-By: Samer El-Haj-Mahmoud 
> > Tested-By: Laszlo Ersek 
> > Cc: Zhichao Gao 
> > Cc: Maciej Rabeda 
> > Cc: Jiaxin Wu 
> > Cc: Siyuan Fu 
> > Cc: Ray Ni 
> > Cc: Liming Gao 
> > Cc: Nd 
> >
> > This patchset introduces an http client utilizing EDK2 HTTP protocol,
> > to allow fast image downloading from http/https servers.
> > HTTP download speed is usually faster than tftp.
> > The client is based on the same approach as tftp dynamic command, and
> > uses the same UEFI Shell command line parameters. This makes it easy
> > integrating http into existing UEFI Shell scripts.
> > Note that to enable HTTP download, feature Pcd
> > gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to
> TRUE.
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
> >
> > PATCH v4 changes:
> > Address comments based on Laszlo's testing:
> >  - Fix .uni help file missing "\r\n" before RETURNVALUES section;
> >  - delete the downloaded file in case of an error, unless
> >-k ("keep bad") option is provided on command line.
> >
> > Allow download time measurement in seconds by providing -m parameter
> > on command line.
>
> (1) "Tested-by" tags cannot be carried forward on a patch if there are any
> changes to the patch. If you update a patch and people would like to have
> their T-b's on the patch, then they'll have to retest the patch. So every
> time
> you update a patch, please drop the previously given Tested-by tags from
> it.
>
>
OK,
> (2) I was about to retest this patch, but I also compared it with the
> previous
> version (v3). I think the "-m" option should not be added, for now anyway.
> For two reasons:
>
> - The patch is already large, and I think there has been no ShellPkg
>   reviewer / maintainer feedback so far. I think we shouldn't make the
>   patch even larger, with new features. "-m" looks like an addition that
>   can be done separately, once the core feature is upstream.
OK, makes sense.
>
>   (I consider "-k" a bugfix on the other hand. More precisely, I
>   consider the new behavior *without "-k"* a bugfix. So I certainly
>   welcome that.)
>
> - The other reason is that the "-m" feature seems to introduce a
>   TimerLib dependency. Depending on TimerLib in a shell application is
>   wrong, IMO; in particular because this application / dynamic command
>   is extremely useful, so some people might easily want to download a
>   pre-built binary, and run it on their system for whatever purposes.
>   But TimerLib is platform-dependent, and that would break this binary
>   portability.
>
>   For some more background, please refer to commit 7a141b1306f6
>   ("ShellPkg: remove superfluous TimerLib resolution", 2018-02-13).
I read it, thanks. Now I understand the complications.
>
>
> ... In fact, upon re-reading the above commit, I'm realizing the current
> patch
> could break the "ShellPkg.dsc" build, because the patch
> (incorrectly) introduces a TimerLib dependency in a ShellPkg module, but
> "ShellPkg.dsc" (correctly) does not resolve the TimerLib class to any
> instance.
>
> And it does break:
>
> $ build -a X64 -b NOOPT -t GCC48 -p ShellPkg/ShellPkg.dsc
>
> > ShellPkg/ShellPkg.dsc(...): error 4000: Instance of library class
> > [TimerLib] is
> not found
> > in
> [ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicComman
> d.inf] [X64]
> > consumed by module
> >
> [ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicComman
> d.inf]
>
> One consequence of the above is that this patch would not pass a CI build.
>
>
> ... Another reason this patch would not pass a CI build is a
> "PatchCheck.py"
> failure:
>
> > ShellPkg/DynamicCommand: add HttpDynamicCommand The commit
> message
> > format is not valid:
> >  * 'Tested-By' should be 'Tested-by'
> >  * 'Tested-By' should be 'Tested-by'
> > https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-F
> > ormat
> > The code passed all checks.
>
> (Side comment: please use the clipboard for cutting and pasting feedback
> tags from emails to commit messages. I have a keyboard shortcut for
> inserting "Tested-by: Laszlo Ersek ", and so I know for
> a fact that I never send an upper-case "By".)
OK, will do.
>
> I suggest running a personal CI build on github.com before submitting the
> patch to the list (just open a 

[edk2-devel] [PATCH v12 36/46] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.

Add exception handling support to the early reset vector code to catch
these exceptions.  Also, since the guest is in 32-bit mode at this point,
writes to the GHCB will be encrypted and thus not able to be read by the
hypervisor, so use the GHCB CPUID request/response protocol to obtain the
requested CPUID function values and provide these to the guest.

The exception handling support is active during the SEV check and uses the
OVMF temporary RAM space for a stack. After the SEV check is complete, the
exception handling support is removed and the stack pointer cleared.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/ResetVector/ResetVector.inf   |   3 +
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 275 +-
 OvmfPkg/ResetVector/ResetVector.nasmb |   2 +
 3 files changed, 277 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 483fd90fe785..a53ae6c194ae 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -34,9 +34,12 @@ [BuildOptions]
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
 
 [Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 9f86ddf6f08f..7c72128a84d6 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -36,13 +36,58 @@ BITS32
PAGE_READ_WRITE + \
PAGE_PRESENT)
 
+;
+; SEV-ES #VC exception handler support
+;
+; #VC handler local variable locations
+;
+%define VC_CPUID_RESULT_EAX 0
+%define VC_CPUID_RESULT_EBX 4
+%define VC_CPUID_RESULT_ECX 8
+%define VC_CPUID_RESULT_EDX12
+%define VC_GHCB_MSR_EDX16
+%define VC_GHCB_MSR_EAX20
+%define VC_CPUID_REQUEST_REGISTER  24
+%define VC_CPUID_FUNCTION  28
+
+; #VC handler total local variable size
+;
+%define VC_VARIABLE_SIZE   32
+
+; #VC handler GHCB CPUID request/response protocol values
+;
+%define GHCB_CPUID_REQUEST  4
+%define GHCB_CPUID_RESPONSE 5
+%define GHCB_CPUID_REGISTER_SHIFT  30
+%define CPUID_INSN_LEN  2
+
+
 ; Check if Secure Encrypted Virtualization (SEV) feature is enabled
 ;
-; If SEV is enabled then EAX will be at least 32
+; Modified:  EAX, EBX, ECX, EDX, ESP
+;
+; If SEV is enabled then EAX will be at least 32.
 ; If SEV is disabled then EAX will be zero.
 ;
 CheckSevFeature:
+; Set the first byte of the workarea to zero to communicate to the SEC
+; phase that SEV-ES is not enabled. If SEV-ES is enabled, the CPUID
+; instruction will trigger a #VC exception where the first byte of the
+; workarea will be set to one.
+mov byte[SEV_ES_WORK_AREA], 0
+
+;
+; Set up exception handlers to check for SEV-ES
+;   Load temporary RAM stack based on PCDs (see SevEsIdtVmmComm for
+;   stack usage)
+;   Establish exception handlers
+;
+mov   esp, SEV_ES_VC_TOP_OF_STACK
+mov   eax, ADDR_OF(Idtr)
+lidt  [cs:eax]
+
 ; Check if we have a valid (0x8000_001F) CPUID leaf
+;   CPUID raises a #VC exception if running as an SEV-ES guest
 mov   eax, 0x8000
 cpuid
 
@@ -53,8 +98,8 @@ CheckSevFeature:
 jlNoSev
 
 ; Check for memory encryption feature:
-;  CPUID  Fn8000_001F[EAX] - Bit 1
-;
+; CPUID  Fn8000_001F[EAX] - Bit 1
+;   CPUID raises a #VC exception if running as an SEV-ES guest
 mov   eax,  0x801f
 cpuid
 bteax, 1
@@ -78,6 +123,15 @@ NoSev:
 xor   eax, eax
 
 SevExit:
+;
+; Clear exception handlers and stack
+;
+push  eax
+mov   eax, ADDR_OF(IdtrClear)
+lidt  [cs:eax]
+pop   eax
+mov   esp, 0
+
 OneTimeCallRet CheckSevFeature
 
 ; Check if Secure Encrypted Virtualization - Encrypted State (SEV-ES) feature
@@ -222,3 +276,218 @@ SetCr3:
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
+
+;
+; Start of #VC exception handling routines
+;
+
+SevEsIdtNotCpuid:
+;
+; Use VMGEXIT to request termination.
+;   1 

[edk2-devel] [PATCH v12 33/46] UefiCpuPkg: Create an SEV-ES workarea PCD

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Create an SEV-ES workarea PCD. This PCD will be used for BSP communication
during SEC and for AP startup during PEI and DXE phases, the latter is the
reason for creating it in the UefiCpuPkg.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/UefiCpuPkg.dec | 8 
 UefiCpuPkg/UefiCpuPkg.uni | 8 
 2 files changed, 16 insertions(+)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index cb92f34b6f55..8c614f9b42bd 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -161,6 +161,14 @@ [PcdsFixedAtBuild]
   # @Prompt Specify the count of pre allocated SMM MP tokens per chunk.
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmMpTokenCountPerChunk|64|UINT32|0x30002002
 
+  ## Area of memory where the SEV-ES work area block lives.
+  # @Prompt Configure the SEV-ES work area base
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|0x0|UINT32|0x30002005
+
+  ## Size of teh area of memory where the SEV-ES work area block lives.
+  # @Prompt Configure the SEV-ES work area base
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize|0x0|UINT32|0x30002006
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## This value is the CPU Local APIC base address, which aligns the address 
on a 4-KByte boundary.
   # @Prompt Configure base address of CPU Local APIC
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index f4a0c72f6293..219c1963bf08 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -281,3 +281,11 @@
 
 #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsIsEnabled_PROMPT  #language 
en-US "Specifies whether SEV-ES is enabled"
 #string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsIsEnabled_HELP#language 
en-US "Set to TRUE when running as an SEV-ES guest, FALSE otherwise."
+
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaBase_PROMPT  #language 
en-US "Specify the address of the SEV-ES work area"
+
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsWorkAreaBase_HELP#language 
en-US "Specifies the address of the work area used by an SEV-ES guest."
+
+#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."
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63337): https://edk2.groups.io/g/devel/message/63337
Mute This Topic: https://groups.io/mt/75825061/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 35/46] OvmfPkg/PlatformPei: Reserve SEV-ES work area if S3 is supported

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Protect the SEV-ES work area memory used by an SEV-ES guest.

Regarding the lifecycle of the SEV-ES memory area:
  PcdSevEsWorkArea

(a) when and how it is initialized after first boot of the VM

  If SEV-ES is enabled, the SEV-ES area is initialized during
  the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].

(b) how it is protected from memory allocations during DXE

  If SEV-ES is enabled, then InitializeRamRegions()
  [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either
  an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory
  allocation HOB, in PEI.

(c) how it is protected from the OS

  If S3 is enabled, then (b) reserves it from the OS too.

  If S3 is disabled, then the range needs no protection.

(d) how it is accessed on the S3 resume path

  It is rewritten same as in (a), which is fine because (b) reserved it.

(e) how it is accessed on the warm reset path

  It is rewritten same as in (a).

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
 OvmfPkg/PlatformPei/MemDetect.c | 20 
 2 files changed, 22 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 4742e1bdf42b..c53be2f4925c 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -118,6 +118,8 @@ [FixedPcd]
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
 
 [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 6b5fee166b5d..ffbbef891a11 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -940,5 +940,25 @@ InitializeRamRegions (
   );
   }
 }
+
+#ifdef MDE_CPU_X64
+if (MemEncryptSevEsIsEnabled ()) {
+  //
+  // If SEV-ES is enabled, reserve the SEV-ES work area.
+  //
+  // Since this memory range will be used by the Reset Vector on S3
+  // resume, it must be reserved as ACPI NVS.
+  //
+  // If S3 is unsupported, then various drivers might still write to the
+  // work area. We ought to prevent DXE from serving allocation requests
+  // such that they would overlap the work area.
+  //
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) FixedPcdGet32 (PcdSevEsWorkAreaBase),
+(UINT64)(UINTN) FixedPcdGet32 (PcdSevEsWorkAreaSize),
+mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+);
+}
+#endif
   }
 }
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63339): https://edk2.groups.io/g/devel/message/63339
Mute This Topic: https://groups.io/mt/75825064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 37/46] OvmfPkg/Sec: Add #VC exception handling for Sec phase

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

An SEV-ES guest will generate a #VC exception when it encounters a
non-automatic exit (NAE) event. It is expected that the #VC exception
handler will communicate with the hypervisor using the GHCB to handle
the NAE event.

NAE events can occur during the Sec phase, so initialize exception
handling early in the OVMF Sec support.

Before establishing the exception handling, validate that the supported
version of the SEV-ES protocol in OVMF is supported by the hypervisor.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Sec/SecMain.inf |   4 +
 OvmfPkg/Sec/SecMain.c   | 181 +---
 2 files changed, 172 insertions(+), 13 deletions(-)

diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index 63ba4cb555fb..7f78dcee2772 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -50,15 +50,19 @@ [LibraryClasses]
   PeCoffExtraActionLib
   ExtractGuidedSectionLib
   LocalApicLib
+  CpuExceptionHandlerLib
 
 [Ppis]
   gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED
 
 [Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 6dea6e771a29..c2a35463dce4 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -34,6 +37,10 @@ typedef struct _SEC_IDT_TABLE {
   IA32_IDT_GATE_DESCRIPTOR  IdtTable[SEC_IDT_ENTRY_COUNT];
 } SEC_IDT_TABLE;
 
+typedef struct _SEC_SEV_ES_WORK_AREA {
+  UINT8  SevEsEnabled;
+} SEC_SEV_ES_WORK_AREA;
+
 VOID
 EFIAPI
 SecStartupPhase2 (
@@ -712,6 +719,120 @@ FindAndReportEntryPoints (
   return;
 }
 
+/**
+  Handle an SEV-ES/GHCB protocol check failure.
+
+  Notify the hypervisor using the VMGEXIT instruction that the SEV-ES guest
+  wishes to be terminated.
+
+  @param[in] ReasonCode  Reason code to provide to the hypervisor for the
+ termination request.
+
+**/
+STATIC
+VOID
+SevEsProtocolFailure (
+  IN UINT8  ReasonCode
+  )
+{
+  MSR_SEV_ES_GHCB_REGISTER  Msr;
+
+  //
+  // Use the GHCB MSR Protocol to request termination by the hypervisor
+  //
+  Msr.GhcbPhysicalAddress = 0;
+  Msr.GhcbTerminate.Function = GHCB_INFO_TERMINATE_REQUEST;
+  Msr.GhcbTerminate.ReasonCodeSet = GHCB_TERMINATE_GHCB;
+  Msr.GhcbTerminate.ReasonCode = ReasonCode;
+  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
+
+  AsmVmgExit ();
+
+  ASSERT (FALSE);
+  CpuDeadLoop ();
+}
+
+/**
+  Validate the SEV-ES/GHCB protocol level.
+
+  Verify that the level of SEV-ES/GHCB protocol supported by the hypervisor
+  and the guest intersect. If they don't intersect, request termination.
+
+**/
+STATIC
+VOID
+SevEsProtocolCheck (
+  VOID
+  )
+{
+  MSR_SEV_ES_GHCB_REGISTER  Msr;
+  GHCB  *Ghcb;
+
+  //
+  // Use the GHCB MSR Protocol to obtain the GHCB SEV-ES Information for
+  // protocol checking
+  //
+  Msr.GhcbPhysicalAddress = 0;
+  Msr.GhcbInfo.Function = GHCB_INFO_SEV_INFO_GET;
+  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
+
+  AsmVmgExit ();
+
+  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
+
+  if (Msr.GhcbInfo.Function != GHCB_INFO_SEV_INFO) {
+SevEsProtocolFailure (GHCB_TERMINATE_GHCB_GENERAL);
+  }
+
+  if (Msr.GhcbProtocol.SevEsProtocolMin > Msr.GhcbProtocol.SevEsProtocolMax) {
+SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
+  }
+
+  if ((Msr.GhcbProtocol.SevEsProtocolMin > GHCB_VERSION_MAX) ||
+  (Msr.GhcbProtocol.SevEsProtocolMax < GHCB_VERSION_MIN)) {
+SevEsProtocolFailure (GHCB_TERMINATE_GHCB_PROTOCOL);
+  }
+
+  //
+  // SEV-ES protocol checking succeeded, set the initial GHCB address
+  //
+  Msr.GhcbPhysicalAddress = FixedPcdGet32 (PcdOvmfSecGhcbBase);
+  AsmWriteMsr64 (MSR_SEV_ES_GHCB, Msr.GhcbPhysicalAddress);
+
+  Ghcb = Msr.Ghcb;
+  SetMem (Ghcb, sizeof (*Ghcb), 0);
+
+  //
+  // Set the version to the maximum that can be supported
+  //
+  Ghcb->ProtocolVersion = MIN (Msr.GhcbProtocol.SevEsProtocolMax, 
GHCB_VERSION_MAX);
+  Ghcb->GhcbUsage = GHCB_STANDARD_USAGE;
+}
+
+/**
+  Determine if SEV-ES is active.
+
+  During early booting, SEV-ES support code will set a flag to indicate that
+  SEV-ES is enabled. Return the value of this flag as an indicator that SEV-ES
+  is enabled.
+
+  @retval TRUE   SEV-ES is enabled
+  @retval FALSE  SEV-ES is not 

[edk2-devel] [PATCH v12 34/46] OvmfPkg: Reserve a page in memory for the SEV-ES usage

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.

This area will be used by SEV-ES support for two purposes:
  1. Communicating the SEV-ES status during BSP boot to SEC:
 Using a byte of memory from the page, the BSP reset vector code can
 communicate the SEV-ES status to SEC for use before exception
 handling can be enabled in SEC. After SEC, this field is no longer
 valid and the standard way of determine if SEV-ES is active should
 be used.

  2. Establishing an area of memory for AP boot support:
 A hypervisor is not allowed to update an SEV-ES guest's register
 state, so when booting an SEV-ES guest AP, the hypervisor is not
 allowed to set the RIP to the guest requested value. Instead an
 SEV-ES AP must be re-directed from within the guest to the actual
 requested staring location as specified in the INIT-SIPI-SIPI
 sequence.

 Use this memory for reset vector code that can be programmed to have
 the AP jump to the desired RIP location after starting the AP. This
 is required for only the very first AP reset.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgX64.fdf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index edb03b5464d4..8da59037e5f0 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -82,6 +82,9 @@ [FD.MEMFD]
 0x009000|0x002000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
 
+0x00B000|0x001000
+gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63338): https://edk2.groups.io/g/devel/message/63338
Mute This Topic: https://groups.io/mt/75825063/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 38/46] OvmfPkg/Sec: Enable cache early to speed up booting

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Currently, the OVMF code relies on the hypervisor to enable the cache
support on the processor in order to improve the boot speed. However,
with SEV-ES, the hypervisor is not allowed to change the CR0 register
to enable caching.

Update the OVMF Sec support to enable caching in order to improve the
boot speed when running as an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Sec/SecMain.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index c2a35463dce4..271a06348ed8 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -905,6 +905,13 @@ SecCoreStartupWithStack (
 // For non SEV-ES guests, just load the IDTR.
 //
 AsmWriteIdtr ();
+  } else {
+//
+// Under SEV-ES, the hypervisor can't modify CR0 and so can't enable
+// caching in order to speed up the boot. Enable caching early for
+// an SEV-ES guest.
+//
+AsmEnableCache ();
   }
 
   DEBUG ((DEBUG_INFO,
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63342): https://edk2.groups.io/g/devel/message/63342
Mute This Topic: https://groups.io/mt/75825076/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 39/46] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check may result in an infinite nested page fault
because of the attempted write. Since the instruction cannot be emulated
when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
nested page faults.

When SEV-ES is enabled, exit the flash detection early and assume that
the FD behaves as Flash. This will result in QemuFlashWrite() being called
to store EFI variables, which will also result in an infinite nested page
fault when the write is performed. In this case, update QemuFlashWrite()
to use the VMGEXIT MMIO write support to have the hypervisor perform the
write without having to emulate the instruction.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../FvbServicesRuntimeDxe.inf |  2 +
 .../QemuFlash.h   | 13 ++
 .../QemuFlash.c   | 23 +--
 .../QemuFlashDxe.c| 40 +++
 .../QemuFlashSmm.c| 16 
 5 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index 72cabba4357d..8bb2325157ea 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -38,6 +38,7 @@ [Sources]
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
@@ -52,6 +53,7 @@ [LibraryClasses]
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   UefiRuntimeLib
+  VmgExitLib
 
 [Guids]
   gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
index f1afabcbe6ae..219d0d6e83cf 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
@@ -89,5 +89,18 @@ QemuFlashBeforeProbe (
   IN  UINTN   FdBlockCount
   );
 
+/**
+  Write to QEMU Flash
+
+  @param[in] PtrPointer to the location to write.
+  @param[in] Value  The value to write.
+
+**/
+VOID
+QemuFlashPtrWrite (
+  INvolatile UINT8*Ptr,
+  INUINT8 Value
+  );
+
 #endif
 
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index 1b0d6c053f1a..0d29bf701aca 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "QemuFlash.h"
@@ -80,6 +81,21 @@ QemuFlashDetected (
 
   DEBUG ((DEBUG_INFO, "QEMU Flash: Attempting flash detection at %p\n", Ptr));
 
+  if (MemEncryptSevEsIsEnabled ()) {
+//
+// When SEV-ES is enabled, the check below can result in an infinite
+// loop with respect to a nested page fault. When the memslot is mapped
+// read-only, the nested page table entry is read-only. The check below
+// will cause a nested page fault that cannot be emulated, causing
+// the instruction to retried over and over. For SEV-ES, acknowledge that
+// the FD appears as ROM and not as FLASH, but report FLASH anyway because
+// FLASH behavior can be simulated using VMGEXIT.
+//
+DEBUG ((DEBUG_INFO,
+  "QEMU Flash: SEV-ES enabled, assuming FD behaves as FLASH\n"));
+return TRUE;
+  }
+
   OriginalUint8 = *Ptr;
   *Ptr = CLEAR_STATUS_CMD;
   ProbeUint8 = *Ptr;
@@ -181,8 +197,9 @@ QemuFlashWrite (
   //
   Ptr = QemuFlashPtr (Lba, Offset);
   for (Loop = 0; Loop < *NumBytes; Loop++) {
-*Ptr = WRITE_BYTE_CMD;
-*Ptr = Buffer[Loop];
+QemuFlashPtrWrite (Ptr, WRITE_BYTE_CMD);
+QemuFlashPtrWrite (Ptr, Buffer[Loop]);
+
 Ptr++;
   }
 
@@ -190,7 +207,7 @@ QemuFlashWrite (
   // Restore flash to read mode
   //
   if (*NumBytes > 0) {
-*(Ptr - 1) = READ_ARRAY_CMD;
+QemuFlashPtrWrite (Ptr - 1, READ_ARRAY_CMD);
   }
 
   return EFI_SUCCESS;
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
index 5aabe9d7b59c..565383ee26d2 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
@@ -10,6 +10,9 @@
 **/
 
 #include 
+#include 
+#include 
+#include 
 
 #include "QemuFlash.h"
 
@@ -32,3 +35,40 @@ QemuFlashBeforeProbe (
   // Do nothing
   //
 }
+
+/**
+  Write to QEMU Flash
+
+  @param[in] PtrPointer to the 

[edk2-devel] [PATCH v12 31/46] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Allocate memory for the GHCB pages and the per-CPU variable pages during
SEV initialization for use during Pei and Dxe phases. The GHCB page(s)
must be shared pages, so clear the encryption mask from the current page
table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase
and PcdGhcbSize).

The per-CPU variable page needs to be unique per AP. Using the page after
the GHCB ensures that it is unique per AP. Only the GHCB page is marked as
shared, keeping the per-CPU variable page encyrpted. The same logic is
used in DXE using CreateIdentityMappingPageTables() before switching to
the DXE pagetables.

The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC
exception handlers. The #VC exception handler will fill in the necessary
fields of the GHCB and exit to the hypervisor using the VMGEXIT
instruction. The hypervisor then accesses the GHCB associated with the
vCPU in order to perform the requested function.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
 OvmfPkg/PlatformPei/AmdSev.c| 45 -
 5 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f84f23f250ef..133a9a93c071 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -608,6 +608,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a66abccf8266..338c38db29b5 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -620,6 +620,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2a8975fd3d29..b80710fbdca4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -618,6 +618,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index a54d10ba90d5..4742e1bdf42b 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -102,6 +102,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 4dc5340caa7a..4fd4534cabea 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -10,12 +10,15 @@
 // The package level header files this module uses
 //
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -32,7 +35,10 @@ AmdSevEsInitialize (
   VOID
   )
 {
-  RETURN_STATUS PcdStatus;
+  VOID  *GhcbBase;
+  PHYSICAL_ADDRESS  GhcbBasePa;
+  UINTN GhcbPageCount, PageCount;
+  RETURN_STATUS PcdStatus, DecryptStatus;
 
   if (!MemEncryptSevEsIsEnabled ()) {
 return;
@@ -40,6 +46,43 @@ AmdSevEsInitialize (
 
   PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
   ASSERT_RETURN_ERROR (PcdStatus);
+
+  //
+  // Allocate GHCB and per-CPU variable pages.
+  //
+  GhcbPageCount = mMaxCpuCount * 2;
+  GhcbBase = AllocatePages (GhcbPageCount);
+  ASSERT (GhcbBase != NULL);
+
+  GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
+
+  //
+  // Each vCPU gets two consecutive pages, the first is the GHCB and the
+  // second is the per-CPU variable page. Loop through the allocation and
+  // only clear the encryption mask for the GHCB pages.
+  //
+  for (PageCount = 0; PageCount < GhcbPageCount; PageCount += 2) {
+DecryptStatus = MemEncryptSevClearPageEncMask (
+  0,
+  

[edk2-devel] [PATCH v12 29/46] OvmfPkg: Create a GHCB page for use during Sec phase

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.

Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.

The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.

Four new fixed PCDs are needed to support the SEC GHCB page:
  - PcdOvmfSecGhcbBase  UINT32 value that is the base address of the
GHCB used during the SEC phase.
  - PcdOvmfSecGhcbSize  UINT32 value that is the size, in bytes, of the
GHCB area used during the SEC phase.

  - PcdOvmfSecGhcbPageTableBase  UINT32 value that is address of a page
table page used to break down the 2MB page into
512 4K pages.
  - PcdOvmfSecGhcbPageTableSize  UINT32 value that is the size, in bytes,
of the page table page.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkg.dec   |  9 +++
 OvmfPkg/OvmfPkgX64.fdf|  6 ++
 OvmfPkg/ResetVector/ResetVector.inf   |  5 ++
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 76 +++
 OvmfPkg/ResetVector/ResetVector.nasmb | 17 +
 5 files changed, 113 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f16c00ad5b99..74d88f61617c 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -289,6 +289,15 @@ [PcdsFixedAtBuild]
   ## Number of page frames to use for storing grant table entries.
   gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
 
+  ## Specify the extra page table needed to mark the GHCB as unencrypted.
+  #  The value should be a multiple of 4KB for each.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|0x0|UINT32|0x3e
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize|0x0|UINT32|0x3f
+
+  ## The base address of the SEC GHCB page used by SEV-ES.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x40
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x41
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 83ff6aef2e8c..edb03b5464d4 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -76,6 +76,12 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
+
+0x009000|0x002000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index b0ddfa5832a2..483fd90fe785 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -26,6 +26,7 @@ [Sources]
 [Packages]
   OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
@@ -33,5 +34,9 @@ [BuildOptions]
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
 
 [Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index abad009f20f5..9f86ddf6f08f 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -21,6 +21,11 @@ BITS32
 %define PAGE_2M_MBO0x080
 %define PAGE_2M_PAT  0x01000
 
+%define PAGE_4K_PDE_ATTR (PAGE_ACCESSED + \
+  PAGE_DIRTY + \
+  

[edk2-devel] [PATCH v12 28/46] OvmfPkg: Add support to perform SEV-ES initialization

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

When SEV-ES is enabled, then SEV is also enabled. Add support to the SEV
initialization function to also check for SEV-ES being enabled, and if
enabled, set the SEV-ES enabled PCD (PcdSevEsIsEnabled).

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc |  3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  3 +++
 OvmfPkg/OvmfPkgX64.dsc  |  3 +++
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 OvmfPkg/PlatformPei/AmdSev.c| 26 ++
 5 files changed, 36 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index c57bba1ba197..f84f23f250ef 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -607,6 +607,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 22e930b12b9b..a66abccf8266 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -619,6 +619,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 60be5eae3d2b..2a8975fd3d29 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -617,6 +617,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index ff397b3ee9d7..00feb96c9308 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -103,6 +103,7 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled
 
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index e484f4b311fe..4dc5340caa7a 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -21,6 +21,27 @@
 
 #include "Platform.h"
 
+/**
+
+  Initialize SEV-ES support if running as an SEV-ES guest.
+
+  **/
+STATIC
+VOID
+AmdSevEsInitialize (
+  VOID
+  )
+{
+  RETURN_STATUS PcdStatus;
+
+  if (!MemEncryptSevEsIsEnabled ()) {
+return;
+  }
+
+  PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
+  ASSERT_RETURN_ERROR (PcdStatus);
+}
+
 /**
 
   Function checks if SEV support is available, if present then it sets
@@ -103,4 +124,9 @@ AmdSevInitialize (
 );
 }
   }
+
+  //
+  // Check and perform SEV-ES initialization if required.
+  //
+  AmdSevEsInitialize ();
 }
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63332): https://edk2.groups.io/g/devel/message/63332
Mute This Topic: https://groups.io/mt/75825046/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 30/46] OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supported

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Protect the memory used by an SEV-ES guest when S3 is supported. This
includes the page table used to break down the 2MB page that contains
the GHCB so that it can be marked un-encrypted, as well as the GHCB
area.

Regarding the lifecycle of the GHCB-related memory areas:
  PcdOvmfSecGhcbPageTableBase
  PcdOvmfSecGhcbBase

(a) when and how it is initialized after first boot of the VM

  If SEV-ES is enabled, the GHCB-related areas are initialized during
  the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].

(b) how it is protected from memory allocations during DXE

  If S3 and SEV-ES are enabled, then InitializeRamRegions()
  [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
  memory allocation HOB, in PEI.

  If S3 is disabled, then these ranges are not protected. DXE's own page
  tables are first built while still in PEI (see HandOffToDxeCore()
  [MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are
  located in permanent PEI memory. After CR3 is switched over to them
  (which occurs before jumping to the DXE core entry point), we don't have
  to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in
  permanent PEI memory and DXE will use these PEI GHCB pages, so we don't
  have to preserve PcdOvmfSecGhcbBase.

(c) how it is protected from the OS

  If S3 is enabled, then (b) reserves it from the OS too.

  If S3 is disabled, then the range needs no protection.

(d) how it is accessed on the S3 resume path

  It is rewritten same as in (a), which is fine because (b) reserved it.

(e) how it is accessed on the warm reset path

  It is rewritten same as in (a).

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  4 
 OvmfPkg/PlatformPei/MemDetect.c | 23 +++
 2 files changed, 27 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 00feb96c9308..a54d10ba90d5 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -75,6 +75,10 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 3b46ea431ade..6b5fee166b5d 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -27,6 +27,7 @@ Module Name:
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -866,6 +867,28 @@ InitializeRamRegions (
   (UINT64)(UINTN) PcdGet32 (PcdOvmfSecPageTablesSize),
   EfiACPIMemoryNVS
   );
+
+if (MemEncryptSevEsIsEnabled ()) {
+  //
+  // If SEV-ES is enabled, reserve the GHCB-related memory area. This
+  // includes the extra page table used to break down the 2MB page
+  // mapping into 4KB page entries where the GHCB resides and the
+  // GHCB area itself.
+  //
+  // Since this memory range will be used by the Reset Vector on S3
+  // resume, it must be reserved as ACPI NVS.
+  //
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfSecGhcbPageTableBase),
+(UINT64)(UINTN) PcdGet32 (PcdOvmfSecGhcbPageTableSize),
+EfiACPIMemoryNVS
+);
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfSecGhcbBase),
+(UINT64)(UINTN) PcdGet32 (PcdOvmfSecGhcbSize),
+EfiACPIMemoryNVS
+);
+}
 #endif
   }
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63334): https://edk2.groups.io/g/devel/message/63334
Mute This Topic: https://groups.io/mt/75825052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 27/46] OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator function

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Create a function that can be used to determine if the VM is running
as an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Include/Library/MemEncryptSevLib.h| 12 +++
 .../MemEncryptSevLibInternal.c| 75 ---
 2 files changed, 60 insertions(+), 27 deletions(-)

diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
b/OvmfPkg/Include/Library/MemEncryptSevLib.h
index 64dd6977b0f8..a50a0de9c870 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -13,6 +13,18 @@
 
 #include 
 
+/**
+  Returns a boolean to indicate whether SEV-ES is enabled
+
+  @retval TRUE   SEV-ES is enabled
+  @retval FALSE  SEV-ES is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsIsEnabled (
+  VOID
+  );
+
 /**
   Returns a boolean to indicate whether SEV is enabled
 
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
index 96a66e373f11..3301c5c2862f 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
@@ -20,19 +20,17 @@
 #include 
 
 STATIC BOOLEAN mSevStatus = FALSE;
+STATIC BOOLEAN mSevEsStatus = FALSE;
 STATIC BOOLEAN mSevStatusChecked = FALSE;
 
 /**
+  Reads and sets the status of SEV features
 
-  Returns a boolean to indicate whether SEV is enabled
-
-  @retval TRUE   SEV is enabled
-  @retval FALSE  SEV is not enabled
   **/
 STATIC
-BOOLEAN
+VOID
 EFIAPI
-InternalMemEncryptSevIsEnabled (
+InternalMemEncryptSevStatus (
   VOID
   )
 {
@@ -56,32 +54,55 @@ InternalMemEncryptSevIsEnabled (
   //
   Msr.Uint32 = AsmReadMsr32 (MSR_SEV_STATUS);
   if (Msr.Bits.SevBit) {
-return TRUE;
+mSevStatus = TRUE;
+  }
+
+  //
+  // Check MSR_0xC0010131 Bit 1 (Sev-Es Enabled)
+  //
+  if (Msr.Bits.SevEsBit) {
+mSevEsStatus = TRUE;
   }
 }
   }
 
-  return FALSE;
-}
-
-/**
-  Returns a boolean to indicate whether SEV is enabled
-
-  @retval TRUE   SEV is enabled
-  @retval FALSE  SEV is not enabled
-**/
-BOOLEAN
-EFIAPI
-MemEncryptSevIsEnabled (
-  VOID
-  )
-{
-  if (mSevStatusChecked) {
-return mSevStatus;
-  }
-
-  mSevStatus = InternalMemEncryptSevIsEnabled();
   mSevStatusChecked = TRUE;
+}
+
+/**
+  Returns a boolean to indicate whether SEV-ES is enabled
+
+  @retval TRUE   SEV-ES is enabled
+  @retval FALSE  SEV-ES is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsIsEnabled (
+  VOID
+  )
+{
+  if (!mSevStatusChecked) {
+InternalMemEncryptSevStatus ();
+  }
+
+  return mSevEsStatus;
+}
+
+/**
+  Returns a boolean to indicate whether SEV is enabled
+
+  @retval TRUE   SEV is enabled
+  @retval FALSE  SEV is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevIsEnabled (
+  VOID
+  )
+{
+  if (!mSevStatusChecked) {
+InternalMemEncryptSevStatus ();
+  }
 
   return mSevStatus;
 }
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63331): https://edk2.groups.io/g/devel/message/63331
Mute This Topic: https://groups.io/mt/75825043/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 32/46] OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enabled

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

The SEV support will clear the C-bit from non-RAM areas.  The early GDT
lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
will be read as un-encrypted even though it is encrypted. This will result
in a failure to be able to handle the exception.

Move the GDT into RAM so it can be accessed without error when running as
an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/AmdSev.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 4fd4534cabea..a2b38c591236 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -39,6 +39,8 @@ AmdSevEsInitialize (
   PHYSICAL_ADDRESS  GhcbBasePa;
   UINTN GhcbPageCount, PageCount;
   RETURN_STATUS PcdStatus, DecryptStatus;
+  IA32_DESCRIPTOR   Gdtr;
+  VOID  *Gdt;
 
   if (!MemEncryptSevEsIsEnabled ()) {
 return;
@@ -83,6 +85,22 @@ AmdSevEsInitialize (
 (UINT64)GhcbPageCount, GhcbBase));
 
   AsmWriteMsr64 (MSR_SEV_ES_GHCB, GhcbBasePa);
+
+  //
+  // The SEV support will clear the C-bit from non-RAM areas.  The early GDT
+  // lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
+  // will be read as un-encrypted even though it was created before the C-bit
+  // was cleared (encrypted). This will result in a failure to be able to
+  // handle the exception.
+  //
+  AsmReadGdtr ();
+
+  Gdt = AllocatePages (EFI_SIZE_TO_PAGES ((UINTN) Gdtr.Limit + 1));
+  ASSERT (Gdt != NULL);
+
+  CopyMem (Gdt, (VOID *) Gdtr.Base, Gdtr.Limit + 1);
+  Gdtr.Base = (UINTN) Gdt;
+  AsmWriteGdtr ();
 }
 
 /**
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63336): https://edk2.groups.io/g/devel/message/63336
Mute This Topic: https://groups.io/mt/75825057/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 26/46] OvmfPkg/VmgExitLib: Add support for DR7 Read/Write NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of the write. However, the #VC handler must
not actually set the value of the DR7 register. On a DR7 read, the #VC
handler must return the cached value of the DR7 register to the guest.
VMGEXIT is not invoked for a DR7 register read.

The caching of the DR7 values will make use of the per-CPU data pages
that are allocated along with the GHCB pages. The per-CPU page for a
vCPU is the page that immediately follows the vCPU's GHCB page. Since
each GHCB page is unique for a vCPU, the page that follows becomes
unique for that vCPU. The SEC phase will reserves an area of memory for
a single GHCB and per-CPU page for use by the BSP. After transitioning
to the PEI phase, new GHCB and per-CPU pages are allocated for the BSP
and all APs.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 114 ++
 1 file changed, 114 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index e70e0ef82f68..c57c8c4ba203 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -126,6 +126,14 @@ UINT64
   SEV_ES_INSTRUCTION_DATA  *InstructionData
   );
 
+//
+// Per-CPU data mapping structure
+//
+typedef struct {
+  BOOLEAN  Dr7Cached;
+  UINT64   Dr7;
+} SEV_ES_PER_CPU_DATA;
+
 
 /**
   Checks the GHCB to determine if the specified register has been marked valid.
@@ -1480,6 +1488,104 @@ RdtscExit (
   return 0;
 }
 
+/**
+  Handle a DR7 register write event.
+
+  Use the VMGEXIT instruction to handle a DR7 write event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+Dr7WriteExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext;
+  SEV_ES_PER_CPU_DATA*SevEsData;
+  UINT64 *Register;
+  UINT64 Status;
+
+  Ext = >Ext;
+  SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb + 1);
+
+  DecodeModRm (Regs, InstructionData);
+
+  //
+  // MOV DRn always treats MOD == 3 no matter how encoded
+  //
+  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
+
+  //
+  // Using a value of 0 for ExitInfo1 means RAX holds the value
+  //
+  Ghcb->SaveArea.Rax = *Register;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+
+  Status = VmgExit (Ghcb, SVM_EXIT_DR7_WRITE, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  SevEsData->Dr7 = *Register;
+  SevEsData->Dr7Cached = TRUE;
+
+  return 0;
+}
+
+/**
+  Handle a DR7 register read event.
+
+  Use the VMGEXIT instruction to handle a DR7 read event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+
+**/
+STATIC
+UINT64
+Dr7ReadExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext;
+  SEV_ES_PER_CPU_DATA*SevEsData;
+  UINT64 *Register;
+
+  Ext = >Ext;
+  SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb + 1);
+
+  DecodeModRm (Regs, InstructionData);
+
+  //
+  // MOV DRn always treats MOD == 3 no matter how encoded
+  //
+  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
+
+  //
+  // If there is a cached valued for DR7, return that. Otherwise return the
+  // DR7 standard reset value of 0x400 (no debug breakpoints set).
+  //
+  *Register = (SevEsData->Dr7Cached) ? SevEsData->Dr7 : 0x400;
+
+  return 0;
+}
+
 /**
   Handle a #VC exception.
 
@@ -1524,6 +1630,14 @@ VmgExitHandleVc (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SVM_EXIT_DR7_READ:
+NaeExit = Dr7ReadExit;
+break;
+
+  case SVM_EXIT_DR7_WRITE:
+NaeExit = Dr7WriteExit;
+break;
+
   case SVM_EXIT_RDTSC:
 NaeExit = RdtscExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63330): 

[edk2-devel] [PATCH v12 21/46] OvmfPkg/VmgExitLib: Add support for INVD NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a INVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index b19bd3ee8906..af5264095b98 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -1166,6 +1166,31 @@ IoioExit (
   return 0;
 }
 
+/**
+  Handle a INVD event.
+
+  Use the VMGEXIT instruction to handle a INVD event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+InvdExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  return VmgExit (Ghcb, SVM_EXIT_INVD, 0, 0);
+}
+
 /**
   Handle a CPUID event.
 
@@ -1358,6 +1383,10 @@ VmgExitHandleVc (
 NaeExit = CpuidExit;
 break;
 
+  case SVM_EXIT_INVD:
+NaeExit = InvdExit;
+break;
+
   case SVM_EXIT_IOIO_PROT:
 NaeExit = IoioExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63325): https://edk2.groups.io/g/devel/message/63325
Mute This Topic: https://groups.io/mt/75825009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 23/46] OvmfPkg/VmgExitLib: Add support for RDTSCP NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a RDTSCP intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index 54134f37e614..a1cf792d4d0b 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -881,6 +881,49 @@ WbinvdExit (
   return VmgExit (Ghcb, SVM_EXIT_WBINVD, 0, 0);
 }
 
+/**
+  Handle a RDTSCP event.
+
+  Use the VMGEXIT instruction to handle a RDTSCP event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+RdtscpExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Status = VmgExit (Ghcb, SVM_EXIT_RDTSCP, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRcx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rcx = Ghcb->SaveArea.Rcx;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 /**
   Handle a VMMCALL event.
 
@@ -1443,6 +1486,10 @@ VmgExitHandleVc (
 NaeExit = VmmCallExit;
 break;
 
+  case SVM_EXIT_RDTSCP:
+NaeExit = RdtscpExit;
+break;
+
   case SVM_EXIT_WBINVD:
 NaeExit = WbinvdExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63327): https://edk2.groups.io/g/devel/message/63327
Mute This Topic: https://groups.io/mt/75825019/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 25/46] OvmfPkg/VmgExitLib: Add support for MWAIT/MWAITX NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a MWAIT/MWAITX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index fe08b1e0ff49..e70e0ef82f68 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -856,6 +856,38 @@ MmioExit (
   return Status;
 }
 
+/**
+  Handle a MWAIT event.
+
+  Use the VMGEXIT instruction to handle a MWAIT event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+MwaitExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+
+  return VmgExit (Ghcb, SVM_EXIT_MWAIT, 0, 0);
+}
+
 /**
   Handle a MONITOR event.
 
@@ -1532,6 +1564,10 @@ VmgExitHandleVc (
 NaeExit = MonitorExit;
 break;
 
+  case SVM_EXIT_MWAIT:
+NaeExit = MwaitExit;
+break;
+
   case SVM_EXIT_NPF:
 NaeExit = MmioExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63329): https://edk2.groups.io/g/devel/message/63329
Mute This Topic: https://groups.io/mt/75825026/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 22/46] OvmfPkg/VmgExitLib: Add support for VMMCALL NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a VMMCALL intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index af5264095b98..54134f37e614 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -881,6 +881,50 @@ WbinvdExit (
   return VmgExit (Ghcb, SVM_EXIT_WBINVD, 0, 0);
 }
 
+/**
+  Handle a VMMCALL event.
+
+  Use the VMGEXIT instruction to handle a VMMCALL event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+VmmCallExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Cpl = (UINT8) (Regs->Cs & 0x3);
+  GhcbSetRegValid (Ghcb, GhcbCpl);
+
+  Status = VmgExit (Ghcb, SVM_EXIT_VMMCALL, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+
+  return 0;
+}
+
 /**
   Handle an MSR event.
 
@@ -1395,6 +1439,10 @@ VmgExitHandleVc (
 NaeExit = MsrExit;
 break;
 
+  case SVM_EXIT_VMMCALL:
+NaeExit = VmmCallExit;
+break;
+
   case SVM_EXIT_WBINVD:
 NaeExit = WbinvdExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63326): https://edk2.groups.io/g/devel/message/63326
Mute This Topic: https://groups.io/mt/75825017/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 24/46] OvmfPkg/VmgExitLib: Add support for MONITOR/MONITORX NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a MONITOR/MONITORX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 38 +++
 1 file changed, 38 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index a1cf792d4d0b..fe08b1e0ff49 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -856,6 +856,40 @@ MmioExit (
   return Status;
 }
 
+/**
+  Handle a MONITOR event.
+
+  Use the VMGEXIT instruction to handle a MONITOR event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+MonitorExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+  Ghcb->SaveArea.Rdx = Regs->Rdx;
+  GhcbSetRegValid (Ghcb, GhcbRdx);
+
+  return VmgExit (Ghcb, SVM_EXIT_MONITOR, 0, 0);
+}
+
 /**
   Handle a WBINVD event.
 
@@ -1494,6 +1528,10 @@ VmgExitHandleVc (
 NaeExit = WbinvdExit;
 break;
 
+  case SVM_EXIT_MONITOR:
+NaeExit = MonitorExit;
+break;
+
   case SVM_EXIT_NPF:
 NaeExit = MmioExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63328): https://edk2.groups.io/g/devel/message/63328
Mute This Topic: https://groups.io/mt/75825022/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 20/46] OvmfPkg/VmgExitLib: Add support for RDPMC NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a RDPMC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index 65af57046063..b19bd3ee8906 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -1221,6 +1221,48 @@ CpuidExit (
   return 0;
 }
 
+/**
+  Handle a RDPMC event.
+
+  Use the VMGEXIT instruction to handle a RDPMC event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+RdpmcExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+
+  Status = VmgExit (Ghcb, SVM_EXIT_RDPMC, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 /**
   Handle a RDTSC event.
 
@@ -1308,6 +1350,10 @@ VmgExitHandleVc (
 NaeExit = RdtscExit;
 break;
 
+  case SVM_EXIT_RDPMC:
+NaeExit = RdpmcExit;
+break;
+
   case SVM_EXIT_CPUID:
 NaeExit = CpuidExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63324): https://edk2.groups.io/g/devel/message/63324
Mute This Topic: https://groups.io/mt/75824998/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 19/46] OvmfPkg/VmgExitLib: Add support for RDTSC NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a RDTSC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index bf07f960e380..65af57046063 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -1221,6 +1221,45 @@ CpuidExit (
   return 0;
 }
 
+/**
+  Handle a RDTSC event.
+
+  Use the VMGEXIT instruction to handle a RDTSC event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+RdtscExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Status = VmgExit (Ghcb, SVM_EXIT_RDTSC, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 /**
   Handle a #VC exception.
 
@@ -1265,6 +1304,10 @@ VmgExitHandleVc (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SVM_EXIT_RDTSC:
+NaeExit = RdtscExit;
+break;
+
   case SVM_EXIT_CPUID:
 NaeExit = CpuidExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63323): https://edk2.groups.io/g/devel/message/63323
Mute This Topic: https://groups.io/mt/75824993/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 18/46] OvmfPkg/VmgExitLib: Add support for WBINVD NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a WBINVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index 0e502ac14819..bf07f960e380 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -856,6 +856,31 @@ MmioExit (
   return Status;
 }
 
+/**
+  Handle a WBINVD event.
+
+  Use the VMGEXIT instruction to handle a WBINVD event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+WbinvdExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  return VmgExit (Ghcb, SVM_EXIT_WBINVD, 0, 0);
+}
+
 /**
   Handle an MSR event.
 
@@ -1252,6 +1277,10 @@ VmgExitHandleVc (
 NaeExit = MsrExit;
 break;
 
+  case SVM_EXIT_WBINVD:
+NaeExit = WbinvdExit;
+break;
+
   case SVM_EXIT_NPF:
 NaeExit = MmioExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63322): https://edk2.groups.io/g/devel/message/63322
Mute This Topic: https://groups.io/mt/75824992/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 12/46] OvmfPkg/VmgExitLib: Implement library support for VmgExitLib in OVMF

[Lendacky, Thomas]

From: Tom Lendacky 

The base VmgExitLib library provides a default limited interface. As it
does not provide full support, create an OVMF version of this library to
begin the process of providing full support of SEV-ES within OVMF.

SEV-ES support is only provided for X64 builds, so only OvmfPkgX64.dsc is
updated to make use of the OvmfPkg version of the library.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgX64.dsc|   2 +-
 OvmfPkg/Library/VmgExitLib/VmgExitLib.inf |  36 
 OvmfPkg/Library/VmgExitLib/VmgExitLib.c   | 159 ++
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c |  81 +
 4 files changed, 277 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/Library/VmgExitLib/VmgExitLib.inf
 create mode 100644 OvmfPkg/Library/VmgExitLib/VmgExitLib.c
 create mode 100644 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 27f5225fc281..60be5eae3d2b 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -233,7 +233,7 @@ [LibraryClasses]
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
-  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
+  VmgExitLib|OvmfPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitLib.inf 
b/OvmfPkg/Library/VmgExitLib/VmgExitLib.inf
new file mode 100644
index ..d003ac63173e
--- /dev/null
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitLib.inf
@@ -0,0 +1,36 @@
+## @file
+#  VMGEXIT Support Library.
+#
+#  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = VmgExitLib
+  FILE_GUID  = 0e923c25-13cd-430b-8714-ffe85652a97b
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = VmgExitLib
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = X64
+#
+
+[Sources.common]
+  VmgExitLib.c
+  VmgExitVcHandler.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+
diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitLib.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitLib.c
new file mode 100644
index ..53040cc6f649
--- /dev/null
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitLib.c
@@ -0,0 +1,159 @@
+/** @file
+  VMGEXIT Support Library.
+
+  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Check for VMGEXIT error
+
+  Check if the hypervisor has returned an error after completion of the VMGEXIT
+  by examining the SwExitInfo1 field of the GHCB.
+
+  @param[in]  Ghcb   A pointer to the GHCB
+
+  @retval  0 VMGEXIT succeeded.
+  @returnException number to be propagated, VMGEXIT processing
+ did not succeed.
+
+**/
+STATIC
+UINT64
+VmgExitErrorCheck (
+  IN GHCB*Ghcb
+  )
+{
+  GHCB_EVENT_INJECTION  Event;
+  GHCB_EXIT_INFOExitInfo;
+  UINT64Status;
+
+  ExitInfo.Uint64 = Ghcb->SaveArea.SwExitInfo1;
+  ASSERT ((ExitInfo.Elements.Lower32Bits == 0) ||
+  (ExitInfo.Elements.Lower32Bits == 1));
+
+  Status = 0;
+  if (ExitInfo.Elements.Lower32Bits == 0) {
+return Status;
+  }
+
+  if (ExitInfo.Elements.Lower32Bits == 1) {
+ASSERT (Ghcb->SaveArea.SwExitInfo2 != 0);
+
+//
+// Check that the return event is valid
+//
+Event.Uint64 = Ghcb->SaveArea.SwExitInfo2;
+if (Event.Elements.Valid &&
+Event.Elements.Type == GHCB_EVENT_INJECTION_TYPE_EXCEPTION) {
+  switch (Event.Elements.Vector) {
+  case GP_EXCEPTION:
+  case UD_EXCEPTION:
+//
+// Use returned event as return code
+//
+Status = Event.Uint64;
+  }
+}
+  }
+
+  if (Status == 0) {
+GHCB_EVENT_INJECTION  GpEvent;
+
+GpEvent.Uint64 = 0;
+GpEvent.Elements.Vector = GP_EXCEPTION;
+GpEvent.Elements.Type   = GHCB_EVENT_INJECTION_TYPE_EXCEPTION;
+GpEvent.Elements.Valid  = 1;
+
+Status = GpEvent.Uint64;
+  }
+
+  return Status;
+}
+
+/**
+  Perform VMGEXIT.
+
+  Sets the necessary fields of the GHCB, invokes the VMGEXIT instruction and
+  then handles the return actions.
+
+  @param[in, out]  Ghcb   A pointer to the GHCB
+  @param[in]   ExitCode   VMGEXIT code to be assigned to the SwExitCode
+  field of the GHCB.
+  @param[in]   ExitInfo1  VMGEXIT information to 

[edk2-devel] [PATCH v12 16/46] OvmfPkg/VmgExitLib: Add support for MSR_PROT NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support an MSR_PROT
NAE event. Parse the instruction that generated the #VC exception to
determine whether it is RDMSR or WRMSR, setting the required register
register values in the GHCB and creating the proper SW_EXIT_INFO1 value in
the GHCB.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index 1c9c272a250e..dbedd4e9f95d 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -374,6 +374,67 @@ UnsupportedExit (
   return Status;
 }
 
+/**
+  Handle an MSR event.
+
+  Use the VMGEXIT instruction to handle either a RDMSR or WRMSR event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+MsrExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  ExitInfo1, Status;
+
+  ExitInfo1 = 0;
+
+  switch (*(InstructionData->OpCodes + 1)) {
+  case 0x30: // WRMSR
+ExitInfo1 = 1;
+Ghcb->SaveArea.Rax = Regs->Rax;
+GhcbSetRegValid (Ghcb, GhcbRax);
+Ghcb->SaveArea.Rdx = Regs->Rdx;
+GhcbSetRegValid (Ghcb, GhcbRdx);
+//
+// fall through
+//
+  case 0x32: // RDMSR
+Ghcb->SaveArea.Rcx = Regs->Rcx;
+GhcbSetRegValid (Ghcb, GhcbRcx);
+break;
+  default:
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+
+  Status = VmgExit (Ghcb, SVM_EXIT_MSR, ExitInfo1, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (ExitInfo1 == 0) {
+if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+!GhcbIsRegValid (Ghcb, GhcbRdx)) {
+  return UnsupportedExit (Ghcb, Regs, InstructionData);
+}
+Regs->Rax = Ghcb->SaveArea.Rax;
+Regs->Rdx = Ghcb->SaveArea.Rdx;
+  }
+
+  return 0;
+}
+
 /**
   Build the IOIO event information.
 
@@ -705,6 +766,10 @@ VmgExitHandleVc (
 NaeExit = IoioExit;
 break;
 
+  case SVM_EXIT_MSR:
+NaeExit = MsrExit;
+break;
+
   default:
 NaeExit = UnsupportedExit;
   }
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63320): https://edk2.groups.io/g/devel/message/63320
Mute This Topic: https://groups.io/mt/75824983/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 17/46] OvmfPkg/VmgExitLib: Add support for NPF NAE events (MMIO)

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set
generates a #VC exception. This condition is assumed to be an MMIO access.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a NPF NAE
event for MMIO.  Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXIT_INFO1, SW_EXITINFO2 and SW_SCRATCH values in the GHCB.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 486 ++
 1 file changed, 486 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index dbedd4e9f95d..0e502ac14819 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -183,6 +183,281 @@ GhcbSetRegValid (
   Ghcb->SaveArea.ValidBitmap[RegIndex] |= (1 << RegBit);
 }
 
+/**
+  Return a pointer to the contents of the specified register.
+
+  Based upon the input register, return a pointer to the registers contents
+  in the x86 processor context.
+
+  @param[in] Regs  x64 processor context
+  @param[in] Register  Register to obtain pointer for
+
+  @return  Pointer to the contents of the requested register
+
+**/
+STATIC
+UINT64 *
+GetRegisterPointer (
+  IN EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN UINT8Register
+  )
+{
+  UINT64 *Reg;
+
+  switch (Register) {
+  case 0:
+Reg = >Rax;
+break;
+  case 1:
+Reg = >Rcx;
+break;
+  case 2:
+Reg = >Rdx;
+break;
+  case 3:
+Reg = >Rbx;
+break;
+  case 4:
+Reg = >Rsp;
+break;
+  case 5:
+Reg = >Rbp;
+break;
+  case 6:
+Reg = >Rsi;
+break;
+  case 7:
+Reg = >Rdi;
+break;
+  case 8:
+Reg = >R8;
+break;
+  case 9:
+Reg = >R9;
+break;
+  case 10:
+Reg = >R10;
+break;
+  case 11:
+Reg = >R11;
+break;
+  case 12:
+Reg = >R12;
+break;
+  case 13:
+Reg = >R13;
+break;
+  case 14:
+Reg = >R14;
+break;
+  case 15:
+Reg = >R15;
+break;
+  default:
+Reg = NULL;
+  }
+  ASSERT (Reg != NULL);
+
+  return Reg;
+}
+
+/**
+  Update the instruction parsing context for displacement bytes.
+
+  @param[in, out] InstructionData  Instruction parsing context
+  @param[in]  Size The instruction displacement size
+
+**/
+STATIC
+VOID
+UpdateForDisplacement (
+  IN OUT SEV_ES_INSTRUCTION_DATA  *InstructionData,
+  IN UINTNSize
+  )
+{
+  InstructionData->DisplacementSize = Size;
+  InstructionData->Immediate += Size;
+  InstructionData->End += Size;
+}
+
+/**
+  Determine if an instruction address if RIP relative.
+
+  Examine the instruction parsing context to determine if the address offset
+  is relative to the instruction pointer.
+
+  @param[in] InstructionData  Instruction parsing context
+
+  @retval TRUEInstruction addressing is RIP relative
+  @retval FALSE   Instruction addressing is not RIP relative
+
+**/
+STATIC
+BOOLEAN
+IsRipRelative (
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext;
+
+  Ext = >Ext;
+
+  return ((InstructionData->Mode == LongMode64Bit) &&
+  (Ext->ModRm.Mod == 0) &&
+  (Ext->ModRm.Rm == 5)  &&
+  (InstructionData->SibPresent == FALSE));
+}
+
+/**
+  Return the effective address of a memory operand.
+
+  Examine the instruction parsing context to obtain the effective memory
+  address of a memory operand.
+
+  @param[in] Regs x64 processor context
+  @param[in] InstructionData  Instruction parsing context
+
+  @return The memory operand effective address
+
+**/
+STATIC
+UINT64
+GetEffectiveMemoryAddress (
+  IN EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext;
+  UINT64 EffectiveAddress;
+
+  Ext = >Ext;
+  EffectiveAddress = 0;
+
+  if (IsRipRelative (InstructionData)) {
+//
+// RIP-relative displacement is a 32-bit signed value
+//
+INT32 RipRelative;
+
+RipRelative = *(INT32 *) InstructionData->Displacement;
+
+UpdateForDisplacement (InstructionData, 4);
+
+//
+// Negative displacement is handled by standard UINT64 wrap-around.
+//
+return Regs->Rip + (UINT64) RipRelative;
+  }
+
+  switch (Ext->ModRm.Mod) {
+  case 1:
+UpdateForDisplacement (InstructionData, 1);
+EffectiveAddress += (UINT64) (*(INT8 *) (InstructionData->Displacement));
+break;
+  case 2:
+switch (InstructionData->AddrSize) {
+case Size16Bits:
+  UpdateForDisplacement (InstructionData, 2);
+  EffectiveAddress += (UINT64) 

[edk2-devel] [PATCH v12 15/46] OvmfPkg/VmgExitLib: Add support for CPUID NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a CPUID intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a CPUID NAE
event. Additionally, CPUID 0x_000d (CPUID_EXTENDED_STATE) requires
XCR0 to be supplied in the GHCB, so add support to issue the XGETBV
instruction.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index b6ac3552894f..1c9c272a250e 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 //
@@ -597,6 +598,61 @@ IoioExit (
   return 0;
 }
 
+/**
+  Handle a CPUID event.
+
+  Use the VMGEXIT instruction to handle a CPUID event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @return  New exception value to propagate
+
+**/
+STATIC
+UINT64
+CpuidExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+  if (Regs->Rax == CPUID_EXTENDED_STATE) {
+IA32_CR4  Cr4;
+
+Cr4.UintN = AsmReadCr4 ();
+Ghcb->SaveArea.XCr0 = (Cr4.Bits.OSXSAVE == 1) ? AsmXGetBv (0) : 1;
+GhcbSetRegValid (Ghcb, GhcbXCr0);
+  }
+
+  Status = VmgExit (Ghcb, SVM_EXIT_CPUID, 0, 0);
+  if (Status != 0) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRbx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRcx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rbx = Ghcb->SaveArea.Rbx;
+  Regs->Rcx = Ghcb->SaveArea.Rcx;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 /**
   Handle a #VC exception.
 
@@ -641,6 +697,10 @@ VmgExitHandleVc (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SVM_EXIT_CPUID:
+NaeExit = CpuidExit;
+break;
+
   case SVM_EXIT_IOIO_PROT:
 NaeExit = IoioExit;
 break;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63319): https://edk2.groups.io/g/devel/message/63319
Mute This Topic: https://groups.io/mt/75824978/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 11/46] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC exception

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Add base support to handle #VC exceptions. Update the common exception
handlers to invoke the VmgExitHandleVc () function of the VmgExitLib
library when a #VC is encountered. A non-zero return code will propagate
to the targeted exception handler.

Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
To avoid exception recursion, a #VC exception will not try to read and
push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct
and instead push zeroes. The #VC exception handler does not make use of
the debug registers from the saved context and the exception processing
exit code does not attempt to restore the debug register values.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 .../DxeCpuExceptionHandlerLib.inf |  1 +
 .../PeiCpuExceptionHandlerLib.inf |  1 +
 .../SecPeiCpuExceptionHandlerLib.inf  |  1 +
 .../SmmCpuExceptionHandlerLib.inf |  1 +
 .../Xcode5SecPeiCpuExceptionHandlerLib.inf|  1 +
 .../CpuExceptionCommon.c  | 10 +-
 .../PeiDxeSmmCpuException.c   | 20 ++-
 .../SecPeiCpuException.c  | 19 ++
 .../X64/ExceptionHandlerAsm.nasm  | 17 
 .../X64/Xcode5ExceptionHandlerAsm.nasm| 17 
 10 files changed, 86 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
index 61e2ec30b089..07b34c92a892 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
@@ -57,3 +57,4 @@ [LibraryClasses]
   PeCoffGetEntryPointLib
   MemoryAllocationLib
   DebugLib
+  VmgExitLib
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
index 093374944df6..feae7b3e06de 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
   HobLib
   MemoryAllocationLib
   SynchronizationLib
+  VmgExitLib
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard# CONSUMES
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
index 6d25cafe2ca3..967cb61ba6d9 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
@@ -48,3 +48,4 @@ [LibraryClasses]
   PrintLib
   LocalApicLib
   PeCoffGetEntryPointLib
+  VmgExitLib
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
index 2ffbbccc302f..4cdb11c04ea0 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
@@ -51,4 +51,5 @@ [LibraryClasses]
   LocalApicLib
   PeCoffGetEntryPointLib
   DebugLib
+  VmgExitLib
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
index 7e21beaab6f2..743c2aa76684 100644
--- 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
+++ 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
@@ -53,3 +53,4 @@ [LibraryClasses]
   PrintLib
   LocalApicLib
   PeCoffGetEntryPointLib
+  VmgExitLib
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index 8adbd43fefb4..c9003b10e552 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -14,7 +14,7 @@
 //
 // 1 means an error code will be pushed, otherwise 0
 //
-CONST UINT32 mErrorCodeFlag = 0x00227d00;
+CONST UINT32 mErrorCodeFlag = 0x20227d00;
 
 //
 // Define the maximum message length
@@ -45,6 +45,14 @@ CONST CHAR8 *mExceptionNameStr[] = {
   "#XM - SIMD floating-point",
   "#VE - Virtualization",
   "#CP - Control Protection"
+  "Reserved",
+  "Reserved",
+  "Reserved",
+  "Reserved",
+  "Reserved",
+  "Reserved",
+  "Reserved",
+  "#VC - VMM Communication",
 };
 
 #define EXCEPTION_KNOWN_NAME_NUM  (sizeof (mExceptionNameStr) / sizeof (CHAR8 
*))
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c 

[edk2-devel] [PATCH v12 13/46] OvmfPkg/VmgExitLib: Add support for IOIO_PROT NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a IOIO_PROT intercept generates a #VC exception. VMGEXIT
must be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a IOIO_PROT
NAE event.  Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXITINFO1 value in the GHCB.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../IndustryStandard/InstructionParsing.h |  83 +++
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 560 +-
 2 files changed, 629 insertions(+), 14 deletions(-)
 create mode 100644 OvmfPkg/Include/IndustryStandard/InstructionParsing.h

diff --git a/OvmfPkg/Include/IndustryStandard/InstructionParsing.h 
b/OvmfPkg/Include/IndustryStandard/InstructionParsing.h
new file mode 100644
index ..149ff328e06c
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/InstructionParsing.h
@@ -0,0 +1,83 @@
+/** @file
+  Instruction parsing support definitions.
+
+  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __INSTRUCTION_PARSING_H__
+#define __INSTRUCTION_PARSING_H__
+
+#include 
+#include 
+
+//
+// Instruction REX prefix definition
+//
+typedef union {
+  struct {
+UINT8  BitB:1;
+UINT8  BitX:1;
+UINT8  BitR:1;
+UINT8  BitW:1;
+UINT8  Rex:4;
+  } Bits;
+
+  UINT8  Uint8;
+} INSTRUCTION_REX_PREFIX;
+
+//
+// Instruction ModRM definition
+//
+typedef union {
+  struct {
+UINT8  Rm:3;
+UINT8  Reg:3;
+UINT8  Mod:2;
+  } Bits;
+
+  UINT8  Uint8;
+} INSTRUCTION_MODRM;
+
+//
+// Instruction SIB definition
+//
+typedef union {
+  struct {
+UINT8  Base:3;
+UINT8  Index:3;
+UINT8  Scale:2;
+  } Bits;
+
+  UINT8  Uint8;
+} INSTRUCTION_SIB;
+
+//
+// Legacy Instruction Prefixes
+//
+#define OVERRIDE_SEGMENT_CS  0x2E
+#define OVERRIDE_SEGMENT_DS  0x3E
+#define OVERRIDE_SEGMENT_ES  0x26
+#define OVERRIDE_SEGMENT_SS  0x36
+#define OVERRIDE_SEGMENT_FS  0x64
+#define OVERRIDE_SEGMENT_GS  0x65
+#define OVERRIDE_OPERAND_SIZE0x66
+#define OVERRIDE_ADDRESS_SIZE0x67
+#define LOCK_PREFIX  0xF0
+#define REPNZ_PREFIX 0xF2
+#define REPZ_PREFIX  0xF3
+
+//
+// REX Prefixes
+//
+#define REX_PREFIX_START 0x40
+#define REX_PREFIX_STOP  0x4F
+#define REX_64BIT_OPERAND_SIZE_MASK  0x08
+
+//
+// Two-byte Opcode Flag
+//
+#define TWO_BYTE_OPCODE_ESCAPE   0x0F
+
+#endif
diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index b6a955ed8088..04e8b8aebf7d 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -11,6 +11,529 @@
 #include 
 #include 
 #include 
+#include 
+
+//
+// Instruction execution mode definition
+//
+typedef enum {
+  LongMode64Bit= 0,
+  LongModeCompat32Bit,
+  LongModeCompat16Bit,
+} SEV_ES_INSTRUCTION_MODE;
+
+//
+// Instruction size definition (for operand and address)
+//
+typedef enum {
+  Size8Bits= 0,
+  Size16Bits,
+  Size32Bits,
+  Size64Bits,
+} SEV_ES_INSTRUCTION_SIZE;
+
+//
+// Intruction segment definition
+//
+typedef enum {
+  SegmentEs= 0,
+  SegmentCs,
+  SegmentSs,
+  SegmentDs,
+  SegmentFs,
+  SegmentGs,
+} SEV_ES_INSTRUCTION_SEGMENT;
+
+//
+// Instruction rep function definition
+//
+typedef enum {
+  RepNone  = 0,
+  RepZ,
+  RepNZ,
+} SEV_ES_INSTRUCTION_REP;
+
+typedef struct {
+  UINT8  Rm;
+  UINT8  Reg;
+  UINT8  Mod;
+} SEV_ES_INSTRUCTION_MODRM_EXT;
+
+typedef struct {
+  UINT8  Base;
+  UINT8  Index;
+  UINT8  Scale;
+} SEV_ES_INSTRUCTION_SIB_EXT;
+
+//
+// Instruction opcode definition
+//
+typedef struct {
+  SEV_ES_INSTRUCTION_MODRM_EXT  ModRm;
+
+  SEV_ES_INSTRUCTION_SIB_EXTSib;
+
+  UINTN RegData;
+  UINTN RmData;
+} SEV_ES_INSTRUCTION_OPCODE_EXT;
+
+//
+// Instruction parsing context definition
+//
+typedef struct {
+  GHCB   *Ghcb;
+
+  SEV_ES_INSTRUCTION_MODEMode;
+  SEV_ES_INSTRUCTION_SIZEDataSize;
+  SEV_ES_INSTRUCTION_SIZEAddrSize;
+  BOOLEANSegmentSpecified;
+  SEV_ES_INSTRUCTION_SEGMENT Segment;
+  SEV_ES_INSTRUCTION_REP RepMode;
+
+  UINT8  *Begin;
+  UINT8  *End;
+
+  UINT8  *Prefixes;
+  UINT8  *OpCodes;
+  UINT8  *Displacement;
+  UINT8  *Immediate;
+
+  INSTRUCTION_REX_PREFIX RexPrefix;
+
+  BOOLEANModRmPresent;
+  INSTRUCTION_MODRM  ModRm;
+
+  

[edk2-devel] [PATCH v12 14/46] OvmfPkg/VmgExitLib: Support string IO for IOIO_PROT NAE events

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Add support to the #VC exception handler to handle string IO. This
requires expanding the IO instruction parsing to recognize string based
IO instructions as well as preparing an un-encrypted buffer to be used
to transfer (either to or from the guest) the string contents for the IO
operation. The SW_EXITINFO2 and SW_SCRATCH fields of the GHCB are set
appropriately for the operation. Multiple VMGEXIT invocations may be
needed to complete the string IO operation.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 90 ---
 1 file changed, 76 insertions(+), 14 deletions(-)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index 04e8b8aebf7d..b6ac3552894f 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -397,6 +397,26 @@ IoioExitInfo (
   ExitInfo = 0;
 
   switch (*(InstructionData->OpCodes)) {
+  //
+  // INS opcodes
+  //
+  case 0x6C:
+  case 0x6D:
+ExitInfo |= IOIO_TYPE_INS;
+ExitInfo |= IOIO_SEG_ES;
+ExitInfo |= ((Regs->Rdx & 0x) << 16);
+break;
+
+  //
+  // OUTS opcodes
+  //
+  case 0x6E:
+  case 0x6F:
+ExitInfo |= IOIO_TYPE_OUTS;
+ExitInfo |= IOIO_SEG_DS;
+ExitInfo |= ((Regs->Rdx & 0x) << 16);
+break;
+
   //
   // IN immediate opcodes
   //
@@ -445,6 +465,8 @@ IoioExitInfo (
   //
   // Single-byte opcodes
   //
+  case 0x6C:
+  case 0x6E:
   case 0xE4:
   case 0xE6:
   case 0xEC:
@@ -506,30 +528,70 @@ IoioExit (
   IN SEV_ES_INSTRUCTION_DATA  *InstructionData
   )
 {
-  UINT64  ExitInfo1, Status;
+  UINT64   ExitInfo1, ExitInfo2, Status;
+  BOOLEAN  IsString;
 
   ExitInfo1 = IoioExitInfo (Regs, InstructionData);
   if (ExitInfo1 == 0) {
 return UnsupportedExit (Ghcb, Regs, InstructionData);
   }
 
-  if ((ExitInfo1 & IOIO_TYPE_IN) != 0) {
-Ghcb->SaveArea.Rax = 0;
+  IsString = ((ExitInfo1 & IOIO_TYPE_STR) != 0) ? TRUE : FALSE;
+  if (IsString) {
+UINTN  IoBytes, VmgExitBytes;
+UINTN  GhcbCount, OpCount;
+
+Status = 0;
+
+IoBytes = IOIO_DATA_BYTES (ExitInfo1);
+GhcbCount = sizeof (Ghcb->SharedBuffer) / IoBytes;
+
+OpCount = ((ExitInfo1 & IOIO_REP) != 0) ? Regs->Rcx : 1;
+while (OpCount) {
+  ExitInfo2 = MIN (OpCount, GhcbCount);
+  VmgExitBytes = ExitInfo2 * IoBytes;
+
+  if ((ExitInfo1 & IOIO_TYPE_IN) == 0) {
+CopyMem (Ghcb->SharedBuffer, (VOID *) Regs->Rsi, VmgExitBytes);
+Regs->Rsi += VmgExitBytes;
+  }
+
+  Ghcb->SaveArea.SwScratch = (UINT64) Ghcb->SharedBuffer;
+  Status = VmgExit (Ghcb, SVM_EXIT_IOIO_PROT, ExitInfo1, ExitInfo2);
+  if (Status != 0) {
+return Status;
+  }
+
+  if ((ExitInfo1 & IOIO_TYPE_IN) != 0) {
+CopyMem ((VOID *) Regs->Rdi, Ghcb->SharedBuffer, VmgExitBytes);
+Regs->Rdi += VmgExitBytes;
+  }
+
+  if ((ExitInfo1 & IOIO_REP) != 0) {
+Regs->Rcx -= ExitInfo2;
+  }
+
+  OpCount -= ExitInfo2;
+}
   } else {
-CopyMem (>SaveArea.Rax, >Rax, IOIO_DATA_BYTES (ExitInfo1));
-  }
-  GhcbSetRegValid (Ghcb, GhcbRax);
+if ((ExitInfo1 & IOIO_TYPE_IN) != 0) {
+  Ghcb->SaveArea.Rax = 0;
+} else {
+  CopyMem (>SaveArea.Rax, >Rax, IOIO_DATA_BYTES (ExitInfo1));
+}
+GhcbSetRegValid (Ghcb, GhcbRax);
 
-  Status = VmgExit (Ghcb, SVM_EXIT_IOIO_PROT, ExitInfo1, 0);
-  if (Status != 0) {
-return Status;
-  }
+Status = VmgExit (Ghcb, SVM_EXIT_IOIO_PROT, ExitInfo1, 0);
+if (Status != 0) {
+  return Status;
+}
 
-  if ((ExitInfo1 & IOIO_TYPE_IN) != 0) {
-if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
-  return UnsupportedExit (Ghcb, Regs, InstructionData);
+if ((ExitInfo1 & IOIO_TYPE_IN) != 0) {
+  if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  CopyMem (>Rax, >SaveArea.Rax, IOIO_DATA_BYTES (ExitInfo1));
 }
-CopyMem (>Rax, >SaveArea.Rax, IOIO_DATA_BYTES (ExitInfo1));
   }
 
   return 0;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63318): https://edk2.groups.io/g/devel/message/63318
Mute This Topic: https://groups.io/mt/75824974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 09/46] OvmfPkg: Prepare OvmfPkg to use the VmgExitLib library

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Various CpuExceptionHandlerLib libraries will updated to use the new
VmgExitLib library. To prevent any build breakage, update the OvmfPkg
DSC files that use a form of the CpuExceptionHandlerLib library to
include the VmgExitLib library.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfXen.dsc| 1 +
 4 files changed, 4 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 9178ffeb71cb..c57bba1ba197 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -229,6 +229,7 @@ [LibraryClasses]
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a665f78f0dc7..22e930b12b9b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -233,6 +233,7 @@ [LibraryClasses]
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 17f345acf4ee..27f5225fc281 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -233,6 +233,7 @@ [LibraryClasses]
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.SEC]
   TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 782803cb2787..37b63a874067 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -213,6 +213,7 @@ [LibraryClasses]
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.SEC]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63313): https://edk2.groups.io/g/devel/message/63313
Mute This Topic: https://groups.io/mt/75824954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 07/46] MdePkg/BaseLib: Add support for the VMGEXIT instruction

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

VMGEXIT is a new instruction used for Hypervisor/Guest communication when
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
to occur, resulting in a #VMEXIT with an exit code value of 0x403.

Provide the necessary support to execute the VMGEXIT instruction, which
is "rep; vmmcall".

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Library/BaseLib/BaseLib.inf   |  2 ++
 MdePkg/Include/Library/BaseLib.h | 14 +
 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm | 37 
 MdePkg/Library/BaseLib/X64/VmgExit.nasm  | 32 
 4 files changed, 85 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 3b93b5db8d24..3b85c56c3c03 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -184,6 +184,7 @@ [Sources.Ia32]
   Ia32/DisableCache.nasm| GCC
   Ia32/RdRand.nasm
   Ia32/XGetBv.nasm
+  Ia32/VmgExit.nasm
 
   Ia32/DivS64x64Remainder.c
   Ia32/InternalSwitchStack.c | MSFT
@@ -317,6 +318,7 @@ [Sources.X64]
   X64/DisablePaging64.nasm
   X64/RdRand.nasm
   X64/XGetBv.nasm
+  X64/VmgExit.nasm
   ChkStkGcc.c  | GCC
 
 [Sources.EBC]
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 7edf0051a0a0..04fb329eaabb 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7848,6 +7848,20 @@ AsmXGetBv (
   );
 
 
+/**
+  Executes a VMGEXIT instruction (VMMCALL with a REP prefix)
+
+  Executes a VMGEXIT instruction. This function is only available on IA-32 and
+  x64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  );
+
+
 /**
   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/VmgExit.nasm 
b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
new file mode 100644
index ..a4b37385cc7a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
@@ -0,0 +1,37 @@
+;--
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+SECTION .text
+
+;--
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+;
+; NASM doesn't support the vmmcall instruction in 32-bit mode, so work around
+; this by temporarily switching to 64-bit mode.
+;
+BITS64
+rep vmmcall
+BITS32
+ret
+
diff --git a/MdePkg/Library/BaseLib/X64/VmgExit.nasm 
b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
new file mode 100644
index ..26f034593c67
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
@@ -0,0 +1,32 @@
+;--
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+DEFAULT REL
+SECTION .text
+
+;--
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+rep vmmcall
+ret
+
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63311): https://edk2.groups.io/g/devel/message/63311
Mute This Topic: https://groups.io/mt/75824947/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 05/46] MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page tables

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

GHCB pages must be mapped as shared pages, so modify the process of
creating identity mapped pagetable entries so that GHCB entries are
created without the encryption bit set. The GHCB range consists of
two pages per CPU, the first being the GHCB and the second being a
per-CPU variable page. Only the GHCB page is mapped as shared.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Dandan Bi 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf   |  2 +
 .../Core/DxeIplPeim/X64/VirtualMemory.h   | 12 +++-
 .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  4 +-
 .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 +++-
 .../Core/DxeIplPeim/X64/VirtualMemory.c   | 57 +++
 5 files changed, 70 insertions(+), 16 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 3f1702854660..19b8a4c8aefa 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -115,6 +115,8 @@ [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable  ## 
SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize## 
CONSUMES
 
 [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
index 2d0493f109e8..6b7c38a441d6 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
@@ -201,6 +201,8 @@ EnableExecuteDisableBit (
   @param[in, out] PageEntry2M   Pointer to 2M page entry.
   @param[in]  StackBase Stack base address.
   @param[in]  StackSize Stack size.
+  @param[in]  GhcbBase  GHCB page area base address.
+  @param[in]  GhcbSize  GHCB page area size.
 
 **/
 VOID
@@ -208,7 +210,9 @@ Split2MPageTo4K (
   IN EFI_PHYSICAL_ADDRESS   PhysicalAddress,
   IN OUT UINT64 *PageEntry2M,
   IN EFI_PHYSICAL_ADDRESS   StackBase,
-  IN UINTN  StackSize
+  IN UINTN  StackSize,
+  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
+  IN UINTN  GhcbSize
   );
 
 /**
@@ -217,6 +221,8 @@ Split2MPageTo4K (
 
   @param[in] StackBase  Stack base address.
   @param[in] StackSize  Stack size.
+  @param[in] GhcbBase   GHCB page area base address.
+  @param[in] GhcbSize   GHCB page area size.
 
   @return The address of 4 level page map.
 
@@ -224,7 +230,9 @@ Split2MPageTo4K (
 UINTN
 CreateIdentityMappingPageTables (
   IN EFI_PHYSICAL_ADDRESS   StackBase,
-  IN UINTN  StackSize
+  IN UINTN  StackSize,
+  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
+  IN UINTN  GhcbkSize
   );
 
 
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 6e8ca824d469..284b34818ca7 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -123,7 +123,7 @@ Create4GPageTablesIa32Pae (
 //
 // Need to split this 2M page that covers stack range.
 //
-Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
StackBase, StackSize);
+Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
StackBase, StackSize, 0, 0);
   } else {
 //
 // Fill in the Page Directory entries
@@ -282,7 +282,7 @@ HandOffToDxeCore (
 //
 // Create page table and save PageMapLevel4 to CR3
 //
-PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE);
+PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE, 0, 
0);
 
 //
 // End of PEI phase signal
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
index f465eb1d8ac4..156a477d8467 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
@@ -35,6 +35,8 @@ HandOffToDxeCore (
   UINT32  Index;
   EFI_VECTOR_HANDOFF_INFO *VectorInfo;
   EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
+  VOID*GhcbBase;
+  UINTN   GhcbSize;
 
   //
   // Clear page 0 and mark it as allocated if NULL pointer detection is 
enabled.
@@ -81,12 +83,19 @@ HandOffToDxeCore (
   TopOfStack = (VOID *) ((UINTN) 

[edk2-devel] [PATCH v12 10/46] UefiPayloadPkg: Prepare UefiPayloadPkg to use the VmgExitLib library

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Various CpuExceptionHandlerLib libraries will updated to use the new
VmgExitLib library. To prevent any build breakage, update the
UefiPayloadPkg DSC files that use a form of the CpuExceptionHandlerLib
library to include the VmgExitLib library.

Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
Reviewed-by: Guo Dong 
Reviewed-by: Maurice Ma 
Signed-off-by: Tom Lendacky 
---
 UefiPayloadPkg/UefiPayloadPkgIa32.dsc| 2 ++
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
index 9a9ca3060e47..460da1c504dc 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
@@ -237,6 +237,7 @@ [LibraryClasses.common.DXE_CORE]
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -249,6 +250,7 @@ [LibraryClasses.common.DXE_DRIVER]
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
index a768a8702c66..942bc9076634 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
@@ -238,6 +238,7 @@ [LibraryClasses.common.DXE_CORE]
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -250,6 +251,7 @@ [LibraryClasses.common.DXE_DRIVER]
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63314): https://edk2.groups.io/g/devel/message/63314
Mute This Topic: https://groups.io/mt/75824959/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 08/46] UefiCpuPkg: Implement library support for VMGEXIT

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

To support handling #VC exceptions and issuing VMGEXIT instructions,
create a library with functions that can be used to perform these
#VC/VMGEXIT related operations. This includes functions for:
  - Handling #VC exceptions
  - Preparing for and issuing a VMGEXIT
  - Performing MMIO-related write operations to support flash emulation
  - Performing AP related boot opeations

The base functions in this driver will not do anything and will return
an error if a return value is required. It is expected that other packages
(like OvmfPkg) will create a version of the library to fully support an
SEV-ES guest.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/UefiCpuPkg.dec |   3 +
 UefiCpuPkg/UefiCpuPkg.dsc |   2 +
 .../Library/VmgExitLibNull/VmgExitLibNull.inf |  27 
 UefiCpuPkg/Include/Library/VmgExitLib.h   | 103 +++
 .../Library/VmgExitLibNull/VmgExitLibNull.c   | 121 ++
 .../Library/VmgExitLibNull/VmgExitLibNull.uni |  15 +++
 6 files changed, 271 insertions(+)
 create mode 100644 UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 create mode 100644 UefiCpuPkg/Include/Library/VmgExitLib.h
 create mode 100644 UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.c
 create mode 100644 UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.uni

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index df5d02bae6b4..cb92f34b6f55 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -53,6 +53,9 @@ [LibraryClasses.IA32, LibraryClasses.X64]
   ##
   MpInitLib|Include/Library/MpInitLib.h
 
+  ##  @libraryclass  Provides function to support VMGEXIT processing.
+  VmgExitLib|Include/Library/VmgExitLib.h
+
 [Guids]
   gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
   gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 0x30, 
0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index afa304128221..f0e58b90ff0a 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -56,6 +56,7 @@ [LibraryClasses]
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
 
 [LibraryClasses.common.SEC]
   PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
@@ -143,6 +144,7 @@ [Components.IA32, Components.X64]
   UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
   UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
+  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
   UefiCpuPkg/SecCore/SecCore.inf
diff --git a/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf 
b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
new file mode 100644
index ..d8770a21c355
--- /dev/null
+++ b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
@@ -0,0 +1,27 @@
+## @file
+#  VMGEXIT Support Library.
+#
+#  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = VmgExitLibNull
+  MODULE_UNI_FILE= VmgExitLibNull.uni
+  FILE_GUID  = 3cd7368f-ef9b-4a9b-9571-2ed93813677e
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = VmgExitLib
+
+[Sources.common]
+  VmgExitLibNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+  BaseLib
+
diff --git a/UefiCpuPkg/Include/Library/VmgExitLib.h 
b/UefiCpuPkg/Include/Library/VmgExitLib.h
new file mode 100644
index ..45fc27d35e29
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/VmgExitLib.h
@@ -0,0 +1,103 @@
+/** @file
+  Public header file for the VMGEXIT Support library class.
+
+  This library class defines some routines used when invoking the VMGEXIT
+  instruction in support of SEV-ES and to handle #VC exceptions.
+
+  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef __VMG_EXIT_LIB_H__
+#define __VMG_EXIT_LIB_H__
+
+#include 
+#include 
+
+
+/**
+  Perform VMGEXIT.
+
+  Sets the necessary fields of the GHCB, invokes the VMGEXIT instruction and
+  then handles the return actions.

[edk2-devel] [PATCH v12 06/46] MdePkg/BaseLib: Add support for the XGETBV instruction

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Under SEV-ES, a CPUID instruction requires the current value of the XCR0
register. In order to retrieve that value, the XGETBV instruction needs
to be executed.

Provide the necessary support to execute the XGETBV instruction.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Library/BaseLib/BaseLib.inf  |  2 ++
 MdePkg/Include/Library/BaseLib.h| 17 +
 MdePkg/Library/BaseLib/Ia32/XGetBv.nasm | 31 ++
 MdePkg/Library/BaseLib/X64/XGetBv.nasm  | 34 +
 4 files changed, 84 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/XGetBv.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index c740a819cacf..3b93b5db8d24 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -183,6 +183,7 @@ [Sources.Ia32]
   Ia32/EnableCache.nasm| GCC
   Ia32/DisableCache.nasm| GCC
   Ia32/RdRand.nasm
+  Ia32/XGetBv.nasm
 
   Ia32/DivS64x64Remainder.c
   Ia32/InternalSwitchStack.c | MSFT
@@ -315,6 +316,7 @@ [Sources.X64]
   X64/EnableDisableInterrupts.nasm
   X64/DisablePaging64.nasm
   X64/RdRand.nasm
+  X64/XGetBv.nasm
   ChkStkGcc.c  | GCC
 
 [Sources.EBC]
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 8e7b87cbda4e..7edf0051a0a0 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7831,6 +7831,23 @@ AsmLfence (
   VOID
   );
 
+/**
+  Executes a XGETBV instruction
+
+  Executes a XGETBV instruction. This function is only available on IA-32 and
+  x64.
+
+  @param[in] IndexExtended control register index
+
+  @return The current value of the extended control register
+**/
+UINT64
+EFIAPI
+AsmXGetBv (
+  IN UINT32  Index
+  );
+
+
 /**
   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/XGetBv.nasm 
b/MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
new file mode 100644
index ..9f7b03bbff35
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
@@ -0,0 +1,31 @@
+;--
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   XGetBv.Asm
+;
+; Abstract:
+;
+;   AsmXgetBv function
+;
+; Notes:
+;
+;--
+
+SECTION .text
+
+;--
+; UINT64
+; EFIAPI
+; AsmXGetBv (
+;   IN UINT32  Index
+;   );
+;--
+global ASM_PFX(AsmXGetBv)
+ASM_PFX(AsmXGetBv):
+mov ecx, [esp + 4]
+xgetbv
+ret
diff --git a/MdePkg/Library/BaseLib/X64/XGetBv.nasm 
b/MdePkg/Library/BaseLib/X64/XGetBv.nasm
new file mode 100644
index ..09f3be8ae0a8
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/XGetBv.nasm
@@ -0,0 +1,34 @@
+;--
+;
+; Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   XGetBv.Asm
+;
+; Abstract:
+;
+;   AsmXgetBv function
+;
+; Notes:
+;
+;--
+
+DEFAULT REL
+SECTION .text
+
+;--
+; UINT64
+; EFIAPI
+; AsmXGetBv (
+;   IN UINT32  Index
+;   );
+;--
+global ASM_PFX(AsmXGetBv)
+ASM_PFX(AsmXGetBv):
+xgetbv
+shl rdx, 32
+or  rax, rdx
+ret
+
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63310): https://edk2.groups.io/g/devel/message/63310
Mute This Topic: https://groups.io/mt/75824946/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 03/46] MdePkg: Add the MSR definition for the GHCB register

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

For SEV-ES, the GHCB page address is stored in the GHCB MSR register
(0xc0010130). Define the register and the format used for register
during GHCB protocol negotiation.

Cc: Michael D Kinney 
Cc: Liming Gao 
Reviewed-by: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Include/Register/Amd/Fam17Msr.h | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h 
b/MdePkg/Include/Register/Amd/Fam17Msr.h
index 6ef45a9b21d3..e4db09c5184c 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -17,6 +17,52 @@
 #ifndef __FAM17_MSR_H__
 #define __FAM17_MSR_H__
 
+/**
+  Secure Encrypted Virtualization - Encrypted State (SEV-ES) GHCB register
+
+**/
+#define MSR_SEV_ES_GHCB0xc0010130
+
+/**
+  MSR information returned for #MSR_SEV_ES_GHCB
+**/
+typedef union {
+  struct {
+UINT32  Function:12;
+UINT32  Reserved1:20;
+UINT32  Reserved2:32;
+  } GhcbInfo;
+
+  struct {
+UINT8   Reserved[3];
+UINT8   SevEncryptionBitPos;
+UINT16  SevEsProtocolMin;
+UINT16  SevEsProtocolMax;
+  } GhcbProtocol;
+
+  struct {
+UINT32  Function:12;
+UINT32  ReasonCodeSet:4;
+UINT32  ReasonCode:8;
+UINT32  Reserved1:8;
+UINT32  Reserved2:32;
+  } GhcbTerminate;
+
+  VOID*Ghcb;
+
+  UINT64  GhcbPhysicalAddress;
+} MSR_SEV_ES_GHCB_REGISTER;
+
+#define GHCB_INFO_SEV_INFO 1
+#define GHCB_INFO_SEV_INFO_GET 2
+#define GHCB_INFO_CPUID_REQUEST4
+#define GHCB_INFO_CPUID_RESPONSE   5
+#define GHCB_INFO_TERMINATE_REQUEST256
+
+#define GHCB_TERMINATE_GHCB0
+#define GHCB_TERMINATE_GHCB_GENERAL0
+#define GHCB_TERMINATE_GHCB_PROTOCOL   1
+
 /**
   Secure Encrypted Virtualization (SEV) status register
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63307): https://edk2.groups.io/g/devel/message/63307
Mute This Topic: https://groups.io/mt/75824936/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 04/46] MdePkg: Add a structure definition for the GHCB

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

The GHCB is used by an SEV-ES guest for communicating between the guest
and the hypervisor. Create the GHCB definition as defined by the GHCB
protocol definition.

Cc: Michael D Kinney 
Cc: Liming Gao 
Reviewed-by: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Include/Register/Amd/Ghcb.h | 166 +
 1 file changed, 166 insertions(+)
 create mode 100644 MdePkg/Include/Register/Amd/Ghcb.h

diff --git a/MdePkg/Include/Register/Amd/Ghcb.h 
b/MdePkg/Include/Register/Amd/Ghcb.h
new file mode 100644
index ..54a80da0f6d7
--- /dev/null
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -0,0 +1,166 @@
+/** @file
+  Guest-Hypervisor Communication Block (GHCB) Definition.
+
+  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.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+  SEV-ES Guest-Hypervisor Communication Block Standardization
+
+**/
+
+#ifndef __GHCB_H__
+#define __GHCB_H__
+
+#include 
+#include 
+#include 
+
+#define UD_EXCEPTION  6
+#define GP_EXCEPTION 13
+#define VC_EXCEPTION 29
+
+#define GHCB_VERSION_MIN 1
+#define GHCB_VERSION_MAX 1
+
+#define GHCB_STANDARD_USAGE  0
+
+//
+// SVM Exit Codes
+//
+#define SVM_EXIT_DR7_READ   0x27ULL
+#define SVM_EXIT_DR7_WRITE  0x37ULL
+#define SVM_EXIT_RDTSC  0x6EULL
+#define SVM_EXIT_RDPMC  0x6FULL
+#define SVM_EXIT_CPUID  0x72ULL
+#define SVM_EXIT_INVD   0x76ULL
+#define SVM_EXIT_IOIO_PROT  0x7BULL
+#define SVM_EXIT_MSR0x7CULL
+#define SVM_EXIT_VMMCALL0x81ULL
+#define SVM_EXIT_RDTSCP 0x87ULL
+#define SVM_EXIT_WBINVD 0x89ULL
+#define SVM_EXIT_MONITOR0x8AULL
+#define SVM_EXIT_MWAIT  0x8BULL
+#define SVM_EXIT_NPF0x400ULL
+
+//
+// VMG Special Exit Codes
+//
+#define SVM_EXIT_MMIO_READ  0x8001ULL
+#define SVM_EXIT_MMIO_WRITE 0x8002ULL
+#define SVM_EXIT_NMI_COMPLETE   0x8003ULL
+#define SVM_EXIT_AP_RESET_HOLD  0x8004ULL
+#define SVM_EXIT_AP_JUMP_TABLE  0x8005ULL
+#define SVM_EXIT_UNSUPPORTED0x8000ULL
+
+//
+// IOIO Exit Information
+//
+#define IOIO_TYPE_STR   BIT2
+#define IOIO_TYPE_IN1
+#define IOIO_TYPE_INS   (IOIO_TYPE_IN | IOIO_TYPE_STR)
+#define IOIO_TYPE_OUT   0
+#define IOIO_TYPE_OUTS  (IOIO_TYPE_OUT | IOIO_TYPE_STR)
+
+#define IOIO_REPBIT3
+
+#define IOIO_ADDR_64BIT9
+#define IOIO_ADDR_32BIT8
+#define IOIO_ADDR_16BIT7
+
+#define IOIO_DATA_32BIT6
+#define IOIO_DATA_16BIT5
+#define IOIO_DATA_8 BIT4
+#define IOIO_DATA_MASK  (BIT6 | BIT5 | BIT4)
+#define IOIO_DATA_OFFSET4
+#define IOIO_DATA_BYTES(x)  (((x) & IOIO_DATA_MASK) >> IOIO_DATA_OFFSET)
+
+#define IOIO_SEG_ES 0
+#define IOIO_SEG_DS (BIT11 | BIT10)
+
+
+typedef enum {
+  GhcbCpl  = 25,
+  GhcbRflags   = 46,
+  GhcbRip,
+  GhcbRsp  = 59,
+  GhcbRax  = 63,
+  GhcbRcx  = 97,
+  GhcbRdx,
+  GhcbRbx,
+  GhcbRbp  = 101,
+  GhcbRsi,
+  GhcbRdi,
+  GhcbR8,
+  GhcbR9,
+  GhcbR10,
+  GhcbR11,
+  GhcbR12,
+  GhcbR13,
+  GhcbR14,
+  GhcbR15,
+  GhcbXCr0 = 125,
+} GHCB_REGISTER;
+
+typedef PACKED struct {
+  UINT8  Reserved1[203];
+  UINT8  Cpl;
+  UINT8  Reserved2[148];
+  UINT64 Dr7;
+  UINT8  Reserved3[144];
+  UINT64 Rax;
+  UINT8  Reserved4[264];
+  UINT64 Rcx;
+  UINT64 Rdx;
+  UINT64 Rbx;
+  UINT8  Reserved5[112];
+  UINT64 SwExitCode;
+  UINT64 SwExitInfo1;
+  UINT64 SwExitInfo2;
+  UINT64 SwScratch;
+  UINT8  Reserved6[56];
+  UINT64 XCr0;
+  UINT8  ValidBitmap[16];
+  UINT64 X87StateGpa;
+  UINT8  Reserved7[1016];
+} GHCB_SAVE_AREA;
+
+typedef PACKED struct {
+  GHCB_SAVE_AREA SaveArea;
+  UINT8  SharedBuffer[2032];
+  UINT8  Reserved1[10];
+  UINT16 ProtocolVersion;
+  UINT32 GhcbUsage;
+} GHCB;
+
+typedef union {
+  struct {
+UINT32  Lower32Bits;
+UINT32  Upper32Bits;
+  } Elements;
+
+  UINT64Uint64;
+} GHCB_EXIT_INFO;
+
+typedef union {
+  struct {
+UINT32  Vector:8;
+UINT32  Type:3;
+UINT32  ErrorCodeValid:1;
+UINT32  Rsvd:19;
+UINT32  Valid:1;
+UINT32  ErrorCode;
+  } Elements;
+
+  UINT64Uint64;
+} GHCB_EVENT_INJECTION;
+
+#define GHCB_EVENT_INJECTION_TYPE_INT0
+#define GHCB_EVENT_INJECTION_TYPE_NMI2
+#define GHCB_EVENT_INJECTION_TYPE_EXCEPTION  3
+#define 

[edk2-devel] [PATCH v12 02/46] UefiCpuPkg: Create PCD to be used in support of SEV-ES

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

A new dynamic UefiCpuPkg PCD is needed to support SEV-ES under OVMF:
  - PcdSevEsIsEnabled: BOOLEAN value used to indicate if SEV-ES is enabled

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Reviewed-by: Eric Dong 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/UefiCpuPkg.dec | 6 ++
 UefiCpuPkg/UefiCpuPkg.uni | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 762badf5d239..df5d02bae6b4 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -370,5 +370,11 @@ [PcdsDynamic, PcdsDynamicEx]
   # @ValidRange  0x8001 | 0 - 1
   gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8|0x6015
 
+  ## This dynamic PCD indicates whether SEV-ES is enabled
+  #   TRUE  - SEV-ES is enabled
+  #   FALSE - SEV-ES is not enabled
+  # @Prompt SEV-ES Status
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|FALSE|BOOLEAN|0x6016
+
 [UserExtensions.TianoCore."ExtraFiles"]
   UefiCpuPkgExtra.uni
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index 1780dfdc126d..f4a0c72f6293 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -278,3 +278,6 @@
 
 #string 
STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuApStatusCheckIntervalInMicroSeconds_PROMPT  
#language en-US "Periodic interval value in microseconds for AP status check in 
DXE.\n"
 #string 
STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuApStatusCheckIntervalInMicroSeconds_HELP
#language en-US "Periodic interval value in microseconds for the status check 
of APs for StartupAllAPs() and StartupThisAP() executed in non-blocking mode in 
DXE phase.\n"
+
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsIsEnabled_PROMPT  #language 
en-US "Specifies whether SEV-ES is enabled"
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdSevEsIsEnabled_HELP#language 
en-US "Set to TRUE when running as an SEV-ES guest, FALSE otherwise."
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63306): https://edk2.groups.io/g/devel/message/63306
Mute This Topic: https://groups.io/mt/75824932/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 01/46] MdeModulePkg: Create PCDs to be used in support of SEV-ES

[Lendacky, Thomas]

From: Tom Lendacky 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198

Two new dynamic MdeModulePkg PCDs are needed to support SEV-ES under OVMF:
  - PcdGhcbBase:   UINT64 value that is the base address of the GHCB
   allocation.
  - PcdGhcbSize:   UINT64 value that is the size, in bytes, of the
   GHCB allocation (size is dependent on the number of
   APs).

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Tom Lendacky 
---
 MdeModulePkg/MdeModulePkg.dec | 9 +
 MdeModulePkg/MdeModulePkg.uni | 8 
 2 files changed, 17 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 843e963ad34b..f8cd9239b4ce 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2051,6 +2051,15 @@ [PcdsDynamic, PcdsDynamicEx]
   # @Prompt If there is any test key used by the platform.
   gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed|FALSE|BOOLEAN|0x00030003
 
+  ## This dynamic PCD holds the base address of the GHCB pool allocation.
+  # @Prompt GHCB Pool Base Address
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0|UINT64|0x00030007
+
+  ## This dynamic PCD holds the total size of the GHCB pool allocation.
+  #  The amount of memory allocated for GHCBs is dependent on the number of 
APs.
+  # @Prompt GHCB Pool Size
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0|UINT64|0x00030008
+
 [PcdsDynamicEx]
   ## This dynamic PCD enables the default variable setting.
   #  Its value is the default store ID value. The default value is zero as 
Standard default.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 2007e0596c4f..2f8cca03e527 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1297,3 +1297,11 @@
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdTcgPfpMeasurementRevision_PROMPT 
#language en-US "TCG Platform Firmware Profile revision"
 
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdTcgPfpMeasurementRevision_HELP 
#language en-US "Indicates which TCG Platform Firmware Profile revision the 
EDKII firmware follows."
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdGhcbBase_PROMPT #language en-US 
"GHCB Pool Base Address"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdGhcbBase_HELP #language en-US 
"Used with SEV-ES support to identify an address range that is not to be 
encrypted."
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdGhcbSize_PROMPT #language en-US 
"GHCB Pool Base Size"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdGhcbSize_HELP #language en-US 
"Used with SEV-ES support to identify the size of the address range that is not 
to be encrypted."
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63305): https://edk2.groups.io/g/devel/message/63305
Mute This Topic: https://groups.io/mt/75824928/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v12 00/46] SEV-ES guest support

[Lendacky, Thomas]

From: Tom Lendacky 

This patch series provides support for running EDK2/OVMF under SEV-ES.

Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].

In order to allow a hypervisor to perform functions on behalf of a guest,
there is architectural support for notifying a guest's operating system
when certain types of VMEXITs are about to occur. This allows the guest to
selectively share information with the hypervisor to satisfy the requested
function. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].

The main areas of the EDK2 code that are updated to support SEV-ES are
around the exception handling support and the AP boot support.

Exception support is required starting in Sec, continuing through Pei
and into Dxe in order to handle #VC exceptions that are generated.  Each
AP requires it's own GHCB page as well as a page to hold values specific
to that AP.

AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. The GHCB document [2] talks about how SMP
booting under SEV-ES is performed.

Since the GHCB page must be a shared (unencrypted) page, the processor
must be running in long mode in order for the guest and hypervisor to
communicate with each other. As a result, SEV-ES is only supported under
the X64 architecture.

[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf

---

These patches are based on commit:
6074f57e5b19 ("MdePkg/Include/IndustryStandard: Main CXL header")

A version of the tree can be found at:
https://github.com/AMDESE/ovmf/tree/sev-es-v20

Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Benjamin You 
Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Guo Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Maurice Ma 
Cc: Michael D Kinney 
Cc: Ray Ni 

Changes since v11:
- Make the XGETBV and VMGEXIT .nasm files buildable for all environments
  and remove the updates that add these instructions to GccInline.c

Changes since v10:
- Fix conflicts around GccInline.c file after moving to latest commit
- Fix conflicts with OVMF PCD values after moving to latest commit

Changes since v9:
- Fixed bit field declarations in the GHCB structure to use UINT32
  and not UINT64.
- Fixed a warning produced by VS2019 in the instruction parsing code
  by expliciting casting a bit shift to an INT64.
- Sorted section entries in the OVMF VmgExitLib INF file.
- Moved the new Maintainers.txt entry so entries remain sorted.
- Documentation style fixes for return values.
- Miscellaneous code style fixes.

Changes since v8:
- Move IOIO exit info definitions into Ghcb.h file
  - Add a macro for calculating IO instruction bytes (IOIO_DATA_BYTES)
- Exception handler support for debug registers
  - Moved the DRx register saving changes into the UefiCpuPkg patch for
base #VC support in CpuExceptionHandlerLib.
- OvmfPkg VmgExitLib
  - Remove the .uni file
  - Update .inf file:
- New file location for VmgExitVcHandler.c
- Add additional Packages and LibraryClasses
- Introduce a header file to hold the #VC instruction parsing related
  definitions
  - Include additional #defines for instruction decoding to replace
hard coded values for things like instruction prefixes and escapes.
- Replace hardcoded CPUID values with values from existing header files
  and use existing CR4 definition for accessing CR4 data.
- Change the type used for obtaining data addresses in the instruction
  parsing
  - Switch from INTN to UINT64 and use compiler conversions and casting
to perform the correct address calculation
- ResetVector code:
  - Revert some inadvertant changes introduced in v7 for reserving the
SEV-ES work area memory and for checking the status of SEV-ES.
- AP Booting
  - Provide support for non-broadcast INIT-SIPI-SIPI AP boot (minimize
code duplication by creating a function to set the AP jump table
vector address).
- Fix file/directory entry in maintainer changes.
- Various coding style fixes
  - Commenting, if statements, etc.
- Various documentation style fixes

Changes since v7:
- Reserve the SEV-ES workarea when S3 is enabled
- Fix warnings issued by the Visual Studio compiler
- Create a NULL VmgExitLib instance that is used for VMGEXIT
  related operations as well as #VC handling. Then create the full
  VmgExitLib support only in OvmfPkg 

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Liming Gao]

Lefi:
  Thanks for your comments.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> Sent: Monday, July 27, 2020 10:25 PM
> To: devel@edk2.groups.io; Javeed, Ashraf 
> Cc: Kinney, Michael D ; Gao, Liming 
> 
> Subject: Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 
> 1.1 Registers
> 
> Hi Ashraf, but also Mike, Liming.
> 
> I just saw this patch go in and have some comments.
> 
> On Fri, Jul 24, 2020 at 23:56:12 +0530, Javeed, Ashraf wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2611
> >
> > Register definitions from chapter 7 of Compute Express Link
> > Specification Revision 1.1 are ported into the new Cxl11.h.
> > The CXL Flex Bus registers are based on the PCIe Extended Capability
> > DVSEC structure header, led to the inclusion of upgraded Pci.h.
> >
> > Signed-off-by: Ashraf Javeed 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > --
> >
> > V4: fix code style
> >
> > V3: Copyright date fix
> >
> > V2: Indentation and double declaration fix, copyright date update
> > ---
> >  MdePkg/Include/IndustryStandard/Cxl11.h | 569
> 
> 
> 
> 
> 
> +
> >  MdePkg/Include/IndustryStandard/Pci.h   |   6 ++
> >  2 files changed, 571 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/Cxl11.h 
> > b/MdePkg/Include/IndustryStandard/Cxl11.h
> > new file mode 100644
> > index 00..933c1ab817
> > --- /dev/null
> > +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> > @@ -0,0 +1,569 @@
> > +/** @file
> > +  CXL 1.1 Register definitions
> > +
> > +  This file contains the register definitions based on the Compute Express 
> > Link
> > +  (CXL) Specification Revision 1.1.
> > +
> > +Copyright (c) 2020, Intel Corporation. All rights reserved.
> > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#ifndef _CXL11_H_
> > +#define _CXL11_H_
> 
> We should not be adding macros with a leading _ - these are intended
> for toolchain use.

This style is align to other header file. This is the file header macro to make 
sure the header file be included more than once. 

> 
> > +
> > +#include 
> > +//
> > +// DVSEC Vendor ID
> > +// Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1 - 
> > Table 58
> > +// (subject to change as per CXL assigned Vendor ID)
> > +//
> > +#define INTEL_CXL_DVSEC_VENDOR_ID   
> > 0x8086
> 
> This is Cxl11.h - surely this should be CXL_DVSEC_VENDOR_ID_INTEL?

Ashraf: is it defined in spec?

> 
> > +
> > +//
> > +// CXL Flex Bus Device default device and function number
> > +// Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1
> > +//
> > +#define CXL_DEV_DEV 0
> > +#define CXL_DEV_FUNC0
> > +
> > +//
> > +// Ensure proper structure formats
> > +//
> > +#pragma pack(1)
> 
> And this pragma has no function whatsoever with regards to any of the
> register definition structs below. It would be much better if the
> structs requiring packing (_DEVICE, _PORT, ...) were grouped together
> and only those were given this treatment.
> 
> #pragma pack(1) is *not* a safe default.
> 

I know pack(1) is for the compact structure layout. 

> > +
> > +///
> > +/// The PCIe DVSEC for Flex Bus Device
> > +///@{
> > +typedef union {
> > +  struct {
> > +UINT16 CacheCapable : 1; // 
> > bit 0
> > +UINT16 IoCapable: 1; // 
> > bit 1
> > +UINT16 MemCapable   : 1; // 
> > bit 2
> > +UINT16 MemHwInitMode: 1; // 
> > bit 3
> > +UINT16 HdmCount : 2; // 
> > bit 4..5
> > +UINT16 Reserved1: 8; // 
> > bit 6..13
> > +UINT16 ViralCapable : 1; // 
> > bit 14
> > +UINT16 Reserved2: 1; // 
> > bit 15
> > +  } Bits;
> > +  UINT16Uint16;
> > +} CXL_DVSEC_FLEX_BUS_DEVICE_CAPABILITY;
> > +
> > +typedef union {
> > +  struct {
> > +UINT16 CacheEnable  : 1; // 
> > bit 0
> > +UINT16 IoEnable   

Re: [edk2-devel] [PATCH V4 1/2] MdePkg/Include/IndustryStandard: CXL 1.1 Registers

[Leif Lindholm]

Hi Ashraf, but also Mike, Liming.

I just saw this patch go in and have some comments.

On Fri, Jul 24, 2020 at 23:56:12 +0530, Javeed, Ashraf wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2611
> 
> Register definitions from chapter 7 of Compute Express Link
> Specification Revision 1.1 are ported into the new Cxl11.h.
> The CXL Flex Bus registers are based on the PCIe Extended Capability
> DVSEC structure header, led to the inclusion of upgraded Pci.h.
> 
> Signed-off-by: Ashraf Javeed 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> --
> 
> V4: fix code style
> 
> V3: Copyright date fix
> 
> V2: Indentation and double declaration fix, copyright date update
> ---
>  MdePkg/Include/IndustryStandard/Cxl11.h | 569 
> +
>  MdePkg/Include/IndustryStandard/Pci.h   |   6 ++
>  2 files changed, 571 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Cxl11.h 
> b/MdePkg/Include/IndustryStandard/Cxl11.h
> new file mode 100644
> index 00..933c1ab817
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/Cxl11.h
> @@ -0,0 +1,569 @@
> +/** @file
> +  CXL 1.1 Register definitions
> +
> +  This file contains the register definitions based on the Compute Express 
> Link
> +  (CXL) Specification Revision 1.1.
> +
> +Copyright (c) 2020, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef _CXL11_H_
> +#define _CXL11_H_

We should not be adding macros with a leading _ - these are intended
for toolchain use.

> +
> +#include 
> +//
> +// DVSEC Vendor ID
> +// Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1 - Table 
> 58
> +// (subject to change as per CXL assigned Vendor ID)
> +//
> +#define INTEL_CXL_DVSEC_VENDOR_ID   
> 0x8086

This is Cxl11.h - surely this should be CXL_DVSEC_VENDOR_ID_INTEL?

> +
> +//
> +// CXL Flex Bus Device default device and function number
> +// Compute Express Link Specification Revision: 1.1 - Chapter 7.1.1
> +//
> +#define CXL_DEV_DEV 0
> +#define CXL_DEV_FUNC0
> +
> +//
> +// Ensure proper structure formats
> +//
> +#pragma pack(1)

And this pragma has no function whatsoever with regards to any of the
register definition structs below. It would be much better if the
structs requiring packing (_DEVICE, _PORT, ...) were grouped together
and only those were given this treatment.

#pragma pack(1) is *not* a safe default.

> +
> +///
> +/// The PCIe DVSEC for Flex Bus Device
> +///@{
> +typedef union {
> +  struct {
> +UINT16 CacheCapable : 1; // bit 0
> +UINT16 IoCapable: 1; // bit 1
> +UINT16 MemCapable   : 1; // bit 2
> +UINT16 MemHwInitMode: 1; // bit 3
> +UINT16 HdmCount : 2; // bit 
> 4..5
> +UINT16 Reserved1: 8; // bit 
> 6..13
> +UINT16 ViralCapable : 1; // bit 
> 14
> +UINT16 Reserved2: 1; // bit 
> 15
> +  } Bits;
> +  UINT16Uint16;
> +} CXL_DVSEC_FLEX_BUS_DEVICE_CAPABILITY;
> +
> +typedef union {
> +  struct {
> +UINT16 CacheEnable  : 1; // bit 0
> +UINT16 IoEnable : 1; // bit 1
> +UINT16 MemEnable: 1; // bit 2
> +UINT16 CacheSfCoverage  : 5; // bit 
> 3..7
> +UINT16 CacheSfGranularity   : 3; // bit 
> 8..10
> +UINT16 CacheCleanEviction   : 1; // bit 
> 11
> +UINT16 Reserved1: 2; // bit 
> 12..13
> +UINT16 ViralEnable  : 1; // bit 
> 14
> +UINT16 Reserved2: 1; // bit 
> 15
> +  } Bits;
> +  UINT16Uint16;
> +} CXL_DVSEC_FLEX_BUS_DEVICE_CONTROL;
> +
> +typedef union {
> +  struct {
> +UINT16 Reserved1  

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[Liming Gao]

Leif:
  VFR file has the similar case. VFR is converted to xxx.c, then compile it to 
obj file. 

Bob:
  Has BaseTools such detection if VFR and C source file have the same file name?

Thanks
Liming
> -Original Message-
> From: Leif Lindholm 
> Sent: Monday, July 27, 2020 9:58 PM
> To: devel@edk2.groups.io; pierre.gond...@arm.com; Masahisa Kojima 
> 
> Cc: sami.muja...@arm.com; tomas.pi...@arm.com; Feng, Bob C 
> ; Gao, Liming ; Ard
> Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode 
> arrays into .obj file
> 
> Hi Pierre, (+Masahisa)
> 
> This commit (0a4aa20e8d44) made for an exciting start to my week.
> 
> Socionext's Developerbox failed to build for me, with the spectacular
> error message:
> 
> /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld:
> DWARF error: could not find abbrev number 5912
> /tmp/ccKt4gaM.ltrans0.ltrans.o: in function `RegisterDevices':
> :(.text.RegisterDevices+0xb0): undefined reference to
> `RegisterEmmc'
> 
> GCC49 (without lto) and CLANG38 profiles give much the same result,
> with slightly less esoteric messages.
> 
> The reason for this turned out to be that edk2-platforms
> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/ has both an Emmc.asl
> and an Emmc.c file, which after this patch both generate an Emmc.obj
> in the same output directory.
> 
> I think the correct course of action is to fix this in the SynQuacer
> driver, but I am reporting it here so we get it logged in the list
> archives.
> 
> It would of course be good if the build system could detect and warn
> over cases like this, rather than silently overwriting existing object
> files.
> 
> Masahisa - since Ard is still on holiday, could you create a patch and
> send out for me to review? Either one of the files needs to be
> renamed, or we need to move the .asl files (Emmc.asl and Optee.asl)
> into a subdirectory.
> 
> Best Regards,
> 
> Leif
> 
> On Wed, Jul 01, 2020 at 15:06:03 +0100, PierreGondois wrote:
> > From: Pierre Gondois 
> >
> > The AmlToHex script and Posix/WindowsLike wrappers convert
> > an AML file to a .hex file, containing a C array storing
> > AML bytecode. This ".hex" file can then be included in a
> > C file, allowing to access the AML bytecode from this C
> > file.
> >
> > The EDK2 build system doesn't allow to a depict dependency
> > orders between files of different languages. For instance,
> > in a module containing a ".c" file and a ".asl", the ".c"
> > file may or may not be built prior to the ".asl" file.
> > This prevents any inclusion of a generated ".hex" in a
> > ".c" file since this later ".hex" file may or may not
> > have been created yet.
> >
> > This patch modifies the AmlToC script to generate a C file
> > instead of a ".hex" file.
> > It also adds the generation of an intermediate ".amli" file
> > when compiling an ASL file, and adds a rule to convert this
> > ".amli" to a C file.
> >
> > This allows to generate a C file containing the AML bytecode
> > from an ASL file. This C file will then be handled by the EDK2
> > build system to generate an object file.
> > Thus, no file inclusion will be required anymore. The C file
> > requiring the AML bytecode as a C array, and the ASL file,
> > will be compiled independently. The C array must be defined
> > as an external symbol. The linker is resolving the
> > reference to the C array symbol.
> >
> > To summarize, the flow goes as:
> >  -1. ASL file is compiled to AML;
> >  -2. AML file is copied to a ".amli" intermediate file;
> >  -3. EDK2 build system applies the rule relevant to ".amli"
> >  files. This is, calling the "AmlToC" script, generating
> >  a C file from the ".amli" file;
> >  -4. EDK2 build system applies the rule relevant to C files.
> >  This is creating an object file.
> >  -5. EDK2 build system links the object file containing the
> >  AML bytecode with the object file requiring it.
> >
> > Signed-off-by: Pierre Gondois 
> > Suggested-by: Tomas Pilar 
> > ---
> >
> > The changes can be seen at: 
> > https://github.com/PierreARM/edk2/commits/803_Compile_AML_bytecode_array_into_OBJ_file_v5
> >
> > Notes:
> > v1:
> >  - Add a new rule to the build_rule.template file to
> >generate ".obj" files from .asl files, and modify
> >the AmlToC script accordingly. [Pierre]
> > v2:
> >  - Restrict the rule to DXE_DRIVER. This allows to build
> >the OvmfPkg, which was not the case in v1. [Pierre]
> > v3:
> >  - Changed "Signed-off-by" to "Suggested-by". [Bob]
> > v4:
> > - No modification. Re-sending the patch with base64
> >   encoding to conserve the right line endings. [Bob]
> > v5:
> >  - No modification. [Pierre]
> >
> >  BaseTools/Conf/build_rule.template   | 15 +++-
> >  BaseTools/Source/Python/AmlToC/AmlToC.py | 82 
> >  2 files changed, 47 insertions(+), 50 deletions(-)
> >
> > diff --git a/BaseTools/Conf/build_rule.template 
> > 

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[Sami Mujawar]

Hi Leif,

Would updating build_rule.template so that the AmlToC Script generates a C file 
with an AutoGen prefix be an option?

Regards,

Sami Mujawar

-Original Message-
From: Leif Lindholm 
Sent: 27 July 2020 02:58 PM
To: devel@edk2.groups.io; Pierre Gondois ; Masahisa 
Kojima 
Cc: Sami Mujawar ; Tomas Pilar ; 
bob.c.f...@intel.com; liming@intel.com; Ard Biesheuvel 

Subject: Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays 
into .obj file

Hi Pierre, (+Masahisa)

This commit (0a4aa20e8d44) made for an exciting start to my week.

Socionext's Developerbox failed to build for me, with the spectacular error 
message:

/usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld:
DWARF error: could not find abbrev number 5912
/tmp/ccKt4gaM.ltrans0.ltrans.o: in function `RegisterDevices':
:(.text.RegisterDevices+0xb0): undefined reference to `RegisterEmmc'

GCC49 (without lto) and CLANG38 profiles give much the same result, with 
slightly less esoteric messages.

The reason for this turned out to be that edk2-platforms 
Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/ has both an Emmc.asl and an 
Emmc.c file, which after this patch both generate an Emmc.obj in the same 
output directory.

I think the correct course of action is to fix this in the SynQuacer driver, 
but I am reporting it here so we get it logged in the list archives.

It would of course be good if the build system could detect and warn over cases 
like this, rather than silently overwriting existing object files.

Masahisa - since Ard is still on holiday, could you create a patch and send out 
for me to review? Either one of the files needs to be renamed, or we need to 
move the .asl files (Emmc.asl and Optee.asl) into a subdirectory.

Best Regards,

Leif

On Wed, Jul 01, 2020 at 15:06:03 +0100, PierreGondois wrote:
> From: Pierre Gondois 
>
> The AmlToHex script and Posix/WindowsLike wrappers convert an AML file
> to a .hex file, containing a C array storing AML bytecode. This ".hex"
> file can then be included in a C file, allowing to access the AML
> bytecode from this C file.
>
> The EDK2 build system doesn't allow to a depict dependency orders
> between files of different languages. For instance, in a module
> containing a ".c" file and a ".asl", the ".c"
> file may or may not be built prior to the ".asl" file.
> This prevents any inclusion of a generated ".hex" in a ".c" file since
> this later ".hex" file may or may not have been created yet.
>
> This patch modifies the AmlToC script to generate a C file instead of
> a ".hex" file.
> It also adds the generation of an intermediate ".amli" file when
> compiling an ASL file, and adds a rule to convert this ".amli" to a C
> file.
>
> This allows to generate a C file containing the AML bytecode from an
> ASL file. This C file will then be handled by the EDK2 build system to
> generate an object file.
> Thus, no file inclusion will be required anymore. The C file requiring
> the AML bytecode as a C array, and the ASL file, will be compiled
> independently. The C array must be defined as an external symbol. The
> linker is resolving the reference to the C array symbol.
>
> To summarize, the flow goes as:
>  -1. ASL file is compiled to AML;
>  -2. AML file is copied to a ".amli" intermediate file;  -3. EDK2
> build system applies the rule relevant to ".amli"
>  files. This is, calling the "AmlToC" script, generating
>  a C file from the ".amli" file;
>  -4. EDK2 build system applies the rule relevant to C files.
>  This is creating an object file.
>  -5. EDK2 build system links the object file containing the
>  AML bytecode with the object file requiring it.
>
> Signed-off-by: Pierre Gondois 
> Suggested-by: Tomas Pilar 
> ---
>
> The changes can be seen at:
> https://github.com/PierreARM/edk2/commits/803_Compile_AML_bytecode_arr
> ay_into_OBJ_file_v5
>
> Notes:
> v1:
>  - Add a new rule to the build_rule.template file to
>generate ".obj" files from .asl files, and modify
>the AmlToC script accordingly. [Pierre]
> v2:
>  - Restrict the rule to DXE_DRIVER. This allows to build
>the OvmfPkg, which was not the case in v1. [Pierre]
> v3:
>  - Changed "Signed-off-by" to "Suggested-by". [Bob]
> v4:
> - No modification. Re-sending the patch with base64
>   encoding to conserve the right line endings. [Bob]
> v5:
>  - No modification. [Pierre]
>
>  BaseTools/Conf/build_rule.template   | 15 +++-
>  BaseTools/Source/Python/AmlToC/AmlToC.py | 82 
>  2 files changed, 47 insertions(+), 50 deletions(-)
>
> diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> index
> 0822b681fcd9f61c6508e6f93ffc31fa70fd7059..c034869915914936e28f64a6aadb
> a08e0169da44 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -419,6 +419,7 @@
>
>  
>  

Re: [edk2-devel] [PATCH v5 4/5] BaseTools: Compile AML bytecode arrays into .obj file

[Leif Lindholm]

Hi Pierre, (+Masahisa)

This commit (0a4aa20e8d44) made for an exciting start to my week.

Socionext's Developerbox failed to build for me, with the spectacular
error message:

/usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld:
DWARF error: could not find abbrev number 5912
/tmp/ccKt4gaM.ltrans0.ltrans.o: in function `RegisterDevices':
:(.text.RegisterDevices+0xb0): undefined reference to
`RegisterEmmc'

GCC49 (without lto) and CLANG38 profiles give much the same result,
with slightly less esoteric messages.

The reason for this turned out to be that edk2-platforms
Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/ has both an Emmc.asl
and an Emmc.c file, which after this patch both generate an Emmc.obj
in the same output directory.

I think the correct course of action is to fix this in the SynQuacer
driver, but I am reporting it here so we get it logged in the list
archives.

It would of course be good if the build system could detect and warn
over cases like this, rather than silently overwriting existing object
files.

Masahisa - since Ard is still on holiday, could you create a patch and
send out for me to review? Either one of the files needs to be
renamed, or we need to move the .asl files (Emmc.asl and Optee.asl)
into a subdirectory.

Best Regards,

Leif

On Wed, Jul 01, 2020 at 15:06:03 +0100, PierreGondois wrote:
> From: Pierre Gondois 
> 
> The AmlToHex script and Posix/WindowsLike wrappers convert
> an AML file to a .hex file, containing a C array storing
> AML bytecode. This ".hex" file can then be included in a
> C file, allowing to access the AML bytecode from this C
> file.
> 
> The EDK2 build system doesn't allow to a depict dependency
> orders between files of different languages. For instance,
> in a module containing a ".c" file and a ".asl", the ".c"
> file may or may not be built prior to the ".asl" file.
> This prevents any inclusion of a generated ".hex" in a
> ".c" file since this later ".hex" file may or may not
> have been created yet.
> 
> This patch modifies the AmlToC script to generate a C file
> instead of a ".hex" file.
> It also adds the generation of an intermediate ".amli" file
> when compiling an ASL file, and adds a rule to convert this
> ".amli" to a C file.
> 
> This allows to generate a C file containing the AML bytecode
> from an ASL file. This C file will then be handled by the EDK2
> build system to generate an object file.
> Thus, no file inclusion will be required anymore. The C file
> requiring the AML bytecode as a C array, and the ASL file,
> will be compiled independently. The C array must be defined
> as an external symbol. The linker is resolving the
> reference to the C array symbol.
> 
> To summarize, the flow goes as:
>  -1. ASL file is compiled to AML;
>  -2. AML file is copied to a ".amli" intermediate file;
>  -3. EDK2 build system applies the rule relevant to ".amli"
>  files. This is, calling the "AmlToC" script, generating
>  a C file from the ".amli" file;
>  -4. EDK2 build system applies the rule relevant to C files.
>  This is creating an object file.
>  -5. EDK2 build system links the object file containing the
>  AML bytecode with the object file requiring it.
> 
> Signed-off-by: Pierre Gondois 
> Suggested-by: Tomas Pilar 
> ---
> 
> The changes can be seen at: 
> https://github.com/PierreARM/edk2/commits/803_Compile_AML_bytecode_array_into_OBJ_file_v5
> 
> Notes:
> v1:
>  - Add a new rule to the build_rule.template file to
>generate ".obj" files from .asl files, and modify
>the AmlToC script accordingly. [Pierre]
> v2:
>  - Restrict the rule to DXE_DRIVER. This allows to build
>the OvmfPkg, which was not the case in v1. [Pierre]
> v3:
>  - Changed "Signed-off-by" to "Suggested-by". [Bob]
> v4:
> - No modification. Re-sending the patch with base64
>   encoding to conserve the right line endings. [Bob]
> v5:
>  - No modification. [Pierre]
> 
>  BaseTools/Conf/build_rule.template   | 15 +++-
>  BaseTools/Source/Python/AmlToC/AmlToC.py | 82 
>  2 files changed, 47 insertions(+), 50 deletions(-)
> 
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> index 
> 0822b681fcd9f61c6508e6f93ffc31fa70fd7059..c034869915914936e28f64a6aadba08e0169da44
>  100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -419,6 +419,7 @@
>  
>  
>  $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
> +$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.amli
>  
>  
>  $(MAKE_FILE)
> @@ -428,14 +429,24 @@
>  "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) /I${s_path} 
> $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
> $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
>  Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
> $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
>  "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
> 

Re: [edk2-devel] [edk2-platforms] [PATCH v3 0/2] Add USB driver support

[Meenakshi Aggarwal (OSS)]

Thanks Leif,

We will take care of same in future patches.

> -Original Message-
> From: Leif Lindholm 
> Sent: Friday, July 24, 2020 10:17 PM
> To: Meenakshi Aggarwal (OSS) 
> Cc: ard.biesheu...@arm.com; michael.d.kin...@intel.com;
> devel@edk2.groups.io; Varun Sethi 
> Subject: Re: [edk2-platforms] [PATCH v3 0/2] Add USB driver support
> 
> On Fri, Jul 10, 2020 at 01:33:54 +0530, Meenakshi Aggarwal wrote:
> > This patchset implement USB driver for DWC3 controller and enable USB
> > for LX2160A Platform.
> >
> > Changes in v2:
> > - Indentation changes
> > - Incorporated review comments
> > - create EndOfDxe event and initialize USB in EndOfDxe
> >   callback function.
> >
> > Changes in v3:
> > - Passing Usb initialization function as init function
> >   of RegisterNonDiscoverableMmioDevice()
> >
> > Meenakshi Aggarwal (2):
> >   Silicon/NXP: Add DWC3 USB controller initialization driver
> >   Platform/NXP:LX2160: Enable support of USB controller
> 
> For series:
> Reviewed-by: Leif Lindholm 
> 
> However, in future, please rebase patches onto current master before
> sumitting later revisions. This set conflicted with 7c552c1a2611
> ("Platform/NXP: LX2160aRdbPkg: Enable PlatformDxe driver") which was
> pushed on 3 July.
> 
> Pushed (together with SATA series previously reviewed) as:
> b972f17b329a..7de21b6aa3e0
> 
> >  Silicon/NXP/NxpQoriqLs.dec   |   5 +
> >  Silicon/NXP/LX2160A/LX2160A.dsc.inc  |   4 +
> >  Silicon/NXP/NxpQoriqLs.dsc.inc   |  12 +
> >  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc |   1 +
> >  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf |  18 +-
> > Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.inf |  45 
> >  Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.h   | 138 ++
> >  Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.c   | 275
> 
> >  8 files changed, 495 insertions(+), 3 deletions(-)  create mode
> > 100644 Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.inf
> >  create mode 100644 Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.h
> >  create mode 100644 Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.c
> >
> > --
> > 1.9.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63298): https://edk2.groups.io/g/devel/message/63298
Mute This Topic: https://groups.io/mt/75403794/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] MdePkg Base.h: Delete prototype for __builtin_return_address

[Jessica Clarke]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1004

Being a compiler builtin, the type of __builtin_return_address is
already known to the compiler so no prototype is needed. Clang also
errors out when redeclaring certain builtins like this[1], though
currently only for ones with custom type checking. At the moment,
__builtin_return_address does not use custom type checking and so does
not trigger this error, however, the CHERI fork of LLVM, which will form
the basis of the toolchain for Arm's experimental Morello platform, does
use custom type checking for it, and so gives an error. Thus, simply
delete the unnecessary line.

[1] llvm/llvm-project@41af97137572ad6d4dafc872e7ecf6bbb08d4984

Cc: Leif Lindholm 
Signed-off-by: Jessica Clarke 
---
Changes in v2:
 * Shortened [1] reference to fit column limit. The bug report has the
   full URL already, and this will still link correctly on GitHub.

 MdePkg/Include/Base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 85a091b9d5..8e4271f6ea 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -1273,7 +1273,6 @@ typedef UINTN RETURN_STATUS;
   **/
   #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
 #elif defined (__GNUC__) || defined (__clang__)
-  void * __builtin_return_address (unsigned int level);
   /**
 Get the return address of the calling function.
 
--
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63297): https://edk2.groups.io/g/devel/message/63297
Mute This Topic: https://groups.io/mt/75819415/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for LicenseCheck

[Laszlo Ersek]

On 07/27/20 08:21, Zhang, Shenglei wrote:
> Hi Laszlo,
> 
> VbeShim.h is existing in edk2 now. This plugin only checks the patches to be 
> checked in.
> So there's no need to add existing files to this section.

OK, thanks, we can always extend this stanza later, if needed.

Rebecca: once this patch is upstream, please post a separate patch for listing 
"OvmfPkg/Bhyve/BhyveRfbDxe/VbeShim.h" in "IgnoreFiles". Otherwise I won't be 
able to merge your patch at .


Shenglei: I have a question regarding IgnoreFiles syntax. In 
"MdeModulePkg/MdeModulePkg.ci.yaml", there are two syntaxes:

- The IgnoreFiles stanza for "CharEncodingCheck" uses pathnames that are 
relative to the *project* root:

> ## options defined ci/Plugin/CharEncodingCheck
> "CharEncodingCheck": {
> "IgnoreFiles": [
> 
> "MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/test/testc.c",
> 
> "MdeModulePkg/Universal/RegularExpressionDxe/oniguruma/windows/testc.c"
> ]
> },

- The IgnoreFiles stanza for "SpellCheck" uses pathnames that are relative to 
the *package* (not project) root:

> "SpellCheck": {
> ...
> "IgnoreFiles": [ # use gitignore syntax to ignore errors 
> in matching files
> "Library/LzmaCustomDecompressLib/Sdk/DOC/*"
> ],

How do we know whether a particular check's IgnoreFiles stanza requires 
project-root-relative or package-root-relative pathnames?

Thanks!
Laszlo

> Thanks,
> Shenglei
> 
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Tuesday, July 21, 2020 6:01 AM
>> To: Zhang, Shenglei ; devel@edk2.groups.io
>> Cc: Justen, Jordan L ; Ard Biesheuvel
>> 
>> Subject: Re: [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for
>> LicenseCheck
>>
>> On 07/20/20 10:37, Shenglei Zhang wrote:
>>> Add configuration IgnoreFiles for package config files.
>>> So users can rely on this to skip license conflict for
>>> some generated files.
>>>
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Signed-off-by: Shenglei Zhang 
>>> ---
>>>  OvmfPkg/OvmfPkg.ci.yaml | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/OvmfPkg/OvmfPkg.ci.yaml b/OvmfPkg/OvmfPkg.ci.yaml
>>> index 98992f0429ff..ed342d7a3d08 100644
>>> --- a/OvmfPkg/OvmfPkg.ci.yaml
>>> +++ b/OvmfPkg/OvmfPkg.ci.yaml
>>> @@ -8,6 +8,10 @@
>>>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>>>  ##
>>>  {
>>> +## options defined .pytool/Plugin/LicenseCheck
>>> +"LicenseCheck": {
>>> +"IgnoreFiles": []
>>> +},
>>>  ## options defined .pytool/Plugin/CompilerPlugin
>>>  "CompilerPlugin": {
>>>  "DscPath": "" # Don't support this test
>>>
>>
>> Can you list the following file at once, please:
>>
>>   OvmfPkg/QemuVideoDxe/VbeShim.h
>>
>> With that:
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> Thanks
>> Laszlo
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63296): https://edk2.groups.io/g/devel/message/63296
Mute This Topic: https://groups.io/mt/75678218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v8 2/9] MdeModulePkg/PeiCore: Enable T-RAM evacuation in PeiCore (CVE-2019-11098)

[Laszlo Ersek]

On 07/24/20 11:54, Guomin Jiang wrote:
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
> 
> Introduces new changes to PeiCore to move the contents of temporary
> RAM visible to the PeiCore to permanent memory. This expands on
> pre-existing shadowing support in the PeiCore to perform the following
> additional actions:
> 
>  1. Migrate pointers in PPIs installed in PeiCore to the permanent
> memory copy of PeiCore.
> 
>  2. Copy all installed firmware volumes to permanent memory.
> 
>  3. Relocate and fix up the PEIMs within the firmware volumes.
> 
>  4. Convert all PPIs into the migrated firmware volume to the corresponding
> PPI address in the permanent memory location.
> 
> This applies to PPIs and PEI notifications.
> 
>  5. Convert all status code callbacks in the migrated firmware volume to
> the corresponding address in the permanent memory location.
> 
>  6. Update the FV HOB to the corresponding firmware volume in permanent
> memory.
> 
>  7. Use PcdMigrateTemporaryRamFirmwareVolumes to control if enable the
> feature or not. when disable the PCD, the EvacuateTempRam() will
> never be called.
> 
> The function control flow as below:
>   PeiCore()
> DumpPpiList()
> EvacuateTempRam()
>   ConvertPeiCorePpiPointers()
> ConvertPpiPointersFv()
>   MigratePeimsInFv()
> MigratePeim()
>   PeiGetPe32Data()
>   LoadAndRelocatePeCoffImageInPlace()
>   MigrateSecModulesInFv()
>   ConvertPpiPointersFv()
>   ConvertStatusCodeCallbacks()
>   ConvertFvHob()
>   RemoveFvHobsInTemporaryMemory()
> DumpPpiList()
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Debkumar De 
> Cc: Harry Han 
> Cc: Catharine West 
> Signed-off-by: Michael Kubacki 
> ---
>  MdeModulePkg/Core/Pei/PeiMain.inf |   2 +
>  MdeModulePkg/Core/Pei/PeiMain.h   | 169 +++
>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 417 +-
>  MdeModulePkg/Core/Pei/Image/Image.c   | 130 +-
>  MdeModulePkg/Core/Pei/Memory/MemoryServices.c |  82 
>  MdeModulePkg/Core/Pei/PeiMain/PeiMain.c   |  22 +-
>  MdeModulePkg/Core/Pei/Ppi/Ppi.c   | 286 
>  7 files changed, 1099 insertions(+), 9 deletions(-)

Acked-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63295): https://edk2.groups.io/g/devel/message/63295
Mute This Topic: https://groups.io/mt/75763376/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v8 1/9] MdeModulePkg: Add new PCD to control the evacuate temporary memory feature (CVE-2019-11098)

[Laszlo Ersek]

On 07/24/20 11:54, Guomin Jiang wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
> 
> The security researcher found that we can get control after NEM disable.
> 
> The reason is that the flash content reside in NEM at startup and the
> code will get the content from flash directly after disable NEM.
> 
> To avoid this vulnerability, the feature will copy the PEIMs from
> temporary memory to permanent memory and only execute the code in
> permanent memory.
> 
> The vulnerability is exist in physical platform and haven't report in
> virtual platform, so the virtual can disable the feature currently.
> 
> When enable the PcdMigrateTemporaryRamFirmwareVolumes, always shadow
> all PEIMs no matter the condition of PcdShadowPeimOnBoot or
> PcdShadowPeimOnS3Boot.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Guomin Jiang 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 9 +
>  MdeModulePkg/MdeModulePkg.uni | 6 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 843e963ad34b..45874e9c8236 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1220,6 +1220,15 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># @Prompt Shadow Peim and PeiCore on boot
>gEfiMdeModulePkgTokenSpaceGuid.PcdShadowPeimOnBoot|TRUE|BOOLEAN|0x30001029
>  
> +  ## Enable the feature that evacuate temporary memory to permanent memory 
> or not
> +  #  Set FALSE as default, if the developer need this feature to avoid this 
> vulnerability, please
> +  #  enable it to shadow all PEIMs no matter the behavior controled by 
> PcdShadowPeimOnBoot or
> +  #  PcdShadowPeimOnS3Boot
> +  #  TRUE - Evacuate temporary memory, the actions include copy memory, 
> convert PPI pointers and so on.
> +  #  FALSE - Do nothing, for example, no copy memory, no convert PPI 
> pointers and so on.
> +  # @Prompt Evacuate temporary memory to permanent memory
> +  
> gEfiMdeModulePkgTokenSpaceGuid.PcdMigrateTemporaryRamFirmwareVolumes|FALSE|BOOLEAN|0x3000102A
> +
>## The mask is used to control memory profile behavior.
>#  BIT0 - Enable UEFI memory profile.
>#  BIT1 - Enable SMRAM profile.
> diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
> index 2007e0596c4f..5235dee561ad 100644
> --- a/MdeModulePkg/MdeModulePkg.uni
> +++ b/MdeModulePkg/MdeModulePkg.uni
> @@ -214,6 +214,12 @@
>   
>   "TRUE  - Shadow PEIM on S3 boot path after memory is ready.\n"
>   
>   "FALSE - Not shadow PEIM on S3 boot path after memory is ready."
>  
> +#string 
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdMigrateTemporaryRamFirmwareVolumes_HELP 
> #language en-US "Enable the feature that evacuate temporary memory to 
> permanent memory or not.\n"
> + 
>  "It will allocate page to save the temporary PEIMs 
> resided in NEM(or CAR) to the permanent memory and change all pointers 
> pointed to the NEM(or CAR) to permanent memory.\n"
> + 
>  "After then, there are no pointer pointed to NEM(or 
> CAR) and TOCTOU volnerability can be avoid.\n"
> +
> +#string 
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdMigrateTemporaryRamFirmwareVolumes_PROMPT
>  #language en-US "Enable the feature that evacuate temporary memory to 
> permanent memory or not"
> +
>  #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdAcpiDefaultOemId_PROMPT  
> #language en-US "Default OEM ID for ACPI table creation"
>  
>  #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdAcpiDefaultOemId_HELP  
> #language en-US "Default OEM ID for ACPI table creation, its length must be 
> 0x6 bytes to follow ACPI specification."
> 

Acked-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63294): https://edk2.groups.io/g/devel/message/63294
Mute This Topic: https://groups.io/mt/75763375/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Laszlo Ersek]

Hi Vladimir,

On 07/23/20 22:50, Vladimir Olovyannikov via groups.io wrote:
> Signed-off-by: Vladimir Olovyannikov 
> Tested-By: Samer El-Haj-Mahmoud 
> Tested-By: Laszlo Ersek 
> Cc: Zhichao Gao 
> Cc: Maciej Rabeda 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Nd 
>
> This patchset introduces an http client utilizing EDK2 HTTP protocol, to
> allow fast image downloading from http/https servers.
> HTTP download speed is usually faster than tftp.
> The client is based on the same approach as tftp dynamic command, and
> uses the same UEFI Shell command line parameters. This makes it easy
> integrating http into existing UEFI Shell scripts.
> Note that to enable HTTP download, feature Pcd
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860
>
> PATCH v4 changes:
> Address comments based on Laszlo's testing:
>  - Fix .uni help file missing "\r\n" before RETURNVALUES section;
>  - delete the downloaded file in case of an error, unless
>-k ("keep bad") option is provided on command line.
>
> Allow download time measurement in seconds
> by providing -m parameter on command line.

(1) "Tested-by" tags cannot be carried forward on a patch if there are
any changes to the patch. If you update a patch and people would like to
have their T-b's on the patch, then they'll have to retest the patch. So
every time you update a patch, please drop the previously given
Tested-by tags from it.


(2) I was about to retest this patch, but I also compared it with the
previous version (v3). I think the "-m" option should not be added, for
now anyway. For two reasons:

- The patch is already large, and I think there has been no ShellPkg
  reviewer / maintainer feedback so far. I think we shouldn't make the
  patch even larger, with new features. "-m" looks like an addition that
  can be done separately, once the core feature is upstream.

  (I consider "-k" a bugfix on the other hand. More precisely, I
  consider the new behavior *without "-k"* a bugfix. So I certainly
  welcome that.)

- The other reason is that the "-m" feature seems to introduce a
  TimerLib dependency. Depending on TimerLib in a shell application is
  wrong, IMO; in particular because this application / dynamic command
  is extremely useful, so some people might easily want to download a
  pre-built binary, and run it on their system for whatever purposes.
  But TimerLib is platform-dependent, and that would break this binary
  portability.

  For some more background, please refer to commit 7a141b1306f6
  ("ShellPkg: remove superfluous TimerLib resolution", 2018-02-13).


... In fact, upon re-reading the above commit, I'm realizing the current
patch could break the "ShellPkg.dsc" build, because the patch
(incorrectly) introduces a TimerLib dependency in a ShellPkg module, but
"ShellPkg.dsc" (correctly) does not resolve the TimerLib class to any
instance.

And it does break:

$ build -a X64 -b NOOPT -t GCC48 -p ShellPkg/ShellPkg.dsc

> ShellPkg/ShellPkg.dsc(...): error 4000: Instance of library class [TimerLib] 
> is not found
> in 
> [ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf] [X64]
> consumed by module 
> [ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf]

One consequence of the above is that this patch would not pass a CI
build.


... Another reason this patch would not pass a CI build is a
"PatchCheck.py" failure:

> ShellPkg/DynamicCommand: add HttpDynamicCommand
> The commit message format is not valid:
>  * 'Tested-By' should be 'Tested-by'
>  * 'Tested-By' should be 'Tested-by'
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
> The code passed all checks.

(Side comment: please use the clipboard for cutting and pasting feedback
tags from emails to commit messages. I have a keyboard shortcut for
inserting "Tested-by: Laszlo Ersek ", and so I know
for a fact that I never send an upper-case "By".)

I suggest running a personal CI build on github.com before submitting
the patch to the list (just open a pull request -- if it fails, you'll
get the error reports, and if it succeeds, then the mergify bot will
auto-close the successful personal build, without actually merging the
patch).


In summary, I suggest posting v5:

- with the Tested-by flags dropped (Samer and myself will have to
  re-test),

- with the "-k" option preserved, but the "-m" option (and the
  associated TimerLib dependency) removed.

Later on, I think "-m" could be added based on gRT->GetTime(), instead
of TimerLib.


Ray, Zhichao, when do you intend to review this patch? It does not make
much sense for Samer and myself to keep testing this patch if you're
going to start the review only later. The review feedback will probably
necessitate updates to the patch, which will invalidate Samer's testing
and mine. We've done a few rounds of testing; the patch certainly
deserves package maintainer 

[edk2-devel] [PATCH v4 1/3] UefiPayloadPkg: Store the size of the MMCONF window

[Marcello Sylvester Bauer]

From: Patrick Rudolph 

Store the real size of the Pcie Memory Mapped Address Space.
This change is necessary to support variable size of MMCONF spaces.

Signed-off-by: Patrick Rudolph 
Signed-off-by: Marcello Sylvester Bauer 
Cc: Patrick Rudolph 
Cc: Christian Walter 
Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
---
 UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h | 1 +
 UefiPayloadPkg/BlSupportPei/BlSupportPei.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h 
b/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
index fe783fe5e14c..043b748ae4a9 100644
--- a/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
+++ b/UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h
@@ -24,6 +24,7 @@ typedef struct {
   UINT64 PmTimerRegBase;
   UINT64 ResetRegAddress;
   UINT64 PcieBaseAddress;
+  UINT64 PcieBaseSize;
 } ACPI_BOARD_INFO;
 
 #endif
diff --git a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c 
b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
index 22972453117a..a7e99f9ec6de 100644
--- a/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
+++ b/UefiPayloadPkg/BlSupportPei/BlSupportPei.c
@@ -240,8 +240,10 @@ Done:
   if (MmCfgHdr != NULL) {
 MmCfgBase = 
(EFI_ACPI_MEMORY_MAPPED_ENHANCED_CONFIGURATION_SPACE_BASE_ADDRESS_ALLOCATION_STRUCTURE
 *)((UINT8*) MmCfgHdr + sizeof (*MmCfgHdr));
 AcpiBoardInfo->PcieBaseAddress = MmCfgBase->BaseAddress;
+AcpiBoardInfo->PcieBaseSize = (MmCfgBase->EndBusNumber + 1 - 
MmCfgBase->StartBusNumber) * 4096 * 32 * 8;
   } else {
 AcpiBoardInfo->PcieBaseAddress = 0;
+AcpiBoardInfo->PcieBaseSize = 0;
   }
   DEBUG ((DEBUG_INFO, "PmCtrl  Reg 0x%lx\n",  AcpiBoardInfo->PmCtrlRegBase));
   DEBUG ((DEBUG_INFO, "PmTimer Reg 0x%lx\n",  AcpiBoardInfo->PmTimerRegBase));
@@ -250,6 +252,7 @@ Done:
   DEBUG ((DEBUG_INFO, "PmEvt   Reg 0x%lx\n",  AcpiBoardInfo->PmEvtBase));
   DEBUG ((DEBUG_INFO, "PmGpeEn Reg 0x%lx\n",  AcpiBoardInfo->PmGpeEnBase));
   DEBUG ((DEBUG_INFO, "PcieBaseAddr 0x%lx\n", AcpiBoardInfo->PcieBaseAddress));
+  DEBUG ((DEBUG_INFO, "PcieBaseSize 0x%lx\n", AcpiBoardInfo->PcieBaseSize));
 
   //
   // Verify values for proper operation
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63290): https://edk2.groups.io/g/devel/message/63290
Mute This Topic: https://groups.io/mt/75818419/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 3/3] UefiPayloadPkg: Support variable size MMCONF space

[Marcello Sylvester Bauer]

The default size is still 256MiB, but will be overwritten by
UefiPayloadPkg with the real MMCONF size.

e.g.: On embedded AMD platforms the MMCONF window size is usually
  only 64MiB.

Fixes crash on platforms not exposing 256 buses.
Tested on:
* AMD Stoney Ridge

Signed-off-by: Patrick Rudolph 
Signed-off-by: Marcello Sylvester Bauer 
Cc: Patrick Rudolph 
Cc: Christian Walter 
Cc: Maurice Ma 
Cc: Nate DeSimone 
Cc: Benjamin You 
---
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 1 +
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf | 1 +
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   | 4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
index a768a8702c66..162cbf47a83f 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc
@@ -363,6 +363,7 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|31
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|100
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0
 
 

 #
diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf 
b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
index 1371d5eb7952..cebc81135565 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf
@@ -54,6 +54,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize
 
 [Depex]
   TRUE
diff --git a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c 
b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
index a3974dcc02f8..a746d0581ee3 100644
--- a/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
+++ b/UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c
@@ -155,13 +155,15 @@ BlDxeEntryPoint (
   }
 
   //
-  // Set PcdPciExpressBaseAddress by HOB info
+  // Set PcdPciExpressBaseAddress and PcdPciExpressBaseSize by HOB info
   //
   GuidHob = GetFirstGuidHob ();
   if (GuidHob != NULL) {
 AcpiBoardInfo = (ACPI_BOARD_INFO *)GET_GUID_HOB_DATA (GuidHob);
 Status = PcdSet64S (PcdPciExpressBaseAddress, 
AcpiBoardInfo->PcieBaseAddress);
 ASSERT_EFI_ERROR (Status);
+Status = PcdSet64S (PcdPciExpressBaseSize, AcpiBoardInfo->PcieBaseSize);
+ASSERT_EFI_ERROR (Status);
   }
 
   return EFI_SUCCESS;
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63292): https://edk2.groups.io/g/devel/message/63292
Mute This Topic: https://groups.io/mt/75818421/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 2/3] MdePkg/BasePciExpressLib: Support variable size MMCONF

[Marcello Sylvester Bauer]

Add support for arbitrary sized MMCONF by introducing a new PCD.

Signed-off-by: Patrick Rudolph 
Signed-off-by: Marcello Sylvester Bauer 
Cc: Patrick Rudolph 
Cc: Christian Walter 
Cc: Michael D Kinney 
Cc: Liming Gao 
---
 MdePkg/MdePkg.dec  |   4 +
 MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf |   6 +-
 MdePkg/Include/Library/PciExpressLib.h |   5 +-
 MdePkg/Library/BasePciExpressLib/PciExpressLib.c   | 216 
+---
 4 files changed, 193 insertions(+), 38 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 73f6c2407357..812be75fb3b2 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2274,6 +2274,10 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt PCI Express Base Address.
   
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000|UINT64|0x000a
 
+  ## This value is used to set the size of PCI express hierarchy. The default 
is 256 MB.
+  # @Prompt PCI Express Base Size.
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x1000|UINT64|0x000f
+
   ## Default current ISO 639-2 language: English & French.
   # @Prompt Default Value of LangCodes Variable.
   
gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangCodes|"engfraengfra"|VOID*|0x001c
diff --git a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf 
b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
index a7edb74cde71..12734b022ac7 100644
--- a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
+++ b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
@@ -1,7 +1,7 @@
 ## @file
-#  Instance of PCI Express Library using the 256 MB PCI Express MMIO window.
+#  Instance of PCI Express Library using the variable size PCI Express MMIO 
window.
 #
-#  PCI Express Library that uses the 256 MB PCI Express MMIO window to perform
+#  PCI Express Library that uses the variable size PCI Express MMIO window to 
perform
 #  PCI Configuration cycles. Layers on top of an I/O Library instance.
 #
 #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
@@ -38,4 +38,4 @@ [LibraryClasses]
 
 [Pcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress  ## CONSUMES
-
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize  ## CONSUMES
diff --git a/MdePkg/Include/Library/PciExpressLib.h 
b/MdePkg/Include/Library/PciExpressLib.h
index 826fdcf7db6c..d78193a0a352 100644
--- a/MdePkg/Include/Library/PciExpressLib.h
+++ b/MdePkg/Include/Library/PciExpressLib.h
@@ -2,8 +2,9 @@
   Provides services to access PCI Configuration Space using the MMIO PCI 
Express window.
 
   This library is identical to the PCI Library, except the access method for 
performing PCI
-  configuration cycles must be through the 256 MB PCI Express MMIO window 
whose base address
-  is defined by PcdPciExpressBaseAddress.
+  configuration cycles must be through the PCI Express MMIO window whose base 
address
+  is defined by PcdPciExpressBaseAddress and size defined by 
PcdPciExpressBaseSize.
+
 
 Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
diff --git a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c 
b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
index 99a166c3609b..0311ecb3025f 100644
--- a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
+++ b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
@@ -22,7 +22,8 @@
 
 /**
   Assert the validity of a PCI address. A valid PCI address should contain 1's
-  only in the low 28 bits.
+  only in the low 28 bits. PcdPciExpressBaseSize limits the size to the real
+  number of PCI busses in this segment.
 
   @param  A The address to validate.
 
@@ -79,6 +80,24 @@ GetPciExpressBaseAddress (
   return (VOID*)(UINTN) PcdGet64 (PcdPciExpressBaseAddress);
 }
 
+/**
+  Gets the size of PCI Express.
+
+  This internal functions retrieves PCI Express Base Size via a PCD entry
+  PcdPciExpressBaseSize.
+
+  @return The base size of PCI Express.
+
+**/
+STATIC
+UINTN
+PcdPciExpressBaseSize (
+  VOID
+  )
+{
+  return (UINTN) PcdGet64 (PcdPciExpressBaseSize);
+}
+
 /**
   Reads an 8-bit PCI configuration register.
 
@@ -91,7 +110,8 @@ GetPciExpressBaseAddress (
   @param  Address The address that encodes the PCI Bus, Device, Function and
   Register.
 
-  @return The read value from the PCI configuration register.
+  @retval 0xFF  Invalid PCI address.
+  @retval other The read value from the PCI configuration register.
 
 **/
 UINT8
@@ -101,6 +121,9 @@ PciExpressRead8 (
   )
 {
   ASSERT_INVALID_PCI_ADDRESS (Address);
+  if (Address >= PcdPciExpressBaseSize()) {
+return (UINT8) ~0;
+  }
   return MmioRead8 ((UINTN) GetPciExpressBaseAddress () + Address);
 }
 
@@ -117,7 +140,8 @@ PciExpressRead8 (
   Register.
   @param  Value   The value to write.
 
-  @return The value written to the PCI configuration register.
+  @retval 0xFF  Invalid PCI address.
+  @retval other The value written 

[edk2-devel] [PATCH v4 0/3] UefiPayloadPkg: Runtime MMCONF

[Marcello Sylvester Bauer]

Support arbitrary platforms with different or even no MMCONF space.
Fixes crash on platforms not exposing 256 buses.

Tested on:
* AMD Stoney Ridge

Branch: https://github.com/9elements/edk2-1/tree/UefiPayloadPkg-MMCONF
PR: https://github.com/tianocore/edk2/pull/817

v4:
* MdePkg: undo default PcdPciExpressBaseSize off by one

v3:
* split patch 2 by package
* MdePkg/PciExpress:
  - PciExpressXX add return value specification
  - Undo remove of ASSERT()
  - PcdPciExpressBaseSize() correct function header
  - correct return value types

v2:
* rebased with regards to commit 3900a63e3a1b9ba9a4105bedead7b986188cec2c
* add MdePkg Maintainer

Marcello Sylvester Bauer (2):
  MdePkg/BasePciExpressLib: Support variable size MMCONF
  UefiPayloadPkg: Support variable size MMCONF space

Patrick Rudolph (1):
  UefiPayloadPkg: Store the size of the MMCONF window

 MdePkg/MdePkg.dec  |   4 +
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc   |   1 +
 MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf |   6 +-
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf   |   1 +
 MdePkg/Include/Library/PciExpressLib.h |   5 +-
 UefiPayloadPkg/Include/Guid/AcpiBoardInfoGuid.h|   1 +
 MdePkg/Library/BasePciExpressLib/PciExpressLib.c   | 216 
+---
 UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c |   4 +-
 UefiPayloadPkg/BlSupportPei/BlSupportPei.c |   3 +
 9 files changed, 202 insertions(+), 39 deletions(-)

-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63289): https://edk2.groups.io/g/devel/message/63289
Mute This Topic: https://groups.io/mt/75818417/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 2/3] MdePkg/BasePciExpressLib: Support variable size MMCONF

[Marcello Sylvester Bauer]

Liming:
My mistake. 0x0FFF is still a valid address offset so default
PcdPciExpressBaseSize should be 0x1000.

Thanks,
Marcello

On Thu, Jul 23, 2020 at 12:04 PM Gao, Liming  wrote:

>
>
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Marcello
> Sylvester Bauer
> Sent: 2020年7月22日 21:16
> To: devel@edk2.groups.io
> Cc: Patrick Rudolph ; Christian Walter <
> christian.wal...@9elements.com>; Kinney, Michael D <
> michael.d.kin...@intel.com>; Gao, Liming 
> Subject: [edk2-devel] [PATCH v3 2/3] MdePkg/BasePciExpressLib: Support
> variable size MMCONF
>
> Add support for arbitrary sized MMCONF by introducing a new PCD.
>
> Signed-off-by: Patrick Rudolph 
> Signed-off-by: Marcello Sylvester Bauer 
> Cc: Patrick Rudolph 
> Cc: Christian Walter 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> ---
>  MdePkg/MdePkg.dec  |   4 +
>  MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf |   6 +-
>  MdePkg/Include/Library/PciExpressLib.h |   5 +-
>  MdePkg/Library/BasePciExpressLib/PciExpressLib.c   | 216
> +---
>  4 files changed, 193 insertions(+), 38 deletions(-)
>
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> 73f6c2407357..02e736a01126 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2274,6 +2274,10 @@ [PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic, PcdsDynamicEx]
># @Prompt PCI Express Base Address.
>  
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000|UINT64|0x000a
> +  ## This value is used to set the size of PCI express hierarchy. The
> default is 256 MB.+  # @Prompt PCI Express Base Size.+
> gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x0FFF|UINT64|0x000f+
>  ## Default current ISO 639-2 language: English & French.   # @Prompt
> Default Value of LangCodes Variable.
>  
> gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangCodes|"engfraengfra"|VOID*|0x001cdiff
> --git a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
> b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
>
> [Liming] 256M is 0x1000. PCD value is 0x0FFF. Does it mean that
> the default value is 256M - 1?
>
> Thanks
> Liming
>
> index a7edb74cde71..12734b022ac7 100644
> --- a/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
> +++ b/MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
> @@ -1,7 +1,7 @@
>  ## @file-#  Instance of PCI Express Library using the 256 MB PCI Express
> MMIO window.+#  Instance of PCI Express Library using the variable size PCI
> Express MMIO window. #-#  PCI Express Library that uses the 256 MB PCI
> Express MMIO window to perform+#  PCI Express Library that uses the
> variable size PCI Express MMIO window to perform #  PCI Configuration
> cycles. Layers on top of an I/O Library instance. # #  Copyright (c) 2007 -
> 2018, Intel Corporation. All rights reserved.@@ -38,4 +38,4 @@
> [LibraryClasses]
>   [Pcd]   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress  ##
> CONSUMES-+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize  ## CONSUMESdiff
> --git a/MdePkg/Include/Library/PciExpressLib.h
> b/MdePkg/Include/Library/PciExpressLib.h
> index 826fdcf7db6c..d78193a0a352 100644
> --- a/MdePkg/Include/Library/PciExpressLib.h
> +++ b/MdePkg/Include/Library/PciExpressLib.h
> @@ -2,8 +2,9 @@
>Provides services to access PCI Configuration Space using the MMIO PCI
> Express window.This library is identical to the PCI Library, except the
> access method for performing PCI-  configuration cycles must be through the
> 256 MB PCI Express MMIO window whose base address-  is defined by
> PcdPciExpressBaseAddress.+  configuration cycles must be through the PCI
> Express MMIO window whose base address+  is defined by
> PcdPciExpressBaseAddress and size defined by PcdPciExpressBaseSize.+
> Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> SPDX-License-Identifier: BSD-2-Clause-Patentdiff --git
> a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
> b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
> index 99a166c3609b..0311ecb3025f 100644
> --- a/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
> +++ b/MdePkg/Library/BasePciExpressLib/PciExpressLib.c
> @@ -22,7 +22,8 @@
>   /**   Assert the validity of a PCI address. A valid PCI address should
> contain 1's-  only in the low 28 bits.+  only in the low 28 bits.
> PcdPciExpressBaseSize limits the size to the real+  number of PCI busses in
> this segment.@param  A The address to validate. @@ -79,6 +80,24 @@
> GetPciExpressBaseAddress (
>return (VOID*)(UINTN) PcdGet64 (PcdPciExpressBaseAddress); } +/**+
> Gets the size of PCI Express.++  This internal functions retrieves PCI
> Express Base Size via a PCD entry+  PcdPciExpressBaseSize.++  @return The
> base size of PCI Express.++**/+STATIC+UINTN+PcdPciExpressBaseSize (+
> VOID+  )+{+  return (UINTN) PcdGet64 (PcdPciExpressBaseSize);+}+ /**
>  Reads an 8-bit PCI configuration register. @@ -91,7 +110,8 @@
> 

Re: [edk2-devel] [PATCH 13/15] ShellPkg/ShellPkg.ci.yaml: Add configuration for LicenseCheck

[Gao, Zhichao]

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhang,
> Shenglei
> Sent: Monday, July 20, 2020 4:37 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Gao, Zhichao 
> Subject: [edk2-devel] [PATCH 13/15] ShellPkg/ShellPkg.ci.yaml: Add 
> configuration
> for LicenseCheck
> 
> Add configuration IgnoreFiles for package config files.
> So users can rely on this to skip license conflict for some generated files.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Shenglei Zhang 
> ---
>  ShellPkg/ShellPkg.ci.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ShellPkg/ShellPkg.ci.yaml b/ShellPkg/ShellPkg.ci.yaml index
> 67de34a2556e..565e08596b2f 100644
> --- a/ShellPkg/ShellPkg.ci.yaml
> +++ b/ShellPkg/ShellPkg.ci.yaml
> @@ -5,6 +5,9 @@
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  ##  {
> +"LicenseCheck": {
> +"IgnoreFiles": []
> +},
>  "CompilerPlugin": {
>  "DscPath": "ShellPkg.dsc"
>  },
> --
> 2.18.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63287): https://edk2.groups.io/g/devel/message/63287
Mute This Topic: https://groups.io/mt/75678224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 15/15] UnitTestFrameworkPkg: Add configuration for LicenseCheck in yaml file

[Zhang, Shenglei]

Hi Michael/Sean/Bret,

Could you help review this patch?

Thanks,
Shenglei

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhang,
> Shenglei
> Sent: Monday, July 20, 2020 4:37 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Sean Brogan
> ; Bret Barkelew
> 
> Subject: [edk2-devel] [PATCH 15/15] UnitTestFrameworkPkg: Add
> configuration for LicenseCheck in yaml file
> 
> Add configuration IgnoreFiles for package config files.
> So users can rely on this to skip license conflict for
> some generated files.
> 
> Cc: Michael D Kinney 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Signed-off-by: Shenglei Zhang 
> ---
>  UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
> b/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
> index 51e172537f8a..2988e03f763f 100644
> --- a/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
> +++ b/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
> @@ -5,6 +5,10 @@
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  ##
>  {
> +## options defined .pytool/Plugin/LicenseCheck
> +"LicenseCheck": {
> +"IgnoreFiles": []
> +},
>  ## options defined .pytool/Plugin/CompilerPlugin
>  "CompilerPlugin": {
>  "DscPath": "UnitTestFrameworkPkg.dsc"
> --
> 2.18.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63286): https://edk2.groups.io/g/devel/message/63286
Mute This Topic: https://groups.io/mt/75817306/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for LicenseCheck

[Zhang, Shenglei]

Hi Laszlo,

VbeShim.h is existing in edk2 now. This plugin only checks the patches to be 
checked in.
So there's no need to add existing files to this section.

Thanks,
Shenglei

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, July 21, 2020 6:01 AM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Justen, Jordan L ; Ard Biesheuvel
> 
> Subject: Re: [PATCH 10/15] OvmfPkg/OvmfPkg.ci.yaml: Add configuration for
> LicenseCheck
> 
> On 07/20/20 10:37, Shenglei Zhang wrote:
> > Add configuration IgnoreFiles for package config files.
> > So users can rely on this to skip license conflict for
> > some generated files.
> >
> > Cc: Jordan Justen 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  OvmfPkg/OvmfPkg.ci.yaml | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkg.ci.yaml b/OvmfPkg/OvmfPkg.ci.yaml
> > index 98992f0429ff..ed342d7a3d08 100644
> > --- a/OvmfPkg/OvmfPkg.ci.yaml
> > +++ b/OvmfPkg/OvmfPkg.ci.yaml
> > @@ -8,6 +8,10 @@
> >  # SPDX-License-Identifier: BSD-2-Clause-Patent
> >  ##
> >  {
> > +## options defined .pytool/Plugin/LicenseCheck
> > +"LicenseCheck": {
> > +"IgnoreFiles": []
> > +},
> >  ## options defined .pytool/Plugin/CompilerPlugin
> >  "CompilerPlugin": {
> >  "DscPath": "" # Don't support this test
> >
> 
> Can you list the following file at once, please:
> 
>   OvmfPkg/QemuVideoDxe/VbeShim.h
> 
> With that:
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks
> Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63285): https://edk2.groups.io/g/devel/message/63285
Mute This Topic: https://groups.io/mt/75678218/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-