Re: [edk2-devel] [edk2-discuss] GSoC Proposal

2022-04-14 Thread Andrew Fish via groups.io 



> On Apr 14, 2022, at 6:06 PM, Nate DeSimone  
> wrote:
> 
> Hi Marvin,
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Marvin
>> Häuser
>> Sent: Thursday, April 14, 2022 12:56 AM
>> To: disc...@edk2.groups.io; Desimone, Nathaniel L
>> 
>> Cc: Pedro Falcato ; edk2-devel-groups-io
>> ; adachristin...@gmail.com; Shi, Steven
>> 
>> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal
>> 
>> I feel like there are so many much easier solutions to this problem that are 
>> at
>> most limited by the clear specification. The UEFI specification with regards 
>> to
>> booting and all of that obviously is of utmost importance.
> 
> If you have a better idea that retains compatibility with the existing UEFI 
> PI then I would be happy to hear it. Ultimately anything we do needs to be a 
> pure extension that retains compatibility with old code. Given that 
> restriction having the ability to coalesce all the LibraryClasses into a 
> single module and have cross-module linking seems like the best way to handle 
> it to me.
> 
>> The UEFI PI specification parts that deal about internal structure, as far 
>> as I know, are
>> only in place to make it easy to integrate Intel IP.
> 
> Its not just for Intel. The biggest reason for it to increase the 
> standardization of the boot flow across the PC ecosystem. We have learned 
> from experience that firmware is super critical to get a product out the door 
> but it is also difficult to write. So we try to make it as reusable as 
> humanly possible.
> 
>> In fact, I don’t *know*, but I’m pretty sure the very strict separation 
>> between PEI and DXE was
>> preserved mostly because MRC was 32-bit-only for a long time. Glad that
>> seems to have been resolved, AMD does memory init by PSP nowadays.
> 
> Having less complex early stages chain load more complex later stages is a 
> common design pattern in firmware, not just UEFI. For example, your typical 
> ARM system loads kinda like this:
> 
> PBL (SoC ROM) --> SBL (RAM Init) --> ARM Trust Zone --> Hypervisor --> EDK II 
> or U-Boot or LittleKernel (which runs android fastboot)
> 
> Comparing relative complexity I believe the Intel UEFI PI design is actually 
> pretty simple when you consider how much it gets done:
> 
> Ucode ROM --> SEC + PEI --> DXE + SMM + BDS
> 
> My biggest criticism of the design is that the strict separation between PEI 
> and DXE doesn't exist between DXE, SMM, and BDS 
> 
> There are a few reasons why PEI was 32-bit for quite some time. The biggest 
> one is the code size increase, 64-bit x86 code is 20-30% larger than 32-bit 
> x86 code. Since the only RAM Pre-Memory code has access to is the cache 
> onboard the processor and for security reasons all that code has to fit 
> within that RAM we generally do everything we can to make that image as small 
> as possible. Second, 64-bit requires a page table and since we desired to 
> keep PEI simple we tried to avoid that. Finally, the PI spec didn't allow a 
> 64-bit PEI until recently. MRC is 32-bit code just because that is what PEI 
> happens to be. Porting it to 64-bit is not terribly difficult.
> 
> Ultimately the mix of 32/64-bit does cause some difficulties. Any data 
> structures that get shared between PEI and DXE (HOBs, PCDs, etc.) need to 
> resolve to the same size and packing. LibraryClasses need to be written to 
> compile properly in both modes. In the case of FSP API mode you need to 
> resort to thunking between 32 and 64-bit modes during DXE. More or less we 
> decided that the costs are starting to outweigh the advantages.
> 

I’d also point out that x86 VMs use X64 (x86-64) PEI today and it works so the 
32-bit/64-bit mix has nothing to do with UEFI/PI/edk2. 

In the PC ecosystem a single chipset family can power thousands of unique 
designs. So the  DRAM memory needs to be external, support lots of different 
chipset packages(signal integrity...), support the lowest cost through the 
highest cost DRAM and thousands of different board layouts. So programing DRAM 
takes a masters degree in antenna design. I’ve seen MRC (Memory Reference Code) 
with over a MiB of DEBUG prints in it, and it literally is printing histograms 
of what it is tuning. So all this code has to run before the system has any 
DRAM, thus it is running using the cache as RAM. I’ve not looked at the x86 
architecture specs form the vendors in a while, but back in the day they did 
not support page tables in ROM or pinned cached. Now it might work, but if it 
breaks your CPU vendor blames you so you don’t code PEI in X64….

We contributed the 1st edk2 ARM platform, Beagle Board, and It was a long time 
ago but I seem to remember the mask ROM used a table in NOR FLASH to init 
memory and then copied an image from NOR FLASH into DRAM and jumped to it. So 
PEI is kind of not really needed and we implemented a PrePEI and jumped 
directly to DXE. 

Given I was around back in the day when all this stuff was designed I can say 
SEC was

Re: [edk2-devel] [edk2-discuss] GSoC Proposal

2022-04-14 Thread Nate DeSimone 
Hi Marvin,

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Marvin
> Häuser
> Sent: Thursday, April 14, 2022 12:56 AM
> To: disc...@edk2.groups.io; Desimone, Nathaniel L
> 
> Cc: Pedro Falcato ; edk2-devel-groups-io
> ; adachristin...@gmail.com; Shi, Steven
> 
> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal
> 
> I feel like there are so many much easier solutions to this problem that are 
> at
> most limited by the clear specification. The UEFI specification with regards 
> to
> booting and all of that obviously is of utmost importance.

If you have a better idea that retains compatibility with the existing UEFI PI 
then I would be happy to hear it. Ultimately anything we do needs to be a pure 
extension that retains compatibility with old code. Given that restriction 
having the ability to coalesce all the LibraryClasses into a single module and 
have cross-module linking seems like the best way to handle it to me.

> The UEFI PI specification parts that deal about internal structure, as far as 
> I know, are
> only in place to make it easy to integrate Intel IP.

Its not just for Intel. The biggest reason for it to increase the 
standardization of the boot flow across the PC ecosystem. We have learned from 
experience that firmware is super critical to get a product out the door but it 
is also difficult to write. So we try to make it as reusable as humanly 
possible.

> In fact, I don’t *know*, but I’m pretty sure the very strict separation 
> between PEI and DXE was
> preserved mostly because MRC was 32-bit-only for a long time. Glad that
> seems to have been resolved, AMD does memory init by PSP nowadays.

Having less complex early stages chain load more complex later stages is a 
common design pattern in firmware, not just UEFI. For example, your typical ARM 
system loads kinda like this:

PBL (SoC ROM) --> SBL (RAM Init) --> ARM Trust Zone --> Hypervisor --> EDK II 
or U-Boot or LittleKernel (which runs android fastboot)

Comparing relative complexity I believe the Intel UEFI PI design is actually 
pretty simple when you consider how much it gets done:

Ucode ROM --> SEC + PEI --> DXE + SMM + BDS

My biggest criticism of the design is that the strict separation between PEI 
and DXE doesn't exist between DXE, SMM, and BDS 

There are a few reasons why PEI was 32-bit for quite some time. The biggest one 
is the code size increase, 64-bit x86 code is 20-30% larger than 32-bit x86 
code. Since the only RAM Pre-Memory code has access to is the cache onboard the 
processor and for security reasons all that code has to fit within that RAM we 
generally do everything we can to make that image as small as possible. Second, 
64-bit requires a page table and since we desired to keep PEI simple we tried 
to avoid that. Finally, the PI spec didn't allow a 64-bit PEI until recently. 
MRC is 32-bit code just because that is what PEI happens to be. Porting it to 
64-bit is not terribly difficult.

Ultimately the mix of 32/64-bit does cause some difficulties. Any data 
structures that get shared between PEI and DXE (HOBs, PCDs, etc.) need to 
resolve to the same size and packing. LibraryClasses need to be written to 
compile properly in both modes. In the case of FSP API mode you need to resort 
to thunking between 32 and 64-bit modes during DXE. More or less we decided 
that the costs are starting to outweigh the advantages.

