date:20210409

Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

2021-04-09 Thread Nate DeSimone

On Thu, Apr 8, 2021 at 10:33 PM, Benjamin Doron wrote:

> Sorry, I meant that the specifics of flashing might not be relevant if no 
> TianoCore mentor/developer will have one of these boards.

Ah I understand now, yes that makes much more sense!

> Okay, nice! I suppose within EDK2, dispatch mode is more intuitive/natural. 
> In other system firmware, well, the "Firmware Support Package" still has API 
> mode, so it's not really my concern.

Yup, the general idea is to have FSP integrate nicely regardless of the 
bootloader architecture.

> I've shared a draft of the project proposal, feel free to take a look at it 
> at your convenience. I'd appreciate any feedback.

I see your application in the system and it looks great, nicely written and 
formatted! Thank you Benjamin we will be in touch.



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

[edk2-devel] [PATCH] DynamicTablesPkg: add validation for PcdNonBsaCompliant16550SerialHid

2021-04-09 Thread Joey Gouly

According to ACPI 6.4, 6.1.5 _HID states:

  - A valid PNP ID must be of the form "AAA" where A is an uppercase
letter and # is a hex digit.
  - A valid ACPI ID must be of the form "" where N is an uppercase
letter or a digit ('0'-'9') and # is a hex digit.

Signed-off-by: Joey Gouly 
---

The changes can be seen at 
https://github.com/jgouly/edk2/tree/1645_non_sba_compliant_validation_v1

 DynamicTablesPkg/Include/Library/TableHelperLib.h  
 | 38 +-
 
DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c 
|  4 ++
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c   
 | 73 +++-
 3 files changed, 113 insertions(+), 2 deletions(-)

diff --git a/DynamicTablesPkg/Include/Library/TableHelperLib.h 
b/DynamicTablesPkg/Include/Library/TableHelperLib.h
index 
099a0a4544e3d1f746d4be8533cb006786f11611..0f93cdbf08953af2377952ef616f760a51706170
 100644
--- a/DynamicTablesPkg/Include/Library/TableHelperLib.h
+++ b/DynamicTablesPkg/Include/Library/TableHelperLib.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017 - 2020, Arm Limited. All rights reserved.
+  Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -12,6 +12,18 @@
 #ifndef TABLE_HELPER_LIB_H_
 #define TABLE_HELPER_LIB_H_
 
+/** Is a character upper case
+*/
+#define IS_UPPER_CHAR(x) ((x >= 'A') && (x <= 'Z'))
+
+/** Is a character a decimal digit
+*/
+#define IS_DIGIT(x) ((x >= '0') && (x <= '9'))
+
+/** Is a character an upper case hexadecimal digit
+*/
+#define IS_UPPER_HEX(x) (((x >= 'A') && (x <= 'F')) || IS_DIGIT (x))
+
 /** The GetCgfMgrInfo function gets the CM_STD_OBJ_CONFIGURATION_MANAGER_INFO
 object from the Configuration Manager.
 
@@ -120,4 +132,28 @@ AsciiFromHex (
   IN  UINT8   x
   );
 
+/** Check if a HID is a valid PNP ID.
+
+  @param [in] Hid The Hid to validate.
+
+  @retvalTRUE The Hid is a valid PNP ID.
+  @retvalFALSEThe Hid is not a valid PNP ID.
+**/
+BOOLEAN
+IsValidPnpId (
+  IN  CONST CHAR8  * Hid
+  );
+
+/** Check if a HID is a valid ACPI ID.
+
+  @param [in] Hid The Hid to validate.
+
+  @retvalTRUE The Hid is a valid ACPI ID.
+  @retvalFALSEThe Hid is not a valid ACPI ID.
+**/
+BOOLEAN
+IsValidAcpiId (
+  IN  CONST CHAR8  * Hid
+  );
+
 #endif // TABLE_HELPER_LIB_H_
diff --git 
a/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
 
b/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
index 
3c4356097c3bf25e8d1432b45ba8ca59d33e8d09..f2b4831ad596284476fb342148d9c1f62bc7f98b
 100644
