date:20210323

[edk2-devel] [PATCH V3 1/2] MdePkg/Include: EFI Redfish Discover protocol

2021-03-23 Thread Abner Chang

Move GUID definition of EFI Redfish Discover protocol
to under MdePkg. With this we don't have dependency of
RedfishPkg in ShellPkg.

Signed-off-by: Abner Chang 

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Nickle Wang 
Cc: Peter O'Hanley 
---
 MdePkg/MdePkg.dec |  5 +-
 RedfishPkg/RedfishPkg.dec |  3 -
 .../Include/Protocol/RedfishDiscover.h| 72 +--
 3 files changed, 37 insertions(+), 43 deletions(-)
 rename {RedfishPkg => MdePkg}/Include/Protocol/RedfishDiscover.h (79%)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 1d2637acc2..e667d44db5 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -6,7 +6,7 @@
 #
 # Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-# (C) Copyright 2016 - 2020 Hewlett Packard Enterprise Development LP
+# (C) Copyright 2016 - 2021 Hewlett Packard Enterprise Development LP
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -1863,6 +1863,9 @@
   ## Include/Protocol/RestJsonStructure.h
   gEfiRestJsonStructureProtocolGuid  = { 0xa9a048f6, 0x48a0, 0x4714, {0xb7, 
0xda, 0xa9, 0xad,0x87, 0xd4, 0xda, 0xc9 }}
 
+  ## Include/Protocol/RedfishDiscover.h
+  gEfiRedfishDiscoverProtocolGuid  = { 0x5db12509, 0x4550, 0x4347, { 0x96, 
0xb3, 0x73, 0xc0, 0xff, 0x6e, 0x86, 0x9f }}
+
   #
   # Protocols defined in Shell2.0
   #
diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index b3e25268a0..846c19fd5e 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -67,9 +67,6 @@
   RedfishLib|PrivateInclude/Library/RedfishLib.h
 
 [Protocols]
-  ## Include/Protocol/RedfishDiscover.h
-  gEfiRedfishDiscoverProtocolGuid  = { 0x5db12509, 0x4550, 0x4347, { 0x96, 
0xb3, 0x73, 0xc0, 0xff, 0x6e, 0x86, 0x9f }}
-
   ## Include/Protocol/EdkIIRedfishCredential.h
   gEdkIIRedfishCredentialProtocolGuid = { 0x8804377, 0xaf7a, 0x4496, { 0x8a, 
0x7b, 0x17, 0x59, 0x0, 0xe9, 0xab, 0x46 } }
 
diff --git a/RedfishPkg/Include/Protocol/RedfishDiscover.h 
b/MdePkg/Include/Protocol/RedfishDiscover.h
similarity index 79%
rename from RedfishPkg/Include/Protocol/RedfishDiscover.h
rename to MdePkg/Include/Protocol/RedfishDiscover.h
index 4c91605c4e..8dbb70b082 100644
--- a/RedfishPkg/Include/Protocol/RedfishDiscover.h
+++ b/MdePkg/Include/Protocol/RedfishDiscover.h
@@ -1,20 +1,19 @@
 /** @file
   This file defines the EFI Redfish Discover Protocol interface.
 
-  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
+  @par Revision Reference:
+  - Some corrections and revises are added to UEFI Specification 2.9.
+  - This Protocol is introduced in UEFI Specification 2.8.
+
 **/
 
 #ifndef EFI_REDFISH_DISCOVER_PROTOCOL_H_
 #define EFI_REDFISH_DISCOVER_PROTOCOL_H_
 
-#include 
-#include 
-#include 
-#include 
-
 //
 // GUID definitions
 //
@@ -40,24 +39,21 @@ typedef UINT32 EFI_REDFISH_DISCOVER_FLAG;
///< 3 to 15. The 
corresponding duration is 8 to 2^15 seconds.
///< Duration is only 
valid when EFI_REDFISH_DISCOVER_KEEP_ALIVE
///< is set to 1.
-#define EFI_REDFISH_DISCOVER_DURATION_BIT_POS 8
-
 typedef struct _EFI_REDFISH_DISCOVER_PROTOCOL EFI_REDFISH_DISCOVER_PROTOCOL;