> 
> For many good reasons, Linux does not provide a stable kernel API. This
> allows to easily deploy breaking changes across the entire codebase.
> Obviously, this is infeasible at a large scale when you need to integrate IP
> blobs, but it would already help to break the expectation that UEFI PI is a
> perfectly forwards- and backwards-compatible system. DXE has SetMem and
> CopyMem as part of gBS. Maybe I don’t like it that much as part of the spec
> itself, but it’s a good idea technically. I’d probably opt to have a quickly
> accessible implementation detail of important function pointers appended to
> PEI and DXE services, used by in-tree modules. This may break both
> forwards- and backwards-compatibility, but as it only applies to in-tree
> modules, that is fine so long as we let go of the compatibility notions. PPIs
> and protocols are an option too of course, but they have a lookup
> performance penalty. Compared to dynamic linking, that should hopefully be
> negligible however.
> 
> Absolutely optional to read, I don’t intend to waste anyone’s time much,
> some philosophical stuff about my rationale:
> 
> If you started UEFI from scratch right now, would it have strictly separated
> PEI and DXE?

For sure a clean slate design started today would look a lot different than 
PEI/DXE... which was a clean slate design circa 1998 . In my opinion, if we 
were to suddenly go back to the drawing board we would build something that is 
much closer to a full OS now than we did back then. There have been cases where 
not being able to use interrupt handlers

[edk2-devel] [PATCH V2 6/6] OvmfPkg: Add CcProbeLib in *.dsc

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc.

Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest
is not supported in those projects.

Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
 OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
 OvmfPkg/CloudHv/CloudHvX64.dsc   | 1 +
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 +
 OvmfPkg/Microvm/MicrovmX64.dsc   | 1 +
 OvmfPkg/OvmfPkgIa32.dsc  | 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
 OvmfPkg/OvmfPkgX64.dsc   | 1 +
 OvmfPkg/OvmfXen.dsc  | 1 +
 9 files changed, 9 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index fcdc3efab204..1c088f25fa4b 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -149,6 +149,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index e1b6b8e15f36..a8fa4d38ab60 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -146,6 +146,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 20f3bc340807..d1c85f60c768 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -158,6 +158,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 245155d41b30..73a6c30096a8 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -135,6 +135,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 59580ccd4691..c9c843e116a9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -156,6 +156,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index e4218b01f0fc..9e4ecd21fb17 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -154,6 +154,7 @@
   PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf

[edk2-devel] [PATCH V2 5/6] MdePkg: Probe Cc guest in BaseIoLibIntrinsicSev

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

Bad IO performance in SEC phase is observed after TDX features was
introduced. (after commit b6b2de884864 - "MdePkg: Support mmio for
Tdx guest in BaseIoLibIntrinsic").

This is because IsTdxGuest() will be called in each MMIO operation.
It is trying to cache the result of the probe in the efi data segment.
However, that doesn't work in SEC, because the data segment is read only
(so the write seems to succeed but a read will always return the
original value), leading to us calling TdIsEnabled() check for every
mmio we do, which is causing the slowdown because it's very expensive.

This patch is to call CcProbe instead of TdIsEnabled in IsTdxGuest.
Null instance of CcProbe always returns CCGuestTypeNonEncrypted. Its
OvmfPkg version returns the guest type in Ovmf work area.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Signed-off-by: Min Xu 
---
 .../BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf|  1 +
 .../Library/BaseIoLibIntrinsic/IoLibInternalTdx.c   | 13 ++---
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
index 7fe1c60f046e..e1b8298ac451 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
@@ -55,6 +55,7 @@
   DebugLib
   BaseLib
   RegisterFilterLib
+  CcProbeLib
 
 [LibraryClasses.X64]
   TdxLib
diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c 
b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
index 1e539dbfbbad..8af6fc35c591 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
+++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "IoLibTdx.h"
 
 // Size of TDVMCALL Access, including IO and MMIO
@@ -22,9 +23,6 @@
 #define TDVMCALL_ACCESS_READ   0
 #define TDVMCALL_ACCESS_WRITE  1
 
-BOOLEAN  mTdxEnabled = FALSE;
-BOOLEAN  mTdxProbed  = FALSE;
-
 /**
   Check if it is Tdx guest.
 
@@ -38,14 +36,7 @@ IsTdxGuest (
   VOID
   )
 {
-  if (mTdxProbed) {
-return mTdxEnabled;
-  }
-
-  mTdxEnabled = TdIsEnabled ();
-  mTdxProbed  = TRUE;
-
-  return mTdxEnabled;
+  return CcProbe () == CCGuestTypeIntelTdx;
 }
 
 /**
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88921): https://edk2.groups.io/g/devel/message/88921
Mute This Topic: https://groups.io/mt/90477280/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 4/6] OvmfPkg: Add CcProbeLib

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

This is the OvmfPkg specific CcProbeLib. It checks the Ovmf WorkArea
(PcdOvmfWorkAreaBase) to return the guest type.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/CcProbeLib/CcProbeLib.c   | 31 +++
 OvmfPkg/Library/CcProbeLib/CcProbeLib.inf | 25 ++
 2 files changed, 56 insertions(+)
 create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.c
 create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.inf

diff --git a/OvmfPkg/Library/CcProbeLib/CcProbeLib.c 
b/OvmfPkg/Library/CcProbeLib/CcProbeLib.c
new file mode 100644
index ..b4babcb423f7
--- /dev/null
+++ b/OvmfPkg/Library/CcProbeLib/CcProbeLib.c
@@ -0,0 +1,31 @@
+/** @file
+
+  CcProbeLib is used to probe the Confidential computing guest type.
+
+  Copyright (c) 2022, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+/**
+  Probe the ConfidentialComputing Guest type. See defition of
+  CC_GUEST_TYPE in .
+
+  @return The guest type
+
+**/
+UINT8
+EFIAPI
+CcProbe (
+  VOID
+  )
+{
+  OVMF_WORK_AREA  *WorkArea;
+
+  WorkArea = (OVMF_WORK_AREA *)FixedPcdGet32 (PcdOvmfWorkAreaBase);
+
+  return WorkArea != NULL ? WorkArea->Header.GuestType : 
CCGuestTypeNonEncrypted;
+}
diff --git a/OvmfPkg/Library/CcProbeLib/CcProbeLib.inf 
b/OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
new file mode 100644
index ..5300c9ba2644
--- /dev/null
+++ b/OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
@@ -0,0 +1,25 @@
+## @file
+# CcProbeLib is used to probe Confidential Computing guest type.
+#
+#  Copyright (c) 2022, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = CcProbeLib
+  FILE_GUID  = 05184ec9-abb0-4491-8584-e388639a7c48
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = CcProbeLib
+
+[Sources]
+  CcProbeLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88920): https://edk2.groups.io/g/devel/message/88920
Mute This Topic: https://groups.io/mt/90477278/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 3/6] MdePkg: Add CcProbeLib

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

CcProbeLib is used to probe the Confidential Computing guest type.
This library is designed to run on SEC / PEI / DXE phases. A null
instance of the library always returns CCGuestTypeNonEncrypted.
A platform specific CcProbeLib will be implemented, for example,
in OvmfPkg.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Signed-off-by: Min Xu 
---
 MdePkg/Include/Library/CcProbeLib.h   | 26 +++
 .../Library/CcProbeLibNull/CcProbeLibNull.c   | 26 +++
 .../Library/CcProbeLibNull/CcProbeLibNull.inf | 21 +++
 MdePkg/MdePkg.dec |  5 
 MdePkg/MdePkg.dsc |  1 +
 5 files changed, 79 insertions(+)
 create mode 100644 MdePkg/Include/Library/CcProbeLib.h
 create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c
 create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf

diff --git a/MdePkg/Include/Library/CcProbeLib.h 
b/MdePkg/Include/Library/CcProbeLib.h
new file mode 100644
index ..2857dddfb2d3
--- /dev/null
+++ b/MdePkg/Include/Library/CcProbeLib.h
@@ -0,0 +1,26 @@
+/** @file
+
+Copyright (c) 2022, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CC_PROBE_LIB_H_
+#define CC_PROBE_LIB_H_
+
+#include 
+
+/**
+  Probe the ConfidentialComputing Guest type. See defition of
+  CC_GUEST_TYPE in .
+
+  @return The guest type
+
+**/
+UINT8
+EFIAPI
+CcProbe (
+  VOID
+  );
+
+#endif
diff --git a/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c 
b/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c
new file mode 100644
index ..152d900eb099
--- /dev/null
+++ b/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c
@@ -0,0 +1,26 @@
+/** @file
+
+  Null stub of CcProbeLib
+
+  Copyright (c) 2022, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  Probe the ConfidentialComputing Guest type. See defition of
+  CC_GUEST_TYPE in .
+
+  @return The guest type
+
+**/
+UINT8
+EFIAPI
+CcProbe (
+  VOID
+  )
+{
+  return CCGuestTypeNonEncrypted;
+}
diff --git a/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf 
b/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
new file mode 100644
index ..f37c25f73439
--- /dev/null
+++ b/MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
@@ -0,0 +1,21 @@
+## @file
+# CcProbeLib null instance.
+#
+#  Copyright (c) 2022, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = CcProbeLibNull
+  FILE_GUID  = B15D67FE-0DAC-4316-8E26-8A6b85E43782
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = CcProbeLib
+
+[Sources]
+  CcProbeLibNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 1934c9840423..faeb28c80cbd 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -267,6 +267,11 @@
   #
   RegisterFilterLib|Include/Library/RegisterFilterLib.h
 
+  ##  @libraryclass  This library provides interfances to probe 
ConfidentialComputing guest type.
+  #
+  #
+  CcProbeLib|Include/Library/CcProbeLib.h
+
 [LibraryClasses.IA32, LibraryClasses.X64, LibraryClasses.AARCH64]
   ##  @libraryclass  Provides services to generate random number.
   #
diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index d6a7af412be7..c8d282882ec1 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -130,6 +130,7 @@
   MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
 
   MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
+  MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
 
 [Components.IA32, Components.X64, Components.ARM, Components.AARCH64]
   #
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88919): https://edk2.groups.io/g/devel/message/88919
Mute This Topic: https://groups.io/mt/90477277/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 2/6] OvmfPkg: Replace GUEST_TYPE with CC_GUEST_TYPE

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

Replace GUEST_TYPE with CC_GUEST_TYPE which is defined in
MdePkg/Include/ConfidentialComputingGuestAttr.h.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/Include/WorkArea.h   | 9 +
 .../BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c   | 2 +-
 .../BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c   | 2 +-
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c  | 2 +-
 OvmfPkg/Sec/AmdSev.c | 2 +-
 5 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/Include/WorkArea.h b/OvmfPkg/Include/WorkArea.h
index b67edd14e79f..bf56fc4a6f65 100644
--- a/OvmfPkg/Include/WorkArea.h
+++ b/OvmfPkg/Include/WorkArea.h
@@ -10,14 +10,7 @@
 #ifndef __OVMF_WORK_AREA_H__
 #define __OVMF_WORK_AREA_H__
 