--- 
a/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
+++ 
b/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
@@ -148,6 +148,10 @@ FixupIds (
   // If there is a non-BSA compliant HID, use that.
   NonBsaHid = (CONST CHAR8*)PcdGetPtr (PcdNonBsaCompliant16550SerialHid);
   if ((NonBsaHid != NULL) && (AsciiStrLen (NonBsaHid) != 0)) {
+if (!(IsValidPnpId (NonBsaHid) || IsValidAcpiId (NonBsaHid))) {
+  return EFI_INVALID_PARAMETER;
+}
+
 HidString = NonBsaHid;
 CidString = "";
   } else {
diff --git a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c 
b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
index 
0d9daad3b05b6e82089f92afb6de45af9a28..9830ce62b3cb94be6d861a09d8d8356d60fdfbba
 100644
--- a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
+++ b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
@@ -1,7 +1,7 @@
 /** @file
   Table Helper
 
-  Copyright (c) 2017 - 2020, Arm Limited. All rights reserved.
+  Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -270,3 +270,74 @@ AsciiFromHex (
   ASSERT (FALSE);
   return (UINT8)0;
 }
+
+/** Check if a HID is a valid PNP ID.
+
+  @param [in] Hid The Hid to validate.
+
+  @retvalTRUE The Hid is a valid PNP ID.
+  @retvalFALSEThe Hid is not a valid PNP ID.
+**/
+BOOLEAN
+IsValidPnpId (
+  IN  CONST CHAR8  * Hid
+  )
+{
+  UINTN Index;
+
+  if (AsciiStrLen (Hid) != 7) {
+return FALSE;
+  }
+
+  // A valid PNP ID must be of the form "AAA"
+  // where A is an uppercase letter and # is a hex digit.
+  for (Index = 0; Index < 3; Index++) {
+if (!IS_UPPER_CHAR (Hid[Index])) {
+  return FALSE;
+}
+  }
+
+  for (Index = 3; Index < 7; Index++) {
+if (!IS_UPPER_HEX (Hid[Index])) {
+  return FALSE;
+}
+  }
+
+  return TRUE;
+}
+
+/** Check if a HID is a valid ACPI ID.
+
+  @param [in] Hid The Hid to validate.
+
+  @retvalTRUE The Hid is a valid ACPI ID.
+  @retvalFALSEThe Hid is not a valid ACPI ID.
+**/
+BOOLEAN
+IsValidAcpiId (
+  IN  CONST CHAR8  * Hid
+  )
+{
+  UINTN Index;
+

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

2021-04-09 Thread Laszlo Ersek

On 04/08/21 13:59, Brijesh Singh wrote:
> On 4/8/21 4:58 AM, Laszlo Ersek wrote:
>> On 03/24/21 16:31, Brijesh Singh wrote:

>>> At this time we only support the pre-validation. OVMF detects all the 
>>> available
>>> system RAM in the PEI phase. When SEV-SNP is enabled, the memory is 
>>> validated
>>> before it is made available to the EDK2 core.
>> Can you describe this in a bit more detail, before I look at the
>> individual patches? Specifically, what existing logic in the PEI phase
>> was taken, and extended, and how?
> 
> One of the key requirement is that the guest private pages much be
> validated before the access. If guest tries to access the pages before
> the validation then it will result in #VC (page-not-validated)
> exception. To avoid the #VC, we propose the validating the memory before
> the access. We will incrementally add the support to lazy validate (i.e
> validate on access).

What is the primary threat (in simple terms please) that validation is
supposed to prevent?

And, against that particular threat, does pre-validation offer some
protection, or will that only come with lazy validation?

> 
> Let me try explaining a bit, the page validation process consist of two
> steps:
> 
> 1. Add the pages in the RMP table -- must be done by the hypervisor
> using the RMPUPDATE instruction. The guest can use VMGEXIT NAEs to ask
> hypervisor to add or remove pages from the RMP table.
> 
> 2. Guest issue the PVALIDATE instruction -- this sets the validate bit
> in the RMP table.
> 
> Similar to SEV, the OVMF_CODE.fd is encrypted through the SNP firmware
> before the launch. The SNP firmware also validates the memory page after
> encrypting. This allows us to boot the initial entry code without guest
> going through the validation process.
> 
> The OVMF reset vector uses few data pages (e.g page table, early Sec
> stack). Access to these data pages will result in #VC. There are two
> approaches we can take to validate these data pages:
> 
> 1. Ask SNP firmware to pre-validate it -- SNP firmware provides an
> special command that can be used to pre-validate the pages without
> affecting the measurement.

This means the two pflash chips, right?

> 
> 2. Enhance the reset vector code to validate the pages.
> 
> For now I choose #1.
> 
> The pre-validation performed by the SNP firmware is sufficient to boot
> through the SEC phase. The SEC phase later decompress the Fv to a new
> memory location. Now we need the OVMF to take over the validation
> procedure.  The series extends the MemEncryptSevLib to add a new helper
> MemEncryptSevSnpValidateRam(). The helper is used to validate the system
> RAM. See patch #12. SEC phase calls the MemEncryptSevSnpValidateRam() to
> validate the output buffer used for the decompression. This was
> sufficient to boot into the PEI phase, see patch #13.

Two questions here:

- Is ACPI S3 in scope for now?

- We need more areas made accessible in SEC than just the decompression
buffer; for example the temporary SEC/PEI heap and stack, and (IIRC)
various special SEV-ES areas laid out via MEMFD. Where are all of those
handled / enumerated?

> The PEI detects
> all the available system RAM. After the memory detection is completed
> the PlatformPei calls the AmdSevSnpInitialize(). The initialization
> routine iterate through the HOB and calls the
> MemEncryptSevSnpValidateRam() to validate all the system RAM. Is it
> possible the more system ram can be detected after the PlatformPei is
> completed ?

That would cause problems even without SEV-SNP (i.e., with plain SEV),
so I'm not worried about it.

> 
> One of the important thing is we should *never* validate the pages
> twice.

What are the symptoms / consequences of:

- the guest accessing an unvalidated page (I understand it causes a #VC,
but what is the direct result of that, when this series is applied?),

- doubly-validating a page?

The first question is relevant because we should crash as soon as we
touch a page we forgot to validate (we shouldn't let any corruption or
similar spread out until we finally realize there's a problem).

The second question is relevant for security I guess. What attacks
become possible, and/or what symptoms are produced, if we
doubly-validate a page?

Furthermore, IIRC, we have separate #VC handlers for the different
firmware phases; do they behave consistently / identicall when a
#VC(page-not-validated) occurs, when this patch set is applied?

My first question is basically asking whether we can *exclusively* rely
on #VC(page-not-validated) faults to tell us that we missed validating a
particular page. If we can do that, then the job is a bit easier,
because from the GPA, we can more or less also derive *when and where*
we should pre-validate the page (at least until validation is done
completely lazily).

> The MemEncryptSevSnpValidateRam() uses a interval search tree to
> keep the record of what has been validated. Before validating the range,
> it lookup in its tree and if it finds

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

2021-04-09 Thread Laszlo Ersek

On 04/08/21 15:31, Tom Lendacky wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:
>> On Wednesday, April 7, 2021 11:03 PM, Laszlo wrote:
>>> On 04/07/21 02:44, James Bottomley wrote:
 On Wed, 2021-04-07 at 00:21 +, Xu, Min M wrote:
> Hi, Laszlo
>
> For Intel TDX supported guest, all processors start in 32-bit
> protected mode, while for Non-Td guest, it starts in 16-bit real
> mode. To make the ResetVector work on both Td-guest and Non-Td guest,
> ResetVector are updated as below:
> --
>   ALIGN   16
>   resetVector:
>   ;
>   ; Reset Vector
>   ;
>   ; This is where the processor will begin execution
>   ;
>   nop
>   nop
>   smswax
>   testal, 1
>   jnz EarlyBspPmEntry
>   jmp EarlyBspInitReal16

 Well, then use the rel8 jump like the compiler would in this situation:

   smswax
   testal, 1
   jz  1f
   jmp EarlyBspPmEntry
 1:
   jmp EarlyBspInitReal16

 So now both entries can be 32k away.
>>>
>>> The problem is that we need NASM to generate such *shared* entry code that
>>> behaves correctly when executed in either 16-bit or 32-bit mode.
>>>
>>> The rel8 near jumps ("short jumps") are like that -- for example, the
>>> "74 cb" opcode decodes to the same "JZ rel8" in both modes.
>>>
>>> But the rel16 ("non-short") near jumps turn into rel32 near jumps when
>>> decoded in 32-bit mode. For example, "E9 cw" decodes to "JMP rel16" in 
>>> 16-bit
>>> mode, but it gets parsed as "E9 cd" (= "JMP rel32") in 32-bit mode.
>>>
>>> So the idea is to add more BITS directives, for covering the non-short near
>>> jumps themselves:
>>
>> Yes this is the root cause. TDX requires the startup mode to be 32-bit
>> protected mode while the legacy VM startup mode is 16-bit real mode.
>> Add more BITS directives can work round this. I have tried it and it works.
>>
>> So my initial solution is to use *jmp rel8* because it works in both 16-bit
>> and 32-bit mode. But *jmp rel8* depends on the distance which should
>> be less than 128 bytes. If more metadata is added in the ResetVector.asm
>> then we have to use the BITS solution. 
> 
> To me, it sounds like the BITS solution should be the approach you use
> from the start.

I agree; we have an extensible approach in place already (with the
GUIDed struct list), and QEMU already knows about one magic GPA (for
locating the head of the list). Using one conditional rel8 jump, and two
non-conditional mode-specific (rel16/rel32) jumps, doesn't cost much in
the assembly code, it's compatible with future GUID additions, and
shouldn't affect QEMU's GUIDed struct list traversal.

Thanks
Laszlo



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

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

2021-04-09 Thread Laszlo Ersek

Hi Min,

On 04/08/21 15:31, Lendacky, Thomas wrote:
> On 4/8/21 1:24 AM, Xu, Min M wrote:

>> Yes this is the root cause. TDX requires the startup mode to be 32-bit
>> protected mode while the legacy VM startup mode is 16-bit real mode.
>> Add more BITS directives can work round this. I have tried it and it works.
>>
>> So my initial solution is to use *jmp rel8* because it works in both 16-bit
>> and 32-bit mode. But *jmp rel8* depends on the distance which should
>> be less than 128 bytes. If more metadata is added in the ResetVector.asm
>> then we have to use the BITS solution. 
> 
> To me, it sounds like the BITS solution should be the approach you use
> from the start.

BTW, have you considered using a separate ResetVector module for TDX?
That would obviate this multi-mode trickery. (Most recently raised by
Paolo.)

I think TDX will need a separate platform DSC / FDF / fw binary anyway.
I realize that's not a done deal yet; it may depend on who provides the
firmware binary (guest owner or cloud owner) -- of course the guest
owner will have to perform the attestation in either case, but the
"provenance" question remains open, IIUC.

And even if TDX gets its own firmware platform, it's a separate question
whether the ResetVector module itself should be split. I'm inclined to
think a separation at that level would make development and maintenance
easier.

(FWIW, Xen PVH has its own reset vector module, in OvmfPkg/XenResetVector.)

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73903): https://edk2.groups.io/g/devel/message/73903
Mute This Topic: https://groups.io/mt/81584577/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] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.

2021-04-09 Thread Laszlo Ersek

Hi Ray,

On 04/09/21 02:45, Ni, Ray wrote:
> Laszlo,
> OVMF isn't using this timerlib so I will assume you doesn't care about
> this change.

correct; that's why I gave my ACK for v1 in last September [1] [2] [3]
-- I didn't want to block progress on this patch.

To be frank, I don't understand why version 2 has now been posted (the
v1 review session didn't seem to ask for changes).

The v2 posting does not include any of the v1 review tags (your R-b, and
my A-b). Neither does v2 spell out the changes relative to v1, which
would justify the absence of the v1 feedback tags in the v2 posting.
It's hard for me to remain responsive when the due process is ignored.

(In case I missed the v2 changelog: I'm sorry.)

Thanks
Laszlo

[1] https://edk2.groups.io/g/devel/message/65608
[2] http://mid.mail-archive.com/9ae864d9-7eb7-2e60-f043-299a7f7b74a7@redhat.com
[3] 
https://listman.redhat.com/archives/edk2-devel-archive/2020-September/msg00736.html

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

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

2021-04-09 Thread Yao, Jiewen

Hi Laszlo
Thanks.

We did provide a separate binary in the beginning - see 
https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy to 
maintain and develop. A clean solution, definitely.

However, we got requirement to deliver one binary solution together with 1) 
normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
Now, we are struggling to merge them..

For DXE, we hope to isolate TDX driver whenever it is possible.
But we only have one reset vector here. Sigh...



> -Original Message-
> From: Laszlo Ersek 
> Sent: Friday, April 9, 2021 9:33 PM
> To: Xu, Min M 
> Cc: devel@edk2.groups.io; thomas.lenda...@amd.com; j...@linux.ibm.com;
> Brijesh Singh ; Yao, Jiewen ;
> Justen, Jordan L ; Ard Biesheuvel
> ; Paolo Bonzini 
> Subject: Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and
> Cpuid page for the SEV-SNP guest
> 
> Hi Min,
> 
> On 04/08/21 15:31, Lendacky, Thomas wrote:
> > On 4/8/21 1:24 AM, Xu, Min M wrote:
> 
> >> Yes this is the root cause. TDX requires the startup mode to be 32-bit
> >> protected mode while the legacy VM startup mode is 16-bit real mode.
> >> Add more BITS directives can work round this. I have tried it and it works.
> >>
> >> So my initial solution is to use *jmp rel8* because it works in both 16-bit
> >> and 32-bit mode. But *jmp rel8* depends on the distance which should
> >> be less than 128 bytes. If more metadata is added in the ResetVector.asm
> >> then we have to use the BITS solution.
> >
> > To me, it sounds like the BITS solution should be the approach you use
> > from the start.
> 
> BTW, have you considered using a separate ResetVector module for TDX?
> That would obviate this multi-mode trickery. (Most recently raised by
> Paolo.)
> 
> I think TDX will need a separate platform DSC / FDF / fw binary anyway.
> I realize that's not a done deal yet; it may depend on who provides the
> firmware binary (guest owner or cloud owner) -- of course the guest
> owner will have to perform the attestation in either case, but the
> "provenance" question remains open, IIUC.
> 
> And even if TDX gets its own firmware platform, it's a separate question
> whether the ResetVector module itself should be split. I'm inclined to
> think a separation at that level would make development and maintenance
> easier.
> 
> (FWIW, Xen PVH has its own reset vector module, in OvmfPkg/XenResetVector.)
> 
> Thanks
> Laszlo



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

[edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

2021-04-09 Thread Laszlo Ersek

On 04/09/21 15:44, Yao, Jiewen wrote:
> Hi Laszlo
> Thanks.
> 
> We did provide a separate binary in the beginning - see 
> https://github.com/tianocore/edk2-staging/tree/TDVF, with same goal - easy to 
> maintain and develop. A clean solution, definitely.
> 
> However, we got requirement to deliver one binary solution together with 1) 
> normal OVMF, 2) AMD-SEV, 3) Intel-TDX.
> Now, we are struggling to merge them..
> 
> For DXE, we hope to isolate TDX driver whenever it is possible.
> But we only have one reset vector here. Sigh...

Can we please pry a little bit at that "one binary" requirement?

Ultimately the "guest bundle" is going to be composed by much
higher-level code, I expect (such as some userspace code, written in
python or similar); selecting a firmware binary in such an environment
is surely easier than handling this "polymorphism" in the most
restrictive software environment imaginable (reset vector assembly code
in the guest)?

Thanks
Laszlo

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

[edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

2021-04-09 Thread Bret Barkelew

DumpVariablePolicy() will return EFI_INVALID_PARAMETER if the Buffer
pointer is NULL and the indirect Size is anything but 0. Since this
TempSize was not being initialized it is very likely that this sequence
would not return the total buffer size as expected.

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=3310

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c 
b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
index 14e1904e96d3..e50edb4ffc5a 100644
--- a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
+++ b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
@@ -216,6 +216,7 @@ VarCheckPolicyLibMmiHandler (
 DumpParamsOut->TotalSize = 0;
 DumpParamsOut->PageSize = 0;
 DumpParamsOut->HasMore = FALSE;
+TempSize = 0;
 SubCommandStatus = DumpVariablePolicy (NULL, &TempSize);
 if (SubCommandStatus == EFI_BUFFER_TOO_SMALL && TempSize > 0) {
   mCurrentPaginationCommand = VAR_CHECK_POLICY_COMMAND_DUMP;
-- 
2.28.0.windows.1



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

Re: [EXTERNAL] [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

2021-04-09 Thread Bret Barkelew via groups.io

+ @Liming Gao

- Bret

From: Bret Barkelew via groups.io
Sent: Friday, April 9, 2021 11:25 AM
To: devel@edk2.groups.io
Cc: Jian J Wang; Hao A 
Wu
Subject: [EXTERNAL] [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp 
variable in VarCheckPolicyLib

DumpVariablePolicy() will return EFI_INVALID_PARAMETER if the Buffer
pointer is NULL and the indirect Size is anything but 0. Since this
TempSize was not being initialized it is very likely that this sequence
would not return the total buffer size as expected.

Bugzilla: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3310&data=04%7C01%7CBret.Barkelew%40microsoft.com%7C3d2f574a01a048aed60708d8fb84dcbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637535895350828079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j6KmN6jcwoGJlunjspLawLJtYqCwGWw18pXNZVMNdC8%3D&reserved=0

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Bret Barkelew 
---
 MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c 
b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
index 14e1904e96d3..e50edb4ffc5a 100644
--- a/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
+++ b/MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLib.c
@@ -216,6 +216,7 @@ VarCheckPolicyLibMmiHandler (
 DumpParamsOut->TotalSize = 0;
 DumpParamsOut->PageSize = 0;
 DumpParamsOut->HasMore = FALSE;
+TempSize = 0;
 SubCommandStatus = DumpVariablePolicy (NULL, &TempSize);
 if (SubCommandStatus == EFI_BUFFER_TOO_SMALL && TempSize > 0) {
   mCurrentPaginationCommand = VAR_CHECK_POLICY_COMMAND_DUMP;
--
2.28.0.windows.1








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

[edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Pandya, Shivanshi

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io for help, attaching following 
call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2430, in Launch
INFO - self._MultiThreadBuildPlatform()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2238, in _MultiThreadBuildPlatform
INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2112, in PerformAutoGen
INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2009, in _GenFfsCmd
INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
ArchList, GlobalData)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
 line 541, in GenFfsMakefile
INFO - FdObj.GenFd(Flag=True)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
 line 131, in GenFd
INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
self.DefineVarDict, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
 line 134, in AddToBuffer
INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
ErasePolarity, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
 line 127, in AddToBuffer
INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
IsMakefile=Flag, FvName=self.UiFvName)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 518, in GenFfs
INFO - InputSectList, InputSectAlignments = 
self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
IsMakefile=IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 969, in __GenComplexFileSection__
INFO - SectList, Align = Sect.GenSection(self.OutputPath, self.ModuleGuid, 
SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
 line 218, in GenSection
INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
'EFI_SECTION_USER_INTERFACE',
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",
 line 466, in GenerateSection
INFO - SectionData.fromstring(Ui.encode("utf_16_le"))
INFO - AttributeError: 'array.array' object has no attribute 'fromstring'

Kind Regards,
Shivanshi


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

Re: [edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Andrew Fish via groups.io

1st thing to check is to see if your *.FDF files have a syntax error and the is 
just bad error processing. 

Thanks,

Andrew Fish

> On Apr 9, 2021, at 12:10 PM, Pandya, Shivanshi  
> wrote:
> 
> Hello,
>
> Build failed with following call trace
>
> build.py...
> INFO -  : error C0DE: Unknown fatal error when processing 
> [c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
>  [X64, VS2017, DEBUG]]
> INFO -
> INFO - (Please send email to devel@edk2.groups.io 
>  for help, attaching following call stack trace!)
> INFO -
> INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2635, in Main
> INFO - MyBuild.Launch()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2430, in Launch
> INFO - self._MultiThreadBuildPlatform()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2238, in _MultiThreadBuildPlatform
> INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2112, in PerformAutoGen
> INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2009, in _GenFfsCmd
> INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, 
> self, ArchList, GlobalData)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
>  line 541, in GenFfsMakefile
> INFO - FdObj.GenFd(Flag=True)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
>  line 131, in GenFd
> INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
> self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
> self.DefineVarDict, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
>  line 134, in AddToBuffer
> INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
> ErasePolarity, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
>  line 127, in AddToBuffer
> INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
> IsMakefile=Flag, FvName=self.UiFvName)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
>  line 518, in GenFfs
> INFO - InputSectList, InputSectAlignments = 
> self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
> IsMakefile=IsMakefile)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
>  line 969, in __GenComplexFileSection__
> INFO - SectList, Align = Sect.GenSection(self.OutputPath, 
> self.ModuleGuid, SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
>  line 218, in GenSection
> INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
> 'EFI_SECTION_USER_INTERFACE',
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",
>  line 466, in GenerateSection
> INFO - SectionData.fromstring(Ui.encode("utf_16_le"))
> INFO - AttributeError: 'array.array' object has no attribute 'fromstring'
>
> Kind Regards,
> Shivanshi
> 



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

Re: [edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Bret Barkelew via groups.io

It looks like a Python 3.8.x vs 3.9.x issue.

It looks as if you’re using Mu Q35 as your platform. Can you tell me what 
branch you’re on?

- Bret

From: Pandya, Shivanshi via 
groups.io
Sent: Friday, April 9, 2021 1:52 PM
To: devel@edk2.groups.io
Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io for help, attaching following 
call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2430, in Launch
INFO - self._MultiThreadBuildPlatform()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2238, in _MultiThreadBuildPlatform
INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2112, in PerformAutoGen
INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2009, in _GenFfsCmd
INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
ArchList, GlobalData)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
 line 541, in GenFfsMakefile
INFO - FdObj.GenFd(Flag=True)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
 line 131, in GenFd
INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
self.DefineVarDict, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
 line 134, in AddToBuffer
INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
ErasePolarity, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
 line 127, in AddToBuffer
INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
IsMakefile=Flag, FvName=self.UiFvName)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 518, in GenFfs
INFO - InputSectList, InputSectAlignments = 
self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
IsMakefile=IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 969, in __GenComplexFileSection__
INFO - SectList, Align = Sect.GenSection(self.OutputPath, self.ModuleGuid, 
SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
 line 218, in GenSection
INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
'EFI_SECTION_USER_INTERFACE',
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",
 line 466, in GenerateSection
INFO - SectionData.fromstring(Ui.encode("utf_16_le"))
INFO - AttributeError: 'array.array' object has no attribute 'fromstring'

Kind Regards,
Shivanshi




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

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve NULL ACPI table lib maintainability

2021-04-09 Thread Nate DeSimone

For the series...

Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Thursday, April 8, 2021 2:25 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Liming Gao ; Dong, 
Eric 
Subject: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve 
NULL ACPI table lib maintainability

From: Michael Kubacki 

This series makes some simple changes to the organization of 
BoardAcpiEnableLibNull and BoardAcpiTableLibNull to better align the library 
instances with patterns typically used so they are easier to integrate into 
platforms.

The following issues are resolved:
1. Sharing of a directory with another unrelated library instance.
2. The directory name "BoardAcpiLibNull" is not directly related to
   either library instance name in the directory.
3. The library instances have unnecessary dependencies.
4. The BASE_NAME does not indicate the library instance is the NULL
   instance.
5. The C source file names do not match the INF file name making
   finding the C source by search more cumbersome than needed.

V2 changes:
1. Remove Base.h from BoardAcpiEnableLibNull.c and
   BoardAcpiTableLibNull.c

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
  MinPlatformPkg/BoardAcpiEnableLibNull: Improve maintainability
  MinPlatformPkg/BoardAcpiTableLibNull: Improve maintainability

 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiEnableLib.c
 => BoardAcpiEnableLibNull/BoardAcpiEnableLibNull.c} |  3 ---
 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiTableLib.c
 => BoardAcpiTableLibNull/BoardAcpiTableLibNull.c}|  3 ---
 Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiEnableLibNull}/BoardAcpiEnableLibNull.inf| 12 

 Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiTableLibNull}/BoardAcpiTableLibNull.inf  | 12 

 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc   
   |  8 
 5 files changed, 12 insertions(+), 26 deletions(-)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiEnableLib.c
 => BoardAcpiEnableLibNull/BoardAcpiEnableLibNull.c} (73%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiTableLib.c
 => BoardAcpiTableLibNull/BoardAcpiTableLibNull.c} (73%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiEnableLibNull}/BoardAcpiEnableLibNull.inf (67%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiTableLibNull}/BoardAcpiTableLibNull.inf (67%)

--
2.28.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73880): https://edk2.groups.io/g/devel/message/73880
Mute This Topic: https://groups.io/mt/81953909/1767664
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub 
[nathaniel.l.desim...@intel.com]
-=-=-=-=-=-=




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

Re: [edk2-devel] [edk2-platforms] [PATCH v5 0/4] Add Large Variable Libraries

2021-04-09 Thread Nate DeSimone

The series has been pushed as 8c62040~..c1d10aa

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Nate DeSimone
Sent: Wednesday, April 7, 2021 12:17 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Liming Gao 
; Dong, Eric ; Michael Kubacki 
; Oram, Isaac W 
Subject: [edk2-devel] [edk2-platforms] [PATCH v5 0/4] Add Large Variable 
Libraries

Changes from V4:
 - Added LibraryClass interface definitions to
   MinPlatformPkg.dec

Changes from V3:
 - Added header guards
 - Documented the possibility of returning EFI_UNSUPPORTED
 - Added MM_CORE_STANDALONE to the StandaloneMm library
   implementations
 - Documented library constructor return status
 - Moved LargeVariableReadLib and LargeVariableWriteLib into
   a single BaseLargeVariableLib folder
 - Added LargeVariableCommon.h for shared macro definitions
 - Converted some debug macros from DEBUG_INFO to DEBUG_VERBOSE

Changes from V2:
 - Added comment to LargeVariableLib INF and header files
   describing the usage for drivers that cannot assume that
   PcdMaxVariableSize has been set to a certain minimum value.

Changes from V1:
 - Changed prefix from "Min" to "VarLib"
 - Better comments
 - Added more whitespace for readability
 - Removed unused INF sections
 - Better debug messages

This patch series introduces libaries that enable large data sets to be stored 
using the UEFI Variable Services. At present, most UEFI Variable Services 
implementations have a maximum variable size of <=64KB. The exact value varies 
depending on platform.

These libaries enable a data set to use as much space as needed, up to the 
remaining space in the UEFI Variable non-volatile storage.

To implement this, I have broken the problem down into two parts:

 1. Phase angostic UEFI Variable access.
 2. Storage of data across multiple UEFI Variables.

For the first part, I have created two new LibraryClasses:
VariableReadLib and VariableWriteLib. I have provided implementation instances 
of VariableReadLib for PEI, DXE, and SMM.
For VariableWriteLib, I have provided implementation instances for DXE and SMM. 
This enables code that accesses UEFI variables to be written in a matter than 
is phase agnostic, so the same code can be used in PEI, DXE, or SMM without 
modification.

The second part involves another two new LibaryClasses:
LargeVariableReadLib and LargeVariableWriteLib. Only one BASE implementation is 
needed for both of these as the phase dependent code was seperated out in the 
first piece. These libraries provide logic to calculate the maximum size of an 
individual UEFI variable and split the data into as many smaller pieces as 
needed to store the entire data set in the UEFI Variable storage. They also 
provide the ability to stitch the data back together when it is read.
Deleting the data will delete all variables used to store it.

Cc: Chasel Chiu 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Michael Kubacki 
Cc: Isaac Oram 
Signed-off-by: Nate DeSimone 

Nate DeSimone (4):
  MinPlatformPkg: Add VariableReadLib
  MinPlatformPkg: Add VariableWriteLib
  MinPlatformPkg: Add LargeVariableReadLib
  MinPlatformPkg: Add LargeVariableWriteLib

 .../Include/Dsc/CoreCommonLib.dsc |   6 +-
 .../MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc |  12 +-
 .../MinPlatformPkg/Include/Dsc/CorePeiLib.dsc |   9 +-
 .../Include/Library/LargeVariableReadLib.h|  61 +++
 .../Include/Library/LargeVariableWriteLib.h   |  69 +++
 .../Include/Library/VariableReadLib.h |  94 
 .../Include/Library/VariableWriteLib.h| 138 ++
 .../BaseLargeVariableReadLib.inf  |  51 ++
 .../BaseLargeVariableWriteLib.inf |  51 ++
 .../LargeVariableCommon.h |  47 ++
 .../LargeVariableReadLib.c| 176 +++
 .../LargeVariableWriteLib.c   | 450 ++
 .../DxeRuntimeVariableReadLib.c   | 117 +
 .../DxeRuntimeVariableReadLib.inf |  41 ++
 .../DxeRuntimeVariableWriteLib.c  | 265 +++
 .../DxeRuntimeVariableWriteLib.inf|  49 ++
 .../PeiVariableReadLib/PeiVariableReadLib.c   | 155 ++
 .../PeiVariableReadLib/PeiVariableReadLib.inf |  42 ++
 .../SmmVariableReadCommon.c   | 116 +
 .../StandaloneMmVariableReadLib.inf   |  50 ++
 .../StandaloneMmVariableReadLibConstructor.c  |  51 ++
 .../TraditionalMmVariableReadLib.inf  |  49 ++
 .../TraditionalMmVariableReadLibConstructor.c |  51 ++
 .../SmmVariableWriteCommon.c  | 171 +++
 .../StandaloneMmVariableWriteLib.inf  |  45 ++
 .../StandaloneMmVariableWriteLibConstructor.c |  51 ++
 .../TraditionalMmVariableWriteLib.inf |  44 ++
 ...TraditionalMmVariableWriteLibConstructor.c |  51 ++
 .../Intel/MinPlatformPkg/MinPlatformPkg.dec   |   5 +
 .../Intel/MinPlatformPkg/MinPlatformPkg.dsc   |   4 +-
 30 files changed, 2511 insertions(+), 10 deletions(-)  create mode 100644 
Platform/Intel/MinPlatformPkg/Includ

[edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS and MAKE_PATH fixes

2021-04-09 Thread Michael D Kinney

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

Update parsing of MAKE_FLAGS in DSC [BuildOptions] sections
to split the flags into a list to be compatible with
running the make command using Popen().  Parsing MAKE_FLAGS
from tools_def.txt already uses _SplitOption().  This change
uses the same _SplitOption() method for MAKE_FLAGS from a
DSC [BuildOptions] section.

Also update the parsing of MAKE_PATH to support MAKE_PATH
from tools_def.txt or the DSC [BuildOptions] section.  MAKE_PATH
in DSC [BuildOptions] section is higher priority than MAKE_PATH
in tools_def.txt.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Signed-off-by: Michael D Kinney 
---
 .../Source/Python/AutoGen/PlatformAutoGen.py  | 36 +++
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
index 7d8e7b3c7cc1..c16f2e4cd8b7 100644
--- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
@@ -1,7 +1,7 @@
 ## @file
 # Create makefile for MS nmake and GNU make
 #
-# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
 #  Copyright (c) 2020, ARM Limited. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -805,20 +805,26 @@ class PlatformAutoGen(AutoGen):
 #
 @cached_property
 def BuildCommand(self):
-RetVal = []
-if "MAKE" in self.ToolDefinition and "PATH" in 
self.ToolDefinition["MAKE"]:
-RetVal += _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
-if "FLAGS" in self.ToolDefinition["MAKE"]:
-NewOption = self.ToolDefinition["MAKE"]["FLAGS"].strip()
-if NewOption != '':
-RetVal += _SplitOption(NewOption)
-if "MAKE" in self.EdkIIBuildOption:
-if "FLAGS" in self.EdkIIBuildOption["MAKE"]:
-Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
-if Flags.startswith('='):
-RetVal = [RetVal[0]] + [Flags[1:]]
-else:
-RetVal.append(Flags)
+if "MAKE" in self.EdkIIBuildOption and "PATH" in 
self.EdkIIBuildOption["MAKE"]:
+# MAKE_PATH in DSC [BuildOptions] section is higher priority
+Path = self.EdkIIBuildOption["MAKE"]["PATH"]
+if Path.startswith('='):
+Path = Path[1:].strip()
+RetVal = _SplitOption(Path)
+elif "MAKE" in self.ToolDefinition and "PATH" in 
self.ToolDefinition["MAKE"]:
+RetVal = _SplitOption(self.ToolDefinition["MAKE"]["PATH"])
+else:
+return []
+if "MAKE" in self.ToolDefinition and "FLAGS" in 
self.ToolDefinition["MAKE"]:
+NewOption = self.ToolDefinition["MAKE"]["FLAGS"].strip()
+if NewOption != '':
+RetVal += _SplitOption(NewOption)
+if "MAKE" in self.EdkIIBuildOption and "FLAGS" in 
self.EdkIIBuildOption["MAKE"]:
+Flags = self.EdkIIBuildOption["MAKE"]["FLAGS"]
+if Flags.startswith('='):
+RetVal = [RetVal[0]] + _SplitOption(Flags[1:].strip())
+else:
+RetVal = RetVal + _SplitOption(Flags.strip())
 return RetVal
 
 ## Get tool chain definition
-- 
2.31.1.windows.1



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

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve NULL ACPI table lib maintainability

2021-04-09 Thread Nate DeSimone

The series has been pushed as 3204cbfe~..ade2b32

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Thursday, April 8, 2021 2:25 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Liming Gao ; Dong, 
Eric 
Subject: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve 
NULL ACPI table lib maintainability

From: Michael Kubacki 

This series makes some simple changes to the organization of 
BoardAcpiEnableLibNull and BoardAcpiTableLibNull to better align the library 
instances with patterns typically used so they are easier to integrate into 
platforms.

The following issues are resolved:
1. Sharing of a directory with another unrelated library instance.
2. The directory name "BoardAcpiLibNull" is not directly related to
   either library instance name in the directory.
3. The library instances have unnecessary dependencies.
4. The BASE_NAME does not indicate the library instance is the NULL
   instance.
5. The C source file names do not match the INF file name making
   finding the C source by search more cumbersome than needed.

V2 changes:
1. Remove Base.h from BoardAcpiEnableLibNull.c and
   BoardAcpiTableLibNull.c

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
  MinPlatformPkg/BoardAcpiEnableLibNull: Improve maintainability
  MinPlatformPkg/BoardAcpiTableLibNull: Improve maintainability

 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiEnableLib.c
 => BoardAcpiEnableLibNull/BoardAcpiEnableLibNull.c} |  3 ---
 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiTableLib.c
 => BoardAcpiTableLibNull/BoardAcpiTableLibNull.c}|  3 ---
 Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiEnableLibNull}/BoardAcpiEnableLibNull.inf| 12 

 Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiTableLibNull}/BoardAcpiTableLibNull.inf  | 12 

 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc   
   |  8 
 5 files changed, 12 insertions(+), 26 deletions(-)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiEnableLib.c
 => BoardAcpiEnableLibNull/BoardAcpiEnableLibNull.c} (73%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull/BoardAcpiTableLib.c
 => BoardAcpiTableLibNull/BoardAcpiTableLibNull.c} (73%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiEnableLibNull}/BoardAcpiEnableLibNull.inf (67%)  rename 