-typedef struct _EFI_REDFISH_DISCOVERED_INFORMATION 
EFI_REDFISH_DISCOVERED_INFORMATION;
-
-typedef struct _EFI_REDFISH_DISCOVERED_INFORMATION {
-  EFI_HANDLE RedfishRestExHandle;   ///< REST EX EFI handle associated 
with this Redfish service.
-  BOOLEAN IsUdp6;   ///< Indicates it's IP versino 6.
-  EFI_IP_ADDRESS  RedfishHostIpAddress; ///< IP address of Redfish service.
-  UINTN RedfishVersion; ///< Redfish service version.
-  CHAR16 *Location; ///< Redfish service location.
-  CHAR16 *Uuid; ///< Redfish service UUID.
-  CHAR16 *Os;   ///< Redfish service OS.
-  CHAR16 *OSVersion;///< Redfish service OS version.
-  CHAR16 *Product;  ///< Redfish service product name.
-  CHAR16 *ProductVer;   ///< Redfish service product 
version.
-  BOOLEAN UseHttps; ///< Using HTTPS.
-};
+
+typedef struct {
+  EFI_HANDLERedfishRestExHandle;///< REST EX EFI handle associated 
with this Redfish service.
+  BOOLEAN   IsUdp6; ///< Indicates it's IP versino 6.
+  EFI_IP_ADDRESSRedfishHostIpAddress;   ///< IP address of Redfish service.
+  UINTN RedfishVersion; ///< Redfish service version.
+  CHAR16*Location;  ///< Redfish service location.
+  CHAR16

[edk2-devel] [PATCH V3 0/2] Support EFI Redfish protocols

2021-03-23 Thread Abner Chang

In v3: Correct the mismatched definitions in both
   RedfishDiscover.h and UEFI spec 2.8 (Refer to v2.9).
In v2: Address comments given by Liming on patch 1/2.

Add handle parsing for EFI Redfish Discover protocol and
EFI RestEx protocol.

This change also moves the GUID definition of EFI Redfish Discover
protocol to under MdePkg. With this we don't have dependency of
RedfishPkg in ShellPkg.

Signed-off-by: Abner Chang 

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Nickle Wang 
Cc: Peter O'Hanley 

Abner Chang (2):
  MdePkg/Include: EFI Redfish Discover protocol
  ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

 MdePkg/MdePkg.dec |  5 +-
 RedfishPkg/RedfishPkg.dec |  3 -
 .../UefiHandleParsingLib.inf  |  4 +-
 .../Include/Protocol/RedfishDiscover.h| 72 +--
 .../UefiHandleParsingLib.c|  8 ++-
 .../UefiHandleParsingLib.uni  |  4 +-
 6 files changed, 49 insertions(+), 47 deletions(-)
 rename {RedfishPkg => MdePkg}/Include/Protocol/RedfishDiscover.h (79%)

-- 
2.17.1



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

[edk2-devel] [PATCH V3 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-23 Thread Abner Chang

Add handle parsing for EFI Redfish Discover protocol.
Add handle parsing for EFI RestEx protocol.

Signed-off-by: Abner Chang 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Nickle Wang 
Cc: Peter O'Hanley 
Reviewed-by: Zhichao Gao 
---
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8 ++--
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
index 93b69cd8e9..446cd8d609 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
@@ -2,7 +2,7 @@
 #  Provides interface to advanced shell functionality for parsing both handle 
and protocol database.
 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved. 
 #  (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-#  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -269,6 +269,8 @@
   gEfiHttpProtocolGuid## UNDEFINED
   gEfiHttpUtilitiesProtocolGuid   ## UNDEFINED
   gEfiRestProtocolGuid## UNDEFINED
+  gEfiRestExProtocolGuid  ## UNDEFINED
+  gEfiRedfishDiscoverProtocolGuid ## UNDEFINED
   gEfiMmEndOfDxeProtocolGuid  ## UNDEFINED
   gEfiMmIoTrapDispatchProtocolGuid## UNDEFINED
   gEfiMmPowerButtonDispatchProtocolGuid   ## UNDEFINED
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index 500a95a89a..c00337d6b2 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -3,7 +3,7 @@
 
   Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -2355,7 +2355,11 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringList[] = {
   {STRING_TOKEN(STR_NET_HTTP),  &gEfiHttpProtocolGuid, 
   NULL},
   {STRING_TOKEN(STR_NET_HTTP_U),&gEfiHttpUtilitiesProtocolGuid,
   NULL},
   {STRING_TOKEN(STR_REST),  &gEfiRestProtocolGuid, 
   NULL},
-
+//
+// UEFI 2.8
+//
+  {STRING_TOKEN(STR_REST_EX),   &gEfiRestExProtocolGuid,   
   NULL},
+  {STRING_TOKEN(STR_REDFISH_DISCOVER),  &gEfiRedfishDiscoverProtocolGuid,  
   NULL},
 //
 // PI 1.5
 //
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
index 9c8028d0d5..69fcbdfe0e 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
@@ -2,7 +2,7 @@
 //
 // Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved. 
 // (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-// (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
+// (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
 // SPDX-License-Identifier: BSD-2-Clause-Patent
 //
 // Module Name:
@@ -308,6 +308,8 @@
 #string STR_NET_HTTP  #language en-US "Http"
 #string STR_NET_HTTP_U#language en-US "HttpUtilities"
 #string STR_REST  #language en-US "Rest"
+#string STR_REST_EX   #language en-US "RestEx"
+#string STR_REDFISH_DISCOVER  #language en-US "RedfishDiscover"
 
 #string STR_MM_EOD#language en-US "MmEndOfDxe"
 #string STR_MM_ITD#language en-US "MmIoTrapDispatch"
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73197): https://edk2.groups.io/g/devel/message/73197
Mute This Topic: https://groups.io/mt/81570740/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 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Ni, Ray

Andrew,
If the change is to use the gEfiAcpiTableGuid to identify another entry in the 
EFI configuration table, I agree it's a violation.

We position this as a pure implementation that reuses a spec defined GUID.
We didn't realize that it's a violation to the spec.

We could define a new GUID for the HOB data. But using the same GUID avoids 
introducing new GUID for the similar purpose.


Thanks,
Ray

From: Andrew Fish 
Sent: Wednesday, March 24, 2021 12:13 AM
To: edk2-devel-groups-io ; Dong, Guo 
Cc: ler...@redhat.com; Liu, Zhiguang ; Ni, Ray 
; Wang, Jian J ; Wu, Hao A 
; Bi, Dandan ; Liming Gao 

Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi 
table from Hob

My concern is gEfiAcpiTableGuid is owned by the UEFI Spec and any off label 
usage should probably be defined by the PI Spec.

Is this a code 1st proposal or just an implementation?

Thanks,

Andrew Fish


On Mar 23, 2021, at 8:45 AM, Guo Dong 
mailto:guo.d...@intel.com>> wrote:


Add my comments on the ideas behind.
UefiPayloadPkg is not a platform specific package, it tries to provide a 
generic payload using platform independent Modules. This allows to reuse the 
payload for different boot firmware solutions (Slim Bootloader, Coreboot, EDK2 
bootloader) on different platforms.

Just like other DXE modules (e.g. variable DXE driver,  firmware performance 
DXE driver), standardizing and modularizing platform independent modules 
through a HOB as the AcpiTableDxe patch did to support potential data from 
PEI/bootloader is a nature way for EDKII modules reuse. Understood the concerns 
to keep AcpiTableDxe as simple as possible. I think it deserve for code reuse 
by adding PEI/bootloader HOB support.

Thanks,
Guo


-Original Message-
From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Laszlo
Ersek
Sent: Tuesday, March 23, 2021 5:40 AM
To: Liu, Zhiguang mailto:zhiguang@intel.com>>; Ni, 
Ray mailto:ray...@intel.com>>; Dong,
Guo mailto:guo.d...@intel.com>>
Cc: devel@edk2.groups.io; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A
mailto:hao.a...@intel.com>>; Bi, Dandan 
mailto:dandan...@intel.com>>; Liming Gao
mailto:gaolim...@byosoft.com.cn>>
Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
table from Hob

On 03/23/21 04:24, Zhiguang Liu wrote:

If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table (starting with
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)

is contained by a single gEfiAcpiTableGuid HOB.
This way, for UefiPayloadPkg, there is no need to specially hanle acpi table.

Zhiguang Liu (2):
 MdeModulePkg/ACPI: Install ACPI table from HOB.
 UefiPayloadPkg: Remove code that installs APCI

MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134

++


UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   |  13 ++---
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h   |   5 +
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf |   5 ++---
5 files changed, 133 insertions(+), 27 deletions(-)

Where does this idea come from?

(1) There is no bugzilla for this, apparently (not linked in the commit
messages anyway).

(2) Also, I'm not sure if reusing an existing (and standardized) GUID
for this purpose is a good idea. I think an edk2-only
(MdeModulePkg-defined), brand new GUID, for the HOB, would be better.

(3) I'm also not convinced at all that this *whole approach* is sound.

The fact that UefiPayloadPkg has the ACPI content available to it in a
particular data representation (as a HOB, for example) is just a
platform trait. Why should that platform trait leak into the central
implementation of the ACPI table protocol?

UefiPayloadPkg can call the ACPI table protocol interfaces to install
its tables. OVMF does the same -- OVMF also does not construct its own
ACPI tables, but downloads them in a quirky representation from QEMU. We
didn't hack the central AcpiTableDxe driver for that use case; instead,
we dissected the blob (in OvmfPkg) into individual tables, and called
the proper ACPI table protocol method (InstallAcpiTable()) with the
individual tables.

I disagree with the code complexity / platform quirk in AcpiTableDxe. At
the bare minimum, this feature should be possible to compile out
altogether. I don't necessarily mean a FeaturePCD; there could be a new
INF file too, that shares most of the functionality with the current
core driver, but also includes (from a different source file) the new logic.

But I'd really like if this mess were kept out of MdeModulePkg
altogether. It's the job of the platform ACPI driver to use the ACPI
t

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Ni, Ray

> 
> (1) Currently, BlSupportDxe expects the ACPI content to come from
> "SYSTEM_TABLE_INFO.AcpiTableBase"
> [Include/Guid/SystemTableInfoGuid.h].
> That header file is at least *moderately* documented (it's better than
> nothing). Additionally, BlSupportDxe is a DXE-phase component.
> 
> The patch set removes the handling of
> "SYSTEM_TABLE_INFO.AcpiTableBase"
> from BlSupportDxe. That means that platforms currently relying on
> BlSupportDxe to expose the ACPI content will break (until they start
> producing the new HOB). I don't see the HOB (with this particular GUID)
> being produced in UefiPayloadPkg anywhere.

The concern is about PEI passing ACPI Table location through two kinds
of HOBs. It looks like a flaw in the design. I agree.

The HOB is produced by PEI phase, by some code that doesn't belong
to edk2 repo.

> 
> (2) The UefiPayloadEntry module ("This is the first module for UEFI
> payload") still relies on "SYSTEM_TABLE_INFO.AcpiTableBase", for parsing
> various pieces of information into the "AcpiBoardInfo" structure. So
> even if the HOB producer phase exposes the ACPI payload via a dedicated
> HOB, it will only create inconsistency between the information parsed by
> UefiPayloadEntry (from "SYSTEM_TABLE_INFO.AcpiTableBase") and the OS
> (which will the ACPI contents from the dedicated HOB).

I agree. At least the SYSTEM_TABLE_INFO.AcpiTableBase field should be removed
and the accordingly code that consumes ACPI Table in BlSupportDxe should
be updated to consume the new HOB.

> 
> (3) The new HOB's structure (regardless of GUID) is not declared in any
> MdeModulePkg header file, nor the "MdeModulePkg.dec" file. All the info
> we have is hidden in the source code:
> 
>   Rsdp = (EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER*)
> (UINTN)(*((UINT64*)GET_GUID_HOB_DATA (GuidHob)));
> 
> If a platform's PEI phase actually inteded to produce this new HOB, it
> couldn't rely on a header file / DEC file.
> 
> This is actually a *step back* from the SystemTableInfoGuid declaration
> -- header file and DEC file -- that we currently have in UefiPayloadPkg.

gEfiAcpiTableGuid is defined in MdePkg/Include/Guid/Acpi.h.
The file header says the GUID is used for entry in EFI system table.
Now we reuse this GUID for HOB data.
I think it's ok to use a spec defined GUID for another implementation purpose.

I can create a file MdeModulePkg/Include/Guid/Acpi.h to define the HOB 
structure.
Do you think it's ok?

> 
> 
> So how can this be called "standardizing and modularizing"?
> 
> You need a new GUID, a new GUID HOB structure (declared in
> MdeModulePkg
> DEC and GUID header); you need to spell out the priority order between
> the HOB and "SYSTEM_TABLE_INFO.AcpiTableBase" for UefiPayloadPkg, and
> you need to update all driver in UefiPayloadPkg accordingly.

Again. I agree it's a flaw in the design. We should remove AcpiTableBase field.

> 
> 
> I will also not make a secret of my annoyance that, the first time Intel
> needs such a core extension for some platform feature, it immediately
> gets all approvals. Whereas, when we needed the exact same feature in
> OVMF, we struggled for months, if not *years*, to reliably split the
> ACPI content that OVMF downloaded from QEMU, into blobs that were
> suitable for the standard ACPI table protocol interfaces. For years I've
> been telling my colleagues that all this complexity in OVMF's ACPI
> platform driver is necessary because the EFI_ACPI_TABLE_PROTOCOL
> implementation in edk2 cannot simply accept a "root pointer", to the
> ACPI table "forest" that's already laid out in memory. Now I find it
> just a little bit too convenient that the first time Intel needs the
> same, we immediately call it "standardizing and modularizing" -- without
> as much as a header file describing the actual contents of the new GUID HOB.

I am not aware of the similar OVMF requirement.

The requirement here is to support different bootloaders that may already
create the essential ACPI table and DXE phase (payload) may use AcpiTable
protocol to install/update tables.

> 
> (Meanwhile we argue for months about actual, proven spec breakage in
> edk2, such as signaling ready to boot around recovery options or
> whatever. Standardization matters as long as *you* need it, huh?)

The definition of spec breakage to me is we cannot do anything that's
conflict with the spec. But we can do things that spec doesn't define.
Please correct if I am wrong.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73195): https://edk2.groups.io/g/devel/message/73195
Mute This Topic: https://groups.io/mt/81543419/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 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

2021-03-23 Thread Bret Barkelew via groups.io

Is this a *good* idea?

What is considered valid extra data? If it’s immaterial to the FW displaying 
the image, our policy has been to strip it off BEFORE adding it to the FW image.

- Bret

From: Jeff Brasen via groups.io
Sent: Tuesday, March 23, 2021 10:29 AM
To: devel@edk2.groups.io
Cc: jian.j.w...@intel.com; 
ao.a...@intel.com; Jeff 
Brasen
Subject: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow 
BMP with extra data

Add support for processing BMP data that contains extra data after the
image array, this data will not be parsed in anyway in the library but
images that contain this will not be rejected from processing.

---
 MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c 
b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
index 3ac31f6723d0..944d01fe7cdf 100644
--- a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
+++ b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
@@ -213,7 +213,7 @@ TranslateBmpToGopBlt (

   if ((BmpHeader->Size != BmpImageSize) ||
   (BmpHeader->Size < BmpHeader->ImageOffset) ||
-  (BmpHeader->Size - BmpHeader->ImageOffset != DataSize)) {
+  (BmpHeader->Size - BmpHeader->ImageOffset < DataSize)) {

 DEBUG ((DEBUG_ERROR, "TranslateBmpToGopBlt: invalid BmpImage... \n"));
 DEBUG ((DEBUG_ERROR, "   BmpHeader->Size: 0x%x\n", BmpHeader->Size));
--
2.25.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73194): https://edk2.groups.io/g/devel/message/73194
Mute This Topic: https://groups.io/mt/81556871/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] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

2021-03-23 Thread Jeff Brasen

Add support for processing BMP data that contains extra data after the
image array, this data will not be parsed in anyway in the library but
images that contain this will not be rejected from processing.

---
 MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c 
b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
index 3ac31f6723d0..944d01fe7cdf 100644
--- a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
+++ b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
@@ -213,7 +213,7 @@ TranslateBmpToGopBlt (
 
   if ((BmpHeader->Size != BmpImageSize) ||
   (BmpHeader->Size < BmpHeader->ImageOffset) ||
-  (BmpHeader->Size - BmpHeader->ImageOffset != DataSize)) {
+  (BmpHeader->Size - BmpHeader->ImageOffset < DataSize)) {
 
 DEBUG ((DEBUG_ERROR, "TranslateBmpToGopBlt: invalid BmpImage... \n"));
 DEBUG ((DEBUG_ERROR, "   BmpHeader->Size: 0x%x\n", BmpHeader->Size));
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73193): https://edk2.groups.io/g/devel/message/73193
Mute This Topic: https://groups.io/mt/81556610/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 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Guo Dong


The universal payload 
specification 
proposes to re-use the existing GUID from UEFI for the HOB.
I don't know if we have to update the UEFI spec firstly in order to reuse the 
GUID.
Any idea?

Thanks,
Guo

From: Andrew Fish 
Sent: Tuesday, March 23, 2021 9:13 AM
To: edk2-devel-groups-io ; Dong, Guo 
Cc: ler...@redhat.com; Liu, Zhiguang ; Ni, Ray 
; Wang, Jian J ; Wu, Hao A 
; Bi, Dandan ; Liming Gao 

Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi 
table from Hob

My concern is gEfiAcpiTableGuid is owned by the UEFI Spec and any off label 
usage should probably be defined by the PI Spec.

Is this a code 1st proposal or just an implementation?

Thanks,

Andrew Fish


On Mar 23, 2021, at 8:45 AM, Guo Dong 
mailto:guo.d...@intel.com>> wrote:


Add my comments on the ideas behind.
UefiPayloadPkg is not a platform specific package, it tries to provide a 
generic payload using platform independent Modules. This allows to reuse the 
payload for different boot firmware solutions (Slim Bootloader, Coreboot, EDK2 
bootloader) on different platforms.

Just like other DXE modules (e.g. variable DXE driver,  firmware performance 
DXE driver), standardizing and modularizing platform independent modules 
through a HOB as the AcpiTableDxe patch did to support potential data from 
PEI/bootloader is a nature way for EDKII modules reuse. Understood the concerns 
to keep AcpiTableDxe as simple as possible. I think it deserve for code reuse 
by adding PEI/bootloader HOB support.

Thanks,
Guo


-Original Message-
From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Laszlo
Ersek
Sent: Tuesday, March 23, 2021 5:40 AM
To: Liu, Zhiguang mailto:zhiguang@intel.com>>; Ni, 
Ray mailto:ray...@intel.com>>; Dong,
Guo mailto:guo.d...@intel.com>>
Cc: devel@edk2.groups.io; Wang, Jian J 
mailto:jian.j.w...@intel.com>>; Wu, Hao A
mailto:hao.a...@intel.com>>; Bi, Dandan 
mailto:dandan...@intel.com>>; Liming Gao
mailto:gaolim...@byosoft.com.cn>>
Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
table from Hob

On 03/23/21 04:24, Zhiguang Liu wrote:

If HOB contains APCI table information, entry point of AcpiTableDxe.inf
should parse the APCI table from HOB, and install these tables.
We assume the whole ACPI table (starting with
EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)

is contained by a single gEfiAcpiTableGuid HOB.
This way, for UefiPayloadPkg, there is no need to specially hanle acpi table.

Zhiguang Liu (2):
 MdeModulePkg/ACPI: Install ACPI table from HOB.
 UefiPayloadPkg: Remove code that installs APCI

MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134

++


UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   |  13 ++---
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h   |   5 +
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf |   5 ++---
5 files changed, 133 insertions(+), 27 deletions(-)

Where does this idea come from?

(1) There is no bugzilla for this, apparently (not linked in the commit
messages anyway).

(2) Also, I'm not sure if reusing an existing (and standardized) GUID
for this purpose is a good idea. I think an edk2-only
(MdeModulePkg-defined), brand new GUID, for the HOB, would be better.

(3) I'm also not convinced at all that this *whole approach* is sound.

The fact that UefiPayloadPkg has the ACPI content available to it in a
particular data representation (as a HOB, for example) is just a
platform trait. Why should that platform trait leak into the central
implementation of the ACPI table protocol?

UefiPayloadPkg can call the ACPI table protocol interfaces to install
its tables. OVMF does the same -- OVMF also does not construct its own
ACPI tables, but downloads them in a quirky representation from QEMU. We
didn't hack the central AcpiTableDxe driver for that use case; instead,
we dissected the blob (in OvmfPkg) into individual tables, and called
the proper ACPI table protocol method (InstallAcpiTable()) with the
individual tables.

I disagree with the code complexity / platform quirk in AcpiTableDxe. At
the bare minimum, this feature should be possible to compile out
altogether. I don't necessarily mean a FeaturePCD; there could be a new
INF file too, that shares most of the functionality with the current
core driver, but also includes (from a different source file) the new logic.

But I'd really like if this mess were kept out of MdeModulePkg
altogether. It's the job of the platform ACPI driver to use the ACPI
table protocol.

Of course if you can show that this HOB usage is standard / publicly
specified, that's different.

Please do not merge th

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Guo Dong


Hi Laszlo,

I don't mean currently UEFI payload is already standardized and modularized.
There are still lots of things to do and I think the AcpiTableDxe patch is the 
one it needed.

More information on ideas behind could be found from 
https://universalpayload.github.io/documentation/spec/spec.html.
A universal payload interface is proposed between the bootloader and the 
payload to allow reuse for the same payload for different boot firmware 
solutions on different platforms. It describes the interface between the 
bootloader and the payload, including what parameters need pass to payload, how 
to pass parameters to payload, the parameters format, the payload image format, 
and the payload boot mode, etc.

I am not saying UefiPayloadPkg would fully follow this proposed interface for 
now. But we are trying to align with the proposed interface under EDKII 
framework.

Thanks,
Guo

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, March 23, 2021 9:48 AM
> To: devel@edk2.groups.io; Dong, Guo ; Liu, Zhiguang
> ; Ni, Ray 
> Cc: Wang, Jian J ; Wu, Hao A ;
> Bi, Dandan ; Liming Gao ;
> Andrew Fish 
> Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
> table from Hob
> 
> On 03/23/21 16:45, Guo Dong wrote:
> >
> > Add my comments on the ideas behind.
> > UefiPayloadPkg is not a platform specific package, it tries to provide a
> generic payload using platform independent Modules. This allows to reuse the
> payload for different boot firmware solutions (Slim Bootloader, Coreboot, EDK2
> bootloader) on different platforms.
> >
> > Just like other DXE modules (e.g. variable DXE driver,  firmware performance
> DXE driver), standardizing and modularizing platform independent modules
> through a HOB as the AcpiTableDxe patch did to support potential data from
> PEI/bootloader is a nature way for EDKII modules reuse. Understood the
> concerns to keep AcpiTableDxe as simple as possible. I think it deserve for 
> code
> reuse by adding PEI/bootloader HOB support.
> 
> I don't understand this argument.
> 
> (1) Currently, BlSupportDxe expects the ACPI content to come from
> "SYSTEM_TABLE_INFO.AcpiTableBase" [Include/Guid/SystemTableInfoGuid.h].
> That header file is at least *moderately* documented (it's better than
> nothing). Additionally, BlSupportDxe is a DXE-phase component.
> 
> The patch set removes the handling of "SYSTEM_TABLE_INFO.AcpiTableBase"
> from BlSupportDxe. That means that platforms currently relying on
> BlSupportDxe to expose the ACPI content will break (until they start
> producing the new HOB). I don't see the HOB (with this particular GUID)
> being produced in UefiPayloadPkg anywhere.
> 
> (2) The UefiPayloadEntry module ("This is the first module for UEFI
> payload") still relies on "SYSTEM_TABLE_INFO.AcpiTableBase", for parsing
> various pieces of information into the "AcpiBoardInfo" structure. So
> even if the HOB producer phase exposes the ACPI payload via a dedicated
> HOB, it will only create inconsistency between the information parsed by
> UefiPayloadEntry (from "SYSTEM_TABLE_INFO.AcpiTableBase") and the OS
> (which will the ACPI contents from the dedicated HOB).
> 
> (3) The new HOB's structure (regardless of GUID) is not declared in any
> MdeModulePkg header file, nor the "MdeModulePkg.dec" file. All the info
> we have is hidden in the source code:
> 
>   Rsdp = (EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER*)
> (UINTN)(*((UINT64*)GET_GUID_HOB_DATA (GuidHob)));
> 
> If a platform's PEI phase actually inteded to produce this new HOB, it
> couldn't rely on a header file / DEC file.
> 
> This is actually a *step back* from the SystemTableInfoGuid declaration
> -- header file and DEC file -- that we currently have in UefiPayloadPkg.
> 
> 
> So how can this be called "standardizing and modularizing"?
> 
> You need a new GUID, a new GUID HOB structure (declared in MdeModulePkg
> DEC and GUID header); you need to spell out the priority order between
> the HOB and "SYSTEM_TABLE_INFO.AcpiTableBase" for UefiPayloadPkg, and
> you need to update all driver in UefiPayloadPkg accordingly.
> 
> 
> I will also not make a secret of my annoyance that, the first time Intel
> needs such a core extension for some platform feature, it immediately
> gets all approvals. Whereas, when we needed the exact same feature in
> OVMF, we struggled for months, if not *years*, to reliably split the
> ACPI content that OVMF downloaded from QEMU, into blobs that were
> suitable for the standard ACPI table protocol interfaces. For years I've
> been telling my colleagues that all this complexity in OVMF's ACPI
> platform driver is necessary because the EFI_ACPI_TABLE_PROTOCOL
> implementation in edk2 cannot simply accept a "root pointer", to the
> ACPI table "forest" that's already laid out in memory. Now I find it
> just a little bit too convenient that the first time Intel needs the
> same, we immediately call it "standardizing and modularizing" -- without
> as much as a header

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Laszlo Ersek

On 03/23/21 16:45, Guo Dong wrote:
> 
> Add my comments on the ideas behind.
> UefiPayloadPkg is not a platform specific package, it tries to provide a 
> generic payload using platform independent Modules. This allows to reuse the 
> payload for different boot firmware solutions (Slim Bootloader, Coreboot, 
> EDK2 bootloader) on different platforms.
> 
> Just like other DXE modules (e.g. variable DXE driver,  firmware performance 
> DXE driver), standardizing and modularizing platform independent modules 
> through a HOB as the AcpiTableDxe patch did to support potential data from 
> PEI/bootloader is a nature way for EDKII modules reuse. Understood the 
> concerns to keep AcpiTableDxe as simple as possible. I think it deserve for 
> code reuse by adding PEI/bootloader HOB support.

I don't understand this argument.

(1) Currently, BlSupportDxe expects the ACPI content to come from
"SYSTEM_TABLE_INFO.AcpiTableBase" [Include/Guid/SystemTableInfoGuid.h].
That header file is at least *moderately* documented (it's better than
nothing). Additionally, BlSupportDxe is a DXE-phase component.

The patch set removes the handling of "SYSTEM_TABLE_INFO.AcpiTableBase"
from BlSupportDxe. That means that platforms currently relying on
BlSupportDxe to expose the ACPI content will break (until they start
producing the new HOB). I don't see the HOB (with this particular GUID)
being produced in UefiPayloadPkg anywhere.

(2) The UefiPayloadEntry module ("This is the first module for UEFI
payload") still relies on "SYSTEM_TABLE_INFO.AcpiTableBase", for parsing
various pieces of information into the "AcpiBoardInfo" structure. So
even if the HOB producer phase exposes the ACPI payload via a dedicated
HOB, it will only create inconsistency between the information parsed by
UefiPayloadEntry (from "SYSTEM_TABLE_INFO.AcpiTableBase") and the OS
(which will the ACPI contents from the dedicated HOB).

(3) The new HOB's structure (regardless of GUID) is not declared in any
MdeModulePkg header file, nor the "MdeModulePkg.dec" file. All the info
we have is hidden in the source code:

  Rsdp = (EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER*)
(UINTN)(*((UINT64*)GET_GUID_HOB_DATA (GuidHob)));

If a platform's PEI phase actually inteded to produce this new HOB, it
couldn't rely on a header file / DEC file.

This is actually a *step back* from the SystemTableInfoGuid declaration
-- header file and DEC file -- that we currently have in UefiPayloadPkg.

So how can this be called "standardizing and modularizing"?

You need a new GUID, a new GUID HOB structure (declared in MdeModulePkg
DEC and GUID header); you need to spell out the priority order between
the HOB and "SYSTEM_TABLE_INFO.AcpiTableBase" for UefiPayloadPkg, and
you need to update all driver in UefiPayloadPkg accordingly.

I will also not make a secret of my annoyance that, the first time Intel
needs such a core extension for some platform feature, it immediately
gets all approvals. Whereas, when we needed the exact same feature in
OVMF, we struggled for months, if not *years*, to reliably split the
ACPI content that OVMF downloaded from QEMU, into blobs that were
suitable for the standard ACPI table protocol interfaces. For years I've
been telling my colleagues that all this complexity in OVMF's ACPI
platform driver is necessary because the EFI_ACPI_TABLE_PROTOCOL
implementation in edk2 cannot simply accept a "root pointer", to the
ACPI table "forest" that's already laid out in memory. Now I find it
just a little bit too convenient that the first time Intel needs the
same, we immediately call it "standardizing and modularizing" -- without
as much as a header file describing the actual contents of the new GUID HOB.

(Meanwhile we argue for months about actual, proven spec breakage in
edk2, such as signaling ready to boot around recovery options or
whatever. Standardization matters as long as *you* need it, huh?)

Laszlo

> 
> Thanks,
> Guo
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, March 23, 2021 5:40 AM
>> To: Liu, Zhiguang ; Ni, Ray ; Dong,
>> Guo 
>> Cc: devel@edk2.groups.io; Wang, Jian J ; Wu, Hao A
>> ; Bi, Dandan ; Liming Gao
>> 
>> Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
>> table from Hob
>>
>> On 03/23/21 04:24, Zhiguang Liu wrote:
>>> If HOB contains APCI table information, entry point of AcpiTableDxe.inf
>>> should parse the APCI table from HOB, and install these tables.
>>> We assume the whole ACPI table (starting with
>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
>>> is contained by a single gEfiAcpiTableGuid HOB.
>>> This way, for UefiPayloadPkg, there is no need to specially hanle acpi 
>>> table.
>>>
>>> Zhiguang Liu (2):
>>>   MdeModulePkg/ACPI: Install ACPI table from HOB.
>>>   UefiPayloadPkg: Remove code that installs APCI
>>>
>>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
>>>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTablePr

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Andrew Fish via groups.io

My concern is gEfiAcpiTableGuid is owned by the UEFI Spec and any off label 
usage should probably be defined by the PI Spec. 

Is this a code 1st proposal or just an implementation? 

Thanks,

Andrew Fish

> On Mar 23, 2021, at 8:45 AM, Guo Dong  wrote:
> 
> 
> Add my comments on the ideas behind.
> UefiPayloadPkg is not a platform specific package, it tries to provide a 
> generic payload using platform independent Modules. This allows to reuse the 
> payload for different boot firmware solutions (Slim Bootloader, Coreboot, 
> EDK2 bootloader) on different platforms.
> 
> Just like other DXE modules (e.g. variable DXE driver,  firmware performance 
> DXE driver), standardizing and modularizing platform independent modules 
> through a HOB as the AcpiTableDxe patch did to support potential data from 
> PEI/bootloader is a nature way for EDKII modules reuse. Understood the 
> concerns to keep AcpiTableDxe as simple as possible. I think it deserve for 
> code reuse by adding PEI/bootloader HOB support.
> 
> Thanks,
> Guo
> 
>> -Original Message-
>> From: devel@edk2.groups.io  
>> mailto:devel@edk2.groups.io>> On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, March 23, 2021 5:40 AM
>> To: Liu, Zhiguang mailto:zhiguang@intel.com>>; 
>> Ni, Ray mailto:ray...@intel.com>>; Dong,
>> Guo mailto:guo.d...@intel.com>>
>> Cc: devel@edk2.groups.io ; Wang, Jian J 
>> mailto:jian.j.w...@intel.com>>; Wu, Hao A
>> mailto:hao.a...@intel.com>>; Bi, Dandan 
>> mailto:dandan...@intel.com>>; Liming Gao
>> mailto:gaolim...@byosoft.com.cn>>
>> Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
>> table from Hob
>> 
>> On 03/23/21 04:24, Zhiguang Liu wrote:
>>> If HOB contains APCI table information, entry point of AcpiTableDxe.inf
>>> should parse the APCI table from HOB, and install these tables.
>>> We assume the whole ACPI table (starting with
>> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
>>> is contained by a single gEfiAcpiTableGuid HOB.
>>> This way, for UefiPayloadPkg, there is no need to specially hanle acpi 
>>> table.
>>> 
>>> Zhiguang Liu (2):
>>>  MdeModulePkg/ACPI: Install ACPI table from HOB.
>>>  UefiPayloadPkg: Remove code that installs APCI
>>> 
>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134
>> 
>> ++
>> 
>>> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   |  13 
>>> ++---
>>> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h   |   5 +
>>> UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf |   5 ++---
>>> 5 files changed, 133 insertions(+), 27 deletions(-)
>>> 
>> 
>> Where does this idea come from?
>> 
>> (1) There is no bugzilla for this, apparently (not linked in the commit
>> messages anyway).
>> 
>> (2) Also, I'm not sure if reusing an existing (and standardized) GUID
>> for this purpose is a good idea. I think an edk2-only
>> (MdeModulePkg-defined), brand new GUID, for the HOB, would be better.
>> 
>> (3) I'm also not convinced at all that this *whole approach* is sound.
>> 
>> The fact that UefiPayloadPkg has the ACPI content available to it in a
>> particular data representation (as a HOB, for example) is just a
>> platform trait. Why should that platform trait leak into the central
>> implementation of the ACPI table protocol?
>> 
>> UefiPayloadPkg can call the ACPI table protocol interfaces to install
>> its tables. OVMF does the same -- OVMF also does not construct its own
>> ACPI tables, but downloads them in a quirky representation from QEMU. We
>> didn't hack the central AcpiTableDxe driver for that use case; instead,
>> we dissected the blob (in OvmfPkg) into individual tables, and called
>> the proper ACPI table protocol method (InstallAcpiTable()) with the
>> individual tables.
>> 
>> I disagree with the code complexity / platform quirk in AcpiTableDxe. At
>> the bare minimum, this feature should be possible to compile out
>> altogether. I don't necessarily mean a FeaturePCD; there could be a new
>> INF file too, that shares most of the functionality with the current
>> core driver, but also includes (from a different source file) the new logic.
>> 
>> But I'd really like if this mess were kept out of MdeModulePkg
>> altogether. It's the job of the platform ACPI driver to use the ACPI
>> table protocol.
>> 
>> Of course if you can show that this HOB usage is standard / publicly
>> specified, that's different.
>> 
>> Please do not merge this series.
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73189): https://edk2.groups.io/g/devel/message/73189
Mute This Topic: https://groups.io/mt/81543419/21656
Group Owner: devel+ow...@ed

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Guo Dong


Add my comments on the ideas behind.
UefiPayloadPkg is not a platform specific package, it tries to provide a 
generic payload using platform independent Modules. This allows to reuse the 
payload for different boot firmware solutions (Slim Bootloader, Coreboot, EDK2 
bootloader) on different platforms.

Just like other DXE modules (e.g. variable DXE driver,  firmware performance 
DXE driver), standardizing and modularizing platform independent modules 
through a HOB as the AcpiTableDxe patch did to support potential data from 
PEI/bootloader is a nature way for EDKII modules reuse. Understood the concerns 
to keep AcpiTableDxe as simple as possible. I think it deserve for code reuse 
by adding PEI/bootloader HOB support.

Thanks,
Guo

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, March 23, 2021 5:40 AM
> To: Liu, Zhiguang ; Ni, Ray ; Dong,
> Guo 
> Cc: devel@edk2.groups.io; Wang, Jian J ; Wu, Hao A
> ; Bi, Dandan ; Liming Gao
> 
> Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi
> table from Hob
> 
> On 03/23/21 04:24, Zhiguang Liu wrote:
> > If HOB contains APCI table information, entry point of AcpiTableDxe.inf
> > should parse the APCI table from HOB, and install these tables.
> > We assume the whole ACPI table (starting with
> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
> > is contained by a single gEfiAcpiTableGuid HOB.
> > This way, for UefiPayloadPkg, there is no need to specially hanle acpi 
> > table.
> >
> > Zhiguang Liu (2):
> >   MdeModulePkg/ACPI: Install ACPI table from HOB.
> >   UefiPayloadPkg: Remove code that installs APCI
> >
> >  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
> >  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134
> 
> ++
> 
> >  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   |  13 
> > ++---
> >  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h   |   5 +
> >  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf |   5 ++---
> >  5 files changed, 133 insertions(+), 27 deletions(-)
> >
> 
> Where does this idea come from?
> 
> (1) There is no bugzilla for this, apparently (not linked in the commit
> messages anyway).
> 
> (2) Also, I'm not sure if reusing an existing (and standardized) GUID
> for this purpose is a good idea. I think an edk2-only
> (MdeModulePkg-defined), brand new GUID, for the HOB, would be better.
> 
> (3) I'm also not convinced at all that this *whole approach* is sound.
> 
> The fact that UefiPayloadPkg has the ACPI content available to it in a
> particular data representation (as a HOB, for example) is just a
> platform trait. Why should that platform trait leak into the central
> implementation of the ACPI table protocol?
> 
> UefiPayloadPkg can call the ACPI table protocol interfaces to install
> its tables. OVMF does the same -- OVMF also does not construct its own
> ACPI tables, but downloads them in a quirky representation from QEMU. We
> didn't hack the central AcpiTableDxe driver for that use case; instead,
> we dissected the blob (in OvmfPkg) into individual tables, and called
> the proper ACPI table protocol method (InstallAcpiTable()) with the
> individual tables.
> 
> I disagree with the code complexity / platform quirk in AcpiTableDxe. At
> the bare minimum, this feature should be possible to compile out
> altogether. I don't necessarily mean a FeaturePCD; there could be a new
> INF file too, that shares most of the functionality with the current
> core driver, but also includes (from a different source file) the new logic.
> 
> But I'd really like if this mess were kept out of MdeModulePkg
> altogether. It's the job of the platform ACPI driver to use the ACPI
> table protocol.
> 
> Of course if you can show that this HOB usage is standard / publicly
> specified, that's different.
> 
> Please do not merge this series.
> 
> Laszlo
> 
> 
> 
> 
> 



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

Re: [edk2-devel] GSoC 2021 (MinPlatform, Ext2, ACPICA, etc)

2021-03-23 Thread Pedro Falcato

Hi Nate!

Sorry for taking so long to get back to you, I've been a bit busy and I'm not 
too used to so many emails in my inbox :)

So, if I'm getting this right, essentially what is proposed in the MinPlatform 
board ports is to refactor the existing board code into an OpenBoardPkg that 
uses MinPlatform to reuse more generic code? I was thinking about getting a 
Raspberry Pi and doing the MinPlatform port for that, although honestly I'm not 
too inclined for that option anymore.

Honestly, I'm looking more towards the ext2/4 drivers now. I've been poking a 
little at the build system and how the driver model is supposed to work and I 
think I more or less got the idea. Here's the link to my ext2 test repo, if 
you're curious: https://github.com/heatd/edk2-ext. Note that it doesn't quite 
do anything right now, it's missing all sorts of features and testing and 
what's there is mostly driver model and build system boilerplate that was 
pieced together by looking at the UEFI spec and the FatPkg code, plus some of 
my own ext2 headers.

With regards to ext4, yes, it sounds like the better option at the moment, 
although I'm not terribly familiar with it. I do have some questions though:

* What are the standards for filesystem driver performance? Is a page/disk 
cache a necessity for the driver? I would assume the FS driver has some 
substancial footprint in the overall boot time.
* Is the read-only behaviour still the target?
Thanks,
Pedro Falcato


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

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

2021-03-23 Thread Dong, Eric

Reviewed-by: Eric Dong 

-Original Message-
From: Ni, Ray  
Sent: Tuesday, March 23, 2021 9:15 AM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Laszlo Ersek ; Kumar, 
Rahul1 
Subject: [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

The comments in PiSmmCommunicationPei.c describe the whole memory
layout of the SMRAM regarding the SMM communication.

But SHA-1: 8b1d14939053b63d80355465649c50f9f391a64a
PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table
removed the code that produces the ACPI Table.

This change updates the accordingly comments.

Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
---
 .../PiSmmCommunication/PiSmmCommunicationPei.c   | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c 
b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
index 68e5003ad4..110165b20b 100644
--- a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
+++ b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
@@ -1,7 +1,7 @@
 /** @file

 PiSmmCommunication PEI Driver.

 

-Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.

+Copyright (c) 2010 - 2021, Intel Corporation. All rights reserved.

 SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -47,16 +47,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
   +--+<--

   | EFI_SMM_COMMUNICATION_CONTEXT|

   |   SwSmiNumber| <- SMRAM

-  |   BufferPtrAddress   |

-  +--+|

-  |

-  +--+|

-  | EFI_SMM_COMMUNICATION_ACPI_TABLE ||

-  |   SwSmiNumber| <- AcpiTable   |

-  |   BufferPtrAddress   |--- |

-  +--+   ||

- ||

-  +--+<---

+  |   BufferPtrAddress   |---

+  +--+   |

+ |

+  +--+<--

   | Communication Buffer Pointer | <- AcpiNvs

   +--+---

  |

-- 
2.27.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73186): https://edk2.groups.io/g/devel/message/73186
Mute This Topic: https://groups.io/mt/81541408/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 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-23 Thread Laszlo Ersek

On 03/23/21 04:24, Zhiguang Liu wrote:
> If HOB contains APCI table information, entry point of AcpiTableDxe.inf
> should parse the APCI table from HOB, and install these tables.
> We assume the whole ACPI table (starting with 
> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER)
> is contained by a single gEfiAcpiTableGuid HOB.
> This way, for UefiPayloadPkg, there is no need to specially hanle acpi table.
> 
> Zhiguang Liu (2):
>   MdeModulePkg/ACPI: Install ACPI table from HOB.
>   UefiPayloadPkg: Remove code that installs APCI
> 
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|   3 ++-
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 134 
> ++
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c   |  13 
> ++---
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.h   |   5 +
>  UefiPayloadPkg/BlSupportDxe/BlSupportDxe.inf |   5 ++---
>  5 files changed, 133 insertions(+), 27 deletions(-)
> 

Where does this idea come from?

(1) There is no bugzilla for this, apparently (not linked in the commit
messages anyway).

(2) Also, I'm not sure if reusing an existing (and standardized) GUID
for this purpose is a good idea. I think an edk2-only
(MdeModulePkg-defined), brand new GUID, for the HOB, would be better.

(3) I'm also not convinced at all that this *whole approach* is sound.

The fact that UefiPayloadPkg has the ACPI content available to it in a
particular data representation (as a HOB, for example) is just a
platform trait. Why should that platform trait leak into the central
implementation of the ACPI table protocol?

UefiPayloadPkg can call the ACPI table protocol interfaces to install
its tables. OVMF does the same -- OVMF also does not construct its own
ACPI tables, but downloads them in a quirky representation from QEMU. We
didn't hack the central AcpiTableDxe driver for that use case; instead,
we dissected the blob (in OvmfPkg) into individual tables, and called
the proper ACPI table protocol method (InstallAcpiTable()) with the
individual tables.

I disagree with the code complexity / platform quirk in AcpiTableDxe. At
the bare minimum, this feature should be possible to compile out
altogether. I don't necessarily mean a FeaturePCD; there could be a new
INF file too, that shares most of the functionality with the current
core driver, but also includes (from a different source file) the new logic.

But I'd really like if this mess were kept out of MdeModulePkg
altogether. It's the job of the platform ACPI driver to use the ACPI
table protocol.

Of course if you can show that this HOB usage is standard / publicly
specified, that's different.

Please do not merge this series.

Laszlo

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

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

2021-03-23 Thread Laszlo Ersek

On 03/23/21 02:15, Ray Ni wrote:
> The comments in PiSmmCommunicationPei.c describe the whole memory
> layout of the SMRAM regarding the SMM communication.
> 
> But SHA-1: 8b1d14939053b63d80355465649c50f9f391a64a
> PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table
> removed the code that produces the ACPI Table.
> 
> This change updates the accordingly comments.
> 
> Signed-off-by: Ray Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> ---
>  .../PiSmmCommunication/PiSmmCommunicationPei.c   | 16 +---
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c 
> b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
> index 68e5003ad4..110165b20b 100644
> --- a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
> +++ b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
> @@ -1,7 +1,7 @@
>  /** @file
>  PiSmmCommunication PEI Driver.
>  
> -Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2010 - 2021, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -47,16 +47,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>+--+<--
>| EFI_SMM_COMMUNICATION_CONTEXT|
>|   SwSmiNumber| <- SMRAM
> -  |   BufferPtrAddress   |
> -  +--+|
> -  |
> -  +--+|
> -  | EFI_SMM_COMMUNICATION_ACPI_TABLE ||
> -  |   SwSmiNumber| <- AcpiTable   |
> -  |   BufferPtrAddress   |--- |
> -  +--+   ||
> - ||
> -  +--+<---
> +  |   BufferPtrAddress   |---
> +  +--+   |
> + |
> +  +--+<--
>| Communication Buffer Pointer | <- AcpiNvs
>+--+---
>   |
> 

Acked-by: Laszlo Ersek 



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

回复: [edk2-devel] [patch V2 00/29] Add a new library class RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access

2021-03-23 Thread gaoliming

Dandan:
  This change is good to me. Reviewed-by: Liming Gao 
for the patch set. 

Thanks
Liming
> -邮件原件-
> 发件人: Bi, Dandan 
> 发送时间: 2021年3月23日 10:06
> 收件人: devel@edk2.groups.io; Bi, Dandan 
> 抄送: Andrew Fish ; Leif Lindholm ;
> Laszlo Ersek ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang 
> 主题: RE: [edk2-devel] [patch V2 00/29] Add a new library class
> RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access
> 
> Hi All,
> 
> Here is the branch for these changes in Edk2.
> https://github.com/dandanbi/edk2/tree/RegisterFilterLibV2
> https://github.com/tianocore/edk2/pull/1509
> 
> Hi Mike, Liming and Zhiguang,
> 
> Could you help review the first and last 2 patches in MdePkg?
> Since we should submit the first 2 patches firstly before the changes of
dsc
> files .
> 
> 
> Thanks,
> Dandan
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Dandan
> > Bi
> > Sent: Monday, March 22, 2021 4:09 PM
> > To: devel@edk2.groups.io
> > Cc: Andrew Fish ; Leif Lindholm ;
> > Laszlo Ersek ; Kinney, Michael D
> > ; Liming Gao ;
> > Liu, Zhiguang 
> > Subject: [edk2-devel] [patch V2 00/29] Add a new library class
> > RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> > RFC: https://edk2.groups.io/g/devel/message/72530
> >
> > Patch 1 is to add RegisterFilterLib Library Class in edk2 to
filter/trace port
> > IO/MMIO/MSR access and add a RegisterFilterLibNull instance.
> > Patch 2 is to add the MdeLibs.dsc.inc file to MdePkg for some default
> libraries
> > provided by MdePkg and add RegisterFilterLib into it as the first
version of
> > MdeLibs.dsc.inc.
> > Last 2 patches are to update APIs in IoLib and BaseLib to filter/trace
port
> > IO/MMIO/MSR access.
> > Remaining patches are to update related dsc files to consume
> > MdeLibs.dsc.inc for RegisterFilterLib.
> >
> > Will submit patch 1 and 2 firstly.
> > And then update related dsc files in edk2 and edk2platform repo to
consume
> > MdeLibs.dsc.inc for RegisterFilterLib.
> > At last will submit the patches to update IoLib and BaseLib to
filter/trace
> port
> > IO/MMIO/MSR access.
> >
> > --
> > V2:
> > Introduce MdeLibs.dsc.inc and add RegisterFilterLib into it as the first
> version
> > of MdeLibs.dsc.inc.
> > Update Platform dsc to consume the MdeLibs.dsc.inc.
> > Add the description for the return flag in FilterBefore functions in
> > header file source code.
> > Extend the years for Intel copyright.
> > Add mssing change the dsc files in OvmfPkg.
> >
> > Cc: Andrew Fish 
> > Cc: Leif Lindholm 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> >
> > Dandan Bi (29):
> >   MdePkg: Add RegisterFilterLib class and NULL instance
> >   MdePkg: Add MdeLibs.dsc.inc file to MdePkg
> >   ArmPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   ArmPlatformPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   ArmVirtPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   CryptoPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   DynamicTablesPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   EmbeddedPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   EmulatorPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   FatPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   FmpDevicePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   IntelFsp2Pkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   IntelFsp2WrapperPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   MdeModulePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   MdePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   NetworkPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   PcAtChipsetPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   RedfishPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   SecurityPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   ShellPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   SignedCapsulePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   SourceLevelDebugPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   StandaloneMmPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   UefiCpuPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   UefiPayloadPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   UnitTestFrameworkPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >   MdePkg/IoLib: Filter/trace port IO/MMIO access
> >   MdePkg/Baseib: Filter/trace MSR access for IA32/X64
> >
> >  ArmPkg/ArmPkg.dsc |   2 +
> >  ArmPlatformPkg/ArmPlatformPkg.dsc |   2 +
> >  ArmVirtPkg/ArmVirt.dsc.inc|   4 +-
> >  CryptoPkg/CryptoPkg.dsc   |   4 +-
> >  DynamicTablesPkg/DynamicTablesPkg.dsc |   2 +
> >  EmbeddedPkg/EmbeddedPkg.dsc   |   4 +-
> >  EmulatorPkg/EmulatorPkg.dsc

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, 23 March 2021 #cal-cancelled

2021-03-23 Thread devel@edk2.groups.io Calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1057056 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20210323T075542Z
ORGANIZER;CN=Liming Gao:mailto:gaolim...@byosoft.com.cn
DTSTART:20210324T013000Z
DTEND:20210324T023000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 nhttps://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd
 010e1e6d43a6f6c65f45\n\nWednesday\, Jan 20\, 2021 10:30 am | 50 minutes |
  (UTC+08:00) Beijing\, Chongqing\, Hong Kong\, Urumqi\n\nOccurs every Wed
 nesday effective 1/20/2021 from 10:30 AM to 11:20 AM\, (UTC+08:00) Beijin
 g\, Chongqing\, Hong Kong\, Urumqi\n\nMeeting number: 126 867 1239\n\nPas
 sword: ZhqYQunw246 (94797869 from video systems)\n\nd8edc6c9604344b08f727
 b4bf054eaac_20210120T023000Z\n\nJoin by video system\n\nDial 1268671239@m
 eetingsamer34.webex.com\n\nYou can also dial 173.243.2.68 and enter your 
 meeting number.\n\nJoin by phone\n\nUse VoIP only
LOCATION:https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c
 5bd411bd010e1e6d43a6f6c65f45
SEQUENCE:999
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 03/23/2021 6:30pm-7:30pm #cal-reminder

2021-03-23 Thread gaoliming

There are few issues. Let’s cancel meeting on this week. 

 


  3272

EDK2 Tes

UEFI-SCT

unassig...@tianocore.org

UNCO

ImageIndex need be corrected in CheckForSupportGetImage 
 

Sun 22:09

eric@intel.com


  3271

EDK2

Tools

unassig...@tianocore.org

UNCO

GenFw: IsDataShdr() always returns false 
 

Sat 19:34

crawf...@gmail.com


  3268

EDK2

Code

qi1.zh...@intel.com

UNCO

SecurityPkg/Tcg2Config: PCR Bank SHA1 checkbox is still can be selected when 
SHA1 algorithm is disbaled 
 

Fri 03:21

qi1.zh...@intel.com


  3270

EDK2 Tes

UEFI-SCT

unassig...@tianocore.org

UNCO

uefi-sct: DevicePathFromText test for Uart() is too strict 
 

Thu 21:27

xypron.g...@gmx.de

 

Thanks

Liming

发件人: devel@edk2.groups.io  
发送时间: 2021年3月23日 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 03/23/2021 
6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 23 March 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles 

Where:https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

View Event  

Organizer: Liming Gao gaolim...@byosoft.com.cn 


Description: 

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

Wednesday, Jan 20, 2021 10:30 am | 50 minutes | (UTC+08:00) Beijing, Chongqing, 
Hong Kong, Urumqi

Occurs every Wednesday effective 1/20/2021 from 10:30 AM to 11:20 AM, 
(UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Meeting number: 126 867 1239

Password: ZhqYQunw246 (94797869 from video systems)

d8edc6c9604344b08f727b4bf054eaac_20210120T023000Z

 

Join by video system

Dial 1268671...@meetingsamer34.webex.com 
 

You can also dial 173.243.2.68 and enter your meeting number.

 

Join by phone

Use VoIP only





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

[edk2-devel] [PATCH V3 1/2] MdePkg/Include: EFI Redfish Discover protocol

[edk2-devel] [PATCH V3 0/2] Support EFI Redfish protocols

[edk2-devel] [PATCH V3 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

[edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] GSoC 2021 (MinPlatform, Ext2, ACPICA, etc)

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

回复: [edk2-devel] [patch V2 00/29] Add a new library class RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, 23 March 2021 #cal-cancelled

回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 03/23/2021 6:30pm-7:30pm #cal-reminder

19 matches

Site Navigation

Mail list logo

Footer information