-//
-// Guest type for the work area
-//
-typedef enum {
-  GUEST_TYPE_NON_ENCRYPTED,
-  GUEST_TYPE_AMD_SEV,
-  GUEST_TYPE_INTEL_TDX,
-} GUEST_TYPE;
+#include 
 
 //
 // Confidential computing work area header definition. Any change
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
index 3f8f91a5da12..fb9d3cbd3645 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
@@ -36,7 +36,7 @@ GetSevEsWorkArea (
   //
   // If its not SEV guest then SevEsWorkArea is not valid.
   //
-  if ((WorkArea == NULL) || (WorkArea->Header.GuestType != 
GUEST_TYPE_AMD_SEV)) {
+  if ((WorkArea == NULL) || (WorkArea->Header.GuestType != CCGuestTypeAmdSev)) 
{
 return NULL;
   }
 
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
index 80aceba01bcf..238e29e2a175 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
@@ -36,7 +36,7 @@ GetSevEsWorkArea (
   //
   // If its not SEV guest then SevEsWorkArea is not valid.
   //
-  if ((WorkArea == NULL) || (WorkArea->Header.GuestType != 
GUEST_TYPE_AMD_SEV)) {
+  if ((WorkArea == NULL) || (WorkArea->Header.GuestType != CCGuestTypeAmdSev)) 
{
 return NULL;
   }
 
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c
index b8230613dcea..1b8133bf5ad6 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c
@@ -35,7 +35,7 @@ QemuFwCfgIsTdxGuest (
   CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER  *CcWorkAreaHeader;
 
   CcWorkAreaHeader = (CONFIDENTIAL_COMPUTING_WORK_AREA_HEADER *)FixedPcdGet32 
(PcdOvmfWorkAreaBase);
-  return (CcWorkAreaHeader != NULL && CcWorkAreaHeader->GuestType == 
GUEST_TYPE_INTEL_TDX);
+  return (CcWorkAreaHeader != NULL && CcWorkAreaHeader->GuestType == 
CCGuestTypeIntelTdx);
 }
 
 /**
diff --git a/OvmfPkg/Sec/AmdSev.c b/OvmfPkg/Sec/AmdSev.c
index d8fd35650d7d..0da6b36020fc 100644
--- a/OvmfPkg/Sec/AmdSev.c
+++ b/OvmfPkg/Sec/AmdSev.c
@@ -251,7 +251,7 @@ IsSevGuest (
 
   WorkArea = (OVMF_WORK_AREA *)FixedPcdGet32 (PcdOvmfWorkAreaBase);
 
-  return ((WorkArea != NULL) && (WorkArea->Header.GuestType == 
GUEST_TYPE_AMD_SEV));
+  return ((WorkArea != NULL) && (WorkArea->Header.GuestType == 
CCGuestTypeAmdSev));
 }
 
 /**
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88918): https://edk2.groups.io/g/devel/message/88918
Mute This Topic: https://groups.io/mt/90477276/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 1/6] MdePkg: Add CC_GUEST_TYPE in ConfidentialComputingGuestAttr.h

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

The confidential computing guest type (GUEST_TYPE) was defined in
OvmfPkg/Include/WorkArea.h. Now it is to be moved to
MdePkg/Include/ConfidentialComputingGuestAttr.h and renamed as
CC_GUEST_TYPE.

There are 2 reasons for this change.
1. CC_GUEST_TYPE is a generic definition and will be used in CcProbeLib
   which is defined in MdePkg.
2. Based on the latest edk2 coding style:
 - First character should be upper case
 - Must contain lower case characters
 - No white space characters
 - Global variable name must start with a 'g'

As the first step CC_GUEST_TYPE is defined in this patch. In the
next patch GUEST_TYPE will be deleted. This is to make sure the
bisect work correctly.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 MdePkg/Include/ConfidentialComputingGuestAttr.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/ConfidentialComputingGuestAttr.h 
b/MdePkg/Include/ConfidentialComputingGuestAttr.h
index dd2541c6dcdf..9e9424a01559 100644
--- a/MdePkg/Include/ConfidentialComputingGuestAttr.h
+++ b/MdePkg/Include/ConfidentialComputingGuestAttr.h
@@ -1,5 +1,5 @@
 /** @file
-Definitions for Confidential Computing Attribute
+Definitions for Confidential Computing Guest Attributes
 
 Copyright (c) 2021 AMD Inc. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -9,6 +9,15 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #ifndef CONFIDENTIAL_COMPUTING_GUEST_ATTR_H_
 #define CONFIDENTIAL_COMPUTING_GUEST_ATTR_H_
 
+//
+// Confidential computing guest type
+//
+typedef enum {
+  CCGuestTypeNonEncrypted = 0,
+  CCGuestTypeAmdSev,
+  CCGuestTypeIntelTdx,
+} CC_GUEST_TYPE;
+
 typedef enum {
   /* The guest is running with memory encryption disabled. */
   CCAttrNotEncrypted = 0,
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88917): https://edk2.groups.io/g/devel/message/88917
Mute This Topic: https://groups.io/mt/90477275/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2 0/6] Introduce CcProbe in MdePkg

2022-04-14 Thread Min Xu 
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902

Bad IO performance in SEC phase is observed after TDX features was
introduced. (after commit b6b2de884864 - "MdePkg: Support mmio for
Tdx guest in BaseIoLibIntrinsic").

This is because IsTdxGuest() will be called in each MMIO operation.
It is trying to cache the result of the probe in the efi data segment.
However, that doesn't work in SEC, because the data segment is read only
(so the write seems to succeed but a read will always return the
original value), leading to us calling TdIsEnabled() check for every
mmio we do, which is causing the slowdown because it's very expensive.

CcProbe is introduced in this patch-set. It is called in
BaseIoLibIntrinsicSev instead of IsTdxGuest. There are 2 versions of
the CcProbeLib. Null instance of CcProbe always returns
CCGuestTypeNonEncrypted. Its OvmfPkg version checks the Ovmf work area
and returns the CC guest type.

Code is at: https://github.com/mxu9/edk2/tree/cc_probe.v2

v2 changes:
 - Rename TdProbe to CcProbe to make the lib work for Confidential
   Computing guests.
 - Rename the GUEST_TYPE to CC_GUEST_TYPE and move it from
   WorkArea.h@OvmfPkg to ConfidentialComputingGuestAttr.h@MdePkg.
   This is because CcProbeLib is designed to return the CC Guest
   type and the lib is located at MdePkg.
 - Rename the CC_GUEST_TYPE's fields name to Camel style. See the
   commit message in patch #1.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 

Min Xu (6):
  MdePkg: Add CC_GUEST_TYPE in ConfidentialComputingGuestAttr.h
  OvmfPkg: Replace GUEST_TYPE with CC_GUEST_TYPE
  MdePkg: Add CcProbeLib
  OvmfPkg: Add CcProbeLib
  MdePkg: Probe Cc guest in BaseIoLibIntrinsicSev
  OvmfPkg: Add CcProbeLib in *.dsc

 .../Include/ConfidentialComputingGuestAttr.h  | 11 ++-
 MdePkg/Include/Library/CcProbeLib.h   | 26 
 .../BaseIoLibIntrinsicSev.inf |  1 +
 .../BaseIoLibIntrinsic/IoLibInternalTdx.c | 13 ++--
 .../Library/CcProbeLibNull/CcProbeLibNull.c   | 26 
 .../Library/CcProbeLibNull/CcProbeLibNull.inf | 21 +
 MdePkg/MdePkg.dec |  5 +++
 MdePkg/MdePkg.dsc |  1 +
 OvmfPkg/AmdSev/AmdSevX64.dsc  |  1 +
 OvmfPkg/Bhyve/BhyveX64.dsc|  1 +
 OvmfPkg/CloudHv/CloudHvX64.dsc|  1 +
 OvmfPkg/Include/WorkArea.h|  9 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  1 +
 .../PeiMemEncryptSevLibInternal.c |  2 +-
 .../SecMemEncryptSevLibInternal.c |  2 +-
 OvmfPkg/Library/CcProbeLib/CcProbeLib.c   | 31 +++
 OvmfPkg/Library/CcProbeLib/CcProbeLib.inf | 25 +++
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c   |  2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc|  1 +
 OvmfPkg/OvmfPkgIa32.dsc   |  1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
 OvmfPkg/OvmfPkgX64.dsc|  1 +
 OvmfPkg/OvmfXen.dsc   |  1 +
 OvmfPkg/Sec/AmdSev.c  |  2 +-
 24 files changed, 162 insertions(+), 24 deletions(-)
 create mode 100644 MdePkg/Include/Library/CcProbeLib.h
 create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c
 create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
 create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.c
 create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.inf

-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88916): https://edk2.groups.io/g/devel/message/88916
Mute This Topic: https://groups.io/mt/90477274/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] GSoC Contributor Proposals

2022-04-14 Thread Ethin Probst 

Hi Nate,
I've submitted my proposal. I ran into some accessibility problems with 
the "project technologies" part, so there might be random junk there 
that was added that I couldn't figure out how to get rid of.


On 4/13/22 22:33, Nate DeSimone wrote:

Hi Everyone,

I hope you are all working on your proposals. If you would like some 
feedback on your proposals before having to submit the final version of 
them on Tuesday next week, please do one of the following:


 1. Upload your current draft proposal to the GSoC website.
 2. Email Mike Kinney and I a link to your draft proposal.

To allow sufficient time for review and implementation of provided 
feedback, please get your drafts to us by 5pm pacific Friday (2022-04-16 
0:00 UTC).


Best Regards,

Nate





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88915): https://edk2.groups.io/g/devel/message/88915
Mute This Topic: https://groups.io/mt/90457259/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 2/2] UefiPayloadPkg: Keep reserved MMIO at runtime

2022-04-14 Thread Guo Dong 


Reviewed-by: Guo Dong 

-Original Message-
From: Akihiko Odaki  
Sent: Sunday, April 10, 2022 7:47 PM
Cc: devel@edk2.groups.io; Dong, Guo ; Wang, Jian J 
; Gao, Liming ; Bi, Dandan 
; Kinney, Michael D ; Liu, 
Zhiguang ; Ni, Ray ; Ma, Maurice 
; You, Benjamin ; Akihiko Odaki 

Subject: [PATCH v2 2/2] UefiPayloadPkg: Keep reserved MMIO at runtime

Signed-off-by: Akihiko Odaki 
---
 UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 0fed1e3691..a50f1c0271 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -74,7 +74,8 @@ MemInfoCallbackMmio (
  EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |

  EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |

  EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |

- EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE;

+ EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |

+ EFI_RESOURCE_ATTRIBUTE_RUNTIME;

 

   BuildResourceDescriptorHob (Type, Attribue, (EFI_PHYSICAL_ADDRESS)Base, 
Size);

   DEBUG ((DEBUG_INFO, "buildhob: base = 0x%lx, size = 0x%lx, type = 0x%x\n", 
Base, Size, Type));

-- 
2.35.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88914): https://edk2.groups.io/g/devel/message/88914
Mute This Topic: https://groups.io/mt/90407108/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI environment

2022-04-14 Thread Frinzell, Aaron 
This is great!

Thanks JP for the patch.


Mike,

Any ETA when this will get merged?

Thanks!

Aaron



-Original Message-
From: Kinney, Michael D  
Sent: Friday, April 8, 2022 1:00 PM
To: Jayaprakash, N ; devel@edk2.groups.io; Kinney, 
Michael D 
Cc: Frinzell, Aaron 
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for UEFI 
environment

Thanks JP.

That makes sense.  Bypass all the OS specific services in UEFI environment and 
generate UUID using time and random number.

Reviewed-by: Michael D Kinney 

Mike


> -Original Message-
> From: Jayaprakash, N 
> Sent: Friday, April 8, 2022 10:19 AM
> To: devel@edk2.groups.io; Jayaprakash, N ; 
> Kinney, Michael D 
> Cc: Frinzell, Aaron 
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> + Aaron
> 
> Regards,
> JP
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of 
> Jayaprakash, N
> Sent: 08 April 2022 22:12
> To: Kinney, Michael D ; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> The UUID generation is done through the random number generation & 
> time unix time stamp features available through the built-in python modules 
> 'random' and 'time' respectively.
> The random number & time (unix time stamp or epoch) based method of 
> generating the UUID is already there in uuid.py module, with this patch 
> request enabled this path to take effect for UEFI invocation of this module.
> 
> There are some OS specific ways to generate the UUID's such as by 
> using the libuuid on Linux kind of OS, windll.rpcrt4 library on windows.
> These will not work for UEFI and hence added appropriate platform 
> check to ensure that this path is not taken for UEFI invocation.
> 
> Besides this there are MAC address based algorithms available in uuid.py 
> module.
> These algorism are based on reading MAC address through various OS 
> supported methods such as ipconfig command processing, NetBIOS calls 
> on Windows, using netstat command in Linux, lanscan in Unix, from arp - 
> address resolution protocol in Linux, NetBSD and other flavours of Linux.
> These are currently not enabled for UEFI invocation of the uuid 
> module. This has been done through platform check added at appropriate place 
> in the uuid.py module code.
> 
> Regards,
> JP
> -Original Message-
> From: Kinney, Michael D 
> Sent: 08 April 2022 21:14
> To: devel@edk2.groups.io; Jayaprakash, N ; 
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] 
> AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> UEFI environment
> 
> How is a UUID generated in UEFI env?  Is there a dependency on MAC address or 
> random number generator?
> 
> Can you add a description of the technique to the BZ and the commit message?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of 
> > Jayaprakash, N
> > Sent: Friday, April 8, 2022 4:52 AM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [edk2-libc Patch 1/1]
> > AppPkg\Applications\Python\Python-3.6.8\Lib: uuid.py module port for 
> > UEFI environment
> >
> >  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3899
> >
> >  This is commit contains the UEFI port of uuid.py module. Made 
> > necessary  changes required to uuid.py module to support UEFI environment.
> >  Porting of this module to UEFI is required for open source tools 
> > such as Chipsec to function properly.
> >
> >  Cc: Rebecca Cran 
> >  Cc: Michael D Kinney 
> >  Signed-off-by: Jayaprakash N 
> > ---
> >  .../Python/Python-3.6.8/Lib/uuid.py   | 94 ++-
> >  1 file changed, 50 insertions(+), 44 deletions(-)
> >
> > diff --git a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > index db8b2ef..84ed0b8 100644
> > --- a/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > +++ b/AppPkg/Applications/Python/Python-3.6.8/Lib/uuid.py
> > @@ -471,57 +471,61 @@ def _netbios_getnode():
> >  continue
> >  return int.from_bytes(bytes, 'big')
> >
> > +
> >  # Thanks to Thomas Heller for ctypes and for his help with its use here.
> >
> >  # If ctypes is available, use it to find system routines for UUID 
> > generation.
> >  # XXX This makes the module non-thread-safe!
> >  _uuid_generate_time = _UuidCreate = None
> > -try:
> > -import ctypes, ctypes.util
> > -import sys
> > -
> > -# The uuid_generate_* routines are provided by libuuid on at least
> > -# Linux and FreeBSD, and provided by libc on Mac OS X.
> > -_libnames = ['uuid']
> > -if not sys.platform.startswith('win'):
> > -_libnames.append('c')
> > -for libname in _libnames:
> > -try:
> > -

[edk2-devel] Cancelled Event: TianoCore Design Meeting - APAC/NAMO - Friday, April 15, 2022 #cal-cancelled

2022-04-14 Thread devel@edk2.groups.io Calendar 
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20220317T223602Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1238726 
UID:ccyo.1615368347866508187.a...@groups.io
DTSTAMP:20220414T145839Z
ORGANIZER;CN=Ray Ni:mailto:ray...@intel.com
DTSTART:20220415T013000Z
DTEND:20220415T023000Z
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:## TOPIC\n\n1. NA\n\nFor more info\, see here: https://www.ti
 anocore.org/design-meeting/\n\n---\n## Microsoft Teams meeting\n\n### Joi
 n on your computer or mobile app\n\n[Click here to join the meeting](http
 s://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZT
 dkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d
 88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc2
 7-3d06c576cc19%22%7d)\n\n### Join with a video conferencing device\n\ntea
 m...@conf.intel.com\n\nVideo Conference ID: 119 715 416 0\n\n[Alternate VTC
  dialing instructions](https://conf.intel.com/teams/?conf=1197154160=
 teams=conf.intel.com=test_call)\n\n[Learn More](https://aka.ms/Joi
 nTeamsMeeting) | [Meeting options](https://teams.microsoft.com/meetingOpt
 ions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19=46c98d88-
 e344-4ed4-8496-4ed7712e255d=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkL
 WI5NDgtYTFmYjNkOWI0ZDg4@thread.v2=0=en-US)
LOCATION:Microsoft Teams
SEQUENCE:1
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/TlsLibNull: Remove MU_CHANGE comment markers

2022-04-14 Thread Yao, Jiewen 
Merged - https://github.com/tianocore/edk2/pull/2779

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Thursday, April 14, 2022 10:32 PM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com
> Cc: Wang, Jian J ; Lu, Xiaoyu1 ;
> Jiang, Guomin 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/TlsLibNull: Remove
> MU_CHANGE comment markers
> 
> Ah, thanks for the reminder. I overlooked this one.
> 
> Reviewed-by: Jiewen Yao 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael
> > Kubacki
> > Sent: Thursday, April 14, 2022 10:19 PM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Wang, Jian J
> ;
> > Lu, Xiaoyu1 ; Jiang, Guomin 
> > Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/TlsLibNull: Remove
> > MU_CHANGE comment markers
> >
> > Please review this patch when possible. It is just removing two
> > irrelevant comments.
> >
> > Thanks,
> > Michael
> >
> > On 4/5/2022 8:50 PM, Michael Kubacki wrote:
> > > From: Michael Kubacki 
> > >
> > > MU_CHANGE tags are used in a different project (Project Mu) to
> > > highlight deviations from Tianocore. Therefore, the comments are
> > > not needed when the changes are present in a Tianocore repository.
> > >
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Xiaoyu Lu 
> > > Cc: Guomin Jiang 
> > > Signed-off-by: Michael Kubacki 
> > > ---
> > >   CryptoPkg/Library/TlsLibNull/TlsConfigNull.c | 4 
> > >   1 file changed, 4 deletions(-)
> > >
> > > diff --git a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > > index b5d9aca06535..03726fd7264c 100644
> > > --- a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > > +++ b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > > @@ -130,8 +130,6 @@ TlsSetVerify (
> > > ASSERT (FALSE);
> > >   }
> > >
> > > -// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN)
> > accepted. [BEGIN]
> > > -
> > >   /**
> > > Set the specified host name to be verified.
> > >
> > > @@ -156,8 +154,6 @@ TlsSetVerifyHost (
> > > return EFI_UNSUPPORTED;
> > >   }
> > >
> > > -// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN)
> > accepted. [END]
> > > -
> > >   /**
> > > Sets a TLS/SSL session ID to be used during TLS/SSL connect.
> > >
> >
> >
> >
> >
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88911): https://edk2.groups.io/g/devel/message/88911
Mute This Topic: https://groups.io/mt/90280180/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 1/1] CryptoPkg/TlsLibNull: Remove MU_CHANGE comment markers

2022-04-14 Thread Yao, Jiewen 
Ah, thanks for the reminder. I overlooked this one.

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Thursday, April 14, 2022 10:19 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Lu, Xiaoyu1 ; Jiang, Guomin 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/TlsLibNull: Remove
> MU_CHANGE comment markers
> 
> Please review this patch when possible. It is just removing two
> irrelevant comments.
> 
> Thanks,
> Michael
> 
> On 4/5/2022 8:50 PM, Michael Kubacki wrote:
> > From: Michael Kubacki 
> >
> > MU_CHANGE tags are used in a different project (Project Mu) to
> > highlight deviations from Tianocore. Therefore, the comments are
> > not needed when the changes are present in a Tianocore repository.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Xiaoyu Lu 
> > Cc: Guomin Jiang 
> > Signed-off-by: Michael Kubacki 
> > ---
> >   CryptoPkg/Library/TlsLibNull/TlsConfigNull.c | 4 
> >   1 file changed, 4 deletions(-)
> >
> > diff --git a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > index b5d9aca06535..03726fd7264c 100644
> > --- a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > +++ b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
> > @@ -130,8 +130,6 @@ TlsSetVerify (
> > ASSERT (FALSE);
> >   }
> >
> > -// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN)
> accepted. [BEGIN]
> > -
> >   /**
> > Set the specified host name to be verified.
> >
> > @@ -156,8 +154,6 @@ TlsSetVerifyHost (
> > return EFI_UNSUPPORTED;
> >   }
> >
> > -// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN)
> accepted. [END]
> > -
> >   /**
> > Sets a TLS/SSL session ID to be used during TLS/SSL connect.
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88910): https://edk2.groups.io/g/devel/message/88910
Mute This Topic: https://groups.io/mt/90280180/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 1/1] CryptoPkg/TlsLibNull: Remove MU_CHANGE comment markers

2022-04-14 Thread Michael Kubacki 
Please review this patch when possible. It is just removing two 
irrelevant comments.


Thanks,
Michael

On 4/5/2022 8:50 PM, Michael Kubacki wrote:

From: Michael Kubacki 

MU_CHANGE tags are used in a different project (Project Mu) to
highlight deviations from Tianocore. Therefore, the comments are
not needed when the changes are present in a Tianocore repository.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Guomin Jiang 
Signed-off-by: Michael Kubacki 
---
  CryptoPkg/Library/TlsLibNull/TlsConfigNull.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c 
b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
index b5d9aca06535..03726fd7264c 100644
--- a/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
+++ b/CryptoPkg/Library/TlsLibNull/TlsConfigNull.c
@@ -130,8 +130,6 @@ TlsSetVerify (
ASSERT (FALSE);
  }
  
-// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN) accepted. [BEGIN]

-
  /**
Set the specified host name to be verified.
  
@@ -156,8 +154,6 @@ TlsSetVerifyHost (

return EFI_UNSUPPORTED;
  }
  
-// MU_CHANGE - Proposed fixes for TCBZ960, invalid domain name (CN) accepted. [END]

-
  /**
Sets a TLS/SSL session ID to be used during TLS/SSL connect.
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88909): https://edk2.groups.io/g/devel/message/88909
Mute This Topic: https://groups.io/mt/90280180/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-discuss] GSoC Proposal

2022-04-14 Thread Marvin Häuser 


> On 14. Apr 2022, at 00:57, Nate DeSimone  
> wrote:
> 
> Hi All,
> 
> Pedro is 100% correct. The primary use case and the reason I added this is to 
> remove library duplication across all the .efi files. This is actually super 
> valuable because LZMA compression is becoming ineffective because compiler 
> optimization is getting so good that the patterns for a library across 
> binaries don’t match very well anymore.

I feel like there are so many much easier solutions to this problem that are at 
most limited by the clear specification. The UEFI specification with regards to 
booting and all of that obviously is of utmost importance. The UEFI PI 
specification parts that deal about internal structure, as far as I know, are 
only in place to make it easy to integrate Intel IP. In fact, I don’t *know*, 
but I’m pretty sure the very strict separation between PEI and DXE was 
preserved mostly because MRC was 32-bit-only for a long time. Glad that seems 
to have been resolved, AMD does memory init by PSP nowadays.

For many good reasons, Linux does not provide a stable kernel API. This allows 
to easily deploy breaking changes across the entire codebase. Obviously, this 
is infeasible at a large scale when you need to integrate IP blobs, but it 
would already help to break the expectation that UEFI PI is a perfectly 
forwards- and backwards-compatible system. DXE has SetMem and CopyMem as part 
of gBS. Maybe I don’t like it that much as part of the spec itself, but it’s a 
good idea technically. I’d probably opt to have a quickly accessible 
implementation detail of important function pointers appended to PEI and DXE 
services, used by in-tree modules. This may break both forwards- and 
backwards-compatibility, but as it only applies to in-tree modules, that is 
fine so long as we let go of the compatibility notions. PPIs and protocols are 
an option too of course, but they have a lookup performance penalty. Compared 
to dynamic linking, that should hopefully be negligible however.

Absolutely optional to read, I don’t intend to waste anyone’s time much, some 
philosophical stuff about my rationale:

If you started UEFI from scratch right now, would it have strictly separated 
PEI and DXE? The duplication between PEI and DXE core, and by extension MM 
core, would be my most obvious place to start reducing size. I would probably 
opt for a PEI/DXE hybrid where it starts in „minimal mode“ (maybe think of PEI 
more like a microkernel here) and after memory is initialised, the rest of DXE 
is loaded. And MM core would get no loading at all, this requirement has gladly 
been dropped ages ago. Just one prelinked snapshot of the address space with a 
relocation table and a safe self-relocator on entry (this is needed at the very 
least for ARM).

Ironically, with my idea for MM, dynamic loading would be free as everything is 
prelinked anyway. The same is true for PEI XIP, it is prelinked by nature. What 
I do not like is the additional dynamic linking code at load-time for non-XIP 
modules. Though, the more I think about it, the more I wonder whether not the 
entirety of UEFI could be composed of prelinked, relocatable memory snapshots 
without traditional image loading entirely (for in-FW stuff). macOS has a 
similar concept with its “Kernel Collections”. Well, way too much off-topic 
now. :)

Why am I explaining all this despite the fact everyone knows this will never 
happen? Because I don’t like the notion of fixing issues of an already 
overcomplicated system by adding even more complicated stuff. Especially when 
the existing overcomplicated stuff is already uncomfortably broken.

Best regards,
Marvin

> For XIP PEI code… it will really help and would be very timely since the 
> transition of PEI from 32-bit to 64-bit is going to increase the size of PEI 
> by ~20%.
> 
> Thanks,
> Nate
> 
> From: Pedro Falcato 
> Sent: Wednesday, April 13, 2022 11:43 AM
> To: edk2-devel-groups-io ; Marvin Häuser 
> 
> Cc: disc...@edk2.groups.io; adachristin...@gmail.com; Desimone, Nathaniel L 
> ; Shi, Steven 
> Subject: Re: [edk2-devel] [edk2-discuss] GSoC Proposal
> 
> Hi Marvin, Ada,
> 
> Some comments:
> 
> I don't think the purpose of the dynamic linker is to treat EFI as a complete 
> operating system, but to try to eliminate the static linking that may be 
> needlessly duplicating
> code that could instead be put in a single dynamic library. For instance, 
> MdePkg and MdeModulePkg are linked into a *lot* of .efi, instead of being 
> just a library. It'd be nice to see some
> numbers on this (something like Google's bloaty could be run on every .efi 
> file, in order to understand how much file space we would actually save).
> 
> Other comments inline.
> 
> On Wed, Apr 13, 2022 at 4:15 PM Marvin Häuser 
> mailto:mhaeu...@posteo.de>> wrote:
> 
> On 13. Apr 2022, at 16:38, Ada Christine 
> mailto:adachristin...@gmail.com>> wrote:
> i was replying via the groups.io web interface, I'm 
> guessing

[edk2-devel] [PATCH v7 1/4] Platform/Phytium: Solved problems during boot.

2022-04-14 Thread Ling Jia 
Solved the problem of lack of dependent Library
in PciHostBridgeDxe.

Solved the problem of missing boot magager menu.

Signed-off-by: Ling Jia 
Reviewed-by: leif Lindholm 
---
 Platform/Phytium/DurianPkg/DurianPkg.fdf | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Platform/Phytium/DurianPkg/DurianPkg.fdf 
b/Platform/Phytium/DurianPkg/DurianPkg.fdf
index 2d4427e5ea..efb855c5da 100644
--- a/Platform/Phytium/DurianPkg/DurianPkg.fdf
+++ b/Platform/Phytium/DurianPkg/DurianPkg.fdf
@@ -142,6 +142,7 @@ READ_LOCK_STATUS   = TRUE
   #
   # PCI Support
   #
+  INF ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
   INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
   INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
 
@@ -204,6 +205,11 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
+  #
+  #Setup
+  #
+  INF MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88903): https://edk2.groups.io/g/devel/message/88903
Mute This Topic: https://groups.io/mt/90458875/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v7 2/4] Silicon/Phytium: Added flash driver support to Phytium Silicon.

2022-04-14 Thread Ling Jia 
The SpiNorFlashDxe provided norflash initialization,
read-write, erase and other interfaces.

This is a set of special communication protocol for
ft2004/4 chip QSPI controller.

Signed-off-by: Ling Jia 
Reviewed-by: leif Lindholm 
---
 Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec   |   1 +
 Platform/Phytium/DurianPkg/DurianPkg.dsc|  13 +
 Platform/Phytium/DurianPkg/DurianPkg.fdf|  24 
+-
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf   |  49 
+++
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h |  95 
+
 Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h |  74 

 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c | 412 

 7 files changed, 658 insertions(+), 10 deletions(-)

diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec 
b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
index 8427f32211..4c6c5c5f11 100644
--- a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
+++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
@@ -49,3 +49,4 @@
 
 [Protocols]
   gSpiMasterProtocolGuid = { 0xdf093560, 0xf955, 0x11ea, { 0x96, 0x42, 0x43, 
0x9d, 0x80, 0xdd, 0x0b, 0x7c}}
+  gSpiNorFlashProtocolGuid = { 0x00b4af42, 0xfbd0, 0x11ea, { 0x80, 0x3a, 0x27, 
0xea, 0x5e, 0x65, 0xe3, 0xf6}}
diff --git a/Platform/Phytium/DurianPkg/DurianPkg.dsc 
b/Platform/Phytium/DurianPkg/DurianPkg.dsc
index c1519070d6..cc0d418555 100644
--- a/Platform/Phytium/DurianPkg/DurianPkg.dsc
+++ b/Platform/Phytium/DurianPkg/DurianPkg.dsc
@@ -100,6 +100,14 @@
   # Stack Size
   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x4000
 
+  #
+  # SPI Flash Control Register Base Address and Size
+  #
+  gPhytiumPlatformTokenSpaceGuid.PcdSpiFlashBase|0x0
+  gPhytiumPlatformTokenSpaceGuid.PcdSpiFlashSize|0x100
+  gPhytiumPlatformTokenSpaceGuid.PcdSpiControllerBase|0x28014000
+  gPhytiumPlatformTokenSpaceGuid.PcdSpiControllerSize|0x1000
+  gPhytiumPlatformTokenSpaceGuid.PcdRtcBaseAddress|0x2800D000
   #
   # Designware PCI Root Complex
   #
@@ -255,6 +263,11 @@
   #
   Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
 
+  #
+  # NOR Flash driver
+  #
+  Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
+
   #
   # Usb Support
   #
diff --git a/Platform/Phytium/DurianPkg/DurianPkg.fdf 
b/Platform/Phytium/DurianPkg/DurianPkg.fdf
index efb855c5da..5c1471d8ed 100644
--- a/Platform/Phytium/DurianPkg/DurianPkg.fdf
+++ b/Platform/Phytium/DurianPkg/DurianPkg.fdf
@@ -83,6 +83,11 @@ READ_LOCK_STATUS   = TRUE
 
   APRIORI DXE {
 INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
+INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
+INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
   }
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -91,29 +96,28 @@ READ_LOCK_STATUS   = TRUE
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
   #
+  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
+  INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
+  INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-  INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
-  INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
   INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
-
-  INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-
-  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
-  INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
-  INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-  INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
+  INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
 
   #
   # Variable services
   #
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
   INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
 
+  INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
+  INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
   INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
+  INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
+  INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
   #
   # ACPI Support
diff --git 
a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf 
b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
new file mode 100755
index 00..2173405809
--- /dev/null
+++

[edk2-devel] [PATCH v7 3/4] Silicon/Phytium: Added fvb driver for flash

2022-04-14 Thread Ling Jia 
The FlashFvbDxe provided the fvb protocol,
which requested by the flash operators.

Signed-off-by: Ling Jia 
Reviewed-by: leif Lindholm 
---
 Platform/Phytium/DurianPkg/DurianPkg.dsc |1 +
 Platform/Phytium/DurianPkg/DurianPkg.fdf |2 +
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf |   63 +
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h   |  105 ++
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c   | 1329 

 5 files changed, 1500 insertions(+)

diff --git a/Platform/Phytium/DurianPkg/DurianPkg.dsc 
b/Platform/Phytium/DurianPkg/DurianPkg.dsc
index cc0d418555..cedf7480a5 100644
--- a/Platform/Phytium/DurianPkg/DurianPkg.dsc
+++ b/Platform/Phytium/DurianPkg/DurianPkg.dsc
@@ -267,6 +267,7 @@
   # NOR Flash driver
   #
   Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
+  Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
 
   #
   # Usb Support
diff --git a/Platform/Phytium/DurianPkg/DurianPkg.fdf 
b/Platform/Phytium/DurianPkg/DurianPkg.fdf
index 5c1471d8ed..1a52250db2 100644
--- a/Platform/Phytium/DurianPkg/DurianPkg.fdf
+++ b/Platform/Phytium/DurianPkg/DurianPkg.fdf
@@ -88,6 +88,7 @@ READ_LOCK_STATUS   = TRUE
 INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
 INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
+INF Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
   }
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -105,6 +106,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
   INF Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.inf
+  INF Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
 
   #
   # Variable services
diff --git 
a/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf 
b/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
new file mode 100755
index 00..9121be921c
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
@@ -0,0 +1,63 @@
+#/** @file
+#  Phytium NorFlash Fvb Drivers.
+#
+#  Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+#  Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001b
+  BASE_NAME  = FlashFvbDxe
+  FILE_GUID  = b8923820-3e7c-11eb-b12c-17525e90ecc8
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 0.1
+  ENTRY_POINT= FvbEntryPoint
+
+[Sources]
+  FlashFvbDxe.c
+  FlashFvbDxe.h
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  DxeServicesTableLib
+  HobLib
+  MemoryAllocationLib
+  UefiBootServicesTableLib
+  UefiRuntimeLib
+  UefiDriverEntryPoint
+  UefiRuntimeServicesTableLib
+
+[Guids]
+  gEfiAuthenticatedVariableGuid
+  gEfiEventVirtualAddressChangeGuid
+  gEfiSystemNvDataFvGuid
+  gEfiVariableGuid
+
+[Protocols]
+  gEfiDevicePathProtocolGuid
+  gEfiFirmwareVolumeBlockProtocolGuid
+  gSpiNorFlashProtocolGuid
+
+[FixedPcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
+
+
+[Depex]
+  TRUE
diff --git a/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h 
b/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h
new file mode 100755
index 00..923ad3ccbb
--- /dev/null
+++ b/Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h
@@ -0,0 +1,105 @@
+/** @file
+  Phytium NorFlash Fvb Drivers Header.
+
+  Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef FVB_FLASH_DXE_H_
+#define FVB_FLASH_DXE_H_
+
+#include 
+#include 
+#include 
+#include 
+
+#define GET_DATA_OFFSET(BaseAddr, Lba, LbaSize) ((BaseAddr) + (UINTN)((Lba) * 
(LbaSize)))
+#define FVB_FLASH_SIGNATURE   SIGNATURE_32('S', 'N', 'O', 
'R')
+#define INSTANCE_FROM_FVB_THIS(a) CR(a, FT_FVB_DEVICE, 
FvbProtocol, FVB_FLASH_SIGNATURE)
+
+typedef struct _FT_FVB_DEVICEFT_FVB_DEVICE;
+
+#define NOR_FLASH_ERASE_RETRY 10
+
+typedef struct {
+  VENDOR_DEVICE_PATH  Vendor;
+  EFI_DEVICE_PATH_PROTOCOLEnd;
+  } FT_FVB_DEVICE_PATH;
+
+struct

[edk2-devel] [PATCH v7 0/4] Improved support for FT2004/4 chip.

2022-04-14 Thread Ling Jia 
Completed the flash driver and fvb driver.
Solved the problems in boot process.
Added virtual address conversion.

The public git repository is :
https://github.com/jialing2020/edk2-platforms/tree/Phytium_Opensource_For_FT2000-4_v7

Ling Jia (4):
  Platform/Phytium: Solved problems during boot.
  Silicon/Phytium: Added flash driver support to Phytium Silicon.
  Silicon/Phytium: Added fvb driver for flash
  Silicon/Phytium: Added runtime support to spi master.

 Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec  
  |1 +
 Platform/Phytium/DurianPkg/DurianPkg.dsc   
  |   14 +
 Platform/Phytium/DurianPkg/DurianPkg.fdf   
  |   32 +-
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf  
  |5 +
 Silicon/Phytium/FT2000-4Pkg/Drivers/{SpiDxe/SpiDxe.inf => 
SpiNorFlashDxe/SpiNorFlashDxe.inf} |   25 +-
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf   
  |   63 +
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h
  |2 +
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h
  |   95 ++
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h 
  |  105 ++
 Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h
  |   74 ++
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c
  |   84 +-
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c
  |  412 ++
 Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c 
  | 1329 
 13 files changed, 2210 insertions(+), 31 deletions(-)
 copy Silicon/Phytium/FT2000-4Pkg/Drivers/{SpiDxe/SpiDxe.inf => 
SpiNorFlashDxe/SpiNorFlashDxe.inf} (55%)
 mode change 100644 => 100755
 create mode 100755 
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.inf
 create mode 100755 
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.h
 create mode 100755 
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.h
 create mode 100755 
Silicon/Phytium/PhytiumCommonPkg/Include/Protocol/SpiNorFlashProtocol.h
 create mode 100755 
Silicon/Phytium/FT2000-4Pkg/Drivers/SpiNorFlashDxe/SpiNorFlashDxe.c
 create mode 100755 
Silicon/Phytium/PhytiumCommonPkg/Drivers/FlashFvbDxe/FlashFvbDxe.c

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88906): https://edk2.groups.io/g/devel/message/88906
Mute This Topic: https://groups.io/mt/90458878/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v7 4/4] Silicon/Phytium: Added runtime support to spi master.

2022-04-14 Thread Ling Jia 
Solved the problem of virtual address translation
in runtime access under OS

Signed-off-by: Ling Jia 
Reviewed-by: leif Lindholm 
---
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf |  5 ++
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h   |  2 +
 Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c   | 84 +---
 3 files changed, 80 insertions(+), 11 deletions(-)

diff --git a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf 
b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
index 21d75f268d..0b23821c65 100644
--- a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
+++ b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.inf
@@ -27,18 +27,23 @@
 [LibraryClasses]
   BaseLib
   DebugLib
+  DxeServicesTableLib
   IoLib
   UefiLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
+  UefiRuntimeLib
+  UefiRuntimeServicesTableLib
 
 [Guids]
+  gEfiEventVirtualAddressChangeGuid
 
 [Protocols]
   gSpiMasterProtocolGuid
 
 [FixedPcd]
   gPhytiumPlatformTokenSpaceGuid.PcdSpiControllerBase
+  gPhytiumPlatformTokenSpaceGuid.PcdSpiControllerSize
 
 [Depex]
   TRUE
diff --git a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h 
b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h
index 8795ea238d..842d0c3d18 100644
--- a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h
+++ b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.h
@@ -10,6 +10,8 @@
 #ifndef SPI_DXE_H_
 #define SPI_DXE_H_
 
+#include 
+#include 
 #include 
 
 #define SPI_MASTER_SIGNATURE SIGNATURE_32 ('M', 'S', 'P', 'I')
diff --git a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c 
b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c
index 7602a3e0cd..5358ff6090 100644
--- a/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c
+++ b/Silicon/Phytium/FT2000-4Pkg/Drivers/SpiDxe/SpiDxe.c
@@ -13,8 +13,9 @@
 #include 
 #include "SpiDxe.h"
 
-PHYT_SPI_MASTER *pSpiMasterInstance;
-static UINTN mSpiControlBase;
+STATIC EFI_EVENT  mSpiMasterVirtualAddrChangeEvent;
+STATIC UINTN  mSpiMasterControlBase;
+PHYT_SPI_MASTER   *mSpiMasterInstance;
 
 /**
   This function inited a spi driver.
@@ -66,7 +67,7 @@ SpiMasterSetConfig (
 Value = Config;
   }
 
-  SpiAddr = mSpiControlBase + RegAddr;
+  SpiAddr = mSpiMasterControlBase + RegAddr;
   MmioWrite32 (SpiAddr, Value);
 
   return EFI_SUCCESS;
@@ -99,7 +100,7 @@ SpiMasterGetConfig (
   SpiAddr = 0;
   Value   = 0;
 
-  SpiAddr = mSpiControlBase + RegAddr;
+  SpiAddr = mSpiMasterControlBase + RegAddr;
   Value = MmioRead32 (SpiAddr);
 
   if (CmdId != 0) {
@@ -157,6 +158,34 @@ SpiMasterInitProtocol (
   return EFI_SUCCESS;
 }
 
+/**
+  Fixup internal data so that EFI can be call in virtual mode.
+  Call the passed in Child Notify event and convert any pointers
+  in lib to virtual mode.
+
+  @param[in]Event   The Event that is being processed.
+
+  @param[in]Context Event Context.
+
+  @retval   None.
+
+**/
+STATIC
+VOID
+EFIAPI
+SpiMasterVirtualNotifyEvent (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  EfiConvertPointer (0x0, (VOID **)&(mSpiMasterControlBase));
+  EfiConvertPointer (0x0, (VOID 
**)&(mSpiMasterInstance->SpiMasterProtocol.SpiGetConfig));
+  EfiConvertPointer (0x0, (VOID 
**)&(mSpiMasterInstance->SpiMasterProtocol.SpiSetConfig));
+  EfiConvertPointer (0x0, (VOID **)&(mSpiMasterInstance->SpiMasterProtocol));
+  EfiConvertPointer (0x0, (VOID **)&(mSpiMasterInstance));
+
+  return;
+}
 
 /**
   This function is the entrypoint of the spi driver.
@@ -178,25 +207,58 @@ SpiMasterDrvEntryPoint (
   )
 {
   EFI_STATUS  Status;
+  UINTN   SpiMasterControlSize;
 
-  pSpiMasterInstance = AllocateRuntimeZeroPool (sizeof (PHYT_SPI_MASTER));
-  if (pSpiMasterInstance == NULL) {
+  mSpiMasterControlBase = FixedPcdGet64 (PcdSpiControllerBase);
+  SpiMasterControlSize = FixedPcdGet64 (PcdSpiControllerSize);
+
+  mSpiMasterInstance = AllocateRuntimeZeroPool (sizeof (PHYT_SPI_MASTER));
+  if (mSpiMasterInstance == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
 
-  mSpiControlBase = FixedPcdGet64 (PcdSpiControllerBase);
+  mSpiMasterControlBase = FixedPcdGet64 (PcdSpiControllerBase);
 
-  SpiMasterInitProtocol (>SpiMasterProtocol);
+  SpiMasterInitProtocol (>SpiMasterProtocol);
 
-  pSpiMasterInstance->Signature = SPI_MASTER_SIGNATURE;
+  mSpiMasterInstance->Signature = SPI_MASTER_SIGNATURE;
 
   Status = gBS->InstallMultipleProtocolInterfaces (
-&(pSpiMasterInstance->Handle),
+&(mSpiMasterInstance->Handle),
 ,
-&(pSpiMasterInstance->SpiMasterProtocol),
+&(mSpiMasterInstance->SpiMasterProtocol),
 NULL
 );
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Declare the SPI Controller Space as EFI_MEMORY_RUNTIME
+  //
+  Status = gDS->AddMemorySpace (
+  EfiGcdMemoryTypeMemoryMappedIo,
+  (mSpiMasterControlBase >> EFI_PAGE_SHIFT) << EFI_PAGE_SHIFT,