Platform/Intel/MinPlatformPkg/Acpi/Library/{BoardAcpiLibNull => 
BoardAcpiTableLibNull}/BoardAcpiTableLibNull.inf (67%)

--
2.28.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73880): https://edk2.groups.io/g/devel/message/73880
Mute This Topic: https://groups.io/mt/81953909/1767664
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub 
[nathaniel.l.desim...@intel.com]
-=-=-=-=-=-=




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

[edk2-devel] [Patch 1/1] BaseTools/Conf: Fix MAKE_FLAGS typos in tools_def.template

2021-04-09 Thread Michael D Kinney

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

Change MAKE_FLAG to MAKE_FLAGS to match required name from
EDK II Build Specifications for VS20xx tool chains.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Conf/tools_def.template | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 933b3160fd2b..c6c9edf5a0d7 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
 #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 #  Portions copyright (c) 2011 - 2019, ARM Ltd. All rights reserved.
 #  Copyright (c) 2015, Hewlett-Packard Development Company, L.P.
@@ -531,7 +531,7 @@ NOOPT_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2008x86_*_*_FAMILY= MSFT
 
 *_VS2008x86_*_MAKE_PATH   = DEF(VS2008x86_BIN)\nmake.exe
-*_VS2008x86_*_MAKE_FLAG   = /nologo
+*_VS2008x86_*_MAKE_FLAGS  = /nologo
 *_VS2008x86_*_RC_PATH = DEF(WINSDK_BIN)\rc.exe
 
 *_VS2008x86_*_MAKE_FLAGS  = /nologo
@@ -765,7 +765,7 @@ NOOPT_VS2010_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2010x86_*_*_FAMILY= MSFT
 
 *_VS2010x86_*_MAKE_PATH   = DEF(VS2010x86_BIN)\nmake.exe
-*_VS2010x86_*_MAKE_FLAG   = /nologo
+*_VS2010x86_*_MAKE_FLAGS  = /nologo
 *_VS2010x86_*_RC_PATH = DEF(WINSDK7x86_BIN)\rc.exe
 
 *_VS2010x86_*_MAKE_FLAGS  = /nologo
@@ -999,7 +999,7 @@ NOOPT_VS2012_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2012x86_*_*_FAMILY= MSFT
 
 *_VS2012x86_*_MAKE_PATH   = DEF(VS2012x86_BIN)\nmake.exe
-*_VS2012x86_*_MAKE_FLAG   = /nologo
+*_VS2012x86_*_MAKE_FLAGS  = /nologo
 *_VS2012x86_*_RC_PATH = DEF(WINSDK71x86_BIN)\rc.exe
 
 *_VS2012x86_*_MAKE_FLAGS  = /nologo
@@ -1233,7 +1233,7 @@ NOOPT_VS2013_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2013x86_*_*_FAMILY= MSFT
 
 *_VS2013x86_*_MAKE_PATH   = DEF(VS2013x86_BIN)\nmake.exe
-*_VS2013x86_*_MAKE_FLAG   = /nologo
+*_VS2013x86_*_MAKE_FLAGS  = /nologo
 *_VS2013x86_*_RC_PATH = DEF(WINSDK8x86_BIN)\rc.exe
 
 *_VS2013x86_*_MAKE_FLAGS  = /nologo
@@ -1468,7 +1468,7 @@ NOOPT_VS2015_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2015x86_*_*_FAMILY= MSFT
 
 *_VS2015x86_*_MAKE_PATH   = DEF(VS2015x86_BIN)\nmake.exe
-*_VS2015x86_*_MAKE_FLAG   = /nologo
+*_VS2015x86_*_MAKE_FLAGS  = /nologo
 *_VS2015x86_*_RC_PATH = DEF(WINSDK81x86_BIN)\rc.exe
 
 *_VS2015x86_*_MAKE_FLAGS  = /nologo
@@ -1586,7 +1586,7 @@ NOOPT_VS2015x86_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2017_*_*_DLL   = DEF(VS2017_BIN_HOST)
 
 *_VS2017_*_MAKE_PATH   = DEF(VS2017_BIN_HOST)\nmake.exe
-*_VS2017_*_MAKE_FLAG   = /nologo
+*_VS2017_*_MAKE_FLAGS  = /nologo
 *_VS2017_*_RC_PATH = DEF(RC_PATH)
 
 *_VS2017_*_MAKE_FLAGS  = /nologo
@@ -1749,7 +1749,7 @@ NOOPT_VS2017_AARCH64_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2019_*_*_DLL   = DEF(VS2019_BIN_HOST)
 
 *_VS2019_*_MAKE_PATH   = DEF(VS2019_BIN_HOST)\nmake.exe
-*_VS2019_*_MAKE_FLAG   = /nologo
+*_VS2019_*_MAKE_FLAGS  = /nologo
 *_VS2019_*_RC_PATH = DEF(RC_PATH)
 
 *_VS2019_*_MAKE_FLAGS  = /nologo
-- 
2.31.1.windows.1



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

Re: [edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Pandya, Shivanshi

Hi Bret,

That's correct. I cloned release/202008 branch.

Just trying to follow below instructions : 
https://github.com/microsoft/mu_tiano_platforms/blob/release/202008/Platforms/QemuQ35Pkg/Docs/Development/building.md

Regards,
Shivanshi

From: Bret Barkelew 
Sent: Friday, April 9, 2021 3:56 PM
To: devel@edk2.groups.io; Pandya, Shivanshi
Subject: RE: Build Failed for QEMU35Pkg


[EXTERNAL EMAIL]
It looks like a Python 3.8.x vs 3.9.x issue.

It looks as if you're using Mu Q35 as your platform. Can you tell me what 
branch you're on?

- Bret

From: Pandya, Shivanshi via 
groups.io
Sent: Friday, April 9, 2021 1:52 PM
To: devel@edk2.groups.io
Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io 
for help, attaching following call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2430, in Launch
INFO - self._MultiThreadBuildPlatform()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2238, in _MultiThreadBuildPlatform
INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2112, in PerformAutoGen
INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2009, in _GenFfsCmd
INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
ArchList, GlobalData)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
 line 541, in GenFfsMakefile
INFO - FdObj.GenFd(Flag=True)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
 line 131, in GenFd
INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
self.DefineVarDict, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
 line 134, in AddToBuffer
INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
ErasePolarity, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
 line 127, in AddToBuffer
INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
IsMakefile=Flag, FvName=self.UiFvName)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 518, in GenFfs
INFO - InputSectList, InputSectAlignments = 
self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
IsMakefile=IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 969, in __GenComplexFileSection__
INFO - SectList, Align = Sect.GenSection(self.OutputPath, self.ModuleGuid, 
SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
 line 218, in GenSection
INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
'EFI_SECTION_USER_INTERFACE',
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",
 line 466, in GenerateSection
INFO - SectionData.fromstring(Ui.encode("utf_16_le"))
INFO - AttributeError: 'array.array' object has no attribute 'fromstring'

Kind Regards,
Shivanshi




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

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

2021-04-09 Thread Brijesh Singh



On 4/9/21 7:24 AM, Laszlo Ersek wrote:
> On 04/08/21 13:59, Brijesh Singh wrote:
>> On 4/8/21 4:58 AM, Laszlo Ersek wrote:
>>> On 03/24/21 16:31, Brijesh Singh wrote:
 At this time we only support the pre-validation. OVMF detects all the 
 available
 system RAM in the PEI phase. When SEV-SNP is enabled, the memory is 
 validated
 before it is made available to the EDK2 core.
>>> Can you describe this in a bit more detail, before I look at the
>>> individual patches? Specifically, what existing logic in the PEI phase
>>> was taken, and extended, and how?
>> One of the key requirement is that the guest private pages much be
>> validated before the access. If guest tries to access the pages before
>> the validation then it will result in #VC (page-not-validated)
>> exception. To avoid the #VC, we propose the validating the memory before
>> the access. We will incrementally add the support to lazy validate (i.e
>> validate on access).
> What is the primary threat (in simple terms please) that validation is
> supposed to prevent?


To protect against the memory re-mapping attack the guest pages must be
validated. The idea is that every guest page can map only to a single
physical memory page at one time.


> And, against that particular threat, does pre-validation offer some
> protection, or will that only come with lazy validation?

For the hardware it does not matter how the memory was validated -- lazy
vs prevalidate. Both approaches use the PVALIDATE instruction to
validate the page.

In the case of pre-validation, the memory is validated before the
access. Whereas in the lazy validation, the access will cause a fault
and fault handler should validate the page and retry the access. Its
similar to a page fault handler, OS can populate the page table or back
the pages on demand.

The only downside of pre-validation is, we will take a hit on the boot
time. The GHCB spec provides method by which we can batch multiple
requests at once to minimize the context switches.


>
>> Let me try explaining a bit, the page validation process consist of two
>> steps:
>>
>> 1. Add the pages in the RMP table -- must be done by the hypervisor
>> using the RMPUPDATE instruction. The guest can use VMGEXIT NAEs to ask
>> hypervisor to add or remove pages from the RMP table.
>>
>> 2. Guest issue the PVALIDATE instruction -- this sets the validate bit
>> in the RMP table.
>>
>> Similar to SEV, the OVMF_CODE.fd is encrypted through the SNP firmware
>> before the launch. The SNP firmware also validates the memory page after
>> encrypting. This allows us to boot the initial entry code without guest
>> going through the validation process.
>>
>> The OVMF reset vector uses few data pages (e.g page table, early Sec
>> stack). Access to these data pages will result in #VC. There are two
>> approaches we can take to validate these data pages:
>>
>> 1. Ask SNP firmware to pre-validate it -- SNP firmware provides an
>> special command that can be used to pre-validate the pages without
>> affecting the measurement.
> This means the two pflash chips, right?


This does not need to be two pflash chips. The SNP firmware command does
not know anything about the ROM or pflash chip. The command accepts the
system physical address that need to be validated by the firmware. In
patch #2, OVMF provides a range of data pages that need to be validated
by the SNP firmware before booting the guest.

>
>> 2. Enhance the reset vector code to validate the pages.
>>
>> For now I choose #1.
>>
>> The pre-validation performed by the SNP firmware is sufficient to boot
>> through the SEC phase. The SEC phase later decompress the Fv to a new
>> memory location. Now we need the OVMF to take over the validation
>> procedure.  The series extends the MemEncryptSevLib to add a new helper
>> MemEncryptSevSnpValidateRam(). The helper is used to validate the system
>> RAM. See patch #12. SEC phase calls the MemEncryptSevSnpValidateRam() to
>> validate the output buffer used for the decompression. This was
>> sufficient to boot into the PEI phase, see patch #13.
> Two questions here:
>
> - Is ACPI S3 in scope for now?


Its not in the scope yet. I have not looked at it.


>
> - We need more areas made accessible in SEC than just the decompression
> buffer; for example the temporary SEC/PEI heap and stack, and (IIRC)
> various special SEV-ES areas laid out via MEMFD. Where are all of those
> handled / enumerated?


Sorry, I simplified my response by saying just decompression. You are
right that its more than the decompression buffer. In my current patch,
the SEC phase validates all the memory up to
PcdOvmfDecompressionScratchEnd (which includes more than just output
buffer). See patch #13.

>
>> The PEI detects
>> all the available system RAM. After the memory detection is completed
>> the PlatformPei calls the AmdSevSnpInitialize(). The initialization
>> routine iterate through the HOB and calls the
>> MemEncryptSevSnpValidateRam() to validate all the

Re: [edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Andrew Fish via groups.io



> On Apr 9, 2021, at 1:55 PM, Bret Barkelew via groups.io 
>  wrote:
> 
> It looks like a Python 3.8.x vs 3.9.x issue.
>

Do we have a scheme to require a min Python version?

Thanks,

Andrew Fish

> It looks as if you’re using Mu Q35 as your platform. Can you tell me what 
> branch you’re on?
>
> - Bret 
>
> From: Pandya, Shivanshi via groups.io 
> 
> Sent: Friday, April 9, 2021 1:52 PM
> To: devel@edk2.groups.io 
> Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg
>
> Hello,
>
> Build failed with following call trace
>
> build.py...
> INFO -  : error C0DE: Unknown fatal error when processing 
> [c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
>  [X64, VS2017, DEBUG]]
> INFO -
> INFO - (Please send email to devel@edk2.groups.io 
>  for help, attaching following call stack trace!)
> INFO -
> INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2635, in Main
> INFO - MyBuild.Launch()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2430, in Launch
> INFO - self._MultiThreadBuildPlatform()
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2238, in _MultiThreadBuildPlatform
> INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2112, in PerformAutoGen
> INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
>  line 2009, in _GenFfsCmd
> INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, 
> self, ArchList, GlobalData)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
>  line 541, in GenFfsMakefile
> INFO - FdObj.GenFd(Flag=True)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
>  line 131, in GenFd
> INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
> self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
> self.DefineVarDict, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
>  line 134, in AddToBuffer
> INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
> ErasePolarity, Flag=Flag)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
>  line 127, in AddToBuffer
> INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
> IsMakefile=Flag, FvName=self.UiFvName)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
>  line 518, in GenFfs
> INFO - InputSectList, InputSectAlignments = 
> self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
> IsMakefile=IsMakefile)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
>  line 969, in __GenComplexFileSection__
> INFO - SectList, Align = Sect.GenSection(self.OutputPath, 
> self.ModuleGuid, SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
>  line 218, in GenSection
> INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
> 'EFI_SECTION_USER_INTERFACE',
> INFO -   File 
> "C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",
>  line 466, in GenerateSection
> INFO - SectionData.fromstring(Ui.encode("utf_16_le"))
> INFO - AttributeError: 'array.array' object has no attribute 'fromstring'
>
> Kind Regards,
> Shivanshi
>
> 
> <79C90400E51C4EC6A197393CD98D0F7A.png>



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

Re: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg

2021-04-09 Thread Bret Barkelew via groups.io

Andrew,
Not a scheme that I would consider a “good” scheme. You can see what we’re 
running CI against (in Mu and EDK, both), by checking for the  
“UsePythonVersion” command in the .azurepipelines/pr-gate-steps.yml file.

Shivanshi,
I just ran a build on my system with that exact version of Python (3.9.0). Did 
your build produce a “BUILD_TOOLS_REPORT.json” file? If so, can you send it?
Can you also send the exact command that you’re running when you see this issue?

Thanks!

- Bret

From: Andrew Fish
Sent: Friday, April 9, 2021 4:54 PM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: shivanshi.pan...@dell.com
Subject: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg




On Apr 9, 2021, at 1:55 PM, Bret Barkelew via 
groups.io
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

It looks like a Python 3.8.x vs 3.9.x issue.


Do we have a scheme to require a min Python version?

Thanks,

Andrew Fish


It looks as if you’re using Mu Q35 as your platform. Can you tell me what 
branch you’re on?

- Bret

From: Pandya, Shivanshi via 
groups.io
Sent: Friday, April 9, 2021 1:52 PM
To: devel@edk2.groups.io
Subject: [EXTERNAL] [edk2-devel] Build Failed for QEMU35Pkg

Hello,

Build failed with following call trace

build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\bea\dfci\mu_tiano_platforms\Common\PRM\PrmPkg\Library\DxePrmModuleDiscoveryLib\DxePrmModuleDiscoveryLib.inf
 [X64, VS2017, DEBUG]]
INFO -
INFO - (Please send email to devel@edk2.groups.io 
for help, attaching following call stack trace!)
INFO -
INFO - (Python 3.9.0 on win32) Traceback (most recent call last):
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2635, in Main
INFO - MyBuild.Launch()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2430, in Launch
INFO - self._MultiThreadBuildPlatform()
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2238, in _MultiThreadBuildPlatform
INFO - Wa, self.BuildModules = self.PerformAutoGen(BuildTarget,ToolChain)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2112, in PerformAutoGen
INFO - CmdListDict = self._GenFfsCmd(Wa.ArchList)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\build\build.py",
 line 2009, in _GenFfsCmd
INFO - GenFfsDict = GenFds.GenFfsMakefile('', GlobalData.gFdfParser, self, 
ArchList, GlobalData)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFds.py",
 line 541, in GenFfsMakefile
INFO - FdObj.GenFd(Flag=True)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fd.py",
 line 131, in GenFd
INFO - RegionObj.AddToBuffer (FdBuffer, self.BaseAddress, 
self.BlockSizeList, self.ErasePolarity, GenFdsGlobalVariable.ImageBinDict, 
self.DefineVarDict, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Region.py",
 line 134, in AddToBuffer
INFO - FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum, 
ErasePolarity, Flag=Flag)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\Fv.py",
 line 127, in AddToBuffer
INFO - FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress, 
IsMakefile=Flag, FvName=self.UiFvName)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 518, in GenFfs
INFO - InputSectList, InputSectAlignments = 
self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr, 
IsMakefile=IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\FfsInfStatement.py",
 line 969, in __GenComplexFileSection__
INFO - SectList, Align = Sect.GenSection(self.OutputPath, self.ModuleGuid, 
SecIndex, self.KeyStringList, self, IsMakefile = IsMakefile)
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\EfiSection.py",
 line 218, in GenSection
INFO - GenFdsGlobalVariable.GenerateSection(OutputFile, [], 
'EFI_SECTION_USER_INTERFACE',
INFO -   File 
"C:\BEA\DFCI\mu_tiano_platforms\MU_BASECORE\BaseTools\Source\Python\GenFds\GenFdsGlobalVariable.py",

Re: [edk2-devel] Doubt in MinPlatform QemuOpenBoardPkg task

2021-04-09 Thread Nate DeSimone

Hi Kaaira,

Great questions! So I’ll start out describing what the FSP is and why we built 
it. The FSP (Firmware Support Package) is a mechanism Intel developed to 
distribute chipset initialization code that must be run during bootup in a 
binary format. Historically there were multiple different BIOS implementations 
from different IBVs (Independent BIOS Vendor, companies like AMI, Phoenix, 
Insyde, etc.) and they had some fundamental incompatibilities that made it 
impossible to run C code provided as a binary. For example, different methods 
for initialization of the stack. Due to this, historically we only provided 
chipset initialization in source code format under NDA. However, this strategy 
limited the companies that were capable of building BIOS implementations to 
those that could obtain NDAs, which eventually became too limiting.

So, we needed a binary executable format that would work with many different 
BIOS implementations while still allowing the chipset initialization code to be 
written in a higher level language than assembly. The first attempt at this was 
UEFI actually, which created a very generic binary format that would work not 
only for chipset initialization, but other multi-vendor compatibility concerns 
like expansion cards and operating systems. UEFI has become very successful in 
the general purpose computing (aka PC) industry, and it is widely used today to 
make PCIe add-in cards (graphics cards for example) work in PC systems from 
different vendors. It is also very successful at making PCs capable of booting 
an operating system from any software vendor.

But UEFI turned out to be overkill for embedded/Internet of Things designs. 
Most embedded designs generally only boot one OS (VxWorks, QNX, heavily 
customized Linux, etc.) and don’t support expansion cards. Moreover, they are 
usually designed by companies with small engineering departments that had 
difficulty working with UEFI due to its large and rich feature set. So we went 
back and built another mechanism for distributing chipset initialization code 
in a binary executable format, and kept it focused to just that use case this 
time. The result of that was FSP. Initially, FSP was only used by embedded 
customers, but its usage has grown over the years and now a lot of PCs use it 
for chipset initialization as well. The earlier versions of the FSP 
specifications (v1.0-v2.0) were designed primarily for use with non-UEFI 
firmware implementations. For example https://slimbootloader.github.io/, which 
is a sister project to TianoCore developed by Intel’s Internet of Things 
department. Due to the increasing interest in using the FSP on PCs, in the FSP 
v2.1 specification we made the FSP operate in two different “modes”: API Mode 
and Dispatch Mode. API mode is backwards compatible with the FSP v2.0 
specification and is intended for use on non-UEFI firmware implementations. 
Dispatch mode is conversely designed to for use with UEFI firmware 
implementations and works very differently.

So, the basic idea is that now that the FSP is widely used on PCs, it makes 
sense to include an FSP in the new QemuOpenBoardPkg so that it closely mirrors 
what a real UEFI firmware/BIOS implementation looks like. The Internet of 
Things department at Intel (the same guys who wrote Slim Bootloader) has 
created a dummy FSP for QEmu and posted it here: 
https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 Since it is just a 
dummy FSP, they released it open source instead of binary only like most FSPs. 
However, since Slim Bootloader does not support dispatch mode they only 
implemented API mode. Hence that QEmu FSP only goes up to the FSP v2.0 
specification. That is where “upgrade QEmu FSP to v2.2” come in. Basically the 
proposal is to implement dispatch mode in the QEmu FSP and then integrate it 
into QemuOpenBoardPkg, so that way we have an open source emulated example that 
is much closer to what the real UEFI implementation on modern PCs actually 
looks like.

Yes there are been several MinPlatform Architecture platform implementations 
available right now:

CometlakeOpenBoardPkg: 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/CometlakeOpenBoardPkg
KabylakeOpenBoardPkg: 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg
TigerlakeOpenBoardPkg: 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/TigerlakeOpenBoardPkg
WhiskeylakeOpenBoardPkg: 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/WhiskeylakeOpenBoardPkg

Out of all of them, I'd say that KabylakeOpenBoardPkg is the best example.

Hope that helps. Let me know if you have more questions!

Best Regards,
Nate

From: Kaaira Gupta  
Sent: Friday, April 9, 2021 3:14 PM
To: disc...@edk2.groups.io; Desimone, Nathaniel L 

Subject: Doubt in MinPlatform QemuOpenBoardPkg task

The second part of this task talks about fsp sdk and its use for testing FSP 
integratio

Re: [edk2-devel] MinPlatform Board port (GSoC 2021)

[edk2-devel] [PATCH] DynamicTablesPkg: add validation for PcdNonBsaCompliant16550SerialHid

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

Re: [edk2-devel] [PATCH v2] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.

Re: [edk2-devel] [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest

[edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]

[edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

Re: [EXTERNAL] [edk2-devel] [PATCH v1 1/1] MdeModulePkg: Initialize temp variable in VarCheckPolicyLib

[edk2-devel] Build Failed for QEMU35Pkg

Re: [edk2-devel] Build Failed for QEMU35Pkg

Re: [edk2-devel] Build Failed for QEMU35Pkg

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve NULL ACPI table lib maintainability

Re: [edk2-devel] [edk2-platforms] [PATCH v5 0/4] Add Large Variable Libraries

[edk2-devel] [Patch 1/1] BaseTools/PlatformAutoGen: MAKE_FLAGS and MAKE_PATH fixes

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/2] MinPlatformPkg: Improve NULL ACPI table lib maintainability

[edk2-devel] [Patch 1/1] BaseTools/Conf: Fix MAKE_FLAGS typos in tools_def.template

Re: [edk2-devel] Build Failed for QEMU35Pkg

Re: [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support

Re: [edk2-devel] Build Failed for QEMU35Pkg

Re: [EXTERNAL] Re: [edk2-devel] Build Failed for QEMU35Pkg

Re: [edk2-devel] Doubt in MinPlatform QemuOpenBoardPkg task

23 matches

Site Navigation

Mail list logo

Footer information