Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: CpuDxe: Sync GCD Capabilities With Page Table Attributes

[Ard Biesheuvel]

On Tue, 9 May 2023 at 04:04, Kinney, Michael D
 wrote:
>
> I would prefer next week as well.
>
> Mike
>

Next week, i can only do Wednesday. The week after (22-26), the time
slot works for me on any day of the week.

-- 
Ard.


> > -Original Message-
> > From: Oliver Smith-Denny 
> > Sent: Monday, May 8, 2023 7:03 PM
> > To: Ni, Ray ; Kinney, Michael D
> > ; Ard Biesheuvel ;
> > devel@edk2.groups.io
> > Cc: Leif Lindholm ; Ard Biesheuvel
> > ; Sami Mujawar ;
> > Michael Kubacki ; Sean Brogan
> > 
> > Subject: Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: CpuDxe: Sync GCD
> > Capabilities With Page Table Attributes
> >
> > Hi Ray,
> >
> > Thanks for setting up a meeting on this! We have some
> > conflicts on our side for this week, does it work
> > for everyone to have it the following Thursday
> > (May 18th)?
> >
> > The time works for us.
> >
> > Thanks,
> > Oliver
> >
> > On 5/8/2023 6:35 PM, Ni, Ray wrote:
> > > All,
> > > Can you check if the meeting time is ok for you?
> > >
> > > It will be in this week:
> > > * PDT Thursday 07:00
> > > * Paris Thursday 16:00
> > > * Shanghai Thursday 22:00
> > >
> > > Thanks,
> > > Ray
> > >
> > >
> > >> -Original Message-
> > >> From: Kinney, Michael D 
> > >> Sent: Tuesday, May 2, 2023 1:59 AM
> > >> To: Oliver Smith-Denny ; Ard Biesheuvel
> > >> ; devel@edk2.groups.io
> > >> Cc: Ni, Ray ; Leif Lindholm
> > ;
> > >> Ard Biesheuvel ; Sami Mujawar
> > >> ; Michael Kubacki
> > >> ; Sean Brogan
> > >> ; Kinney, Michael D
> > >> 
> > >> Subject: RE: [edk2-devel] [PATCH v1 1/1] ArmPkg: CpuDxe: Sync GCD
> > >> Capabilities With Page Table Attributes
> > >>
> > >> Thanks for the quick feedback.  Ray is out this week.  I will work with 
> > >> Ray to
> > >> arrange a time slot, hopefully next week that works for everyone.
> > >>
> > >> Mike
> > >>
> > >>> -Original Message-
> > >>> From: Oliver Smith-Denny 
> > >>> Sent: Monday, May 1, 2023 10:53 AM
> > >>> To: Ard Biesheuvel ; devel@edk2.groups.io; Kinney,
> > >>> Michael D 
> > >>> Cc: Ni, Ray ; Leif Lindholm
> > ;
> > >>> Ard Biesheuvel ; Sami Mujawar
> > >>> ; Michael Kubacki
> > >>> ; Sean Brogan
> > >>> 
> > >>> Subject: Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: CpuDxe: Sync GCD
> > >>> Capabilities With Page Table Attributes
> > >>>
> > >>> On 5/1/2023 10:50 AM, Ard Biesheuvel wrote:
> >  On Mon, 1 May 2023 at 19:49, Michael D Kinney
> >   wrote:
> > >
> > > Hi,
> > >
> > > These UEFI Memory Map, GCD, and Page Table interactions can be
> > >>> complex and I
> > > agree there are some UEFI/PI spec clarifications that may help.
> > >
> > > Ray hosts a TianoCore design meeting when needed.  Do you think a
> > >>> meeting with
> > > an open discussion on these topics would help, or do we prefer to
> > >>> continue with
> > > email discussions?
> > >
> > 
> >  I'll gladly join a call to discuss this if we can find a timeslot that
> >  works for everyone in terms of time zone. (I'm on Paris time)
> > >>>
> > >>> I also think a call would be great, I certainly would benefit from
> > >>> learning more here :). I'm sure various members of my team would
> > >>> be interested in joining, happy to be flexible on timeslot (we are
> > >>> generally in PST).
> > >>>
> > >>> Thanks,
> > >>> Oliver


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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Gerd Hoffmann]

On Mon, May 08, 2023 at 09:31:23PM +, Michael Brown wrote:
> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> specification) and so we should never encounter a situation in which
> an interrupt occurs at TPL_HIGH_LEVEL. The specification also
> restricts usage of TPL_HIGH_LEVEL to the firmware itself.
> 
> However, nothing prevents a rogue UEFI application from illegally
> calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately violating
> the invariant by enabling interrupts via the STI or equivalent
> instruction. Some versions of the Microsoft Windows bootloader are
> known to do this.
> 
> NestedInterruptTplLib maintains the invariant that interrupts are
> disabled at TPL_HIGH_LEVEL (even when performing the dark art of
> deliberately manipulating the stack so that IRET will return with
> interrupts still disabled), but does not itself rely on external code
> maintaining this invariant.
> 
> Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
> to an error message, to allow rogue UEFI applications such as the
> Microsoft Windows bootloader to continue to function.
> 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Pawel Polawski 
> Cc: Jiewen Yao 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> 
> Michael Brown (2):
>   OvmfPkg: Clarify invariants for NestedInterruptTplLib
>   OvmfPkg: Relax assertion that interrupts do not occur at
> TPL_HIGH_LEVEL

Reviewed-by: Gerd Hoffmann 

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 1/2] Ext4Pkg: Improve extent node validation on the number of entries

[Marvin Häuser]

> On 9. May 2023, at 02:42, Pedro Falcato  wrote:
> 
> Improve the extent tree node validation by validating the number of
> entries the node advertises against the theoretical max (derived from
> the size of on-disk structs and the block size (or i_data, if inline
> extents).
> 
> Previously, we did not validate the number of entries. This could be
> exploited for out-of-bounds reads and crashes.
> 
> Cc: Marvin Häuser 
> Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
> Reported-by: Savva Mitrofanov 
> Signed-off-by: Pedro Falcato 
> ---
> Features/Ext4Pkg/Ext4Dxe/Extents.c | 47 +++---
> 1 file changed, 30 insertions(+), 17 deletions(-)
> 
> diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c 
> b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> index 9e4364e50d99..66d085938549 100644
> --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> +++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> @@ -1,7 +1,7 @@
> /** @file
>   Extent related routines
> 
> -  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
> **/
> 
> @@ -80,13 +80,15 @@ Ext4GetInoExtentHeader (
> /**
>Checks if an extent header is valid.
>@param[in]  Header Pointer to the EXT4_EXTENT_HEADER structure.
> +   @param[in]  MaxEntries Maximum number of entries possible for 
> this tree node.
> 
>@return TRUE if valid, FALSE if not.
> **/
> STATIC
> BOOLEAN
> Ext4ExtentHeaderValid (
> -  IN CONST EXT4_EXTENT_HEADER  *Header
> +  IN CONST EXT4_EXTENT_HEADER  *Header,
> +  IN UINT16MaxEntries
>   )
> {
>   if (Header->eh_depth > EXT4_EXTENT_TREE_MAX_DEPTH) {
> @@ -99,6 +101,18 @@ Ext4ExtentHeaderValid (
> return FALSE;
>   }
> 
> +  if ((Header->eh_max > MaxEntries) || (Header->eh_entries > MaxEntries)) {

For eh_entries, this is implicit via the check below.

> +DEBUG ((
> +  DEBUG_ERROR,
> +  "[ext4] Invalid extent header entries (extent header: %u max,"
> +  " %u entries, theoretical max: %u) (larger than permitted)\n",
> +  Header->eh_max,
> +  Header->eh_entries,
> +  MaxEntries
> +  ));
> +return FALSE;
> +  }
> +
>   if (Header->eh_max < Header->eh_entries) {
> DEBUG ((
>   DEBUG_ERROR,
> @@ -212,6 +226,9 @@ Ext4ExtentIdxLeafBlock (
>   return LShiftU64 (Index->ei_leaf_hi, 32) | Index->ei_leaf_lo;
> }
> 
> +// Results of sizeof(i_data) / sizeof(extent) - 1 = 4
> +#define EXT4_NR_INLINE_EXTENTS  4
> +
> /**
>Retrieves an extent from an EXT4 inode.
>@param[in]  Partition Pointer to the opened EXT4 partition.
> @@ -237,7 +254,7 @@ Ext4GetExtent (
>   EXT4_EXTENT_HEADER  *ExtHeader;
>   EXT4_EXTENT_INDEX   *Index;
>   EFI_STATUS  Status;
> -  EXT4_BLOCK_NR   BlockNumber;
> +  UINT32  MaxExtentsPerNode;
> 
>   Inode  = File->Inode;
>   Ext= NULL;
> @@ -275,12 +292,17 @@ Ext4GetExtent (
> 
>   ExtHeader = Ext4GetInoExtentHeader (Inode);
> 
> -  if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +  if (!Ext4ExtentHeaderValid (ExtHeader, EXT4_NR_INLINE_EXTENTS)) {
> return EFI_VOLUME_CORRUPTED;
>   }
> 
>   CurrentDepth = ExtHeader->eh_depth;
> 
> +  // A single node fits into a single block, so we can only have (BlockSize 
> / sizeof(EXT4_EXTENT)) - 1
> +  // extents in a single node. Note the -1, because both leaf and internal 
> node headers are 12 bytes,
> +  // and so are individual entries.
> +  MaxExtentsPerNode = (Partition->BlockSize / sizeof (EXT4_EXTENT)) - 1;
> +
>   while (ExtHeader->eh_depth != 0) {
> CurrentDepth--;
> // While depth != 0, we're traversing the tree itself and not any leaves
> @@ -289,17 +311,7 @@ Ext4GetExtent (
> // Therefore, we can use binary search, and it's actually the standard 
> for doing so
> // (see FreeBSD).
> 
> -Index   = Ext4BinsearchExtentIndex (ExtHeader, LogicalBlock);
> -BlockNumber = Ext4ExtentIdxLeafBlock (Index);
> -
> -// Check that block isn't file hole
> -if (BlockNumber == EXT4_BLOCK_FILE_HOLE)

Why is this no longer possible?

Best regards,
Marvin

> {
> -  if (Buffer != NULL) {
> -FreePool (Buffer);
> -  }
> -
> -  return EFI_VOLUME_CORRUPTED;
> -}
> +Index = Ext4BinsearchExtentIndex (ExtHeader, LogicalBlock);
> 
> if (Buffer == NULL) {
>   Buffer = AllocatePool (Partition->BlockSize);
> @@ -309,7 +321,8 @@ Ext4GetExtent (
> }
> 
> // Read the leaf block onto the previously-allocated buffer.
> -Status = Ext4ReadBlocks (Partition, Buffer, 1, BlockNumber);
> +
> +Status = Ext4ReadBlocks (Partition, Buffer, 1, Ext4ExtentIdxLeafBlock 
> (Index));
> if (EFI_ERROR (Status)) {
>   FreePool (Buffer);
>   return Status;
> @@ -317,7 +330,7 @@ Ext4GetExtent (
> 
> ExtHeader = Buffer;
> 
> -if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +if (!Ext4ExtentHeaderValid (ExtHeader, MaxExtentsPerNode)) {
>   FreePool (Buffer);
>   return E

Re: [edk2-devel] [PATCH 2/2] Ext4Pkg: Advertise CSUM_SEED as supported

[Marvin Häuser]

Reviewed-by: Marvin Häuser 

> On 9. May 2023, at 02:42, Pedro Falcato  wrote:
> 
> We had added support for CSUM_SEED but accidentally forgot to advertise
> it in gSupportedIncompatFeat. This made it (erroneously) impossible to
> mount CSUM_SEED filesystems.
> 
> Detected by attempting to mount a relatively new mkfs.ext4'd filesystem.
> 
> Cc: Marvin Häuser 
> Signed-off-by: Pedro Falcato 
> ---
> Features/Ext4Pkg/Ext4Dxe/Superblock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Features/Ext4Pkg/Ext4Dxe/Superblock.c 
> b/Features/Ext4Pkg/Ext4Dxe/Superblock.c
> index 3f56de93c105..604925b582c1 100644
> --- a/Features/Ext4Pkg/Ext4Dxe/Superblock.c
> +++ b/Features/Ext4Pkg/Ext4Dxe/Superblock.c
> @@ -1,7 +1,7 @@
> /** @file
>   Superblock managing routines
> 
> -  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
> **/
> 
> @@ -18,7 +18,7 @@ STATIC CONST UINT32  gSupportedIncompatFeat =
>   EXT4_FEATURE_INCOMPAT_64BIT | EXT4_FEATURE_INCOMPAT_DIRDATA |
>   EXT4_FEATURE_INCOMPAT_FLEX_BG | EXT4_FEATURE_INCOMPAT_FILETYPE |
>   EXT4_FEATURE_INCOMPAT_EXTENTS | EXT4_FEATURE_INCOMPAT_LARGEDIR |
> -  EXT4_FEATURE_INCOMPAT_MMP | EXT4_FEATURE_INCOMPAT_RECOVER;
> +  EXT4_FEATURE_INCOMPAT_MMP | EXT4_FEATURE_INCOMPAT_RECOVER | 
> EXT4_FEATURE_INCOMPAT_CSUM_SEED;
> 
> // Future features that may be nice additions in the future:
> // 1) Btree support: Required for write support and would speed up lookups in 
> large directories.
> -- 
> 2.40.1
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104338): https://edk2.groups.io/g/devel/message/104338
Mute This Topic: https://groups.io/mt/98774551/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 1/2] Ext4Pkg: Improve extent node validation on the number of entries

[Marvin Häuser]

Sorry, saw V2 too late…

> On 9. May 2023, at 02:55, Pedro Falcato  wrote:
> 
> Improve the extent tree node validation by validating the number of
> entries the node advertises against the theoretical max (derived from
> the size of on-disk structs and the block size (or i_data, if inline
> extents).
> 
> Previously, we did not validate the number of entries. This could be
> exploited for out-of-bounds reads and crashes.
> 
> Cc: Marvin Häuser 
> Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
> Reported-by: Savva Mitrofanov 
> Signed-off-by: Pedro Falcato 
> ---
> v2:
> Accidentally based my previous patch on the wrong version of Extents.c, which 
> accidentally undid some previous changes.
> 
> Features/Ext4Pkg/Ext4Dxe/Extents.c | 32 ++
> 1 file changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c 
> b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> index 9e4364e50d99..2d86a7abdedb 100644
> --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> +++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> @@ -1,7 +1,7 @@
> /** @file
>   Extent related routines
> 
> -  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
> **/
> 
> @@ -80,13 +80,15 @@ Ext4GetInoExtentHeader (
> /**
>Checks if an extent header is valid.
>@param[in]  Header Pointer to the EXT4_EXTENT_HEADER structure.
> +   @param[in]  MaxEntries Maximum number of entries possible for 
> this tree node.
> 
>@return TRUE if valid, FALSE if not.
> **/
> STATIC
> BOOLEAN
> Ext4ExtentHeaderValid (
> -  IN CONST EXT4_EXTENT_HEADER  *Header
> +  IN CONST EXT4_EXTENT_HEADER  *Header,
> +  IN UINT16MaxEntries
>   )
> {
>   if (Header->eh_depth > EXT4_EXTENT_TREE_MAX_DEPTH) {
> @@ -99,6 +101,18 @@ Ext4ExtentHeaderValid (
> return FALSE;
>   }
> 
> +  if ((Header->eh_max > MaxEntries) || (Header->eh_entries > MaxEntries)) {

My comment on V1 is still valid, this is implicit for eh_entries via the check 
below. The other comment does not apply to V2.

Best regards,
Marvin

> +DEBUG ((
> +  DEBUG_ERROR,
> +  "[ext4] Invalid extent header entries (extent header: %u max,"
> +  " %u entries, theoretical max: %u) (larger than permitted)\n",
> +  Header->eh_max,
> +  Header->eh_entries,
> +  MaxEntries
> +  ));
> +return FALSE;
> +  }
> +
>   if (Header->eh_max < Header->eh_entries) {
> DEBUG ((
>   DEBUG_ERROR,
> @@ -212,6 +226,9 @@ Ext4ExtentIdxLeafBlock (
>   return LShiftU64 (Index->ei_leaf_hi, 32) | Index->ei_leaf_lo;
> }
> 
> +// Results of sizeof(i_data) / sizeof(extent) - 1 = 4
> +#define EXT4_NR_INLINE_EXTENTS  4
> +
> /**
>Retrieves an extent from an EXT4 inode.
>@param[in]  Partition Pointer to the opened EXT4 partition.
> @@ -237,6 +254,7 @@ Ext4GetExtent (
>   EXT4_EXTENT_HEADER  *ExtHeader;
>   EXT4_EXTENT_INDEX   *Index;
>   EFI_STATUS  Status;
> +  UINT32  MaxExtentsPerNode;
>   EXT4_BLOCK_NR   BlockNumber;
> 
>   Inode  = File->Inode;
> @@ -275,12 +293,17 @@ Ext4GetExtent (
> 
>   ExtHeader = Ext4GetInoExtentHeader (Inode);
> 
> -  if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +  if (!Ext4ExtentHeaderValid (ExtHeader, EXT4_NR_INLINE_EXTENTS)) {
> return EFI_VOLUME_CORRUPTED;
>   }
> 
>   CurrentDepth = ExtHeader->eh_depth;
> 
> +  // A single node fits into a single block, so we can only have (BlockSize 
> / sizeof(EXT4_EXTENT)) - 1
> +  // extents in a single node. Note the -1, because both leaf and internal 
> node headers are 12 bytes,
> +  // and so are individual entries.
> +  MaxExtentsPerNode = (Partition->BlockSize / sizeof (EXT4_EXTENT)) - 1;
> +
>   while (ExtHeader->eh_depth != 0) {
> CurrentDepth--;
> // While depth != 0, we're traversing the tree itself and not any leaves
> @@ -309,6 +332,7 @@ Ext4GetExtent (
> }
> 
> // Read the leaf block onto the previously-allocated buffer.
> +
> Status = Ext4ReadBlocks (Partition, Buffer, 1, BlockNumber);
> if (EFI_ERROR (Status)) {
>   FreePool (Buffer);
> @@ -317,7 +341,7 @@ Ext4GetExtent (
> 
> ExtHeader = Buffer;
> 
> -if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +if (!Ext4ExtentHeaderValid (ExtHeader, MaxExtentsPerNode)) {
>   FreePool (Buffer);
>   return EFI_VOLUME_CORRUPTED;
> }
> -- 
> 2.40.1
> 



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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Replace the OVMF-specific SataControllerDxe with the generic one

[Gerd Hoffmann]

On Mon, May 08, 2023 at 10:52:44PM +0100, Pedro Falcato wrote:
> This patch-set replaces the OVMF specific SataControllerDxe with the 
> MdeModulePkg/Bus/Pci one.
> They were both forked from the same code, and are code-and-functionality 
> similar. As such, there
> seems to be no need for duplication here.
> 
> First I manually replayed OvmfPkg/SataControllerDxe's patches on top of the 
> generic one. Only one
> seemed to make sense. The second patch removes OvmfPkg/SataControllerDxe and 
> replaces it for all platforms
> under OvmfPkg. 
> 
> Tested by booting in QEMU (Q35 (AHCI) and PC (IDE)).
> More testing from other, alternative platforms is desired, although breakage 
> seems unlikely.
> 
> (+CC Laszlo as the author of the original SataControllerDxe patches)

Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 

take care,
  Gerd



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

[edk2-devel] [PATCH v1 0/8] SecurityPkg/MdePkg: RngLib GUID

[PierreGondois]

From: Pierre Gondois 

This patchset follows the 'code first' approach and relies on [1].
This patchset follows the thread at [3] that aims to solve [2].
[1] and [2] are bound and this patchset aims to solve both.

In this patchset:
a-
The RngDxe can rely on the RngLib. However the RngLib has no
interface allowing to describe which Rng algorithm is implemented.
The RngDxe must advertise the algorithm that are available through
the RngGetInfo() callback.
Add a GetRngGuid() for interface to the RngLib.

b-
The Arm Architecture states the RNDR that the DRBG algorithm should
be compliant with NIST SP800-90A, while not mandating a particular
algorithm, so as to be inclusive of different geographies.
The RngLib can rely on this Arm RNDR instruction. In order to
accurately describe the implementation using the RNDR instruction,
add a EFI_RNG_ALGORITHM_ARM_RNDR GUID [1].

c-
For the same reason as a/b, add a GUID describing unsafe RNG
algorithms, allowing to accurately describe the BaseRngLibTimerLib.

d-
Use a/b/c mechanisms/GUIDs to select a safe Rng algorithm in the
Arm implementation of the RngDxe.

[1] BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
[2] BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151
[3] https://edk2.groups.io/g/devel/message/100806

Pierre Gondois (8):
  MdePkg/ArmTrngLib: Remove ASSERTs in Null implementation
  MdePkg/MdePkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg
  MdePkg/DxeRngLib: Request raw algorithm instead of default
  MdePkg/Rng: Add GUIDs to describe Rng algorithms
  MdePkg/Rng: Add GetRngGuid() to RngLib
  SecurityPkg/RngDxe: Use GetRngGuid() when probing RngLib
  SecurityPkg/RngDxe: Select safe default Rng algorithm
  SecurityPkg/RngDxe: Simplify Rng algorithm selection for Arm

 MdePkg/Include/Library/RngLib.h   | 17 +
 MdePkg/Include/Protocol/Rng.h | 20 ++
 .../BaseArmTrngLibNull/BaseArmTrngLibNull.c   |  4 --
 MdePkg/Library/BaseRngLib/AArch64/Rndr.c  | 42 +++
 MdePkg/Library/BaseRngLib/BaseRngLib.inf  |  9 +++
 MdePkg/Library/BaseRngLib/Rand/RdRand.c   | 26 +++
 .../Library/BaseRngLibNull/BaseRngLibNull.c   | 22 ++
 .../BaseRngLibTimerLib/BaseRngLibTimerLib.inf |  3 +
 .../Library/BaseRngLibTimerLib/RngLibTimer.c  | 28 
 MdePkg/Library/DxeRngLib/DxeRngLib.c  | 36 +-
 MdePkg/MdePkg.dec |  7 ++
 .../RngDxe/AArch64/AArch64Algo.c  | 70 +++
 .../RandomNumberGenerator/RngDxe/ArmRngDxe.c  | 23 +++---
 .../RandomNumberGenerator/RngDxe/RngDxe.inf   |  5 +-
 SecurityPkg/SecurityPkg.dec   |  2 -
 15 files changed, 278 insertions(+), 36 deletions(-)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104341): https://edk2.groups.io/g/devel/message/104341
Mute This Topic: https://groups.io/mt/98779037/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/8] MdePkg/ArmTrngLib: Remove ASSERTs in Null implementation

[PierreGondois]

From: Pierre Gondois 

Remove ASSERTs to allow RngDxe probing the Null implementation
of the TrngLib.

Signed-off-by: Pierre Gondois 
---
 MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.c 
b/MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.c
index 316d78bf5e83..0ea9aafa59f1 100644
--- a/MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.c
+++ b/MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.c
@@ -41,7 +41,6 @@ GetArmTrngVersion (
   OUT UINT16  *MinorRevision
   )
 {
-  ASSERT (FALSE);
   return RETURN_UNSUPPORTED;
 }
 
@@ -67,7 +66,6 @@ GetArmTrngUuid (
   OUT GUID  *Guid
   )
 {
-  ASSERT (FALSE);
   return RETURN_UNSUPPORTED;
 }
 
@@ -83,7 +81,6 @@ GetArmTrngMaxSupportedEntropyBits (
   VOID
   )
 {
-  ASSERT (FALSE);
   return 0;
 }
 
@@ -116,6 +113,5 @@ GetArmTrngEntropy (
   OUT UINT8  *Buffer
   )
 {
-  ASSERT (FALSE);
   return RETURN_UNSUPPORTED;
 }
-- 
2.25.1



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

[edk2-devel] [PATCH v1 2/8] MdePkg/MdePkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkg

[PierreGondois]

From: Pierre Gondois 

In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a
following patch and to avoid making the MdePkg dependent on another
package, move PcdCpuRngSupportedAlgorithm to the MdePkg.

As the Pcf is only used for AARCH64, place it in an AARCH64
specific sections.

Signed-off-by: Pierre Gondois 
---
 MdePkg/MdePkg.dec   | 5 +
 SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf | 4 ++--
 SecurityPkg/SecurityPkg.dec | 2 --
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index d6c4179b2a48..0ecfad5795e4 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2357,6 +2357,11 @@ [PcdsFixedAtBuild,PcdsPatchableInModule]
   # @Prompt IPMI KCS Interface I/O Base Address
   gEfiMdePkgTokenSpaceGuid.PcdIpmiKcsIoBaseAddress|0xca2|UINT16|0x0031
 
+[PcdsFixedAtBuild.AARCH64, PcdsPatchableInModule.AARCH64]
+  ## GUID identifying the Rng algorithm implemented by CPU instruction.
+  # @Prompt CPU Rng algorithm's GUID.
+  
gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0032
+
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## This value is used to set the base address of PCI express hierarchy.
   # @Prompt PCI Express Base Address.
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf 
b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
index c8e0ee4ae5d9..d6c2d30195bf 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
@@ -79,8 +79,8 @@ [Guids]
 [Protocols]
   gEfiRngProtocolGuid## PRODUCES
 
-[Pcd]
-  gEfiSecurityPkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm  ## CONSUMES
+[Pcd.AARCH64]
+  gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm  ## CONSUMES
 
 [Depex]
   TRUE
diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 0a8042d63fe1..6bb02d58bdf0 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -325,8 +325,6 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   
gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeFvVerificationPass|0x0303100A|UINT32|0x00010030
   
gEfiSecurityPkgTokenSpaceGuid.PcdStatusCodeFvVerificationFail|0x0303100B|UINT32|0x00010031
 
-  
gEfiSecurityPkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x00010032
-
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## Image verification policy for OptionRom. Only following values are 
valid:
   #  NOTE: Do NOT use 0x5 and 0x2 since it violates the UEFI specification and 
has been removed.
-- 
2.25.1



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

[edk2-devel] [PATCH v1 3/8] MdePkg/DxeRngLib: Request raw algorithm instead of default

[PierreGondois]

From: Pierre Gondois 

The DxeRngLib tries to generate a random number using the 3 NIST
SP 800-90 compliant DRBG algorithms, i.e. 256-bits CTR, HASH and HMAC.
If none of the call is successful, the fallback option is the default
RNG algorithm of the EFI_RNG_PROTOCOL. This default algorithm might
be an unsafe implementation.

Try requesting the Raw algorithm before requesting the default one.

Signed-off-by: Pierre Gondois 
---
 MdePkg/Library/DxeRngLib/DxeRngLib.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/DxeRngLib/DxeRngLib.c 
b/MdePkg/Library/DxeRngLib/DxeRngLib.c
index 46aea515924f..a01b66ad7d20 100644
--- a/MdePkg/Library/DxeRngLib/DxeRngLib.c
+++ b/MdePkg/Library/DxeRngLib/DxeRngLib.c
@@ -65,9 +65,15 @@ GenerateRandomNumberViaNist800Algorithm (
 return Status;
   }
 
+  Status = RngProtocol->GetRNG (RngProtocol, &gEfiRngAlgorithmRaw, BufferSize, 
Buffer);
+  DEBUG ((DEBUG_INFO, "%a: GetRNG algorithm Raw - Status = %r\n", __func__, 
Status));
+  if (!EFI_ERROR (Status)) {
+return Status;
+  }
+
   // If all the other methods have failed, use the default method from the 
RngProtocol
   Status = RngProtocol->GetRNG (RngProtocol, NULL, BufferSize, Buffer);
-  DEBUG ((DEBUG_INFO, "%a: GetRNG algorithm Hash-256 - Status = %r\n", 
__func__, Status));
+  DEBUG ((DEBUG_INFO, "%a: GetRNG algorithm default - Status = %r\n", 
__func__, Status));
   if (!EFI_ERROR (Status)) {
 return Status;
   }
-- 
2.25.1



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

[edk2-devel] [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms

[PierreGondois]

From: Pierre Gondois 

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

The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function is added in a following patch.

Prepare GetRngGuid() return values and add GUIDs describing
Rng algorithms:
- gEfiRngAlgorithmArmRndr
to describe a Rng algorithm accessed through Arm's RNDR instruction.
[1] states that the implementation of this algorithm should be
compliant to NIST SP900-80. The compliance is not guaranteed.
- gEfiRngAlgorithmUnSafe
to describe an unsafe implementation, cf. the BaseRngLibTimerLib.

[1] Arm Architecture Reference Manual Armv8, for A-profile architecture
sK12.1 'Properties of the generated random number'

Signed-off-by: Pierre Gondois 
---
 MdePkg/Include/Protocol/Rng.h | 20 
 MdePkg/MdePkg.dec |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/MdePkg/Include/Protocol/Rng.h b/MdePkg/Include/Protocol/Rng.h
index baf425587b3c..dfdaf36e41dc 100644
--- a/MdePkg/Include/Protocol/Rng.h
+++ b/MdePkg/Include/Protocol/Rng.h
@@ -67,6 +67,24 @@ typedef EFI_GUID EFI_RNG_ALGORITHM;
   { \
 0xe43176d7, 0xb6e8, 0x4827, {0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85, 
0x61 } \
   }
+///
+/// The Arm Architecture states the RNDR that the DRBG algorithm should be 
compliant
+/// with NIST SP800-90A, while not mandating a particular algorithm, so as to 
be
+/// inclusive of different geographies.
+///
+#define EFI_RNG_ALGORITHM_ARM_RNDR \
+  { \
+0x43d2fde3, 0x9d4e, 0x4d79,  {0x02, 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08, 
0x41} \
+  }
+///
+/// The implementation of a Random Number Generator might be unsafe, when using
+/// a dummy implementation for instance. Allow identifying such implementation
+/// with this GUID.
+///
+#define EFI_RNG_ALGORITHM_UNSAFE \
+  { \
+0x869f728c, 0x409d, 0x4ab4, {0xac, 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3, 
0xf4 } \
+  }
 
 /**
   Returns information about the random number generation implementation.
@@ -146,5 +164,7 @@ extern EFI_GUID  gEfiRngAlgorithmSp80090Ctr256Guid;
 extern EFI_GUID  gEfiRngAlgorithmX9313DesGuid;
 extern EFI_GUID  gEfiRngAlgorithmX931AesGuid;
 extern EFI_GUID  gEfiRngAlgorithmRaw;
+extern EFI_GUID  gEfiRngAlgorithmArmRndr;
+extern EFI_GUID  gEfiRngAlgorithmUnSafe;
 
 #endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 0ecfad5795e4..754085eaa55b 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -633,6 +633,8 @@ [Guids]
   gEfiRngAlgorithmX9313DesGuid   = { 0x63c4785a, 0xca34, 0x4012, {0xa3, 
0xc8, 0x0b, 0x6a, 0x32, 0x4f, 0x55, 0x46 }}
   gEfiRngAlgorithmX931AesGuid= { 0xacd03321, 0x777e, 0x4d3d, {0xb1, 
0xc8, 0x20, 0xcf, 0xd8, 0x88, 0x20, 0xc9 }}
   gEfiRngAlgorithmRaw= { 0xe43176d7, 0xb6e8, 0x4827, {0xb7, 
0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85, 0x61 }}
+  gEfiRngAlgorithmArmRndr= { 0x43d2fde3, 0x9d4e, 0x4d79, {0x02, 
0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08, 0x41 }}
+  gEfiRngAlgorithmUnSafe = { 0x869f728c, 0x409d, 0x4ab4, {0xac, 
0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3, 0xf4 }}
 
   ## Include/Protocol/AdapterInformation.h
   gEfiAdapterInfoMediaStateGuid   = { 0xD7C74207, 0xA831, 0x4A26, {0xB1, 
0xF5, 0xD1, 0x93, 0x06, 0x5C, 0xE8, 0xB6 }}
-- 
2.25.1



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

[edk2-devel] [PATCH v1 5/8] MdePkg/Rng: Add GetRngGuid() to RngLib

[PierreGondois]

From: Pierre Gondois 

The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
add a GetRngGuid() function to the RngLib.

Signed-off-by: Pierre Gondois 
---
 MdePkg/Include/Library/RngLib.h   | 17 
 MdePkg/Library/BaseRngLib/AArch64/Rndr.c  | 42 +++
 MdePkg/Library/BaseRngLib/BaseRngLib.inf  |  9 
 MdePkg/Library/BaseRngLib/Rand/RdRand.c   | 26 
 .../Library/BaseRngLibNull/BaseRngLibNull.c   | 22 ++
 .../BaseRngLibTimerLib/BaseRngLibTimerLib.inf |  3 ++
 .../Library/BaseRngLibTimerLib/RngLibTimer.c  | 28 +
 MdePkg/Library/DxeRngLib/DxeRngLib.c  | 28 +
 8 files changed, 175 insertions(+)

diff --git a/MdePkg/Include/Library/RngLib.h b/MdePkg/Include/Library/RngLib.h
index 429ed19e287e..945482cd5e56 100644
--- a/MdePkg/Include/Library/RngLib.h
+++ b/MdePkg/Include/Library/RngLib.h
@@ -1,6 +1,7 @@
 /** @file
   Provides random number generator services.
 
+Copyright (c) 2023, Arm Limited. All rights reserved.
 Copyright (c) 2015, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -77,4 +78,20 @@ GetRandomNumber128 (
   OUT UINT64  *Rand
   );
 
+/**
+  Get a GUID identifying the RNG algorithm implementation.
+
+  @param [out] RngGuid  If success, contains the GUID identifying
+the RNG algorithm implementation.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_UNSUPPORTED Not supported.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+GetRngGuid (
+  GUID  *RngGuid
+  );
+
 #endif // __RNG_LIB_H__
diff --git a/MdePkg/Library/BaseRngLib/AArch64/Rndr.c 
b/MdePkg/Library/BaseRngLib/AArch64/Rndr.c
index 20811bf3ebf3..d39db62153ee 100644
--- a/MdePkg/Library/BaseRngLib/AArch64/Rndr.c
+++ b/MdePkg/Library/BaseRngLib/AArch64/Rndr.c
@@ -2,6 +2,7 @@
   Random number generator service that uses the RNDR instruction
   to provide pseudorandom numbers.
 
+  Copyright (c) 2023, Arm Limited. All rights reserved.
   Copyright (c) 2021, NUVIA Inc. All rights reserved.
   Copyright (c) 2015, Intel Corporation. All rights reserved.
 
@@ -11,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -138,3 +140,43 @@ ArchIsRngSupported (
 {
   return mRndrSupported;
 }
+
+/**
+  Get a GUID identifying the RNG algorithm implementation.
+
+  @param [out] RngGuid  If success, contains the GUID identifying
+the RNG algorithm implementation.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_UNSUPPORTED Not supported.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+GetRngGuid (
+  GUID  *RngGuid
+  )
+{
+  GUID  *RngLibGuid;
+
+  if (RngGuid == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (!mRndrSupported) {
+return EFI_UNSUPPORTED;
+  }
+
+  //
+  // If the platform advertises the algorithm behind RNDR instruction,
+  // use it. Otherwise use gEfiRngAlgorithmArmRndr.
+  //
+  RngLibGuid = PcdGetPtr (PcdCpuRngSupportedAlgorithm);
+  if (!IsZeroGuid (RngLibGuid)) {
+CopyMem (RngGuid, RngLibGuid, sizeof (*RngGuid));
+  } else {
+CopyMem (RngGuid, &gEfiRngAlgorithmArmRndr, sizeof (*RngGuid));
+  }
+
+  return EFI_SUCCESS;
+}
diff --git a/MdePkg/Library/BaseRngLib/BaseRngLib.inf 
b/MdePkg/Library/BaseRngLib/BaseRngLib.inf
index 1fcceb941495..a79fbf03d74c 100644
--- a/MdePkg/Library/BaseRngLib/BaseRngLib.inf
+++ b/MdePkg/Library/BaseRngLib/BaseRngLib.inf
@@ -4,6 +4,7 @@
 #  BaseRng Library that uses CPU RNG instructions (e.g. RdRand) to
 #  provide random numbers.
 #
+#  Copyright (c) 2023, Arm Limited. All rights reserved.
 #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
 #  Copyright (c) 2015, Intel Corporation. All rights reserved.
 #
@@ -43,9 +44,17 @@ [Sources.AARCH64]
   AArch64/ArmReadIdIsar0.asm | MSFT
   AArch64/ArmRng.asm | MSFT
 
+[Guids]
+  gEfiRngAlgorithmArmRndr
+  gEfiRngAlgorithmSp80090Ctr256Guid
+  gEfiRngAlgorithmUnSafe
+
 [Packages]
   MdePkg/MdePkg.dec
 
+[Pcd.AARCH64]
+  gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm
+
 [LibraryClasses]
   BaseLib
   DebugLib
diff --git a/MdePkg/Library/BaseRngLib/Rand/RdRand.c 
b/MdePkg/Library/BaseRngLib/Rand/RdRand.c
index 070d41e2555f..9bd68352f9f7 100644
--- a/MdePkg/Library/BaseRngLib/Rand/RdRand.c
+++ b/MdePkg/Library/BaseRngLib/Rand/RdRand.c
@@ -2,6 +2,7 @@
   Random number generator services that uses RdRand instruction access
   to provide high-quality random numbers.
 
+Copyright (c) 2023, Arm Limited. All rights reserved.
 Copyright (c) 2021, NUVIA Inc. All rights reserved.
 Copyright (c) 2015, Intel Corporation. All rights reserved.
 
@@ -11,6 +12,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #include 
 #include 
+#include 
 #include 
 
 #include "BaseRngLibInternals.h"
@@ -128,

[edk2-devel] [PATCH v1 6/8] SecurityPkg/RngDxe: Use GetRngGuid() when probing RngLib

[PierreGondois]

From: Pierre Gondois 

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

The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
To allow the RngDxe to detect when such implementation is used,
a GetRngGuid() function was added in a previous patch.

The EFI_RNG_PROTOCOL can advertise multiple algorithms through
Guids. The PcdCpuRngSupportedAlgorithm is currently used to
advertise the RngLib in the Arm implementation.

The issues of doing that are:
- the RngLib implementation might not use CPU instructions,
  cf. the BaseRngLibTimerLib
- most platforms don't set PcdCpuRngSupportedAlgorithm

A GetRngGuid() was added to the RngLib in a previous patch,
allowing to identify the algorithm implemented by the RngLib.
Make use of this function.

Signed-off-by: Pierre Gondois 
---
 .../RngDxe/AArch64/AArch64Algo.c  | 24 +--
 .../RandomNumberGenerator/RngDxe/ArmRngDxe.c  |  6 -
 .../RandomNumberGenerator/RngDxe/RngDxe.inf   |  5 ++--
 3 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
index e8be217f8a8c..a1ff7bd58fda 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "RngDxeInternals.h"
 
@@ -28,9 +29,10 @@ GetAvailableAlgorithms (
   VOID
   )
 {
-  UINT64  DummyRand;
-  UINT16  MajorRevision;
-  UINT16  MinorRevision;
+  EFI_STATUS  Status;
+  UINT16  MajorRevision;
+  UINT16  MinorRevision;
+  GUIDRngGuid;
 
   // Rng algorithms 2 times, one for the allocation, one to populate.
   mAvailableAlgoArray = AllocateZeroPool (RNG_AVAILABLE_ALGO_MAX);
@@ -38,24 +40,22 @@ GetAvailableAlgorithms (
 return EFI_OUT_OF_RESOURCES;
   }
 
-  // Check RngGetBytes() before advertising PcdCpuRngSupportedAlgorithm.
-  if (!EFI_ERROR (RngGetBytes (sizeof (DummyRand), (UINT8 *)&DummyRand))) {
+  // Identify RngLib algorithm.
+  Status = GetRngGuid (&RngGuid);
+  if (!EFI_ERROR (Status)) {
 CopyMem (
   &mAvailableAlgoArray[mAvailableAlgoArrayCount],
-  PcdGetPtr (PcdCpuRngSupportedAlgorithm),
-  sizeof (EFI_RNG_ALGORITHM)
+  RngGuid,
+  sizeof (RngGuid)
   );
 mAvailableAlgoArrayCount++;
 
-DEBUG_CODE_BEGIN ();
-if (IsZeroGuid (PcdGetPtr (PcdCpuRngSupportedAlgorithm))) {
+if (IsZeroGuid (&RngGuid)) {
   DEBUG ((
 DEBUG_WARN,
-"PcdCpuRngSupportedAlgorithm should be a non-zero GUID\n"
+"RngLib should have a non-zero GUID\n"
 ));
 }
-
-DEBUG_CODE_END ();
   }
 
   // Raw algorithm (Trng)
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
index ce49ff7ae661..78a18c5e1177 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
@@ -78,6 +78,7 @@ RngGetRNG (
 {
   EFI_STATUS  Status;
   UINTN   Index;
+  GUIDRngGuid;
 
   if ((This == NULL) || (RNGValueLength == 0) || (RNGValue == NULL)) {
 return EFI_INVALID_PARAMETER;
@@ -102,7 +103,10 @@ RngGetRNG (
   }
 
 FoundAlgo:
-  if (CompareGuid (RNGAlgorithm, PcdGetPtr (PcdCpuRngSupportedAlgorithm))) {
+  Status = GetRngGuid (&RngGuid);
+  if (!EFI_ERROR (Status) &&
+  CompareGuid (RNGAlgorithm, &RngGuid))
+  {
 Status = RngGetBytes (RNGValueLength, RNGValue);
 return Status;
   }
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf 
b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
index d6c2d30195bf..aa5743387ed9 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
@@ -75,13 +75,12 @@ [Guids]
   gEfiRngAlgorithmX9313DesGuid## SOMETIMES_PRODUCES## GUID
# Unique ID of the algorithm for RNG
   gEfiRngAlgorithmX931AesGuid ## SOMETIMES_PRODUCES## GUID
# Unique ID of the algorithm for RNG
   gEfiRngAlgorithmRaw ## SOMETIMES_PRODUCES## GUID
# Unique ID of the algorithm for RNG
+  gEfiRngAlgorithmArmRndr ## SOMETIMES_PRODUCES## GUID
# Unique ID of the algorithm for RNG
+  gEfiRngAlgorithmUnSafe  ## SOMETIMES_PRODUCES## GUID
# Unique ID of the algorithm for RNG
 
 [Protocols]
   gEfiRngProtocolGuid## PRODUCES
 
-[Pcd.AARCH64]
-  gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm  ## CONSUMES
-
 [Depex]
   TRUE
 
-- 
2.25.1



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

[edk2-devel] [PATCH v1 7/8] SecurityPkg/RngDxe: Select safe default Rng algorithm

[PierreGondois]

From: Pierre Gondois 

The first element of mAvailableAlgoArray should be the default
algorithm to avoid going through a selection process at each
RngGetRNG() call.
Once all the available Rng algorithms have been probed, place
a safe Rng algorithm at the first position of mAvailableAlgoArray.

Signed-off-by: Pierre Gondois 
---
 .../RngDxe/AArch64/AArch64Algo.c  | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
index a1ff7bd58fda..ed236b2e8141 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/AArch64/AArch64Algo.c
@@ -17,6 +17,50 @@
 // Maximum number of Rng algorithms.
 #define RNG_AVAILABLE_ALGO_MAX  2
 
+/** mAvailableAlgoArray[0] should contain the default Rng algorithm.
+The Rng algorithm at the first index might be unsafe.
+If a safe algorithm is available, choose it as the default one.
+**/
+VOID
+EFIAPI
+RngFindDefaultAlgo (
+  VOID
+  )
+{
+  EFI_RNG_ALGORITHM  *CurAlgo;
+  EFI_RNG_ALGORITHM  TmpGuid;
+  UINTN  Index;
+
+  CurAlgo = &mAvailableAlgoArray[0];
+
+  if (IsZeroGuid (CurAlgo) ||
+  !CompareGuid (CurAlgo, &gEfiRngAlgorithmUnSafe))
+  {
+// mAvailableAlgoArray[0] is a valid Rng algorithm.
+return;
+  }
+
+  for (Index = 1; Index < mAvailableAlgoArrayCount; Index++) {
+CurAlgo = &mAvailableAlgoArray[Index];
+if (!IsZeroGuid (CurAlgo) ||
+CompareGuid (CurAlgo, &gEfiRngAlgorithmUnSafe))
+{
+  break;
+}
+  }
+
+  if (Index == mAvailableAlgoArrayCount) {
+// No valid Rng algorithm available.
+return;
+  }
+
+  CopyMem (&TmpGuid, CurAlgo, sizeof (EFI_RNG_ALGORITHM));
+  CopyMem (CurAlgo, &mAvailableAlgoArray[0], sizeof (EFI_RNG_ALGORITHM));
+  CopyMem (&mAvailableAlgoArray[0], &TmpGuid, sizeof (EFI_RNG_ALGORITHM));
+
+  return;
+}
+
 /** Allocate and initialize mAvailableAlgoArray with the available
 Rng algorithms. Also update mAvailableAlgoArrayCount.
 
@@ -45,7 +89,7 @@ GetAvailableAlgorithms (
   if (!EFI_ERROR (Status)) {
 CopyMem (
   &mAvailableAlgoArray[mAvailableAlgoArrayCount],
-  RngGuid,
+  &RngGuid,
   sizeof (RngGuid)
   );
 mAvailableAlgoArrayCount++;
@@ -68,5 +112,7 @@ GetAvailableAlgorithms (
 mAvailableAlgoArrayCount++;
   }
 
+  RngFindDefaultAlgo ();
+
   return EFI_SUCCESS;
 }
-- 
2.25.1



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

[edk2-devel] [PATCH v1 8/8] SecurityPkg/RngDxe: Simplify Rng algorithm selection for Arm

[PierreGondois]

From: Pierre Gondois 

The first element of mAvailableAlgoArray is defined as the default
Rng algorithm to use. Don't go through the array at each RngGetRNG()
call and just return the first element of the array.

Signed-off-by: Pierre Gondois 
---
 .../RandomNumberGenerator/RngDxe/ArmRngDxe.c| 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
index 78a18c5e1177..7a42e3cbe3d2 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c
@@ -77,7 +77,6 @@ RngGetRNG (
   )
 {
   EFI_STATUS  Status;
-  UINTN   Index;
   GUIDRngGuid;
 
   if ((This == NULL) || (RNGValueLength == 0) || (RNGValue == NULL)) {
@@ -88,21 +87,13 @@ RngGetRNG (
 //
 // Use the default RNG algorithm if RNGAlgorithm is NULL.
 //
-for (Index = 0; Index < mAvailableAlgoArrayCount; Index++) {
-  if (!IsZeroGuid (&mAvailableAlgoArray[Index])) {
-RNGAlgorithm = &mAvailableAlgoArray[Index];
-goto FoundAlgo;
-  }
-}
-
-if (Index == mAvailableAlgoArrayCount) {
-  // No algorithm available.
-  ASSERT (Index != mAvailableAlgoArrayCount);
-  return EFI_DEVICE_ERROR;
+if (mAvailableAlgoArrayCount != 0) {
+  RNGAlgorithm = &mAvailableAlgoArray[0];
+} else {
+  return EFI_UNSUPPORTED;
 }
   }
 
-FoundAlgo:
   Status = GetRngGuid (&RngGuid);
   if (!EFI_ERROR (Status) &&
   CompareGuid (RNGAlgorithm, &RngGuid))
-- 
2.25.1



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

Re: [edk2-devel] 回复: [PATCH v1 03/11] MdePkg/Acpi64: Add _PSD/_CPC/State Coordination Types macros

[PierreGondois]

Hello Liming,

On 5/6/23 03:25, gaoliming wrote:

Pierre:


-邮件原件-
发件人: pierre.gond...@arm.com 
发送时间: 2023年5月5日 21:17
收件人: devel@edk2.groups.io
抄送: Ard Biesheuvel ; Leif Lindholm
; Sami Mujawar ; Michael D
Kinney ; Liming Gao
; Zhiguang Liu 
主题: [PATCH v1 03/11] MdePkg/Acpi64: Add _PSD/_CPC/State Coordination
Types macros

From: Pierre Gondois 

Add macros for:
- _PSD version
- _CPC version
- C-state/T-state/P-state Coordination Types

These objects were present in previous ACPI specification version,
but are only added to the latest availbable version (6.4).

Signed-off-by: Pierre Gondois 
---
  MdePkg/Include/IndustryStandard/Acpi64.h | 25
+++-
  1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index 575ca0430c13..e3c128d7548d 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -2,7 +2,7 @@
ACPI 6.4 definitions from the ACPI Specification Revision 6.4 Jan,

2021.


Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.
-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2019 - 2023, Arm Ltd. All rights reserved.


I see other source files all use ARM Ltd. Is it required to be updated to
Arm Ltd?


I think the name of the company was rebranded from ARM to Arm in 2017,
so I've been asked to change the the copyright name when we update the copyright
year ...




Thanks
Liming

SPDX-License-Identifier: BSD-2-Clause-Patent
  **/
@@ -17,6 +17,29 @@
  //
  #pragma pack(1)

+///
+/// C-state/T-state/P-state Coordination Types
+/// Cf. s8.3 Power, Performance, and Throttling State Dependencies
+///
+#define EFI_ACPI_6_4_AML_STATE_COORD_TYPE_SW_ALL  0xFC
+#define EFI_ACPI_6_4_AML_STATE_COORD_TYPE_SW_ANY  0xFD
+#define EFI_ACPI_6_4_AML_STATE_COORD_TYPE_HW_ALL  0xFE
+
+///
+/// _PSD Revision
+/// Cf. s8.4.6.5 _PSD (P-State Dependency)
+///
+#define EFI_ACPI_6_4_AML_PSD_REVISION_V0  0
+
+///
+/// _CPC Revision
+/// Cf. s8.4.7.1 _CPC (Continuous Performance Control)
+///
+#define EFI_ACPI_6_4_AML_CPC_REVISION_V0  0
+#define EFI_ACPI_6_4_AML_CPC_REVISION_V1  1
+#define EFI_ACPI_6_4_AML_CPC_REVISION_V2  2
+#define EFI_ACPI_6_4_AML_CPC_REVISION_V3  3
+
  ///
  /// ACPI 6.4 Generic Address Space definition
  ///
--
2.25.1







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

[edk2-devel] [edk2-platforms][PATCH 1/2] ManageabilityPkg: Add Manageability IPMI helper Library

[Chang, Abner via groups.io]

From: Abner Chang 

Add IPMI helper library to print debug message
of IPMI Completion Code in human readable string
and return the transport interface additional
status.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Tinh Nguyen 
---
 .../BaseManageabilityTransportHelper.inf  |  1 +
 .../Library/ManageabilityTransportHelperLib.h | 24 +++
 .../Library/ManageabilityTransportIpmiLib.h   | 13 +++-
 .../Library/ManageabilityTransportLib.h   | 11 +--
 .../BaseManageabilityTransportIpmiHelper.c| 70 +++
 5 files changed, 112 insertions(+), 7 deletions(-)
 create mode 100644 
Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportIpmiHelper.c

diff --git 
a/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
 
b/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
index c9e5eaef60..0936449fda 100644
--- 
a/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
+++ 
b/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
@@ -21,6 +21,7 @@
 
 [Sources]
   BaseManageabilityTransportHelper.c
+  BaseManageabilityTransportIpmiHelper.c
 
 [LibraryClasses]
   BaseMemoryLib
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h
index c2c98d6c2d..11a1bd0521 100644
--- 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h
+++ 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h
@@ -187,4 +187,28 @@ HelperManageabilityDebugPrint (
   ...
   );
 
+///
+/// IPMI Helper Functions.
+///
+
+/**
+  This function returns a human readable string of IPMI KCS Completion Code
+  and returns the corresponding additional status of transport interface.
+
+  @param [in]  CompletionCode The Completion Code returned from KCS.
+  @param [out] CompletionCodeStr  Human readable string of IPMI Completion 
Code.
+  @param [out] AdditionalStatus   Return the addtional status.
+
+  @retval  EFI_SUCCESSThe information of Completion Code is 
returned.
+  @retval  EFI_NOT_FOUND  No information of Completion Code is 
returned.
+  @retval  EFI_INVALID_PARAMETER  The given parameter is incorrect.
+
+**/
+EFI_STATUS
+IpmiHelperCheckCompletionCode (
+  IN   UINT8  CompletionCode,
+  OUT  CHAR16 **CompletionCodeStr,
+  OUT  MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS  *AdditionalStatus
+  );
+
 #endif
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h
index 1628255a6a..6d136e460f 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h
@@ -16,9 +16,18 @@
 /// the payload.
 ///
 typedef struct {
-  UINT8Lun:2;
-  UINT8NetFn:6;
+  UINT8Lun   : 2;
+  UINT8NetFn : 6;
   UINT8Command;
 } MANAGEABILITY_IPMI_TRANSPORT_HEADER;
 
+///
+/// The IPMI Completion Code mapping.
+///
+typedef struct {
+  UINT8CompletionCode;
+  CHAR16   *CompletionCodeString;
+  MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUSAdditionalStatus;
+} MANAGEABILITY_IPMI_COMPLETTION_CODE_MAPPING;
+
 #endif
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h
index 04072aee89..f423a1ed44 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h
@@ -61,11 +61,12 @@ typedef union {
 /// Additional transport interface status.
 ///
 typedef UINT32 MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS;
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NO_ERRORS  0x
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_ERROR  0x0001
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_READ   0x0002
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_WRITE  0x0004
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NOT_AVAILABLE  0x
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NO_ERRORS0x
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_ERROR0x0001
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_READ 0x0002
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_WRITE0x0004
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_INVALID_COMMAND  0x0008
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NOT_AVA

[edk2-devel] [edk2-platforms][PATCH 2/2] ManageabilityPkg/ManageabilityTransportKcsLib: Add debug message of IPMI KCS Completion Code

[Chang, Abner via groups.io]

From: abnchang 

Print out IPMI Completion Code and return additional
transport interface status.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Tinh Nguyen 
---
 .../Common/ManageabilityTransportKcs.h| 18 +
 .../Common/KcsCommon.c| 39 +--
 .../Dxe/ManageabilityTransportKcs.c   |  7 +++-
 3 files changed, 42 insertions(+), 22 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/ManageabilityTransportKcs.h
 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/ManageabilityTransportKcs.h
index 8c6a64416a..166aa8dcde 100644
--- 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/ManageabilityTransportKcs.h
+++ 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/ManageabilityTransportKcs.h
@@ -51,6 +51,7 @@ typedef struct {
 code is the first byte of response
 data.
   @param[in, out] ResponseDataSize  Size of Command Response Data.
+  @param[out] AdditioalStatus   Additional status of this transaction.
 
   @retval EFI_SUCCESS   The command byte stream was
 successfully submit to the device and a
@@ -71,14 +72,15 @@ typedef struct {
 EFI_STATUS
 EFIAPI
 KcsTransportSendCommand (
-  IN  MANAGEABILITY_TRANSPORT_HEADER   TransmitHeader OPTIONAL,
-  IN  UINT16   TransmitHeaderSize,
-  IN  MANAGEABILITY_TRANSPORT_TRAILER  TransmitTrailer OPTIONAL,
-  IN  UINT16   TransmitTrailerSize,
-  IN  UINT8*RequestData OPTIONAL,
-  IN  UINT32   RequestDataSize,
-  OUT UINT8*ResponseData OPTIONAL,
-  IN OUT UINT32*ResponseDataSize OPTIONAL
+  IN  MANAGEABILITY_TRANSPORT_HEADER  TransmitHeader OPTIONAL,
+  IN  UINT16  TransmitHeaderSize,
+  IN  MANAGEABILITY_TRANSPORT_TRAILER TransmitTrailer OPTIONAL,
+  IN  UINT16  TransmitTrailerSize,
+  IN  UINT8   *RequestData OPTIONAL,
+  IN  UINT32  RequestDataSize,
+  OUT UINT8   *ResponseData OPTIONAL,
+  IN  OUT UINT32  *ResponseDataSize OPTIONAL,
+  OUT  MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS  *AdditioalStatus
   );
 
 /**
diff --git 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
index a8c6a674c9..84792311be 100644
--- 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
+++ 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
@@ -392,10 +392,8 @@ KcsTransportRead (
 code is the first byte of response
 data.
   @param[in, out] ResponseDataSize  Size of Command Response Data.
-When IN, it is the expected data size
-of response data.
-When OUT, it is the data size of 
response
-exactly returned.
+  @param[out] AdditioalStatus   Additional status of this transaction.
+
   @retval EFI_SUCCESS   The command byte stream was
 successfully submit to the device and a
 response was successfully received.
@@ -414,20 +412,22 @@ KcsTransportRead (
 EFI_STATUS
 EFIAPI
 KcsTransportSendCommand (
-  IN  MANAGEABILITY_TRANSPORT_HEADER   TransmitHeader OPTIONAL,
-  IN  UINT16   TransmitHeaderSize,
-  IN  MANAGEABILITY_TRANSPORT_TRAILER  TransmitTrailer OPTIONAL,
-  IN  UINT16   TransmitTrailerSize,
-  IN  UINT8*RequestData OPTIONAL,
-  IN  UINT32   RequestDataSize,
-  OUT UINT8*ResponseData OPTIONAL,
-  IN OUT UINT32*ResponseDataSize OPTIONAL
+  IN  MANAGEABILITY_TRANSPORT_HEADER  TransmitHeader OPTIONAL,
+  IN  UINT16  TransmitHeaderSize,
+  IN  MANAGEABILITY_TRANSPORT_TRAILER TransmitTrailer OPTIONAL,
+  IN  UINT16  TransmitTrailerSize,
+  IN  UINT8   *RequestData OPTIONAL,
+  IN  UINT32  RequestDataSize,
+  OUT UINT8   *ResponseData OPTIONAL,
+  IN  OUT UINT32  

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Replace the OVMF-specific SataControllerDxe with the generic one

[Laszlo Ersek]

On 5/8/23 23:52, Pedro Falcato wrote:
> This patch-set replaces the OVMF specific SataControllerDxe with the
> MdeModulePkg/Bus/Pci one. They were both forked from the same code,
> and are code-and-functionality similar. As such, there seems to be no
> need for duplication here.

Man, the *coat-turning* of the MdeModulePkg maintainers is just
staggering here.

When we first wanted to use SataControllerDxe in OvmfPkg, the driver
used to exist in DuetPkg. Clearly we attempted to upstream it to
MdeModulePkg too, and to consume it in OvmfPkg from there. But n,
the argument was that SataControllerDxe was inherently platform
specific, and so every platform was going to need its own.

Do read the first paragraph of commit 12e92a23ada7 ("OvmfPkg: copy
SataControllerDxe from DuetPkg", 2015-09-22):

Edk2 maintainers reached the consensus that SataControllerDxe was
inherently platform specific, for which reason it was not appropriate for
either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use
it, it should either reference it directly from under DuetPkg, or copy it.

Also note the date: September 2015.

And then, less than a year later, Intel introduced a so-called "generic"
SataController driver, in commit fda951df6827 ("MdeModulePkg: add
generic SataController driver.", 2016-08-03). Completely useless
(empty!) commit message of course, as it was usual back then. Splendid
example of pretending ignorance, of falsifying history, and of *not*
reaching out to people to trim their platform code now that "we have
changed our minds". Stay classy, Intel.

(But, I need not tell you, Pedro, this; there's a reason why the Ext4
driver is not under MdeModulePkg/Universal/Disk, alongside UdfDxe; or at
least in edk2, alongside FatPkg. Until Intel doesn't need the driver,
it's not a "generic enough" driver; period.)

If you review "Maintainers.txt" exactly at commit fda951df6827, it gets
funnier. Back then, MdeModulePkg had two maintainers, Feng Tian and Star
Zeng. The patch was authored by Feng, i.e., one of the package
maintainers. The other maintainer (Star) didn't review the patch (based
on the commit message); two other Intel developers did. I see this as a
lack of accountability.

And then for comparison, consider:

- PciSegmentInfoLib (from commit e457c1f65d18),

- BasePciSegmentLibSegmentInfo and DxeRuntimePciSegmentLibSegmentInfo
  instances of PciSegmentLib (from child commit 5c9bb86f171c), which
  consume the above.

These were added to MdePkg in August 2017. And if you check the tree:

- DxeRuntimePciSegmentLibSegmentInfo remains unused *to this day* (even
  in edk2-platforms!),

- BasePciSegmentLibSegmentInfo was first put to use in edk2 nearly three
  years later, in UefiPayloadPkg -- in commit 3900a63e3a1b
  ("UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo
  HOB", 2020-06-24).

So DxeRuntimePciSegmentLibSegmentInfo has been "generic enough" to be in
*MdePkg* for 5+ years without a single open source consumer, and
BasePciSegmentLibSegmentInfo had been generic enough to exist in MdePkg
for ~3 years without a single open-source consumer.

It's difficult to get used to this double standard.

Anyway, end of history lesson.

> First I manually replayed OvmfPkg/SataControllerDxe's patches on top
> of the generic one. Only one seemed to make sense. The second patch
> removes OvmfPkg/SataControllerDxe and replaces it for all platforms
> under OvmfPkg.

bcab71413407 --> 24fee0528c32; OK
81310a62be31 --> your patch#1 in this series (which I wasn't CC'd on,
 apparently)
0b448dd8b27c --> not necessary
5dfba97c4d59 --> missing

I disagree with your assessment that commit 5dfba97c4d59 does not make
sense for the MdeModulePkg driver. If you have a "silent" firmware build
that only enables the DEBUG_ERROR bit in the debug message mask (I'm too
lazy to look up the precise PCD name now), then the driver will
needlessly pollute the error log.

Therefore I suggest porting 5dfba97c4d59 as well.

In turn, 5dfba97c4d59 depends (contextually at least) on commit
379b17965f0f ("OvmfPkg: SataControllerDxe: add cascading error handling
to Start()", 2015-09-22), so you might or might not want to port that
one too.

> Tested by booting in QEMU (Q35 (AHCI) and PC (IDE)).
> More testing from other, alternative platforms is desired, although
> breakage seems unlikely.

Eliminating code duplication is almost always a good thing. Duplicating
code is justified when it alleviates friction across responsibility
boundaries. In this instance, I agree that the one driver should exist
in MdeModulePkg; that's how it always should have been. I'm just shaking
my head as to why Intel foisted this 7+ year detour on us.

I suggest porting 5dfba97c4d59 as well, in v2.

> (+CC Laszlo as the author of the original SataControllerDxe patches)

Thanks for the CC.

Judged from my own emotional reaction, it's quite possible that I'm
learning of the existence of MdeModulePkg/Bus/Pci/SataControllerDxe on

Re: [edk2-devel] [PATCH 2/2] OvmfPkg: Replace the OVMF-specific SataControllerDxe with a generic one

[Laszlo Ersek]

On 5/8/23 23:52, Pedro Falcato wrote:
> Previously, OVMF had forked DuetPkg's SataControllerDxe (see commit
> 12e92a2). However, in commit fda951d a generic SataControllerDxe was
> added to MdeModulePkg/Bus/Pci.
> Since they are most similar (both code-wise and functionally), let's
> unify them and de-duplicate code.
> 
> Tested by booting in QEMU, in both Q35 and PC (to test IDE and AHCI
> functionality).
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc :Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Rebecca Cran 
> Cc: Peter Grehan 
> Cc: Corvin Köhne 
> Cc: Sebastien Boeuf 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Cc: Laszlo Ersek 
> Signed-off-by: Pedro Falcato 
> ---
>  OvmfPkg/AmdSev/AmdSevX64.dsc  |2 +-
>  OvmfPkg/AmdSev/AmdSevX64.fdf  |2 +-
>  OvmfPkg/Bhyve/BhyveX64.dsc|2 +-
>  OvmfPkg/Bhyve/BhyveX64.fdf|2 +-
>  OvmfPkg/CloudHv/CloudHvX64.dsc|2 +-
>  OvmfPkg/CloudHv/CloudHvX64.fdf|2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.fdf  |2 +-
>  OvmfPkg/Microvm/MicrovmX64.dsc|2 +-
>  OvmfPkg/Microvm/MicrovmX64.fdf|2 +-
>  OvmfPkg/OvmfPkgIa32.dsc   |2 +-
>  OvmfPkg/OvmfPkgIa32.fdf   |2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc|2 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf|2 +-
>  OvmfPkg/OvmfPkgX64.dsc|2 +-
>  OvmfPkg/OvmfPkgX64.fdf|2 +-
>  OvmfPkg/OvmfXen.dsc   |2 +-
>  OvmfPkg/OvmfXen.fdf   |2 +-
>  OvmfPkg/SataControllerDxe/ComponentName.c |  170 ---
>  OvmfPkg/SataControllerDxe/SataController.c| 1112 -
>  OvmfPkg/SataControllerDxe/SataController.h|  544 
>  .../SataControllerDxe/SataControllerDxe.inf   |   43 -
>  22 files changed, 18 insertions(+), 1887 deletions(-)
>  delete mode 100644 OvmfPkg/SataControllerDxe/ComponentName.c
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataController.c
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataController.h
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataControllerDxe.inf

Just to make this patch a bit more tractable, I'd suggest splitting it.

First, update only the DSC/FDF files. In particular, if you do that
alongside review/maintainer responsibilities -- that is, for example,
you create a separate FDF+DSC patch for Bhyve and another FDF+DSC patch
for Xen --, then your reviewers will thank you for the effort, as they
won't have to wade through platform DSC+FDF code they don't care about.

Second, removing "OvmfPkg/SataControllerDxe" can be its own patch at the
very end of the series; and that one need not be CC'd to the various
platform maintainers. With smaller / more focused patches,
"GetMaintainer.py" will provide more targeted CC lists.

Thanks!
Laszlo



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

Re: [edk2-devel] [PATCH 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Laszlo Ersek]

On 5/8/23 23:31, Michael Brown wrote:
> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> specification) and so we should never encounter a situation in which
> an interrupt occurs at TPL_HIGH_LEVEL.  The specification also
> restricts usage of TPL_HIGH_LEVEL to the firmware itself.

Great introduction!

Regarding the rest of the commit message, I'd like us to tone it down a
little bit.

Here's why: I'd been used to Microsoft *not* cooperating usefully in
Windows-on-QEMU/KVM situations. But this instance was totally different.
In fact I'm still a bit shocked, in the positive sense. We got a fast
and helpful, to-the-point response. It's a first, considering my own
experience, and it has strongly changed my impression of Microsoft's
Windows team. I'd like us to acknowledge that in the commit message, if
possible.

Mind you, I'm not a native English speaker, so I could be seeing things
(and proposing worse language than the original).

With all that said:

> However, nothing prevents a rogue UEFI application from illegally

I request s/rogue/non-conformant/.

I'd also request "invalidly" rather than "illegally"; the latter has
connotations with the law, and seeing such in a commit message makes me
fidget uncomfortably. I do apologize.

> calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately violating

You are not wrong about "deliberately", but I'd still like us to remove
that word. :)

> the invariant by enabling interrupts via the STI or equivalent
> instruction.  Some versions of the Microsoft Windows bootloader are
> known to do this.
> 
> NestedInterruptTplLib maintains the invariant that interrupts are
> disabled at TPL_HIGH_LEVEL (even when performing the dark art of
> deliberately manipulating the stack so that IRET will return with
> interrupts still disabled), but does not itself rely on external code
> maintaining this invariant.
> 
> Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
> to an error message, to allow rogue UEFI applications such as the

s/rogue/non-conformant/

> Microsoft Windows bootloader to continue to function.

Can we say "particular version of the Microsoft Windows bootloader"?

> 
> Debugged-by: Gerd Hoffmann 
> Debugged-by: Laszlo Ersek 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> Signed-off-by: Michael Brown 
> ---
>  OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c 
> b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
> index e921a09c5599..a91f2d3cb8c7 100644
> --- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
> +++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
> @@ -34,12 +34,27 @@ NestedInterruptRaiseTPL (
>  
>//
>// Raise TPL and assert that we were called from within an interrupt
> -  // handler (i.e. with TPL below TPL_HIGH_LEVEL but with interrupts
> -  // disabled).
> +  // handler (i.e. with interrupts already disabled before raising the
> +  // TPL).
>//
>ASSERT (GetInterruptState () == FALSE);
>InterruptedTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
> -  ASSERT (InterruptedTPL < TPL_HIGH_LEVEL);
> +
> +  //
> +  // At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> +  // specification) and so we should never encounter a situation in
> +  // which InterruptedTPL==TPL_HIGH_LEVEL.  The specification also
> +  // restricts usage of TPL_HIGH_LEVEL to the firmware itself.
> +  //
> +  // However, nothing prevents a rogue UEFI application from illegally
> +  // calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately
> +  // violating the invariant by enabling interrupts via the STI or
> +  // equivalent instruction.  Some versions of the Microsoft Windows
> +  // bootloader are known to do this.
> +  //

Same three requests on the wording: rogue, illegally, deliberately.

(I am happy with "Some versions of"!)

> +  if (InterruptedTPL >= TPL_HIGH_LEVEL) {
> +DEBUG ((DEBUG_ERROR, "Illegal interrupt at TPL_HIGH_LEVEL!\n"));

s/Illegal/Invalid/ please! :)

> +  }
>  
>return InterruptedTPL;
>  }

Thank you for the patch; I do apologize about splitting hairs. The
debugging was difficult, and you *are* working around a bug here -- but
I'd really like our tone of voice to be positive here, simply because of
the stunningly positive attitude I've experienced from Microsoft.

Thanks!
Laszlo



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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Laszlo Ersek]

On 5/8/23 23:31, Michael Brown wrote:
> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> specification) and so we should never encounter a situation in which
> an interrupt occurs at TPL_HIGH_LEVEL. The specification also
> restricts usage of TPL_HIGH_LEVEL to the firmware itself.
> 
> However, nothing prevents a rogue UEFI application from illegally
> calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then deliberately violating
> the invariant by enabling interrupts via the STI or equivalent
> instruction. Some versions of the Microsoft Windows bootloader are
> known to do this.
> 
> NestedInterruptTplLib maintains the invariant that interrupts are
> disabled at TPL_HIGH_LEVEL (even when performing the dark art of
> deliberately manipulating the stack so that IRET will return with
> interrupts still disabled), but does not itself rely on external code
> maintaining this invariant.
> 
> Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
> to an error message, to allow rogue UEFI applications such as the
> Microsoft Windows bootloader to continue to function.
> 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Pawel Polawski 
> Cc: Jiewen Yao 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> 
> Michael Brown (2):
>   OvmfPkg: Clarify invariants for NestedInterruptTplLib
>   OvmfPkg: Relax assertion that interrupts do not occur at
> TPL_HIGH_LEVEL
> 
>  OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
>  1 file changed, 26 insertions(+), 5 deletions(-)
> 

I'm not subscribed to the list, so I don't have a copy of patch#1. I've
checked patch#1 at this URL:

https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html

and I'll comment on it using the cover letter:

I really like that patch, with one stylistic exception: in edk2,
explicit FALSE and TRUE comparisons are not desired. So I suggest:

  ASSERT (!GetInterruptState ());

Twice.

In fact, I *think* that if you run uncrustify with the edk2 config on
the patch, then it will rewrite that code.

Uncrustify normally only complains in CI on github, but you can run it
manually too, after each commit:

(1) Clone and build uncrustify:

https://projec...@dev.azure.com/projectmu/Uncrustify/_git/Uncrustify

(2) After each commit, preferably when your working tree *and* index are
clean, run uncrustify in the edk2 project root, with the following flags:

  -c .pytool/Plugin/UncrustifyCheck/uncrustify.cfg \
  --replace \
  --no-backup \
  --if-changed

The file list can be passed in via stdin ("-F -") or on the uncrustify
command line.

The "file list" is generally the list of *.c and *.h files modified by
the particular commit. Just dumping the entire file list modified by a
commit to uncrustify is not good: uncrustify will happily garble (for
example) *.inf files, and then it will also crash with SEGV.

Thank you!
Laszlo



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

Re: [edk2-devel] [PATCH] ShellPkg: Add a condition to print accurate type0 Bios Size in smbiosview.

[Gao, Zhichao]

Reviewed-by: Zhichao Gao zhichao@intel.com

Thanks,
Zhichao

From: devel@edk2.groups.io  On Behalf Of Nickle Wang via 
groups.io
Sent: Thursday, May 4, 2023 10:37 PM
To: devel@edk2.groups.io; Thejaswani Putta ; Ni, Ray 
; Gao, Zhichao 
Cc: Nick Ramirez 
Subject: Re: [edk2-devel] [PATCH] ShellPkg: Add a condition to print accurate 
type0 Bios Size in smbiosview.


Hi @Ray Ni, @Zhichao Gao,



Could you please help to review this change?



Thanks,

Nickle



> -Original Message-

> From: devel@edk2.groups.io 
> mailto:devel@edk2.groups.io>> On Behalf Of Thejaswani

> Putta via groups.io

> Sent: Friday, April 21, 2023 9:00 AM

> To: devel@edk2.groups.io

> Cc: Ray Ni mailto:ray...@intel.com>>; Zhichao Gao 
> mailto:zhichao@intel.com>>

> Subject: [edk2-devel] [PATCH] ShellPkg: Add a condition to print accurate 
> type0

> Bios Size in smbiosview.

>

> External email: Use caution opening links or attachments

>

>

> As per the SMBIOS spec, in smbios type0 table, if the Bios size is greater 
> than

> 16MB, extended bios size is used to update size information and bios size is 
> set

> to 0xff. when this data is printed by smbiosview, both bios size and extended

> bios size is printed if the smbios version is beyond 3.1, which is incorrect 
> as Bios

> size is set to 0xff when rom size is more than 16MB.

>

> To fix this bug, added a condition to print bios size only when it is not set 
> to 0xff

> or if the smbios version is older than 3.1.

>

> Signed-off-by: Thejaswani Putta mailto:tpu...@nvidia.com>>

> Cc: Ray Ni mailto:ray...@intel.com>>

> Cc: Zhichao Gao mailto:zhichao@intel.com>>

> ---

>  .../Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 4 +++-

>  1 file changed, 3 insertions(+), 1 deletion(-)

>

> diff --git

> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c

> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c

> index 1811cf0c44..5448abaa22 100644

> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c

> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c

> @@ -339,7 +339,9 @@ SmbiosPrintStructure (

>ShellPrintEx (-1, -1, L"BIOS Version: %a\n", LibGetSmbiosString 
> (Struct,

> Struct->Type0->BiosVersion));

>ShellPrintEx (-1, -1, L"BIOS Starting Address Segment: 0x%x\n", Struct-

> >Type0->BiosSegment);

>ShellPrintEx (-1, -1, L"BIOS Release Date: %a\n", LibGetSmbiosString 
> (Struct,

> Struct->Type0->BiosReleaseDate));

> -  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN

> (STR_SMBIOSVIEW_PRINTINFO_BIOS_SIZE), gShellDebug1HiiHandle, 64 *

> (Struct->Type0->BiosSize + 1));

> +  if ((Struct->Type0->BiosSize != 0xFF) || !(AE_SMBIOS_VERSION (0x3, 
> 0x1))) {

> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN

> (STR_SMBIOSVIEW_PRINTINFO_BIOS_SIZE), gShellDebug1HiiHandle, 64 *

> (Struct->Type0->BiosSize + 1));

> +  }

>

>DisplayBiosCharacteristics (ReadUnaligned64 ((UINT64 *)(UINTN)&(Struct-

> >Type0->BiosCharacteristics)), Option);

>

> --

> 2.17.1

>

>

>

>

>





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104357): https://edk2.groups.io/g/devel/message/104357
Mute This Topic: https://groups.io/mt/98439054/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 1/1] OvmfPkg/NestedInterruptTplLib: replace ASSERT() with a warning logged.

[Ard Biesheuvel]

On Mon, 8 May 2023 at 08:46, Laszlo Ersek  wrote:
>
> On 5/6/23 01:57, Ard Biesheuvel wrote:
> > On Sat, 6 May 2023 at 01:27, Michael Brown  wrote:
> >>
> >> On 05/05/2023 19:56, Laszlo Ersek wrote:
> >>> I don't like the patch. For two reasons:
> >>>
> >>> (1) It papers over the actual issue. The problem should be fixed where
> >>> it is, if possible.
> >>
> >> Agreed, but (as you have shown in
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2189136) the bug lies in
> >> Windows code rather than in EDK2 code.  If the goal is to allow these
> >> buggy Windows builds to still be used with OVMF, then the only option is
> >> to paper over the issue.  We should do this only if it can be proven
> >> safe to do so, of course.
> >>
> >>> (2) With the patch applied, NestedInterruptRaiseTPL() can return
> >>> TPL_HIGH_LEVEL (as "InterruptedTPL"). Consequently,
> >>> TimerInterruptHandler() [OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.c]
> >>> may pass TPL_HIGH_LEVEL back to NestedInterruptRestoreTPL(), as
> >>> "InterruptedTPL".
> >>>
> >>> I believe that this in turn may invalidate at least one comment in
> >>> NestedInterruptRestoreTPL():
> >>>
> >>>  //
> >>>  // Call RestoreTPL() to allow event notifications to be
> >>>  // dispatched.  This will implicitly re-enable interrupts.
> >>>  //
> >>>  gBS->RestoreTPL (InterruptedTPL);
> >>>
> >>> Restoring TPL_HIGH_LEVEL does not re-enable interrupts -- nominally 
> >>> anyways.
> >>
> >> I agree that the comment is invalidated, but as far as I can tell the
> >> logic remains safe.
> >>
> >> I will put together a patch to update the comments in
> >> NestedInterruptTplLib to address the possibility of an interrupt
> >> occurring (illegally) at TPL_HIGH_LEVEL.
> >>
> >>> (a) Make LocalApicTimerDxe Xen-specific again. It's only the OVMF Xen
> >>> platform that really *needs* NestedInterruptTplLib. (Don't get me wrong:
> >>> NestedInterruptTplLib is technically correct in all circumstances, but
> >>> in practice it happens to be too strict.)
> >>>
> >>> (b) For the non-Xen OVMF platforms, re-create a LocalApicTimerDxe
> >>> variant that effectively has commits a086f4a63bc0 and a24fbd606125
> >>> reverted. (We should keep 9bf473da4c1d.) This returns us to
> >>> pre-239b50a86370 status -- that is, a timer interrupt handler that (a)
> >>> does not try to be smart about nested interrupts, therefore one that is
> >>> much simpler, and (b) is more tolerant of the Windows / cdboot.efi spec
> >>> violation, (c) is vulnerable to the timer interrupt storm seen on Xen,
> >>> but will never run on Xen. (Only the OVMF Xen platform is supposed to be
> >>> launched on Xen.)
> >>
> >> I'm less keen on this because it reduces the runtime exposure of a very
> >> complex piece of code, and will effectively cause that code to become
> >> unmaintained.
> >>
> >> It's also satisfying (to me) that NestedInterruptTplLib provides a
> >> provable upper bound on stack consumption due to interrupts, which can't
> >> be guaranteed by the simpler pre-239b50a86370 scheme.
> >>
> >> Could we defer judgement until after I've fully reasoned through (and
> >> documented) how NestedInterruptTplLib will work in the presence of
> >> interrupts occurring at TPL_HIGH_LEVEL?
> >>
> >
> > Would it be feasible for our firmware implementation to disable the
> > timer interrupt at the timer end as well?
> >
> > E.g.,
> >
> > RaiseTPL(HIGH)::
> >
> > CLI
> > disarm timer
> >
> >
> > RestoreTPL::
> >
> > 
> > re-arm timer
> > STI
> >
>
> I can be entirely wrong here, but:
>
> - we looked for a solution (or workaround) to the original problem that
> stays within the boundaries of OvmfPkg, so sinking tweaks into the core
> TPL manipulation functions isn't ideal
>
> - regarding the TimerInterruptHandler() function(s) that do live in
> OvmfPkg, there had been tweaks to signaling end-of-interrupt (which I
> understand as sort of equivalent to your suggestion, as unless/until you
> signal EOI, no more interrupts will be *generated*), but those had not
> helped. The EOI was either too early and so we got the unbounded
> nesting, or it was too late, and no interrupts were generated while (for
> example) TPL_CALLBACK code would depend on timers with CheckEvent. See
> bug 4162 -- that was what prompted Michael to revert the EOI placement
> tweak and to implement NestedInterruptLib.
>
> Apologies if there are further interpretations of disarming the timer
> that I'm missing!
>

No, I think you've summed it up. And in any case, it is not OVMF's job
to police what the loader is doing to that extent - we should flag it
as a violation but beyond that, I don't think we should try to
interfere with this non-compliant behavior.


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

Re: [edk2-devel] [PATCH 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Gerd Hoffmann]

  Hi,

> Here's why: I'd been used to Microsoft *not* cooperating usefully in
> Windows-on-QEMU/KVM situations. But this instance was totally different.
> In fact I'm still a bit shocked, in the positive sense. We got a fast
> and helpful, to-the-point response. It's a first, considering my own
> experience, and it has strongly changed my impression of Microsoft's
> Windows team. I'd like us to acknowledge that in the commit message, if
> possible.

And Microsoft saying this is tsc calibration code also gives us a
workaround: When using 'qemu -cpu host,hv-frequencies=on' the windows
installer iso boots just fine, most likely because cdboot.efi queries
the hypervisor for the tsc frequency instead of running the calibration
loop.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104359): https://edk2.groups.io/g/devel/message/104359
Mute This Topic: https://groups.io/mt/98771399/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/3] UefiCpuPkg/SecCore: Migrate page table to permanent memory

[Wu, Jiaxin]

Background:
For arch X64, system will enable the page table in SPI to cover 0-512G range
via CR4.PAE & MSR.LME & CR0.PG & CR3 setting (see ResetVector code). Existing
code doesn't cover the higher address access above 512G before memory-discovered
callback. That will be potential problem if system access the higher address
after the transition from temporary RAM to permanent MEM RAM.

Solution:
This patch is to migrate page table to permanent memory to map entire physical
address space if CR0.PG is set during temporary RAM Done.

Change-Id: I29bdb078ef567ed9455d1328cb007f4f60a617a2
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Zeng Star 
Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Signed-off-by: Jiaxin Wu 
---
 UefiCpuPkg/SecCore/SecCore.inf   |   1 +
 UefiCpuPkg/SecCore/SecCoreNative.inf |   1 +
 UefiCpuPkg/SecCore/SecMain.c | 164 +++
 UefiCpuPkg/SecCore/SecMain.h |   4 +
 4 files changed, 170 insertions(+)

diff --git a/UefiCpuPkg/SecCore/SecCore.inf b/UefiCpuPkg/SecCore/SecCore.inf
index 3758aded3b..cab69b8b97 100644
--- a/UefiCpuPkg/SecCore/SecCore.inf
+++ b/UefiCpuPkg/SecCore/SecCore.inf
@@ -53,10 +53,11 @@
   CpuExceptionHandlerLib
   ReportStatusCodeLib
   PeiServicesLib
   PeiServicesTablePointerLib
   HobLib
+  CpuPageTableLib
 
 [Ppis]
   ## SOMETIMES_CONSUMES
   ## PRODUCES
   gEfiSecPlatformInformationPpiGuid
diff --git a/UefiCpuPkg/SecCore/SecCoreNative.inf 
b/UefiCpuPkg/SecCore/SecCoreNative.inf
index 1ee6ff7d88..fa241cca94 100644
--- a/UefiCpuPkg/SecCore/SecCoreNative.inf
+++ b/UefiCpuPkg/SecCore/SecCoreNative.inf
@@ -50,10 +50,11 @@
   CpuExceptionHandlerLib
   ReportStatusCodeLib
   PeiServicesLib
   PeiServicesTablePointerLib
   HobLib
+  CpuPageTableLib
 
 [Ppis]
   ## SOMETIMES_CONSUMES
   ## PRODUCES
   gEfiSecPlatformInformationPpiGuid
diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
index 95375850ec..d0dc76e804 100644
--- a/UefiCpuPkg/SecCore/SecMain.c
+++ b/UefiCpuPkg/SecCore/SecMain.c
@@ -70,10 +70,159 @@ MigrateGdt (
   AsmWriteGdtr (&Gdtr);
 
   return EFI_SUCCESS;
 }
 
+/**
+  Migrate page table to permanent memory mapping entire physical address space.
+
+  @retval   EFI_SUCCESS   The PageTable was migrated successfully.
+  @retval   EFI_UNSUPPORTED   Unsupport to migrate page table to permanent 
memory if IA-32e Mode not actived.
+  @retval   EFI_OUT_OF_RESOURCES  The PageTable could not be migrated due to 
lack of available memory.
+
+**/
+EFI_STATUS
+MigratePageTable (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  IA32_CR4Cr4;
+  BOOLEAN Page5LevelSupport;
+  UINT32  RegEax;
+  UINT32  RegEdx;
+  BOOLEAN Page1GSupport;
+  PAGING_MODE PagingMode;
+
+  CPUID_VIR_PHY_ADDRESS_SIZE_EAX  VirPhyAddressSize;
+  UINT32  MaxExtendedFunctionId;
+
+  UINTN   PageTable;
+  VOID*Buffer;
+  UINTN   BufferSize;
+  IA32_MAP_ATTRIBUTE  MapAttribute;
+  IA32_MAP_ATTRIBUTE  MapMask;
+
+  VirPhyAddressSize.Uint32 = 0;
+  PageTable= 0;
+  Buffer   = NULL;
+  BufferSize   = 0;
+  MapAttribute.Uint64  = 0;
+  MapMask.Uint64   = MAX_UINT64;
+  MapAttribute.Bits.Present= 1;
+  MapAttribute.Bits.ReadWrite  = 1;
+
+  //
+  // Check CPU runs in 64bit mode or 32bit mode
+  //
+  if (sizeof (UINTN) == sizeof (UINT32)) {
+DEBUG ((DEBUG_WARN, "MigratePageTable: CPU runs in 32bit mode, unsupport 
to migrate page table to permanent memory.\n"));
+ASSERT (TRUE);
+return EFI_UNSUPPORTED;
+  }
+
+  //
+  // Check Page5Level Support or not.
+  //
+  Cr4.UintN = AsmReadCr4 ();
+  Page5LevelSupport = (Cr4.Bits.LA57 ? TRUE : FALSE);
+
+  //
+  // Check Page1G Support or not.
+  //
+  Page1GSupport = FALSE;
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);
+  if (RegEax >= CPUID_EXTENDED_CPU_SIG) {
+AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, &RegEdx);
+if ((RegEdx & BIT26) != 0) {
+  Page1GSupport = TRUE;
+}
+  }
+
+  //
+  // Decide Paging Mode according Page5LevelSupport & Page1GSupport.
+  //
+  PagingMode = Paging5Level1GB;
+  if (Page5LevelSupport && !Page1GSupport) {
+PagingMode = Paging5Level;
+  } else if (!Page5LevelSupport && Page1GSupport) {
+PagingMode = Paging4Level1GB;
+  } else if (!Page5LevelSupport && !Page1GSupport) {
+PagingMode = Paging4Level;
+  }
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: PagingMode = 0x%lx\n", (UINTN) 
PagingMode));
+
+  //
+  // Get Maximum Physical Address Bits
+  // Get the number of address lines; Maximum Physical Address is 
2^PhysicalAddressBits - 1.
+  // If CPUID does not supported, then use a max value of 36 as per SDM 3A, 
4.1.4.
+  //
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, &MaxExten

[edk2-devel] [PATCH v1 2/3] UefiCpuPkg/CpuMpPei: Enable PAE page table if CR0.PG is not set

[Wu, Jiaxin]

Some security features depends on the page table enabling. So, This patch
is to enable the page table if page table has not been enabled during the
transition from Temporary RAM to Permanent RAM.

Note: If page table is not enabled before this point, which means the system
IA-32e Mode is not activated. Because on Intel 64 processors, IA-32e Mode
operation requires physical address extensions with 4 or 5 levels of enhanced
paging structures (see Section 4.5, "4 - Level Paging and 5 -Level Paging"
and Section 9.8, "Initializing IA-32e Mode"). So, just enable PAE page table
if CR0.PG is not set.

Change-Id: Ibfbfdace1fe7e29ab94463629d8d2f539a43f1b9
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Zeng Star 
Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Signed-off-by: Jiaxin Wu 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   1 +
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   1 +
 UefiCpuPkg/CpuMpPei/CpuPaging.c  | 228 +--
 3 files changed, 102 insertions(+), 128 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
index 0649c48d14..1b9a94e18f 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
@@ -26,10 +26,11 @@
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 extern EFI_PEI_PPI_DESCRIPTOR  mPeiCpuMpPpiDesc;
 
 /**
   This service retrieves the number of logical processor in the platform
diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
index 7444bdb968..865be5627e 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
@@ -44,10 +44,11 @@
   CpuExceptionHandlerLib
   MpInitLib
   BaseMemoryLib
   CpuLib
   MemoryAllocationLib
+  CpuPageTableLib
 
 [Guids]
   gEdkiiMigratedFvInfoGuid ## 
SOMETIMES_CONSUMES ## HOB
 
 [Ppis]
diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c b/UefiCpuPkg/CpuMpPei/CpuPaging.c
index a471f089c8..6c113051fe 100644
--- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
+++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
@@ -115,42 +115,10 @@ AllocatePageTableMemory (
   }
 
   return Address;
 }
 
-/**
-  Get the address width supported by current processor.
-
-  @retval 32  If processor is in 32-bit mode.
-  @retval 36-48   If processor is in 64-bit mode.
-
-**/
-UINTN
-GetPhysicalAddressWidth (
-  VOID
-  )
-{
-  UINT32  RegEax;
-
-  if (sizeof (UINTN) == 4) {
-return 32;
-  }
-
-  AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);
-  if (RegEax >= CPUID_VIR_PHY_ADDRESS_SIZE) {
-AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, &RegEax, NULL, NULL, NULL);
-RegEax &= 0xFF;
-if (RegEax > 48) {
-  return 48;
-}
-
-return (UINTN)RegEax;
-  }
-
-  return 36;
-}
-
 /**
   Get the type of top level page table.
 
   @retval Page512G  PML4 paging.
   @retval Page1GPAE paging.
@@ -381,120 +349,93 @@ ConvertMemoryPageAttributes (
 
   return RETURN_SUCCESS;
 }
 
 /**
-  Get maximum size of page memory supported by current processor.
-
-  @param[in]   TopLevelType The type of top level page entry.
+  Enable PAE Page Table.
 
-  @retval Page1G If processor supports 1G page and PML4.
-  @retval Page2M For all other situations.
+  @retval   EFI_SUCCESS   The PAE Page Table was enabled successfully.
+  @retval   EFI_OUT_OF_RESOURCES  The PAE Page Table could not be enabled due 
to lack of available memory.
 
 **/
-PAGE_ATTRIBUTE
-GetMaxMemoryPage (
-  IN  PAGE_ATTRIBUTE  TopLevelType
-  )
-{
-  UINT32  RegEax;
-  UINT32  RegEdx;
-
-  if (TopLevelType == Page512G) {
-AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);
-if (RegEax >= CPUID_EXTENDED_CPU_SIG) {
-  AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, &RegEdx);
-  if ((RegEdx & BIT26) != 0) {
-return Page1G;
-  }
-}
-  }
-
-  return Page2M;
-}
-
-/**
-  Create PML4 or PAE page table.
-
-  @return The address of page table.
-
-**/
-UINTN
-CreatePageTable (
+EFI_STATUS
+EnablePaePageTable (
   VOID
   )
 {
-  RETURN_STATUS Status;
-  UINTN PhysicalAddressBits;
-  UINTN NumberOfEntries;
-  PAGE_ATTRIBUTETopLevelPageAttr;
-  UINTN PageTable;
-  PAGE_ATTRIBUTEMaxMemoryPage;
-  UINTN Index;
-  UINT64AddressEncMask;
-  UINT64*PageEntry;
-  EFI_PHYSICAL_ADDRESS  PhysicalAddress;
-
-  TopLevelPageAttr= (PAGE_ATTRIBUTE)GetPageTableTopLevelType ();
-  PhysicalAddressBits = GetPhysicalAddressWidth ();
-  NumberOfEntries = (UINTN)1 << (PhysicalAddressBits -
- 
mPageAttributeTable[TopLevelPageAttr].AddressBitOffset);
+  EFI_STATUSStatus;
+  PAGING_MODE   PagingMode;
+
+  UINTN PageTable;
+  VOID  *Buffer;
+  UINTN BufferSize;
+  IA32_MAP_ATTRIBUTEMapAttribute;
+  IA32_MAP_ATTRIBUTEMapMask;
+
+  PagingMode= PagingPae;
+  P

[edk2-devel] [PATCH v1 0/3] Target to enable paging from temporary RAM Done

[Wu, Jiaxin]

For arch X64, system will enable the page table in SPI to cover 0-512G
range via CR4.PAE & MSR.LME & CR0.PG & CR3 setting. Existing code doesn't
cover the higher address access above 512G before memory-discovered
callback. This series patches provide the solution to enable paging from
temporary RAM Done.

Jiaxin Wu (3):
  UefiCpuPkg/SecCore: Migrate page table to permanent memory
  UefiCpuPkg/CpuMpPei: Enable PAE page table if CR0.PG is not set
  MdeModulePkg/DxeIpl: Align Page table Level setting with previous
level.

 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c |  39 ++--
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   1 +
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   1 +
 UefiCpuPkg/CpuMpPei/CpuPaging.c  | 228 ++-
 UefiCpuPkg/SecCore/SecCore.inf   |   1 +
 UefiCpuPkg/SecCore/SecCoreNative.inf |   1 +
 UefiCpuPkg/SecCore/SecMain.c | 164 
 UefiCpuPkg/SecCore/SecMain.h |   4 +
 8 files changed, 299 insertions(+), 140 deletions(-)

-- 
2.16.2.windows.1



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

[edk2-devel] [PATCH v1 3/3] MdeModulePkg/DxeIpl: Align Page table Level setting with previous level.

[Wu, Jiaxin]

System paging 5 level enabled or not can be checked via CR4.LA57, system
preferred Page table Level (PcdUse5LevelPageTable) must align
with previous level for X64 mode.

This patch is to do the wise check:
If X64, Page table Level setting in PcdUse5LevelPageTable must align with
previous level.
If IA32, Page table Level is decided by PcdUse5LevelPageTable and feature
capability.

Change-Id: Ia7f7e365c7354cc49f971209bfcbc5af5aded062
Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Zeng Star 
Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 39 
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 18b121d768..301e200cd8 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -737,22 +737,37 @@ CreateIdentityMappingPageTables (
 } else {
   PhysicalAddressBits = 36;
 }
   }
 
-  Page5LevelSupport = FALSE;
-  if (PcdGetBool (PcdUse5LevelPageTable)) {
-AsmCpuidEx (
-  CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS,
-  CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO,
-  NULL,
-  NULL,
-  &EcxFlags.Uint32,
-  NULL
-  );
-if (EcxFlags.Bits.FiveLevelPage != 0) {
-  Page5LevelSupport = TRUE;
+  //
+  // Check run in X64 or IA32
+  //
+  if (sizeof (UINTN) == sizeof (UINT64)) {
+//
+// If X64, Page table Level must align with previous level.
+//
+Cr4.UintN = AsmReadCr4 ();
+Page5LevelSupport = Cr4.Bits.LA57 ? TRUE : FALSE;
+ASSERT (PcdGetBool (PcdUse5LevelPageTable) == Page5LevelSupport);
+  } else {
+//
+// If IA32, Page table Level is decided by PCD and feature capbility.
+//
+Page5LevelSupport = FALSE;
+if (PcdGetBool (PcdUse5LevelPageTable)) {
+  AsmCpuidEx (
+CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS,
+CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO,
+NULL,
+NULL,
+&EcxFlags.Uint32,
+NULL
+);
+  if (EcxFlags.Bits.FiveLevelPage != 0) {
+Page5LevelSupport = TRUE;
+  }
 }
   }
 
   DEBUG ((DEBUG_INFO, "AddressBits=%u 5LevelPaging=%u 1GPage=%u\n", 
PhysicalAddressBits, Page5LevelSupport, Page1GSupport));
 
-- 
2.16.2.windows.1



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

Re: [edk2-devel] [PATCH 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

On 09/05/2023 09:35, Laszlo Ersek wrote:

Thank you for the patch; I do apologize about splitting hairs. The
debugging was difficult, and you *are* working around a bug here -- but
I'd really like our tone of voice to be positive here, simply because of
the stunningly positive attitude I've experienced from Microsoft.


No problem.  Patch v2 to follow.

Michael



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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

On 09/05/2023 09:43, Laszlo Ersek wrote:

I'm not subscribed to the list, so I don't have a copy of patch#1. I've
checked patch#1 at this URL:

https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html

and I'll comment on it using the cover letter:

I really like that patch, with one stylistic exception: in edk2,
explicit FALSE and TRUE comparisons are not desired. So I suggest:

   ASSERT (!GetInterruptState ());

Twice.

In fact, I *think* that if you run uncrustify with the edk2 config on
the patch, then it will rewrite that code.


I built and ran uncrustify with the edk2 config but it did not modify 
the code.  (I did check that it would fix other deliberate errors such 
as extra whitespace, so I don't think this was an error in my setup.)


I will send through v2 with the explicit "== FALSE" still present, for 
consistency with the rest of the code in that file.  (I think I vaguely 
remember someone asking me to add the explicit comparisons when I first 
submitted the code.)  I'm happy for there to be a follow up patch to 
change the coding style to remove all of the explicit boolean 
comparisons, if that is what is wanted.


Thanks,

Michael



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

[edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.

However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction. Some
versions of the Microsoft Windows bootloader are known to do this.

NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.

Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Cc: Laszlo Ersek 
Cc: Gerd Hoffmann 
Cc: Oliver Steffen 
Cc: Pawel Polawski 
Cc: Jiewen Yao 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Michael Brown (2):
  OvmfPkg: Clarify invariants for NestedInterruptTplLib
  OvmfPkg: Relax assertion that interrupts do not occur at
TPL_HIGH_LEVEL

 OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
 1 file changed, 26 insertions(+), 5 deletions(-)

-- 
2.39.0



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

[edk2-devel] [PATCH v2 1/2] OvmfPkg: Clarify invariants for NestedInterruptTplLib

[Michael Brown]

NestedInterruptTplLib relies on CPU interrupts being disabled to
guarantee exclusive (and hence atomic) access to the shared state in
IsrState.  Nothing in the calling interrupt handler should have
re-enabled interrupts before calling NestedInterruptRestoreTPL(), and
the loop in NestedInterruptRestoreTPL() itself maintains the invariant
that interrupts are disabled at the start of each iteration.

Add assertions to clarify this invariant, and expand the comments
around the calls to RestoreTPL() and DisableInterrupts() to clarify
the expectations around enabling and disabling interrupts.

Signed-off-by: Michael Brown 
---
 OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c 
b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
index e19d98878eb7..e921a09c5599 100644
--- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
+++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
@@ -104,6 +104,7 @@ NestedInterruptRestoreTPL (
   // defer our call to RestoreTPL() to the in-progress outer instance
   // of the same interrupt handler.
   //
+  ASSERT (GetInterruptState () == FALSE);
   if (InterruptedTPL == IsrState->InProgressRestoreTPL) {
 //
 // Trigger outer instance of this interrupt handler to perform the
@@ -153,6 +154,7 @@ NestedInterruptRestoreTPL (
 //
 // Check shared state loop invariants.
 //
+ASSERT (GetInterruptState () == FALSE);
 ASSERT (IsrState->InProgressRestoreTPL < InterruptedTPL);
 ASSERT (IsrState->DeferredRestoreTPL == FALSE);
 
@@ -167,13 +169,17 @@ NestedInterruptRestoreTPL (
 
 //
 // Call RestoreTPL() to allow event notifications to be
-// dispatched.  This will implicitly re-enable interrupts.
+// dispatched.  This will implicitly re-enable interrupts (if
+// InterruptedTPL is below TPL_HIGH_LEVEL), even though we are
+// still inside the interrupt handler.
 //
 gBS->RestoreTPL (InterruptedTPL);
 
 //
 // Re-disable interrupts after the call to RestoreTPL() to ensure
-// that we have exclusive access to the shared state.
+// that we have exclusive access to the shared state.  Interrupts
+// will be re-enabled by the IRET or equivalent instruction when
+// we subsequently return from the interrupt handler.
 //
 DisableInterrupts ();
 
-- 
2.39.0



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

[edk2-devel] [PATCH v2 2/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL.  The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.

However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction.  Some
versions of the Microsoft Windows bootloader are known to do this.

NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.

Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.

Debugged-by: Gerd Hoffmann 
Debugged-by: Laszlo Ersek 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown 
---
 OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c 
b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
index e921a09c5599..d56c12a44529 100644
--- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
+++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c
@@ -34,12 +34,27 @@ NestedInterruptRaiseTPL (
 
   //
   // Raise TPL and assert that we were called from within an interrupt
-  // handler (i.e. with TPL below TPL_HIGH_LEVEL but with interrupts
-  // disabled).
+  // handler (i.e. with interrupts already disabled before raising the
+  // TPL).
   //
   ASSERT (GetInterruptState () == FALSE);
   InterruptedTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
-  ASSERT (InterruptedTPL < TPL_HIGH_LEVEL);
+
+  //
+  // At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
+  // specification) and so we should never encounter a situation in
+  // which InterruptedTPL==TPL_HIGH_LEVEL.  The specification also
+  // restricts usage of TPL_HIGH_LEVEL to the firmware itself.
+  //
+  // However, nothing actually prevents a UEFI application from
+  // invalidly calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then
+  // violating the invariant by enabling interrupts via the STI or
+  // equivalent instruction.  Some versions of the Microsoft Windows
+  // bootloader are known to do this.
+  //
+  if (InterruptedTPL >= TPL_HIGH_LEVEL) {
+DEBUG ((DEBUG_ERROR, "ERROR: Interrupts enabled at TPL_HIGH_LEVEL!\n"));
+  }
 
   return InterruptedTPL;
 }
-- 
2.39.0



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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Laszlo Ersek]

On 5/9/23 14:08, Michael Brown wrote:
> On 09/05/2023 09:43, Laszlo Ersek wrote:
>> I'm not subscribed to the list, so I don't have a copy of patch#1. I've
>> checked patch#1 at this URL:
>>
>> https://listman.redhat.com/archives/edk2-devel-archive/2023-May/063591.html
>>
>> and I'll comment on it using the cover letter:
>>
>> I really like that patch, with one stylistic exception: in edk2,
>> explicit FALSE and TRUE comparisons are not desired. So I suggest:
>>
>>    ASSERT (!GetInterruptState ());
>>
>> Twice.
>>
>> In fact, I *think* that if you run uncrustify with the edk2 config on
>> the patch, then it will rewrite that code.
> 
> I built and ran uncrustify with the edk2 config but it did not modify
> the code.  (I did check that it would fix other deliberate errors such
> as extra whitespace, so I don't think this was an error in my setup.)
> 
> I will send through v2 with the explicit "== FALSE" still present, for
> consistency with the rest of the code in that file.  (I think I vaguely
> remember someone asking me to add the explicit comparisons when I first
> submitted the code.)

Wow, I totally missed the preexistent comparisons. You are right to stay
consistent.

(I do disagree with the preexistent comparisons as well, but that's
indeed a different discussion.)

Thanks!
Laszlo

> I'm happy for there to be a follow up patch to
> change the coding style to remove all of the explicit boolean
> comparisons, if that is what is wanted.
> 
> Thanks,
> 
> Michael
> 



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

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Laszlo Ersek]

On 5/9/23 14:09, Michael Brown wrote:
> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> specification) and so we should never encounter a situation in which
> an interrupt occurs at TPL_HIGH_LEVEL. The specification also
> restricts usage of TPL_HIGH_LEVEL to the firmware itself.
> 
> However, nothing actually prevents a UEFI application from calling
> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
> enabling interrupts via the STI or equivalent instruction. Some
> versions of the Microsoft Windows bootloader are known to do this.
> 
> NestedInterruptTplLib maintains the invariant that interrupts are
> disabled at TPL_HIGH_LEVEL (even when performing the dark art of
> deliberately manipulating the stack so that IRET will return with
> interrupts still disabled), but does not itself rely on external code
> maintaining this invariant.
> 
> Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
> to an error message, to allow UEFI applications such as these versions
> of the Microsoft Windows bootloader to continue to function.
> 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Pawel Polawski 
> Cc: Jiewen Yao 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> 
> Michael Brown (2):
>   OvmfPkg: Clarify invariants for NestedInterruptTplLib
>   OvmfPkg: Relax assertion that interrupts do not occur at
> TPL_HIGH_LEVEL
> 
>  OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
>  1 file changed, 26 insertions(+), 5 deletions(-)
> 

series
Acked-by: Laszlo Ersek 

Many thanks,
Laszlo



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

Re: [edk2-devel] [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms

[Yao, Jiewen]

Is this defined in UEFI spec? or approved in future UEFI spec?

> -Original Message-
> From: pierre.gond...@arm.com 
> Sent: Tuesday, May 9, 2023 3:41 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Yao,
> Jiewen ; Wang, Jian J ; Ard
> Biesheuvel ; Sami Mujawar
> ; Jose Marinho ;
> Samer El-Haj-Mahmoud 
> Subject: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms
> 
> From: Pierre Gondois 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
> 
> The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
> implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
> To allow the RngDxe to detect when such implementation is used,
> a GetRngGuid() function is added in a following patch.
> 
> Prepare GetRngGuid() return values and add GUIDs describing
> Rng algorithms:
> - gEfiRngAlgorithmArmRndr
> to describe a Rng algorithm accessed through Arm's RNDR instruction.
> [1] states that the implementation of this algorithm should be
> compliant to NIST SP900-80. The compliance is not guaranteed.
> - gEfiRngAlgorithmUnSafe
> to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
> 
> [1] Arm Architecture Reference Manual Armv8, for A-profile architecture
> sK12.1 'Properties of the generated random number'
> 
> Signed-off-by: Pierre Gondois 
> ---
>  MdePkg/Include/Protocol/Rng.h | 20 
>  MdePkg/MdePkg.dec |  2 ++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/MdePkg/Include/Protocol/Rng.h
> b/MdePkg/Include/Protocol/Rng.h
> index baf425587b3c..dfdaf36e41dc 100644
> --- a/MdePkg/Include/Protocol/Rng.h
> +++ b/MdePkg/Include/Protocol/Rng.h
> @@ -67,6 +67,24 @@ typedef EFI_GUID EFI_RNG_ALGORITHM;
>{ \
>  0xe43176d7, 0xb6e8, 0x4827, {0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85,
> 0x61 } \
>}
> +///
> +/// The Arm Architecture states the RNDR that the DRBG algorithm should
> be compliant
> +/// with NIST SP800-90A, while not mandating a particular algorithm, so as
> to be
> +/// inclusive of different geographies.
> +///
> +#define EFI_RNG_ALGORITHM_ARM_RNDR \
> +  { \
> +0x43d2fde3, 0x9d4e, 0x4d79,  {0x02, 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08,
> 0x41} \
> +  }
> +///
> +/// The implementation of a Random Number Generator might be unsafe,
> when using
> +/// a dummy implementation for instance. Allow identifying such
> implementation
> +/// with this GUID.
> +///
> +#define EFI_RNG_ALGORITHM_UNSAFE \
> +  { \
> +0x869f728c, 0x409d, 0x4ab4, {0xac, 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3,
> 0xf4 } \
> +  }
> 
>  /**
>Returns information about the random number generation implementation.
> @@ -146,5 +164,7 @@ extern EFI_GUID
> gEfiRngAlgorithmSp80090Ctr256Guid;
>  extern EFI_GUID  gEfiRngAlgorithmX9313DesGuid;
>  extern EFI_GUID  gEfiRngAlgorithmX931AesGuid;
>  extern EFI_GUID  gEfiRngAlgorithmRaw;
> +extern EFI_GUID  gEfiRngAlgorithmArmRndr;
> +extern EFI_GUID  gEfiRngAlgorithmUnSafe;
> 
>  #endif
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index 0ecfad5795e4..754085eaa55b 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -633,6 +633,8 @@ [Guids]
>gEfiRngAlgorithmX9313DesGuid   = { 0x63c4785a, 0xca34, 0x4012, {0xa3,
> 0xc8, 0x0b, 0x6a, 0x32, 0x4f, 0x55, 0x46 }}
>gEfiRngAlgorithmX931AesGuid= { 0xacd03321, 0x777e, 0x4d3d, {0xb1,
> 0xc8, 0x20, 0xcf, 0xd8, 0x88, 0x20, 0xc9 }}
>gEfiRngAlgorithmRaw= { 0xe43176d7, 0xb6e8, 0x4827, {0xb7,
> 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85, 0x61 }}
> +  gEfiRngAlgorithmArmRndr= { 0x43d2fde3, 0x9d4e, 0x4d79, {0x02,
> 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08, 0x41 }}
> +  gEfiRngAlgorithmUnSafe = { 0x869f728c, 0x409d, 0x4ab4, {0xac,
> 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3, 0xf4 }}
> 
>## Include/Protocol/AdapterInformation.h
>gEfiAdapterInfoMediaStateGuid   = { 0xD7C74207, 0xA831, 0x4A26,
> {0xB1, 0xF5, 0xD1, 0x93, 0x06, 0x5C, 0xE8, 0xB6 }}
> --
> 2.25.1



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

Re: [edk2-devel] [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms

[Samer El-Haj-Mahmoud]

Hi Jiewen,

There is an open ECR for UEFI spec review: 
https://bugzilla.tianocore.org/show_bug.cgi?id=4441. These patches can wait on 
the list until the ECR is reviewed by UEFI Forum and the decision is documented 
in the BZ. If approved, then the code patches should be able to proceed.

Thanks,
--Samer



> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, May 9, 2023 9:46 AM
> To: Pierre Gondois ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Wang,
> Jian J ; Ard Biesheuvel ;
> Sami Mujawar ; Jose Marinho
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: RE: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms
>
> Is this defined in UEFI spec? or approved in future UEFI spec?
>
> > -Original Message-
> > From: pierre.gond...@arm.com 
> > Sent: Tuesday, May 9, 2023 3:41 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ; Yao,
> > Jiewen ; Wang, Jian J ; Ard
> > Biesheuvel ; Sami Mujawar
> > ; Jose Marinho ;
> > Samer El-Haj-Mahmoud 
> > Subject: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms
> >
> > From: Pierre Gondois 
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
> >
> > The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
> > implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
> > To allow the RngDxe to detect when such implementation is used,
> > a GetRngGuid() function is added in a following patch.
> >
> > Prepare GetRngGuid() return values and add GUIDs describing
> > Rng algorithms:
> > - gEfiRngAlgorithmArmRndr
> > to describe a Rng algorithm accessed through Arm's RNDR instruction.
> > [1] states that the implementation of this algorithm should be
> > compliant to NIST SP900-80. The compliance is not guaranteed.
> > - gEfiRngAlgorithmUnSafe
> > to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
> >
> > [1] Arm Architecture Reference Manual Armv8, for A-profile architecture
> > sK12.1 'Properties of the generated random number'
> >
> > Signed-off-by: Pierre Gondois 
> > ---
> >  MdePkg/Include/Protocol/Rng.h | 20 
> >  MdePkg/MdePkg.dec |  2 ++
> >  2 files changed, 22 insertions(+)
> >
> > diff --git a/MdePkg/Include/Protocol/Rng.h
> > b/MdePkg/Include/Protocol/Rng.h
> > index baf425587b3c..dfdaf36e41dc 100644
> > --- a/MdePkg/Include/Protocol/Rng.h
> > +++ b/MdePkg/Include/Protocol/Rng.h
> > @@ -67,6 +67,24 @@ typedef EFI_GUID EFI_RNG_ALGORITHM;
> >{ \
> >  0xe43176d7, 0xb6e8, 0x4827, {0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85,
> > 0x61 } \
> >}
> > +///
> > +/// The Arm Architecture states the RNDR that the DRBG algorithm should
> > be compliant
> > +/// with NIST SP800-90A, while not mandating a particular algorithm, so as
> > to be
> > +/// inclusive of different geographies.
> > +///
> > +#define EFI_RNG_ALGORITHM_ARM_RNDR \
> > +  { \
> > +0x43d2fde3, 0x9d4e, 0x4d79,  {0x02, 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08,
> > 0x41} \
> > +  }
> > +///
> > +/// The implementation of a Random Number Generator might be unsafe,
> > when using
> > +/// a dummy implementation for instance. Allow identifying such
> > implementation
> > +/// with this GUID.
> > +///
> > +#define EFI_RNG_ALGORITHM_UNSAFE \
> > +  { \
> > +0x869f728c, 0x409d, 0x4ab4, {0xac, 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3,
> > 0xf4 } \
> > +  }
> >
> >  /**
> >Returns information about the random number generation implementation.
> > @@ -146,5 +164,7 @@ extern EFI_GUID
> > gEfiRngAlgorithmSp80090Ctr256Guid;
> >  extern EFI_GUID  gEfiRngAlgorithmX9313DesGuid;
> >  extern EFI_GUID  gEfiRngAlgorithmX931AesGuid;
> >  extern EFI_GUID  gEfiRngAlgorithmRaw;
> > +extern EFI_GUID  gEfiRngAlgorithmArmRndr;
> > +extern EFI_GUID  gEfiRngAlgorithmUnSafe;
> >
> >  #endif
> > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > index 0ecfad5795e4..754085eaa55b 100644
> > --- a/MdePkg/MdePkg.dec
> > +++ b/MdePkg/MdePkg.dec
> > @@ -633,6 +633,8 @@ [Guids]
> >gEfiRngAlgorithmX9313DesGuid   = { 0x63c4785a, 0xca34, 0x4012, {0xa3,
> > 0xc8, 0x0b, 0x6a, 0x32, 0x4f, 0x55, 0x46 }}
> >gEfiRngAlgorithmX931AesGuid= { 0xacd03321, 0x777e, 0x4d3d, {0xb1,
> > 0xc8, 0x20, 0xcf, 0xd8, 0x88, 0x20, 0xc9 }}
> >gEfiRngAlgorithmRaw= { 0xe43176d7, 0xb6e8, 0x4827, {0xb7,
> > 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85, 0x61 }}
> > +  gEfiRngAlgorithmArmRndr= { 0x43d2fde3, 0x9d4e, 0x4d79, {0x02,
> > 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08, 0x41 }}
> > +  gEfiRngAlgorithmUnSafe = { 0x869f728c, 0x409d, 0x4ab4, {0xac,
> > 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3, 0xf4 }}
> >
> >## Include/Protocol/AdapterInformation.h
> >gEfiAdapterInfoMediaStateGuid   = { 0xD7C74207, 0xA831, 0x4A26,
> > {0xB1, 0xF5, 0xD1, 0x93, 0x06, 0x5C, 0xE8, 0xB6 }}
> > --
> > 2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not

Re: [edk2-devel] [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms

[Yao, Jiewen]

Got it. Before that, I believe you can add the extension in MdeModulePkg or 
SecurityPkg.


> -Original Message-
> From: Samer El-Haj-Mahmoud 
> Sent: Tuesday, May 9, 2023 9:50 PM
> To: Yao, Jiewen ; Pierre Gondois
> ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> Wang, Jian J ; Ard Biesheuvel
> ; Sami Mujawar ;
> Jose Marinho ; Samer El-Haj-Mahmoud
> 
> Subject: RE: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng
> algorithms
> 
> Hi Jiewen,
> 
> There is an open ECR for UEFI spec review:
> https://bugzilla.tianocore.org/show_bug.cgi?id=4441. These patches can
> wait on the list until the ECR is reviewed by UEFI Forum and the decision is
> documented in the BZ. If approved, then the code patches should be able to
> proceed.
> 
> Thanks,
> --Samer
> 
> 
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Tuesday, May 9, 2023 9:46 AM
> > To: Pierre Gondois ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Wang,
> > Jian J ; Ard Biesheuvel
> ;
> > Sami Mujawar ; Jose Marinho
> > ; Samer El-Haj-Mahmoud  > mahm...@arm.com>
> > Subject: RE: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng
> algorithms
> >
> > Is this defined in UEFI spec? or approved in future UEFI spec?
> >
> > > -Original Message-
> > > From: pierre.gond...@arm.com 
> > > Sent: Tuesday, May 9, 2023 3:41 PM
> > > To: devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Gao, Liming
> > > ; Liu, Zhiguang ;
> Yao,
> > > Jiewen ; Wang, Jian J ;
> Ard
> > > Biesheuvel ; Sami Mujawar
> > > ; Jose Marinho ;
> > > Samer El-Haj-Mahmoud 
> > > Subject: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng
> algorithms
> > >
> > > From: Pierre Gondois 
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
> > >
> > > The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
> > > implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
> > > To allow the RngDxe to detect when such implementation is used,
> > > a GetRngGuid() function is added in a following patch.
> > >
> > > Prepare GetRngGuid() return values and add GUIDs describing
> > > Rng algorithms:
> > > - gEfiRngAlgorithmArmRndr
> > > to describe a Rng algorithm accessed through Arm's RNDR instruction.
> > > [1] states that the implementation of this algorithm should be
> > > compliant to NIST SP900-80. The compliance is not guaranteed.
> > > - gEfiRngAlgorithmUnSafe
> > > to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
> > >
> > > [1] Arm Architecture Reference Manual Armv8, for A-profile architecture
> > > sK12.1 'Properties of the generated random number'
> > >
> > > Signed-off-by: Pierre Gondois 
> > > ---
> > >  MdePkg/Include/Protocol/Rng.h | 20 
> > >  MdePkg/MdePkg.dec |  2 ++
> > >  2 files changed, 22 insertions(+)
> > >
> > > diff --git a/MdePkg/Include/Protocol/Rng.h
> > > b/MdePkg/Include/Protocol/Rng.h
> > > index baf425587b3c..dfdaf36e41dc 100644
> > > --- a/MdePkg/Include/Protocol/Rng.h
> > > +++ b/MdePkg/Include/Protocol/Rng.h
> > > @@ -67,6 +67,24 @@ typedef EFI_GUID EFI_RNG_ALGORITHM;
> > >{ \
> > >  0xe43176d7, 0xb6e8, 0x4827, {0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6,
> 0x85,
> > > 0x61 } \
> > >}
> > > +///
> > > +/// The Arm Architecture states the RNDR that the DRBG algorithm
> should
> > > be compliant
> > > +/// with NIST SP800-90A, while not mandating a particular algorithm, so
> as
> > > to be
> > > +/// inclusive of different geographies.
> > > +///
> > > +#define EFI_RNG_ALGORITHM_ARM_RNDR \
> > > +  { \
> > > +0x43d2fde3, 0x9d4e, 0x4d79,  {0x02, 0x96, 0xa8, 0x9b, 0xca, 0x78,
> 0x08,
> > > 0x41} \
> > > +  }
> > > +///
> > > +/// The implementation of a Random Number Generator might be
> unsafe,
> > > when using
> > > +/// a dummy implementation for instance. Allow identifying such
> > > implementation
> > > +/// with this GUID.
> > > +///
> > > +#define EFI_RNG_ALGORITHM_UNSAFE \
> > > +  { \
> > > +0x869f728c, 0x409d, 0x4ab4, {0xac, 0x03, 0x71, 0xd3, 0x09, 0xc1,
> 0xb3,
> > > 0xf4 } \
> > > +  }
> > >
> > >  /**
> > >Returns information about the random number generation
> implementation.
> > > @@ -146,5 +164,7 @@ extern EFI_GUID
> > > gEfiRngAlgorithmSp80090Ctr256Guid;
> > >  extern EFI_GUID  gEfiRngAlgorithmX9313DesGuid;
> > >  extern EFI_GUID  gEfiRngAlgorithmX931AesGuid;
> > >  extern EFI_GUID  gEfiRngAlgorithmRaw;
> > > +extern EFI_GUID  gEfiRngAlgorithmArmRndr;
> > > +extern EFI_GUID  gEfiRngAlgorithmUnSafe;
> > >
> > >  #endif
> > > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > index 0ecfad5795e4..754085eaa55b 100644
> > > --- a/MdePkg/MdePkg.dec
> > > +++ b/MdePkg/MdePkg.dec
> > > @@ -633,6 +633,8 @@ [Guids]
> > >gEfiRngAlgorithmX9313DesGuid   = { 0x63c4785a, 0xca34, 0x4012,
> {0xa3,
> > > 0xc8, 0x0b, 0x6a, 0x32, 0x4f, 0x55, 0x46 }}
> > >gEfiRngAlgorithmX931AesGuid= { 0xacd03321, 0x777e, 0x4d3d,
> {0xb1,
> > > 0xc8, 

[edk2-devel] [edk2-redfish-client][PATCH 1/6] RedfishClientPkg: Introduce Redfish event library

[Nickle Wang via groups.io]

Add RedfishEventLib to handle Redfish event. There are two events
defined in this library. One is the event before feature driver
provisioning and the other one is the event after all provisioning
is finished.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   5 +
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   1 +
 .../RedfishEventLib/RedfishEventLib.inf   |  42 ++
 .../Include/Guid/RedfishClientEventGroup.h|  27 
 .../Include/Library/RedfishEventLib.h |  77 ++
 .../Library/RedfishEventLib/RedfishEventLib.c | 138 ++
 6 files changed, 290 insertions(+)
 create mode 100644 RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
 create mode 100644 RedfishClientPkg/Include/Guid/RedfishClientEventGroup.h
 create mode 100644 RedfishClientPkg/Include/Library/RedfishEventLib.h
 create mode 100644 RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index 09df062d..39b2f5ba 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -21,6 +21,7 @@
 
 [LibraryClasses]
   RedfishFeatureUtilityLib|Include/Library/RedfishFeatureUtilityLib.h
+  RedfishEventLib|Include/Library/RedfishEventLib.h
 
 [LibraryClasses.Common.Private]
   ##  @libraryclass Redfish Helper Library
@@ -39,6 +40,10 @@
   ## Include/Guid/RedfishClientPkgTokenSpace.h
   gEfiRedfishClientPkgTokenSpaceGuid= { 0x8c444dae, 0x728b, 0x48ee, { 
0x9e, 0x19, 0x8f, 0x0a, 0x3d, 0x4e, 0x9c, 0xc8 } }
 
+  ## Include/Guid/RedfishClientEventGroup.h
+  gEfiRedfishClientFeatureReadyToProvisioningGuid = { 0x77E4FC1C, 0x2428, 
0x47EE, { 0x9E, 0xEC, 0x8B, 0x77, 0xEF, 0x9D, 0x4E, 0xF0 } }
+  gEfiRedfishClientFeatureAfterProvisioningGuid   = { 0xE547CB6F, 0x306F, 
0x4226, { 0xAB, 0x70, 0xA0, 0x6E, 0x26, 0xF1, 0x2E, 0xD0 } }
+
 [PcdsFixedAtBuild]
   
gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaStringSize|32|UINT32|0x1001
   
gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaVersionSize|8|UINT32|0x1002
diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index 5467aced..ce1c27d8 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -28,3 +28,4 @@
   
RedfishContentCodingLib|RedfishPkg/Library/RedfishContentCodingLibNull/RedfishContentCodingLibNull.inf
   
ConverterCommonLib|RedfishClientPkg/ConverterLib/edk2library/ConverterCommonLib/ConverterCommonLib.inf
 
+  RedfishEventLib|RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
diff --git a/RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf 
b/RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
new file mode 100644
index ..a9d475c2
--- /dev/null
+++ b/RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
@@ -0,0 +1,42 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = RedfishEventLib
+  FILE_GUID  = C4F7E27D-2338-43EA-9D1F-D10960E36521
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = RedfishEventLib| DXE_DRIVER UEFI_DRIVER
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 EBC
+#
+
+[Sources]
+  RedfishEventLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  RedfishPkg/RedfishPkg.dec
+  RedfishClientPkg/RedfishClientPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiBootServicesTableLib
+  UefiLib
+
+[Protocols]
+
+[Pcd]
+
+[Guids]
+  gEfiRedfishClientFeatureReadyToProvisioningGuid
+  gEfiRedfishClientFeatureAfterProvisioningGuid
diff --git a/RedfishClientPkg/Include/Guid/RedfishClientEventGroup.h 
b/RedfishClientPkg/Include/Guid/RedfishClientEventGroup.h
new file mode 100644
index ..07ce118e
--- /dev/null
+++ b/RedfishClientPkg/Include/Guid/RedfishClientEventGroup.h
@@ -0,0 +1,27 @@
+/** @file
+  GUID for Redfish Client Event Group GUID
+
+  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef REDFISH_CLIENT_EVENT_GROUP_GUID_H_
+#define REDFISH_CLIENT_EVENT_GROUP_GUID_H_
+
+#define REDFISH_CLIENT_FEATURE_READY_TO_PROVISIONING_GUID \
+  { \
+0x77E4FC1C, 0x2428, 0x47EE, { 0x9E, 0xEC, 0x8B, 0x77, 0xEF, 0x9D, 0x4E, 
0xF0 } \
+  }
+
+extern EFI_GUID  gEfiRedfishClientFeatureReadyToProvisioningGuid;
+
+#define REDFISH_CLIENT_FEATURE_AFTER_PROVISIONING_GUID \
+  { \
+0xE547CB6F, 0x306F, 0x4226, { 0xAB, 0x70, 0xA0, 0x6E, 0x26, 0xF1, 0x2E, 
0xD0 } \
+  }
+
+extern EFI_GUID  gEfiRedfishClientFeatureAfterProvisioningGuid;
+
+#endif
diff --git a/RedfishClientPkg/Include/Library/RedfishEventLib.h 
b/RedfishClie

[edk2-devel] [edk2-redfish-client][PATCH 2/6] RedfishClientPkg: Introduce Redfish version library

[Nickle Wang via groups.io]

Add RedfishVersionLib in order to get Redfish version hosted at BMC.
When there is trouble to get Redfish support version, the default
version is retrieved from pre-defined PCD value.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   4 +-
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   1 +
 .../RedfishVersionLib/RedfishVersionLib.inf   |  50 +
 .../Include/Library/RedfishVersionLib.h   |  30 +++
 RedfishClientPkg/Include/RedfishBase.h|  22 ++
 .../RedfishVersionLib/RedfishVersionLib.c | 202 ++
 6 files changed, 308 insertions(+), 1 deletion(-)
 create mode 100644 
RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
 create mode 100644 RedfishClientPkg/Include/Library/RedfishVersionLib.h
 create mode 100644 RedfishClientPkg/Include/RedfishBase.h
 create mode 100644 
RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index 39b2f5ba..2ce51d14 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -22,6 +22,7 @@
 [LibraryClasses]
   RedfishFeatureUtilityLib|Include/Library/RedfishFeatureUtilityLib.h
   RedfishEventLib|Include/Library/RedfishEventLib.h
+  RedfishVersionLib|Include/Library/RedfishVersionLib.h
 
 [LibraryClasses.Common.Private]
   ##  @libraryclass Redfish Helper Library
@@ -52,4 +53,5 @@
   # { 0x7CE88FB3, 0x4BD7, 0x4679, { 0x87, 0xA8, 0xA8, 0xD8, 0xDE, 0xE5, 0x0D, 
0x2B }}
   #
   
gEfiRedfishClientPkgTokenSpaceGuid.PcdEdkIIRedfishFeatureDriverStartupEventGuid|{0xB3,
 0x8F, 0xE8, 0x7C, 0xD7, 0x4B, 0x79, 0x46, 0x87, 0xA8, 0xA8, 0xD8, 0xDE, 0xE5, 
0x0D, 0x2B}|VOID*|0x1003
-
+  ## Default Redfish version string
+  
gEfiRedfishClientPkgTokenSpaceGuid.PcdDefaultRedfishVersion|L"v1"|VOID*|0x1004
diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index ce1c27d8..1cf04069 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -29,3 +29,4 @@
   
ConverterCommonLib|RedfishClientPkg/ConverterLib/edk2library/ConverterCommonLib/ConverterCommonLib.inf
 
   RedfishEventLib|RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
+  
RedfishVersionLib|RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
diff --git a/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf 
b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
new file mode 100644
index ..34d13d64
--- /dev/null
+++ b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
@@ -0,0 +1,50 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = RedfishVersionLib
+  FILE_GUID  = 396A7508-B611-49F7-9C81-DAD96B526B61
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = RedfishVersionLib| DXE_DRIVER
+  CONSTRUCTOR= RedfishVersionLibConstructor
+  DESTRUCTOR = RedfishVersionLibDestructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 EBC
+#
+
+[Sources]
+  RedfishVersionLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  RedfishPkg/RedfishPkg.dec
+  RedfishClientPkg/RedfishClientPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  MemoryAllocationLib
+  PcdLib
+  RedfishLib
+  JsonLib
+
+[Protocols]
+
+[Pcd]
+  gEfiRedfishClientPkgTokenSpaceGuid.PcdDefaultRedfishVersion
+
+[BuildOptions]
+  #
+  # NOTE: /wd4706 disables the following Visual Studio compiler warning in 
Jansson:
+  #   "C4706: assignment within conditional expression"
+  #
+  MSFT:*_*_*_CC_FLAGS = /wd4706
diff --git a/RedfishClientPkg/Include/Library/RedfishVersionLib.h 
b/RedfishClientPkg/Include/Library/RedfishVersionLib.h
new file mode 100644
index ..319f22bd
--- /dev/null
+++ b/RedfishClientPkg/Include/Library/RedfishVersionLib.h
@@ -0,0 +1,30 @@
+/** @file
+  This file defines the Redfish version Library interface.
+
+  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef REDFISH_VERSION_LIB_H_
+#define REDFISH_VERSION_LIB_H_
+
+/**
+  Query HTTP request to BMC with given redfish service and return redfish
+  version information. If there is troulbe to get Redfish version on BMC,
+  The value of PcdDefaultRedfishVersion is returned.
+
+  It's call responsibility to release returned buffer.
+
+  @param[in]   Service  Redfish service instance
+
+  @retval EFI_STRING  Redfish version string. NULL while error occurs.
+
+**/
+EFI_STRING
+RedfishGetVersion (
+  IN REDFISH_SERVICE  *Service
+  );
+
+#endif
diff --git a/RedfishClientPkg/Inclu

[edk2-devel] [edk2-redfish-client][PATCH 3/6] RedfishClientPkg: Update Redfish Resource Config Protocol

[Nickle Wang via groups.io]

Update Redfish resource config protocol to support Identify action in
order to identify remote resource and see if this is resource belongs
to current owner or not. Use unicode string instead of ASCII string for
all interfaces to align with HTTP interface.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../EdkIIRedfishResourceConfigProtocol.h  | 29 +++
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git 
a/RedfishClientPkg/Include/Protocol/EdkIIRedfishResourceConfigProtocol.h 
b/RedfishClientPkg/Include/Protocol/EdkIIRedfishResourceConfigProtocol.h
index 814fa9f9..3f49a56e 100644
--- a/RedfishClientPkg/Include/Protocol/EdkIIRedfishResourceConfigProtocol.h
+++ b/RedfishClientPkg/Include/Protocol/EdkIIRedfishResourceConfigProtocol.h
@@ -1,7 +1,7 @@
 /** @file
   This file defines the EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL interface.
 
-  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -29,7 +29,7 @@ typedef
 EFI_STATUS
 (EFIAPI *EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_PROVISIONING)(
   IN EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL  *This,
-  IN CHAR8   *Uri,
+  IN EFI_STRING  Uri,
   IN BOOLEAN HttpPostMode
   );
 
@@ -47,7 +47,7 @@ typedef
 EFI_STATUS
 (EFIAPI *EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_CONSUME)(
   IN EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL  *This,
-  IN CHAR8   *Uri
+  IN EFI_STRING  Uri
   );
 
 /**
@@ -64,7 +64,7 @@ typedef
 EFI_STATUS
 (EFIAPI *EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_UPDATE)(
   IN EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL  *This,
-  IN CHAR8   *Uri
+  IN EFI_STRING  Uri
   );
 
 /**
@@ -81,7 +81,25 @@ typedef
 EFI_STATUS
 (EFIAPI *EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_CHECK)(
   IN EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL  *This,
-  IN CHAR8   *Uri
+  IN EFI_STRING  Uri
+  );
+
+/**
+  Identify resource on given URI.
+
+  @param[in]   ThisPointer to 
EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL instance.
+  @param[in]   Uri The target URI to consume.
+
+  @retval EFI_SUCCESS  This is target resource which we want to 
handle.
+  @retval EFI_UNSUPPORTED  This is not the target resource.
+  @retval Others   Some error happened.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_IDENTIFY)(
+  IN EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL  *This,
+  IN EFI_STRING  Uri
   );
 
 //
@@ -119,6 +137,7 @@ struct _EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL {
   EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_CONSUME Consume;
   EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_UPDATE  Update;
   EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_CHECK   Check;
+  EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_IDENTIFYIdentify;
   EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL_GET_INFOGetInfo;
 };
 
-- 
2.17.1



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

[edk2-devel] [edk2-redfish-client][PATCH 4/6] RedfishClientPkg: Introduce Redfish resource config library

[Nickle Wang via groups.io]

Add EdkIIRedfishResourceConfigLib in order to work with Redfish Config
Protocol and do the communication between each feature drivers. Also
introduce Redfish interchange data protocol to exchange data
efficiently.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   5 +-
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   1 +
 .../EdkIIRedfishResourceConfigLib.inf |  49 ++
 .../Library/EdkIIRedfishResourceConfigLib.h   | 162 +
 .../Protocol/EdkIIRedfishInterchangeData.h|  52 ++
 .../RedfishFeatureUtilityInternal.h   |   3 +-
 .../EdkIIRedfishResourceConfigLib.c   | 603 ++
 7 files changed, 873 insertions(+), 2 deletions(-)
 create mode 100644 
RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
 create mode 100644 
RedfishClientPkg/Include/Library/EdkIIRedfishResourceConfigLib.h
 create mode 100644 
RedfishClientPkg/Include/Protocol/EdkIIRedfishInterchangeData.h
 create mode 100644 
RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index 2ce51d14..9d18c42c 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -1,7 +1,7 @@
 ## @file
 # Redfish Client Package
 #
-# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
+# (C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
@@ -21,6 +21,7 @@
 
 [LibraryClasses]
   RedfishFeatureUtilityLib|Include/Library/RedfishFeatureUtilityLib.h
+  EdkIIRedfishResourceConfigLib|Include/Library/EdkIIRedfishResourceConfigLib.h
   RedfishEventLib|Include/Library/RedfishEventLib.h
   RedfishVersionLib|Include/Library/RedfishVersionLib.h
 
@@ -36,6 +37,8 @@
   gEdkIIRedfishResourceConfigProtocolGuid = { 0x6f164c68, 0xfb09, 0x4646, { 
0xa8, 0xd3, 0x24, 0x11, 0x5d, 0xab, 0x3e, 0xe7 } }
   ## Include/Protocol/EdkiiRedfishETagProtocol.h
   gEdkIIRedfishETagProtocolGuid   = { 0x5706d368, 0xaf66, 0x48f5, { 
0x89, 0xfc, 0xa6, 0x61, 0xce, 0xb5, 0xa6, 0xa9 } }
+  ## Include/Protocol/EdkIIRedfishInterchangeData.h
+  gEdkIIRedfishFeatureInterchangeDataProtocolGuid = { 0x4B8FF71C, 0x4A7B, 
0x9478, { 0xB7, 0x81, 0x35, 0x9B, 0x0A, 0xF2, 0x00, 0x91 } }
 
 [Guids]
   ## Include/Guid/RedfishClientPkgTokenSpace.h
diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index 1cf04069..8acb4791 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -28,5 +28,6 @@
   
RedfishContentCodingLib|RedfishPkg/Library/RedfishContentCodingLibNull/RedfishContentCodingLibNull.inf
   
ConverterCommonLib|RedfishClientPkg/ConverterLib/edk2library/ConverterCommonLib/ConverterCommonLib.inf
 
+  
EdkIIRedfishResourceConfigLib|RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
   RedfishEventLib|RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
   
RedfishVersionLib|RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
diff --git 
a/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
new file mode 100644
index ..0da3423d
--- /dev/null
+++ 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
@@ -0,0 +1,49 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = EdkIIRedfishResourceConfigLib
+  FILE_GUID  = B41884F6-693B-4ADE-9558-5C220A24A025
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = EdkIIRedfishResourceConfigLib| DXE_DRIVER
+  CONSTRUCTOR= RedfishResourceConfigConstructor
+  DESTRUCTOR = RedfishResourceConfigDestructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 EBC
+#
+
+[Sources]
+  EdkIIRedfishResourceConfigLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  RedfishPkg/RedfishPkg.dec
+  RedfishClientPkg/RedfishClientPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiBootServicesTableLib
+  BaseMemoryLib
+  PcdLib
+  MemoryAllocationLib
+  RedfishFeatureUtilityLib
+  RedfishPlatformConfigLib
+
+[Protocols]
+  gEdkIIRedfishResourceConfigProtocolGuid   ## CONSUMES ##
+  gEdkIIRedfishFeatureInterchangeDataProtocolGuid ## CONSUMES ##
+
+[Pcd]
+  gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaStringSize
+  gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaVersionSize
+
diff --git a/RedfishClientPkg/Include/Library/EdkIIRedfis

[edk2-devel] [edk2-redfish-client][PATCH 5/6] RedfishClientPkg: Introduce resource identify library

[Nickle Wang via groups.io]

Introduce resource identify library which works with resource config
protocol to identify Redfish resource. This library provides the
flexibility for platform to implement its own policy and identify
resource. Two library implementation are provided as demonstration
code. NULL version of library accepts all Redfish resource and another
implementation to computer system resource uses UUID to identify
Redfish resource.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   1 +
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   2 +-
 ...edfishResourceIdentifyLibComuterSystem.inf |  39 +
 .../RedfishResourceIdentifyLibNull.inf|  32 
 .../Library/RedfishResourceIdentifyLib.h  |  29 
 .../RedfishResourceIdentifyLibComuterSystem.c | 163 ++
 .../RedfishResourceIdentifyLibNull.c  |  37 
 7 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 
RedfishClientPkg/Library/RedfishResourceIdentifyLibComuterSystem/v1_5_0/RedfishResourceIdentifyLibComuterSystem.inf
 create mode 100644 
RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.inf
 create mode 100644 
RedfishClientPkg/Include/Library/RedfishResourceIdentifyLib.h
 create mode 100644 
RedfishClientPkg/Library/RedfishResourceIdentifyLibComuterSystem/v1_5_0/RedfishResourceIdentifyLibComuterSystem.c
 create mode 100644 
RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index 9d18c42c..c61c5812 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -21,6 +21,7 @@
 
 [LibraryClasses]
   RedfishFeatureUtilityLib|Include/Library/RedfishFeatureUtilityLib.h
+  RedfishResourceIdentifyLib|Include/Library/RedfishResourceIdentifyLib.h
   EdkIIRedfishResourceConfigLib|Include/Library/EdkIIRedfishResourceConfigLib.h
   RedfishEventLib|Include/Library/RedfishEventLib.h
   RedfishVersionLib|Include/Library/RedfishVersionLib.h
diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index 8acb4791..413b83a7 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -27,7 +27,7 @@
   
RedfishPlatformConfigLib|RedfishPkg/Library/RedfishPlatformConfigLib/RedfishPlatformConfigLib.inf
   
RedfishContentCodingLib|RedfishPkg/Library/RedfishContentCodingLibNull/RedfishContentCodingLibNull.inf
   
ConverterCommonLib|RedfishClientPkg/ConverterLib/edk2library/ConverterCommonLib/ConverterCommonLib.inf
-
+  
RedfishResourceIdentifyLib|RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.inf
   
EdkIIRedfishResourceConfigLib|RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
   RedfishEventLib|RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
   
RedfishVersionLib|RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
diff --git 
a/RedfishClientPkg/Library/RedfishResourceIdentifyLibComuterSystem/v1_5_0/RedfishResourceIdentifyLibComuterSystem.inf
 
b/RedfishClientPkg/Library/RedfishResourceIdentifyLibComuterSystem/v1_5_0/RedfishResourceIdentifyLibComuterSystem.inf
new file mode 100644
index ..ae269b58
--- /dev/null
+++ 
b/RedfishClientPkg/Library/RedfishResourceIdentifyLibComuterSystem/v1_5_0/RedfishResourceIdentifyLibComuterSystem.inf
@@ -0,0 +1,39 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = RedfishResourceIdentifyLibComuterSystem
+  FILE_GUID  = 2AEE2C80-126A-44A6-877E-642F20510D13
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = RedfishResourceIdentifyLib| DXE_DRIVER
+  CONSTRUCTOR= 
RedfishResourceIdentifyComuterSystemConstructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 EBC
+#
+
+[Sources]
+  RedfishResourceIdentifyLibComuterSystem.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  NetworkPkg/NetworkPkg.dec
+  RedfishPkg/RedfishPkg.dec
+  RedfishClientPkg/RedfishClientPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiBootServicesTableLib
+  UefiLib
+
+[Protocols]
+  gEfiRestJsonStructureProtocolGuid   ## CONSUMES
diff --git 
a/RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.inf
 
b/RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.inf
new file mode 100644
index ..9164b229
--- /dev/null
+++ 
b/RedfishClientPkg/Library/RedfishResourceIdentifyLibNull/RedfishResourceIdentifyLibNull.inf
@@ -0,0 +1,32 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Pa

[edk2-devel] [edk2-redfish-client][PATCH 6/6] RedfishClientPkg: Introduce RedfishConfigLangMap driver

[Nickle Wang via groups.io]

Introduce Redfish configure language map driver. This driver keeps the
mapping between configure language and Redfish URI for internal use.
This saves the communication time between feature drivers and Redfish
service. It also provides the history records so that feature drivers
can do provisioning, consuming and updating efficiently.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   2 +
 .../RedfishClientComponents.dsc.inc   |   1 +
 .../RedfishConfigLangMapDxe.inf   |  46 +
 .../EdkIIRedfishConfigLangMapProtocol.h   |  88 ++
 .../RedfishConfigLangMapDxe.h |  71 ++
 .../RedfishConfigLangMapDxe.c | 809 ++
 RedfishClientPkg/RedfishClient.fdf.inc|   3 +-
 7 files changed, 1019 insertions(+), 1 deletion(-)
 create mode 100644 
RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
 create mode 100644 
RedfishClientPkg/Include/Protocol/EdkIIRedfishConfigLangMapProtocol.h
 create mode 100644 
RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.h
 create mode 100644 
RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index c61c5812..7bdab5be 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -38,6 +38,8 @@
   gEdkIIRedfishResourceConfigProtocolGuid = { 0x6f164c68, 0xfb09, 0x4646, { 
0xa8, 0xd3, 0x24, 0x11, 0x5d, 0xab, 0x3e, 0xe7 } }
   ## Include/Protocol/EdkiiRedfishETagProtocol.h
   gEdkIIRedfishETagProtocolGuid   = { 0x5706d368, 0xaf66, 0x48f5, { 
0x89, 0xfc, 0xa6, 0x61, 0xce, 0xb5, 0xa6, 0xa9 } }
+  ## Include/Protocol/EdkIIRedfishConfigLangMapProtocol.h
+  gEdkIIRedfishConfigLangMapProtocolGuid= { 0x1d9ba9fe, 0x5d5a, 0x4b66, 
{0x83, 0x5b, 0xe2, 0x5d, 0x13, 0x93, 0x4a, 0x9c } }
   ## Include/Protocol/EdkIIRedfishInterchangeData.h
   gEdkIIRedfishFeatureInterchangeDataProtocolGuid = { 0x4B8FF71C, 0x4A7B, 
0x9478, { 0xB7, 0x81, 0x35, 0x9B, 0x0A, 0xF2, 0x00, 0x91 } }
 
diff --git a/RedfishClientPkg/RedfishClientComponents.dsc.inc 
b/RedfishClientPkg/RedfishClientComponents.dsc.inc
index b89df12c..ee4602fe 100644
--- a/RedfishClientPkg/RedfishClientComponents.dsc.inc
+++ b/RedfishClientPkg/RedfishClientComponents.dsc.inc
@@ -15,6 +15,7 @@
 !if $(REDFISH_CLIENT) == TRUE
   RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
   RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.inf
+  RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
   #
   # Below two modules should be pulled in by build tool.
   #
diff --git 
a/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf 
b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
new file mode 100644
index ..9f195338
--- /dev/null
+++ b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
@@ -0,0 +1,46 @@
+## @file
+#
+#  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION   = 0x0001000b
+  BASE_NAME = RedfishConfigLangMapDxe
+  FILE_GUID = F4121E32-454D-4E51-AB4B-DAA577833E95
+  MODULE_TYPE   = DXE_DRIVER
+  VERSION_STRING= 1.0
+  ENTRY_POINT   = RedfishConfigLangMapDriverEntryPoint
+  UNLOAD_IMAGE  = RedfishConfigLangMapDriverUnload
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  RedfishPkg/RedfishPkg.dec
+  RedfishClientPkg/RedfishClientPkg.dec
+
+[Sources]
+  RedfishConfigLangMapDxe.h
+  RedfishConfigLangMapDxe.c
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  MemoryAllocationLib
+  UefiLib
+  UefiBootServicesTableLib
+  UefiRuntimeServicesTableLib
+  UefiDriverEntryPoint
+  RedfishEventLib
+
+[Protocols]
+  gEdkIIRedfishConfigLangMapProtocolGuid   ## PRODUCED ##
+
+[Guids]
+  gEfiEventExitBootServicesGuid  ## CONSUMED ##
+
+[Depex]
+  TRUE
diff --git 
a/RedfishClientPkg/Include/Protocol/EdkIIRedfishConfigLangMapProtocol.h 
b/RedfishClientPkg/Include/Protocol/EdkIIRedfishConfigLangMapProtocol.h
new file mode 100644
index ..89846d06
--- /dev/null
+++ b/RedfishClientPkg/Include/Protocol/EdkIIRedfishConfigLangMapProtocol.h
@@ -0,0 +1,88 @@
+/** @file
+  This file defines the EDKII_REDFISH_CONFIG_LANG_MAP_PROTOCOL interface.
+
+  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef EDKII_REDFISH_CONFIG_LANG_MAP_PROTOCOL_H_
+#define EDKII_REDFISH_CONFIG_LANG_MAP_PROTOCOL_H_
+
+typedef struct _EDKII_REDFISH_CONFIG_LANG_MAP_PROTOCOL 
EDKII_REDFISH_CONFIG_LANG_MAP_PROTOCOL;
+
+/**
+ Definition of REDFISH_CONFIG_LANG_MAP_GET_TYPE
+ **/
+typedef enum {
+  RedfishGetTypeUri = 0,
+  RedfishGetTypeConfigLang,
+  RedfishGetTypeMax

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Michael Brown]

On 09/05/2023 14:31, Laszlo Ersek wrote:

On 5/9/23 14:09, Michael Brown wrote:

At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.

However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction. Some
versions of the Microsoft Windows bootloader are known to do this.

NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.

Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.

Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Cc: Laszlo Ersek 
Cc: Gerd Hoffmann 
Cc: Oliver Steffen 
Cc: Pawel Polawski 
Cc: Jiewen Yao 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Michael Brown (2):
   OvmfPkg: Clarify invariants for NestedInterruptTplLib
   OvmfPkg: Relax assertion that interrupts do not occur at
 TPL_HIGH_LEVEL

  OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
  1 file changed, 26 insertions(+), 5 deletions(-)



series
Acked-by: Laszlo Ersek 


Thank you!

Gerd: are you happy for your Reviewed-by to stand, since the only 
changes since v1 were to comment wording?  (My apologies for forgetting 
to include a v2 description in the cover letter.)


Thanks,

Michael




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

Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page table to permanent memory

[Gerd Hoffmann]

  Hi,

> +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> +//
> +// The max lineaddress bits is 48 for 4 level page table.
> +//
> +VirPhyAddressSize.Bits.PhysicalAddressBits = MIN 
> (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> +  }

virtual addresses in long mode are sign-extended.  Which means you have
only 47 bits (or 56 bits with 5-level paging) for identity mappings.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v1 2/3] UefiCpuPkg/CpuMpPei: Enable PAE page table if CR0.PG is not set

[Gerd Hoffmann]

  Hi,

> +//
> +// Check CPU runs in 32bit mode.
> +//
> +MsrEfer.Uint64 = AsmReadMsr64 (MSR_CORE_IA32_EFER);
> +if (MsrEfer.Bits.LMA == 1) {

Checking this at runtime is pointless.  32bit code would simply
not work in long mode and visa versa.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v1 3/3] MdeModulePkg/DxeIpl: Align Page table Level setting with previous level.

[Gerd Hoffmann]

> +//
> +// If IA32, Page table Level is decided by PCD and feature capbility.
> +//

There is neither 5-level nor 4-level paging support in ia32 mode.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v1 0/3] Target to enable paging from temporary RAM Done

[Gerd Hoffmann]

On Tue, May 09, 2023 at 06:22:50PM +0800, Wu, Jiaxin wrote:
> For arch X64, system will enable the page table in SPI to cover 0-512G
> range via CR4.PAE & MSR.LME & CR0.PG & CR3 setting. Existing code doesn't
> cover the higher address access above 512G before memory-discovered
> callback. This series patches provide the solution to enable paging from
> temporary RAM Done.
> 
> Jiaxin Wu (3):
>   UefiCpuPkg/SecCore: Migrate page table to permanent memory
>   UefiCpuPkg/CpuMpPei: Enable PAE page table if CR0.PG is not set
>   MdeModulePkg/DxeIpl: Align Page table Level setting with previous
> level.

Fails to build OvmfPkg/OvmfPkgX64.dsc

Please run this through CI before sending out the patches.

thanks,
  Gerd



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

Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: CpuDxe: Sync GCD Capabilities With Page Table Attributes

[Oliver Smith-Denny]

On 5/8/2023 11:59 PM, Ard Biesheuvel wrote:

On Tue, 9 May 2023 at 04:04, Kinney, Michael D
 wrote:


I would prefer next week as well.

Mike



Next week, i can only do Wednesday. The week after (22-26), the time
slot works for me on any day of the week.



Weds works from our side, the week after also works perfectly well
any day. Thanks for the flexibility and willingness to meet.

For reference for this specific patch, this bz may help cache in
some info: https://bugzilla.tianocore.org/show_bug.cgi?id=753. The
mail links are largely dead, of course, but can be found on other
mailing list retention sites (maybe in the future we will have PRs
and discussions to reference :).

Thanks,
Oliver


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104385): https://edk2.groups.io/g/devel/message/104385
Mute This Topic: https://groups.io/mt/98505340/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 V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Michael Kubacki]

At the surface, this looks similar to the following patch I sent a while 
back:


https://edk2.groups.io/g/devel/message/92644

That triggered a thread where we had a similar discussion about 
LargeVariableLib responsibilities, etc.


We still have a fork of SaveMemoryConfig that uses the PCD I sent in the 
patch:


https://github.com/microsoft/mu_common_intel_min_platform/blob/release/202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf

I believe a challenge that led to adding compression (in our fork code) 
to SaveMemoryConfig was the fact that the data was produced in pre-mem 
PEI and compression is expensive in CAR.


In general though, I still believe that it is simpler to separate data 
mutation from service APIs. Platforms can manipulate data to achieve 
their goals whether size, security, and so on and the service APIs 
provide a simple interface to store and retrieve that data blob.


I'd also like to see FSP reduce in size and eliminate operations that 
are not essential to its role and can be consolidated/reused in the wrapper.


Thanks,
Michael

On 5/8/2023 5:48 PM, Michael D Kinney wrote:

When reviewing the Variable feature that adds integrity and confidentiality,
I suggested that the interface between the Variable services and the NVStorage
could provide an abstraction to encode/decode the stored data that would
support encryption, compression, or both.  Could also support a platform
policy for which variables the encode/decode operation is applied.

Wouldn't that be a better abstraction than piecemeal adding these
features?

Doesn't mean that this can't go in as-is.  But would be an opportunity to
consolidate in the future.

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu,
Chasel
Sent: Monday, May 8, 2023 12:37 PM
To: Oram, Isaac W ; Gudla, Raghava
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kubacki,
Michael ; Chaganty, Rangasai V
; Chiu, Chasel 
Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Hi Isaac,

Just my thoughts, I would vote for platform/bootloader to decide
compressing the variable data before saving to NVRAM or not.
It should be optional and when platform having big SPI flash they might not
want to do this.

Thanks,
Chasel



-Original Message-
From: Oram, Isaac W 
Sent: Monday, May 8, 2023 12:15 PM
To: Gudla, Raghava ; devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L
; Kubacki, Michael
; Chaganty, Rangasai V

Subject: RE: [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig:
Support NVS Data compression.

The proposed implementation is fine and I will reviewed-by and push if that

is

the desired direction.

My question is if we generally like the design of doing compression in

common

MinPlatform code, decompression in board specific FSP wrapper code.  The
alternative design is to do compression and decompression inside the FSP.

This

seems like a slightly simpler separation of responsibilities.
The board code is responsible for save/restore, the FSP code is responsible

for

data blob creation and use.  Data integrity, authentication, compression, etc

all

can be done based on more detailed knowledge of the silicon

implementation

requirements.

I can see another argument though that doing it inside FSP effectively forces
both bootloader and FSP to carry compression/decompression.  The
compression/decompression aren't likely to need to be silicon specific.  And
bootloader may have more requirements to balance than just the silicon
requirements.

Can I get some votes on preferred answer for compressing/decompressing

FSP

non-volatile data in bootloader or FSP?

Thanks,
Isaac

-Original Message-
From: Gudla, Raghava 
Sent: Friday, May 5, 2023 5:03 PM
To: devel@edk2.groups.io
Cc: Gudla, Raghava ; Chiu, Chasel
; Desimone, Nathaniel L
; Oram, Isaac W



Subject: [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig:
Support NVS Data compression.

Around 50KB "FspNonVolatileStorageHob" data can be compressed to
approximately 3 KB which can save NVRAM space and enhance life of the SPI
part by decreasing the number of reclaim cycles needed.

This patch added support to compress "FspNonVolatileStorageHob" data

before

saving to NVRAM.

A PcdEnableCompressFspNvsHob is introduced to enable/disable this

feature per

platform usage.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Isaac Oram 

Signed-off-by: Raghava Gudla 
---
  .../SaveMemoryConfig/SaveMemoryConfig.c   | 34 +++
  .../SaveMemoryConfig/SaveMemoryConfig.inf |  6 +++-
  .../Include/Dsc/CoreCommonLib.dsc |  1 +
  .../Intel/MinPlatformPkg/MinPlatformPkg.dec   |  5 +++
  4 files changed, 45 insertions(+), 1 deletion(-)

diff --git


a/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemo
r

yConfig.c


b/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMem
or

yConfig.c
index 0215e8eed..8aa935b54 100644
--

[edk2-devel] [PATCH v1] MinPlatformPkg: Fix SetLargeVariable fail issue

[Xiaoqiang Zhang]

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

On Server platform, when the large variable "FspNvsBuffer" is
already in the UEFI variable store and the remaining variable
storage space is less than the large variable size. And also
not in OS runtime then we need to add the size of the current
data that will end up being replaced by the new data to the
remaining space before we decide that there is not enough
space to store the large variable.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Eric Dong 

Signed-off-by: Xiaoqiang Zhang 
---
 
Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c
   | 10 +-
 
Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/BaseLargeVariableWriteLib.inf
 |  1 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c
 
b/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c
index de23ae6160..da820f65b9 100644
--- 
a/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c
+++ 
b/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/LargeVariableWriteLib.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "LargeVariableCommon.h"
 
 /**
@@ -270,6 +270,7 @@ SetLargeVariable (
   UINT8 *OffsetPtr;
   UINTN BytesRemaining;
   UINTN SizeToSave;
+  UINTN BufferSize = 0;
 
   //
   // Check input parameters.
@@ -365,6 +366,13 @@ SetLargeVariable (
 // Non-Volatile storage to store the data.
 //
 RemainingVariableStorage = GetRemainingVariableStorageSpace ();
+//
+// Check if current variable already existed in NV storage variable space
+//
+Status = GetLargeVariable (VariableName, VendorGuid, &BufferSize, NULL);
+if ((Status == EFI_BUFFER_TOO_SMALL) && (BufferSize != 0)) {
+  RemainingVariableStorage = RemainingVariableStorage + BufferSize;
+}
 if (DataSize > RemainingVariableStorage) {
   DEBUG ((DEBUG_ERROR, "SetLargeVariable: Not enough NV storage space to 
store the data\n"));
   Status = EFI_OUT_OF_RESOURCES;
diff --git 
a/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/BaseLargeVariableWriteLib.inf
 
b/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/BaseLargeVariableWriteLib.inf
index 2493a94596..cbc2a5d93a 100644
--- 
a/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/BaseLargeVariableWriteLib.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Library/BaseLargeVariableLib/BaseLargeVariableWriteLib.inf
@@ -49,3 +49,4 @@
   PrintLib
   VariableReadLib
   VariableWriteLib
+  LargeVariableReadLib
-- 
2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104388): https://edk2.groups.io/g/devel/message/104388
Mute This Topic: https://groups.io/mt/98786447/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] ManageabilityPkg/IpmiCommandLib: Add IpmiCommandLib to package

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abdul Lateef Attar 

-Original Message-
From: Chang, Abner 
Sent: 05 May 2023 10:54
To: devel@edk2.groups.io
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul Lateef) 
; Nickle Wang ; Tinh Nguyen 

Subject: [edk2-platforms][PATCH] ManageabilityPkg/IpmiCommandLib: Add 
IpmiCommandLib to package

From: Abner Chang 

BZ #: 
Add IpmiCommandLib to ManageabilityPkg package.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Tinh Nguyen 
---
 Features/ManageabilityPkg/ManageabilityPkg.dec  | 4 
 Features/ManageabilityPkg/Include/Manageability.dsc | 1 +
 Features/ManageabilityPkg/ManageabilityPkg.dsc  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/Features/ManageabilityPkg/ManageabilityPkg.dec 
b/Features/ManageabilityPkg/ManageabilityPkg.dec
index 6f58ab4f45..38813c5f48 100644
--- a/Features/ManageabilityPkg/ManageabilityPkg.dec
+++ b/Features/ManageabilityPkg/ManageabilityPkg.dec
@@ -18,6 +18,10 @@
   Include

 [LibraryClasses]
+  ##  @libraryclass IPMI command library
+  #   Provide the help functions to send IPMI commands.
+  IpmiCommandLib|Include/Library/IpmiCommandLib.h
+
   ##  @libraryclass Manageability Transport Library
   #   Manageability Transport Library definitions
   ManageabilityTransportLib|Include/Library/ManageabilityTransportLib.h
diff --git a/Features/ManageabilityPkg/Include/Manageability.dsc 
b/Features/ManageabilityPkg/Include/Manageability.dsc
index 5e7cdb885f..a432b0ff26 100644
--- a/Features/ManageabilityPkg/Include/Manageability.dsc
+++ b/Features/ManageabilityPkg/Include/Manageability.dsc
@@ -7,6 +7,7 @@
 ##
 [LibraryClasses]
   
ManageabilityTransportHelperLib|ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
+  IpmiCommandLib|ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf

 [LibraryClasses.common.DXE_DRIVER]
   
PldmProtocolLib|ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.inf
diff --git a/Features/ManageabilityPkg/ManageabilityPkg.dsc 
b/Features/ManageabilityPkg/ManageabilityPkg.dsc
index a0712d1c0a..e3baf27f2a 100644
--- a/Features/ManageabilityPkg/ManageabilityPkg.dsc
+++ b/Features/ManageabilityPkg/ManageabilityPkg.dsc
@@ -49,6 +49,7 @@
   
ManageabilityPkg/Library/ManageabilityTransportKcsLib/Dxe/DxeManageabilityTransportKcs.inf
   
ManageabilityPkg/Library/ManageabilityTransportMctpLib/Dxe/DxeManageabilityTransportMctp.inf
   ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.inf
+  ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf

 [LibraryClasses]
   
ManageabilityTransportLib|ManageabilityPkg/Library/BaseManageabilityTransportNullLib/BaseManageabilityTransportNull.inf
--
2.37.1.windows.1



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

Re: [edk2-devel] [PATCH V3 0/5] Adding necessary changes for RedfishPkg

[Minh Nguyen]

Hi Abner,

 Thanks for your information.

Thanks,

Minh Nguyen

On 5/8/2023 8:45 PM, Chang, Abner wrote:
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
Please be mindful of safe email handling and proprietary information 
protection practices.]


[AMD Official Use Only - General]

Hi Minh,

Just let you know your PR is just merged.

Thanks

Abner

*From:* Minh Nguyen 
*Sent:* Friday, May 5, 2023 2:50 PM
*To:* Chang, Abner ; Minh Nguyen 
; devel@edk2.groups.io
*Cc:* patc...@amperecomputing.com; nick...@nvidia.com; ig...@ami.com; 
n...@os.amperecomputing.com; tinhngu...@os.amperecomputing.com

*Subject:* Re: [PATCH V3 0/5] Adding necessary changes for RedfishPkg




*Caution:*This message originated from an External Source. Use proper 
caution when opening attachments, clicking links, or responding.


Hi Abner,

 While they're checking this issue, they recommend me to re-send v3 so 
I just sent it, you can also use the PR to review at the same time.


Thanks,

Minh Nguyen.

On 5/5/2023 1:01 PM, Minh Nguyen wrote:

Hi Abner,

 Here you are: #4338 

Thanks,

Minh Nguyen

On 5/5/2023 12:45 PM, Chang, Abner wrote:

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
Please be mindful of safe email handling and proprietary information protection 
practices.]

[AMD Official Use Only - General]

Ok, because the patch in email always has format problem when apply the 
patch, plus I can't get the patch from group.io; could you please create a PR 
on your Github thus I can review patches from there.

Just let me know the PR # after you creating it.

Thanks

Abner

-Original Message-

From: Minh Nguyen  


Sent: Friday, May 5, 2023 1:35 PM

To: Chang, Abner  
; Minh Nguyen

  
;devel@edk2.groups.io

Cc:patc...@amperecomputing.com;nick...@nvidia.com;ig...@ami.com;

n...@os.amperecomputing.com;tinhngu...@os.amperecomputing.com

Subject: Re: [PATCH V3 0/5] Adding necessary changes for RedfishPkg

Caution: This message originated from an External Source. Use proper

caution when opening attachments, clicking links, or responding.

Hi Abner,

   Yes, me too. I have sent the email tomiki.deme...@intel.com  for 
checking

it.

Thanks,

Minh Nguyen

On 5/5/2023 12:03 PM, Chang, Abner wrote:

[AMD Official Use Only - General]

Hi Minh,

I don't know why however I can't see V3 patch set on group.io. 
Can you see

those patches on group.io?

Abner

-Original Message-

From: Minh Nguyen  


Sent: Friday, May 5, 2023 11:58 AM

To:devel@edk2.groups.io

Cc:patc...@amperecomputing.com; Chang, Abner

  ;


nick...@nvidia.com;ig...@ami.com;n...@os.amperecomputing.com;

tinhngu...@os.amperecomputing.com;

Minh Nguyen  


Subject: [PATCH V3 0/5] Adding necessary changes for 
RedfishPkg

Caution: This message originated from an External Source. 
Use proper

caution when opening attachments, clicking links, or 
responding.

This patchset adds necessary changes for RedfishPkg to 
avoid some

unexpected cases and fix compilation.

Changes since v3:

   + Replaced __FUNCTION__ with __func__ to be more C11 
compliant.

Changes since v2:

   + Added "Cc:" to maintainers in commit message.

   + Corrected patch format subject prefix.

Changes since v1:

   + Removed redundant change and change the commit message 
for more

precise in PATCH 2/5.

Nhi Pham (1):

    RedfishPkg: Add missing newline character

Vu Nguyen (4):

    RedfishPkg: Correct variable type to prevent memory 
corruption

    RedfishPkg: Fix condition checking of error status

    RedfishPkg: Create RestEx child on selected interface

    RedfishPkg: Fix compile issue on Linux

   RedfishPkg/Include/Library/RestExLib.h   
    |   3 +

   RedfishPkg/Include/Pcd/RestExServiceDevicePath.h

Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg/IpmiCommandLib:IPMI Command Library

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[AMD Official Use Only - General]

reviewed-by: Abdul Lateef Attar 

-Original Message-
From: Chang, Abner 
Sent: 05 May 2023 10:54
To: devel@edk2.groups.io
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul Lateef) 
; Nickle Wang ; Tinh Nguyen 

Subject: [edk2-platforms][PATCH] ManageabilityPkg/IpmiCommandLib:IPMI Command 
Library

From: Abner Chang 

BZ #: 

IpmiCommandLib is cloned from
edk2-platforms/Features/Intel/OutOfBandManagement/
IpmiFeaturePkg/Library/IpmiCommandLib in order to
consolidate edk2 system manageability support in
one place. Function header are added to the source
files and header files. Uncustify is applied to C
files and no functionalities are changed in this patch.

We will still keep the one under IpmiFeaturePkg/Library/
IpmiCommandLib until the reference to this instance are
removed from platforms.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Tinh Nguyen 
---
 .../Library/IpmiCommandLib/IpmiCommandLib.inf |  33 +
 .../Include/Library/IpmiCommandLib.h  | 620 ++
 .../IpmiCommandLib/IpmiCommandLibNetFnApp.c   | 444 +
 .../IpmiCommandLibNetFnChassis.c  | 199 ++
 .../IpmiCommandLibNetFnStorage.c  | 384 +++
 .../IpmiCommandLibNetFnTransport.c| 156 +
 6 files changed, 1836 insertions(+)
 create mode 100644 
Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf
 create mode 100644 Features/ManageabilityPkg/Include/Library/IpmiCommandLib.h
 create mode 100644 
Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLibNetFnApp.c
 create mode 100644 
Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLibNetFnChassis.c
 create mode 100644 
Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLibNetFnStorage.c
 create mode 100644 
Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLibNetFnTransport.c

diff --git 
a/Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf 
b/Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf
new file mode 100644
index 00..3dc485cf38
--- /dev/null
+++ b/Features/ManageabilityPkg/Library/IpmiCommandLib/IpmiCommandLib.inf
@@ -0,0 +1,33 @@
+### @file
+# Component description file for IPMI Command Library.
+#
+# Copyright (c) 2018 - 2021, Intel Corporation. All rights reserved.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = IpmiCommandLib
+  FILE_GUID  = 96FC1989-CB7F-489B-9D3B-68DCA2C2DADC
+  MODULE_TYPE= UEFI_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = IpmiCommandLib
+
+[sources]
+  IpmiCommandLibNetFnApp.c
+  IpmiCommandLibNetFnTransport.c
+  IpmiCommandLibNetFnChassis.c
+  IpmiCommandLibNetFnStorage.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ManageabilityPkg/ManageabilityPkg.dec
+
+[LibraryClasses]
+  BaseMemoryLib
+  DebugLib
+  IpmiLib
diff --git a/Features/ManageabilityPkg/Include/Library/IpmiCommandLib.h 
b/Features/ManageabilityPkg/Include/Library/IpmiCommandLib.h
new file mode 100644
index 00..685f6e2ea2
--- /dev/null
+++ b/Features/ManageabilityPkg/Include/Library/IpmiCommandLib.h
@@ -0,0 +1,620 @@
+/** @file
+  This library abstract how to send/receive IPMI command.
+
+Copyright (c) 2018-2021, Intel Corporation. All rights reserved.
+Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef IPMI_COMMAND_LIB_H_
+#define IPMI_COMMAND_LIB_H_
+
+#include 
+#include 
+
+///
+/// Functions for IPMI NetFnApp commands
+///
+
+/**
+  This function is used to retrieve device ID.
+
+  @param [out]  DeviceId  The pointer to receive IPMI_GET_DEVICE_ID_RESPONSE.
+
+  @retval EFI_STASTUS   See the return values of IpmiSubmitCommand () function.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetDeviceId (
+  OUT IPMI_GET_DEVICE_ID_RESPONSE  *DeviceId
+  );
+
+/**
+  This function returns device self test results
+
+  @param [out]  SelfTestResult  The pointer to receive 
IPMI_SELF_TEST_RESULT_RESPONSE.
+
+  @retval EFI_STASTUS   See the return values of IpmiSubmitCommand () function.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetSelfTestResult (
+  OUT IPMI_SELF_TEST_RESULT_RESPONSE  *SelfTestResult
+  );
+
+/**
+  This function is used for starting and restarting the Watchdog
+  Timer from the initial countdown value that was specified in
+  the Set Watchdog Timer command the watchdog timer.
+
+  @param [out]  CompletionCode  IPMI completetion code, refer to Ipmi.h.
+
+  @retval EFI_STASTUS   See the return values of IpmiSubmitCommand () function.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiResetWatchdogTimer (
+  OUT UINT8  *CompletionCode
+  );
+
+/**
+  This function  is used for initializing and configuring
+  the watchdo

Re: [edk2-devel] [edk2-platforms][PATCH 1/2] ManageabilityPkg: Add Manageability IPMI helper Library

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abdul Lateef Attar 

-Original Message-
From: Chang, Abner 
Sent: 09 May 2023 13:26
To: devel@edk2.groups.io
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul Lateef) 
; Nickle Wang ; Tinh Nguyen 

Subject: [edk2-platforms][PATCH 1/2] ManageabilityPkg: Add Manageability IPMI 
helper Library

From: Abner Chang 

Add IPMI helper library to print debug message of IPMI Completion Code in human 
readable string and return the transport interface additional status.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Tinh Nguyen 
---
 .../BaseManageabilityTransportHelper.inf  |  1 +
 .../Library/ManageabilityTransportHelperLib.h | 24 +++
 .../Library/ManageabilityTransportIpmiLib.h   | 13 +++-
 .../Library/ManageabilityTransportLib.h   | 11 +--
 .../BaseManageabilityTransportIpmiHelper.c| 70 +++
 5 files changed, 112 insertions(+), 7 deletions(-)  create mode 100644 
Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportIpmiHelper.c

diff --git 
a/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
 
b/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
index c9e5eaef60..0936449fda 100644
--- 
a/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelperLib/BaseManageabilityTransportHelper.inf
+++ b/Features/ManageabilityPkg/Library/BaseManageabilityTransportHelper
+++ Lib/BaseManageabilityTransportHelper.inf
@@ -21,6 +21,7 @@

 [Sources]
   BaseManageabilityTransportHelper.c
+  BaseManageabilityTransportIpmiHelper.c

 [LibraryClasses]
   BaseMemoryLib
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h
index c2c98d6c2d..11a1bd0521 100644
--- 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHelperLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportHe
+++ lperLib.h
@@ -187,4 +187,28 @@ HelperManageabilityDebugPrint (
   ...
   );

+///
+/// IPMI Helper Functions.
+///
+
+/**
+  This function returns a human readable string of IPMI KCS Completion
+Code
+  and returns the corresponding additional status of transport interface.
+
+  @param [in]  CompletionCode The Completion Code returned from KCS.
+  @param [out] CompletionCodeStr  Human readable string of IPMI Completion 
Code.
+  @param [out] AdditionalStatus   Return the addtional status.
+
+  @retval  EFI_SUCCESSThe information of Completion Code is 
returned.
+  @retval  EFI_NOT_FOUND  No information of Completion Code is 
returned.
+  @retval  EFI_INVALID_PARAMETER  The given parameter is incorrect.
+
+**/
+EFI_STATUS
+IpmiHelperCheckCompletionCode (
+  IN   UINT8  CompletionCode,
+  OUT  CHAR16 **CompletionCodeStr,
+  OUT  MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS  *AdditionalStatus
+  );
+
 #endif
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h
index 1628255a6a..6d136e460f 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIpmiLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportIp
+++ miLib.h
@@ -16,9 +16,18 @@
 /// the payload.
 ///
 typedef struct {
-  UINT8Lun:2;
-  UINT8NetFn:6;
+  UINT8Lun   : 2;
+  UINT8NetFn : 6;
   UINT8Command;
 } MANAGEABILITY_IPMI_TRANSPORT_HEADER;

+///
+/// The IPMI Completion Code mapping.
+///
+typedef struct {
+  UINT8CompletionCode;
+  CHAR16   *CompletionCodeString;
+  MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUSAdditionalStatus;
+} MANAGEABILITY_IPMI_COMPLETTION_CODE_MAPPING;
+
 #endif
diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h
index 04072aee89..f423a1ed44 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportLi
+++ b.h
@@ -61,11 +61,12 @@ typedef union {
 /// Additional transport interface status.
 ///
 typedef UINT32 MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS;
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NO_ERRORS  0x
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_ERROR  0x0001
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_READ   0x0002
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_BUSY_IN_WRITE  0x0004 
-#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NOT_AVAILABLE  0x
+#define MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NO_ERRORS0x
+#define MANAGE

Re: [edk2-devel] [PATCH v5 0/5] UefiCpuPkg/ResetVector: Refine page table creation, and support 5 Level paging

[Gerd Hoffmann]

On Mon, May 08, 2023 at 04:14:59PM +0800, Zhiguang Liu wrote:
> This patch set simplify the page table creation code, remove some
> hard-code, combine files and support 5 Level paging.
> 
> V4:
> Refine comments and update below macro names:
> PG_NLE -> PAGE_NLE
> PTE_2MB -> PDE_2MB
> PDP_1G -> PDPTE_1GB
> PAGE_BLP_ATTR -> PAGE_BLE_ATTR
> 
> No code logic impact
> 
> V5:
> Update below macro names:
> PDE_2MB -> PAGE_PDE_2MB
> PDPTE_1GB -> PAGE_PDPTE_1GB
> 
> No code logic impact
> 
> Zhiguang Liu (5):
>   UefiCpuPkg/ResetVector: Rename macros about page table.
>   UefiCpuPkg/ResetVector: Simplify page table creation in ResetVector
>   UefiCpuPkg/ResetVector: Combine PageTables1G.asm and PageTables2M.asm
>   UefiCpuPkg/ResetVector: Modify Page Table in ResetVector
>   UefiCpuPkg/ResetVector: Support 5 level page table in ResetVector

Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 

take care,
  Gerd



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

[edk2-devel] Stuart Feedback

[Michael Kubacki]

We created a edk2 discussion to gather feedback on the Stuart tool here:

https://github.com/tianocore/edk2/discussions/4369

Of course, feel free to reply on the mailing list as well if you prefer 
but we'd like to use some edk2 discussion features to help assist with 
gathering and assigning feedback if possible.


Regards,
Michael


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

Re: [edk2-devel] [PATCH v10 9/9] OvmfPkg: Uses MmSaveStateLib library

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abdul
> Lateef Attar via groups.io
> Sent: Thursday, May 4, 2023 2:39 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Paul Grimes
> ; Abner Chang ; Dong,
> Eric ; Ni, Ray ; Kumar, Rahul R
> ; Gerd Hoffmann ; Ard
> Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ;
> Abdul Lateef Attar 
> Subject: [edk2-devel] [PATCH v10 9/9] OvmfPkg: Uses MmSaveStateLib
> library
> 
> From: Abdul Lateef Attar 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
> 
> Uses new MmSaveStateLib library instance.
> 
> Cc: Paul Grimes 
> Cc: Abner Chang 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Signed-off-by: Abdul Lateef Attar 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 767 --
>  4 files changed, 5 insertions(+), 767 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 86177bb94899..cde1ce4b2984 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -977,6 +977,7 @@ [Components]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/OvmfMmSaveStateLi
> b.inf
>}
> 
>#
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 065b54450647..a5883085257e 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -4,6 +4,7 @@
>  #  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #  Copyright (c) Microsoft Corporation.
> +#  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -451,6 +452,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> 
> SmmCpuRendezvousLib|UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCp
> uRendezvousLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/OvmfMmSaveStateLi
> b.inf
> 
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -995,6 +997,7 @@ [Components.X64]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/OvmfMmSaveStateLi
> b.inf
>}
> 
>#
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 3d405cd4ade0..d0f6536d1764 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -1071,6 +1071,7 @@ [Components]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/OvmfMmSaveStateLi
> b.inf
>}
> 
>#
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> index a009123dae88..4c354bafe42f 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> @@ -578,773 +578,6 @@ SmmCpuFeaturesSetSmmRegister (
>ASSERT (FALSE);
>  }
> 
> -///
> -/// Macro used to simplify the lookup table entries of type
> -/// CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
> -///
> -#define SMM_CPU_OFFSET(Field)  OFFSET_OF
> (QEMU_SMRAM_SAVE_STATE_MAP, Field)
> -
> -///
> -/// Macro used to simplify the lookup table entries of type
> -/// CPU_SMM_SAVE_STATE_REGISTER_RANGE
> -///
> -#define SMM_REGISTER_RANGE(Start, End)  { Start, End, End - Start + 1 }
> -
> -///
> -/// Structure used to describe a range of registers
> -///
> -typedef struct {
> -  EFI_SMM_SAVE_STATE_REGISTERStart;
> -  EFI_SMM_SAVE_STATE_REGISTEREnd;
> -  UINTN  Length;
> -} CPU_SMM_SAVE_STATE_REGISTER_RANGE;
> -
> -///
> -/// Structure used to build a lookup table to retrieve the widths and offsets
> -/// associated with each supported EFI_SMM_SAVE_STATE_REGISTER value
> -///
> -
> -#define SMM_SAVE_STATE_REGISTER_FIRST_INDEX  1
> -
> -typedef struct {
> -  UINT8  Width32;
> -  UINT8  Width64;
> -  UINT16 Offset32;
> -  UINT16 Offset64Lo;
> -  UINT16 Offset64Hi;
> -  BOOLEANWriteable;
> -} CPU_SMM_SAVE_STATE_LOOKUP_ENTRY;
> -
> -///
> -/// Table used by GetRegisterIndex() to convert an
> EFI_SMM_SAVE_STATE_REGISTER
> -//

Re: [edk2-devel] [PATCH v11 8/8] OvmfPkg: Uses MmSaveStateLib library

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: Abdul Lateef Attar 
> Sent: Saturday, May 6, 2023 12:07 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Paul Grimes
> ; Abner Chang ; Dong,
> Eric ; Ni, Ray ; Kumar, Rahul R
> ; Gerd Hoffmann ; Ard
> Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ;
> Abdul Lateef Attar 
> Subject: [PATCH v11 8/8] OvmfPkg: Uses MmSaveStateLib library
> 
> From: Abdul Lateef Attar 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
> 
> Uses new MmSaveStateLib library instance.
> 
> Cc: Paul Grimes 
> Cc: Abner Chang 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Signed-off-by: Abdul Lateef Attar 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 767 --
>  4 files changed, 5 insertions(+), 767 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index e333b8b41803..86fc9f6174b2 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -972,6 +972,7 @@ [Components]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib
> .inf
>}
> 
>#
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 25974230a27e..da5fd7042f4f 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -4,6 +4,7 @@
>  #  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  #  Copyright (c) Microsoft Corporation.
> +#  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -444,6 +445,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
>PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
> 
> SmmCpuRendezvousLib|UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCp
> uRendezvousLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib
> .inf
> 
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -990,6 +992,7 @@ [Components.X64]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib
> .inf
>}
> 
>#
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index c1762ffca445..ae706a5099c5 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -1066,6 +1066,7 @@ [Components]
>  
> 
> SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu
> /SmmCpuPlatformHookLibQemu.inf
> 
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeature
> sLib.inf
> +
> MmSaveStateLib|UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib
> .inf
>}
> 
>#
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> index a009123dae88..4c354bafe42f 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> @@ -578,773 +578,6 @@ SmmCpuFeaturesSetSmmRegister (
>ASSERT (FALSE);
>  }
> 
> -///
> -/// Macro used to simplify the lookup table entries of type
> -/// CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
> -///
> -#define SMM_CPU_OFFSET(Field)  OFFSET_OF
> (QEMU_SMRAM_SAVE_STATE_MAP, Field)
> -
> -///
> -/// Macro used to simplify the lookup table entries of type
> -/// CPU_SMM_SAVE_STATE_REGISTER_RANGE
> -///
> -#define SMM_REGISTER_RANGE(Start, End)  { Start, End, End - Start + 1 }
> -
> -///
> -/// Structure used to describe a range of registers
> -///
> -typedef struct {
> -  EFI_SMM_SAVE_STATE_REGISTERStart;
> -  EFI_SMM_SAVE_STATE_REGISTEREnd;
> -  UINTN  Length;
> -} CPU_SMM_SAVE_STATE_REGISTER_RANGE;
> -
> -///
> -/// Structure used to build a lookup table to retrieve the widths and offsets
> -/// associated with each supported EFI_SMM_SAVE_STATE_REGISTER value
> -///
> -
> -#define SMM_SAVE_STATE_REGISTER_FIRST_INDEX  1
> -
> -typedef struct {
> -  UINT8  Width32;
> -  UINT8  Width64;
> -  UINT16 Offset32;
> -  UINT16 Offset64Lo;
> -  UINT16 Offset64Hi;
> -  BOOLEANWriteable;
> -} CPU_SMM_SAVE_STATE_LOOKUP_ENTRY;
> -
> -///
> -/// Table used by GetRegisterIndex() to convert an
> EFI_SMM_SAVE_STATE_REGISTER
> -/// value to an index into a table of type
> CPU_SMM_SAVE_STATE_LOOKUP

[edk2-devel] [PATCH v3 2/2] Ext4Pkg: Advertise CSUM_SEED as supported

[Pedro Falcato]

We had added support for CSUM_SEED but accidentally forgot to advertise
it in gSupportedIncompatFeat. This made it (erroneously) impossible to
mount CSUM_SEED filesystems.

Detected by attempting to mount a relatively new mkfs.ext4'd filesystem.

Cc: Marvin Häuser 
Signed-off-by: Pedro Falcato 
Reviewed-by: Marvin Häuser 
---
 Features/Ext4Pkg/Ext4Dxe/Superblock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Features/Ext4Pkg/Ext4Dxe/Superblock.c 
b/Features/Ext4Pkg/Ext4Dxe/Superblock.c
index 3f56de93c105..604925b582c1 100644
--- a/Features/Ext4Pkg/Ext4Dxe/Superblock.c
+++ b/Features/Ext4Pkg/Ext4Dxe/Superblock.c
@@ -1,7 +1,7 @@
 /** @file
   Superblock managing routines
 
-  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
+  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -18,7 +18,7 @@ STATIC CONST UINT32  gSupportedIncompatFeat =
   EXT4_FEATURE_INCOMPAT_64BIT | EXT4_FEATURE_INCOMPAT_DIRDATA |
   EXT4_FEATURE_INCOMPAT_FLEX_BG | EXT4_FEATURE_INCOMPAT_FILETYPE |
   EXT4_FEATURE_INCOMPAT_EXTENTS | EXT4_FEATURE_INCOMPAT_LARGEDIR |
-  EXT4_FEATURE_INCOMPAT_MMP | EXT4_FEATURE_INCOMPAT_RECOVER;
+  EXT4_FEATURE_INCOMPAT_MMP | EXT4_FEATURE_INCOMPAT_RECOVER | 
EXT4_FEATURE_INCOMPAT_CSUM_SEED;
 
 // Future features that may be nice additions in the future:
 // 1) Btree support: Required for write support and would speed up lookups in 
large directories.
-- 
2.40.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104397): https://edk2.groups.io/g/devel/message/104397
Mute This Topic: https://groups.io/mt/98786843/21656
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] Ext4Pkg: Improve extent node validation on the number of entries

[Pedro Falcato]

Improve the extent tree node validation by validating the number of
entries the node advertises against the theoretical max (derived from
the size of on-disk structs and the block size (or i_data, if inline
extents).

Previously, we did not validate the number of entries. This could be
exploited for out-of-bounds reads and crashes.

Cc: Marvin Häuser 
Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
Reported-by: Savva Mitrofanov 
Signed-off-by: Pedro Falcato 
---
 Features/Ext4Pkg/Ext4Dxe/Extents.c | 32 ++
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c 
b/Features/Ext4Pkg/Ext4Dxe/Extents.c
index 9e4364e50d99..2b82417c9e10 100644
--- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
+++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
@@ -1,7 +1,7 @@
 /** @file
   Extent related routines
 
-  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
+  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -80,13 +80,15 @@ Ext4GetInoExtentHeader (
 /**
Checks if an extent header is valid.
@param[in]  Header Pointer to the EXT4_EXTENT_HEADER structure.
+   @param[in]  MaxEntries Maximum number of entries possible for this 
tree node.
 
@return TRUE if valid, FALSE if not.
 **/
 STATIC
 BOOLEAN
 Ext4ExtentHeaderValid (
-  IN CONST EXT4_EXTENT_HEADER  *Header
+  IN CONST EXT4_EXTENT_HEADER  *Header,
+  IN UINT16MaxEntries
   )
 {
   if (Header->eh_depth > EXT4_EXTENT_TREE_MAX_DEPTH) {
@@ -99,6 +101,18 @@ Ext4ExtentHeaderValid (
 return FALSE;
   }
 
+  // Note: We do not need to check eh_entries here, as the next branch makes 
sure max >= entries
+  if (Header->eh_max > MaxEntries) {
+DEBUG ((
+  DEBUG_ERROR,
+  "[ext4] Invalid extent header max entries (%u eh_max, "
+  "theoretical max is %u) (larger than permitted)\n",
+  Header->eh_max,
+  MaxEntries
+  ));
+return FALSE;
+  }
+
   if (Header->eh_max < Header->eh_entries) {
 DEBUG ((
   DEBUG_ERROR,
@@ -212,6 +226,9 @@ Ext4ExtentIdxLeafBlock (
   return LShiftU64 (Index->ei_leaf_hi, 32) | Index->ei_leaf_lo;
 }
 
+// Results of sizeof(i_data) / sizeof(extent) - 1 = 4
+#define EXT4_NR_INLINE_EXTENTS  4
+
 /**
Retrieves an extent from an EXT4 inode.
@param[in]  Partition Pointer to the opened EXT4 partition.
@@ -237,6 +254,7 @@ Ext4GetExtent (
   EXT4_EXTENT_HEADER  *ExtHeader;
   EXT4_EXTENT_INDEX   *Index;
   EFI_STATUS  Status;
+  UINT32  MaxExtentsPerNode;
   EXT4_BLOCK_NR   BlockNumber;
 
   Inode  = File->Inode;
@@ -275,12 +293,17 @@ Ext4GetExtent (
 
   ExtHeader = Ext4GetInoExtentHeader (Inode);
 
-  if (!Ext4ExtentHeaderValid (ExtHeader)) {
+  if (!Ext4ExtentHeaderValid (ExtHeader, EXT4_NR_INLINE_EXTENTS)) {
 return EFI_VOLUME_CORRUPTED;
   }
 
   CurrentDepth = ExtHeader->eh_depth;
 
+  // A single node fits into a single block, so we can only have (BlockSize / 
sizeof(EXT4_EXTENT)) - 1
+  // extents in a single node. Note the -1, because both leaf and internal 
node headers are 12 bytes,
+  // and so are individual entries.
+  MaxExtentsPerNode = (Partition->BlockSize / sizeof (EXT4_EXTENT)) - 1;
+
   while (ExtHeader->eh_depth != 0) {
 CurrentDepth--;
 // While depth != 0, we're traversing the tree itself and not any leaves
@@ -309,6 +332,7 @@ Ext4GetExtent (
 }
 
 // Read the leaf block onto the previously-allocated buffer.
+
 Status = Ext4ReadBlocks (Partition, Buffer, 1, BlockNumber);
 if (EFI_ERROR (Status)) {
   FreePool (Buffer);
@@ -317,7 +341,7 @@ Ext4GetExtent (
 
 ExtHeader = Buffer;
 
-if (!Ext4ExtentHeaderValid (ExtHeader)) {
+if (!Ext4ExtentHeaderValid (ExtHeader, MaxExtentsPerNode)) {
   FreePool (Buffer);
   return EFI_VOLUME_CORRUPTED;
 }
-- 
2.40.1



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

Re: [edk2-devel] [PATCH v3 1/2] Ext4Pkg: Improve extent node validation on the number of entries

[Marvin Häuser]

Reviewed-by: Marvin Häuser 

> On 9. May 2023, at 17:49, Pedro Falcato  wrote:
> 
> Improve the extent tree node validation by validating the number of
> entries the node advertises against the theoretical max (derived from
> the size of on-disk structs and the block size (or i_data, if inline
> extents).
> 
> Previously, we did not validate the number of entries. This could be
> exploited for out-of-bounds reads and crashes.
> 
> Cc: Marvin Häuser 
> Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
> Reported-by: Savva Mitrofanov 
> Signed-off-by: Pedro Falcato 
> ---
> Features/Ext4Pkg/Ext4Dxe/Extents.c | 32 ++
> 1 file changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c 
> b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> index 9e4364e50d99..2b82417c9e10 100644
> --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> +++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> @@ -1,7 +1,7 @@
> /** @file
>   Extent related routines
> 
> -  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
> +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
> **/
> 
> @@ -80,13 +80,15 @@ Ext4GetInoExtentHeader (
> /**
>Checks if an extent header is valid.
>@param[in]  Header Pointer to the EXT4_EXTENT_HEADER structure.
> +   @param[in]  MaxEntries Maximum number of entries possible for 
> this tree node.
> 
>@return TRUE if valid, FALSE if not.
> **/
> STATIC
> BOOLEAN
> Ext4ExtentHeaderValid (
> -  IN CONST EXT4_EXTENT_HEADER  *Header
> +  IN CONST EXT4_EXTENT_HEADER  *Header,
> +  IN UINT16MaxEntries
>   )
> {
>   if (Header->eh_depth > EXT4_EXTENT_TREE_MAX_DEPTH) {
> @@ -99,6 +101,18 @@ Ext4ExtentHeaderValid (
> return FALSE;
>   }
> 
> +  // Note: We do not need to check eh_entries here, as the next branch makes 
> sure max >= entries
> +  if (Header->eh_max > MaxEntries) {
> +DEBUG ((
> +  DEBUG_ERROR,
> +  "[ext4] Invalid extent header max entries (%u eh_max, "
> +  "theoretical max is %u) (larger than permitted)\n",
> +  Header->eh_max,
> +  MaxEntries
> +  ));
> +return FALSE;
> +  }
> +
>   if (Header->eh_max < Header->eh_entries) {
> DEBUG ((
>   DEBUG_ERROR,
> @@ -212,6 +226,9 @@ Ext4ExtentIdxLeafBlock (
>   return LShiftU64 (Index->ei_leaf_hi, 32) | Index->ei_leaf_lo;
> }
> 
> +// Results of sizeof(i_data) / sizeof(extent) - 1 = 4
> +#define EXT4_NR_INLINE_EXTENTS  4
> +
> /**
>Retrieves an extent from an EXT4 inode.
>@param[in]  Partition Pointer to the opened EXT4 partition.
> @@ -237,6 +254,7 @@ Ext4GetExtent (
>   EXT4_EXTENT_HEADER  *ExtHeader;
>   EXT4_EXTENT_INDEX   *Index;
>   EFI_STATUS  Status;
> +  UINT32  MaxExtentsPerNode;
>   EXT4_BLOCK_NR   BlockNumber;
> 
>   Inode  = File->Inode;
> @@ -275,12 +293,17 @@ Ext4GetExtent (
> 
>   ExtHeader = Ext4GetInoExtentHeader (Inode);
> 
> -  if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +  if (!Ext4ExtentHeaderValid (ExtHeader, EXT4_NR_INLINE_EXTENTS)) {
> return EFI_VOLUME_CORRUPTED;
>   }
> 
>   CurrentDepth = ExtHeader->eh_depth;
> 
> +  // A single node fits into a single block, so we can only have (BlockSize 
> / sizeof(EXT4_EXTENT)) - 1
> +  // extents in a single node. Note the -1, because both leaf and internal 
> node headers are 12 bytes,
> +  // and so are individual entries.
> +  MaxExtentsPerNode = (Partition->BlockSize / sizeof (EXT4_EXTENT)) - 1;
> +
>   while (ExtHeader->eh_depth != 0) {
> CurrentDepth--;
> // While depth != 0, we're traversing the tree itself and not any leaves
> @@ -309,6 +332,7 @@ Ext4GetExtent (
> }
> 
> // Read the leaf block onto the previously-allocated buffer.
> +
> Status = Ext4ReadBlocks (Partition, Buffer, 1, BlockNumber);
> if (EFI_ERROR (Status)) {
>   FreePool (Buffer);
> @@ -317,7 +341,7 @@ Ext4GetExtent (
> 
> ExtHeader = Buffer;
> 
> -if (!Ext4ExtentHeaderValid (ExtHeader)) {
> +if (!Ext4ExtentHeaderValid (ExtHeader, MaxExtentsPerNode)) {
>   FreePool (Buffer);
>   return EFI_VOLUME_CORRUPTED;
> }
> -- 
> 2.40.1
> 



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

[edk2-devel] [PATCH edk2-platforms 1/4] QemuOpenBoardPkg: Use MdeModulePkg's SataControllerDxe

[Pedro Falcato]

As part of an effort to remove OvmfPkg/SataControllerDxe, switch to the
generic version in MdeModulePkg.

Tested-by: Pedro Falcato 
Cc: Isaac Oram 
Cc: Theo Jehl 
Signed-off-by: Pedro Falcato 
---
 Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc   | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc 
b/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
index 283c235b44c0..5a63848f26cd 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
+++ b/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
@@ -21,7 +21,7 @@
 [Components.$(DXE_ARCH)]
   OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
diff --git a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc 
b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
index f5c317c83e6a..b409a6164412 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
+++ b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
@@ -160,7 +160,7 @@
 [Components.$(DXE_ARCH)]
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf 
b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
index 5af0f0f2faa2..b106828460a9 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
+++ b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
@@ -266,7 +266,7 @@ SET gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaSize  
   = 0x80
   INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
-  INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 
   INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH edk2-platforms 3/4] LoongArchQemuPkg: Use MdeModulePkg's SataControllerDxe

[Pedro Falcato]

As part of an effort to remove OvmfPkg/SataControllerDxe, switch to the
generic version in MdeModulePkg.

Cc: Bibo Mao 
Cc: Xianglai li 
Cc: Chao Li 
Signed-off-by: Pedro Falcato 
---
 Platform/Loongson/LoongArchQemuPkg/Loongson.dsc | 2 +-
 Platform/Loongson/LoongArchQemuPkg/Loongson.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
index 465e9229a2c4..6875e39cc604 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
@@ -550,7 +550,7 @@
   #
   # IDE/SCSI
   #
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
index 03cbcf86301b..8a759c0238ee 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
@@ -178,7 +178,7 @@ INF  OvmfPkg/PlatformDxe/Platform.inf
 #
 # SATA/SCSI
 #
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
-- 
2.40.1



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

[edk2-devel] [PATCH edk2-platforms 4/4] Silicon/Armada7k8k: Use MdeModulePkg's SataControllerDxe

[Pedro Falcato]

As part of an effort to remove OvmfPkg/SataControllerDxe, switch to the
generic version in MdeModulePkg.

Cc: Leif Lindholm 
Cc: Marcin Wojtas 
Signed-off-by: Pedro Falcato 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index b64c0ffdeed9..a135cb88b898 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -492,7 +492,7 @@
   # SATA
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 
   # USB
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
index bc7284652bbd..ffde102dcfc0 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
@@ -145,7 +145,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   # SATA
   INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
-  INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 
   # USB
   INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH edk2-platforms 2/4] SbsaQemu: Use MdeModulePkg's SataControllerDxe

[Pedro Falcato]

As part of an effort to remove OvmfPkg/SataControllerDxe, switch to the
generic version in MdeModulePkg.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Graeme Gregory 
Cc: Radoslaw Biernacki 
Signed-off-by: Pedro Falcato 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 +-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 79dd200ca7fc..9ca030cfe9a7 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -705,7 +705,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
   
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   # IDE/AHCI Support
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
index 781215707c3d..677cea6344dc 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
@@ -298,7 +298,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
   # IDE/AHCI Support
-  INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH edk2-platforms 0/4] Remove usage of OvmfPkg/SataControllerDxe

[Pedro Falcato]

As part of an effort undertaken by me (in another patchset) to unify and replace
OvmfPkg/SataControllerDxe with MdeModulePkg's, this patchset replaces all usage
of it with MdeModulePkg/Bus/Pci/SataControllerDxe.

The two drivers were forked from the same code and are mostly 
code-and-functionality
equivalent.

This patchset should *not* rely on the edk2 patchset, and should be merged 
before edk2's
(as to not break platforms).

Cc: Isaac Oram 
Cc: Theo Jehl 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Graeme Gregory 
Cc: Radoslaw Biernacki 
Cc: Bibo Mao 
Cc: Xianglai li 
Cc: Chao Li 
Cc: Marcin Wojtas 

Pedro Falcato (4):
  QemuOpenBoardPkg: Use MdeModulePkg's SataControllerDxe
  SbsaQemu: Use MdeModulePkg's SataControllerDxe
  LoongArchQemuPkg: Use MdeModulePkg's SataControllerDxe
  Silicon/Armada7k8k: Use MdeModulePkg's SataControllerDxe

 Platform/Loongson/LoongArchQemuPkg/Loongson.dsc   | 2 +-
 Platform/Loongson/LoongArchQemuPkg/Loongson.fdf   | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc   | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf   | 2 +-
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc   | 2 +-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf   | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.40.1



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

[edk2-devel] [PATCH v2 02/12] MdeModulePkg/SataControllerDxe: Log expected errors at DEBUG_INFO level

[Pedro Falcato]

When a UEFI_DRIVER attempts to open a protocol interface with BY_DRIVER
attribute that it already has open with BY_DRIVER attribute,
OpenProtocol() returns EFI_ALREADY_STARTED. This is not an error. The
UEFI-2.7 spec currently says,

> EFI_ALREADY_STARTED -- Attributes is BY_DRIVER and there is an item on
>the open list with an attribute of BY_DRIVER
>whose agent handle is the same as AgentHandle.

Downgrade the log mask for this one condition to DEBUG_INFO, in
SataControllerStart(). This will match the log mask of the other two
informative messages in this function.

(ported from commit 5dfba97)

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Pedro Falcato 
---
 .../Bus/Pci/SataControllerDxe/SataController.c| 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c 
b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
index d67a3e69f649..277bc6182db6 100644
--- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -358,10 +358,12 @@ SataControllerStart (
   UINTN TotalCount;
   UINT64Supports;
   UINT8 MaxPortNumber;
+  UINTN BailLogMask;
 
   DEBUG ((DEBUG_INFO, "SataControllerStart start\n"));
 
-  Private = NULL;
+  Private = NULL;
+  BailLogMask = DEBUG_ERROR;
 
   //
   // Now test and open PCI I/O Protocol
@@ -375,6 +377,15 @@ SataControllerStart (
   EFI_OPEN_PROTOCOL_BY_DRIVER
   );
   if (EFI_ERROR (Status)) {
+if (Status == EFI_ALREADY_STARTED) {
+  //
+  // This is an expected condition for OpenProtocol() / BY_DRIVER, in a
+  // DriverBindingStart() member function; degrade the log mask to
+  // DEBUG_INFO in order to reduce log pollution.
+  //
+  BailLogMask = DEBUG_INFO;
+}
+
 goto Bail;
   }
 
@@ -555,7 +566,7 @@ FreeSataPrivate:
 ClosePciIo:
   gBS->CloseProtocol (Controller, &gEfiPciIoProtocolGuid, 
This->DriverBindingHandle, Controller);
 Bail:
-  DEBUG ((DEBUG_ERROR, "SataControllerStart error return status = %r\n", 
Status));
+  DEBUG ((BailLogMask, "SataControllerStart error return status = %r\n", 
Status));
   return Status;
 }
 
-- 
2.40.1



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

[edk2-devel] [PATCH v2 01/12] MdeModulePkg/SataControllerDxe: Clean up error handling in Start()

[Pedro Falcato]

Clean up error handling using cascading labels + goto.

(port of commit 379b179 + bcab714)

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Pedro Falcato 
---
 .../Pci/SataControllerDxe/SataController.c| 80 ---
 1 file changed, 35 insertions(+), 45 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c 
b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
index f661efaec7e9..d67a3e69f649 100644
--- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -375,8 +375,7 @@ SataControllerStart (
   EFI_OPEN_PROTOCOL_BY_DRIVER
   );
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "SataControllerStart error. return status = %r\n", 
Status));
-return Status;
+goto Bail;
   }
 
   //
@@ -385,7 +384,7 @@ SataControllerStart (
   Private = AllocateZeroPool (sizeof (EFI_SATA_CONTROLLER_PRIVATE_DATA));
   if (Private == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
-goto Done;
+goto ClosePciIo;
   }
 
   //
@@ -412,7 +411,7 @@ SataControllerStart (
 &Private->OriginalPciAttributes
 );
   if (EFI_ERROR (Status)) {
-goto Done;
+goto FreeSataPrivate;
   }
 
   DEBUG ((
@@ -428,7 +427,7 @@ SataControllerStart (
 &Supports
 );
   if (EFI_ERROR (Status)) {
-goto Done;
+goto FreeSataPrivate;
   }
 
   DEBUG ((DEBUG_INFO, "Supported PCI Attributes = 0x%llx\n", Supports));
@@ -441,7 +440,7 @@ SataControllerStart (
NULL
);
   if (EFI_ERROR (Status)) {
-goto Done;
+goto FreeSataPrivate;
   }
 
   DEBUG ((DEBUG_INFO, "Enabled PCI Attributes = 0x%llx\n", Supports));
@@ -456,7 +455,7 @@ SataControllerStart (
 );
   if (EFI_ERROR (Status)) {
 ASSERT (FALSE);
-goto Done;
+goto RestorePciAttributes;
   }
 
   if (IS_PCI_IDE (&PciData)) {
@@ -470,7 +469,7 @@ SataControllerStart (
 DEBUG ((DEBUG_INFO, "Ports Implemented(PI) = 0x%x\n", Data32));
 if (Data32 == 0) {
   Status = EFI_UNSUPPORTED;
-  goto Done;
+  goto RestorePciAttributes;
 }
 
 MaxPortNumber = 31;
@@ -502,19 +501,19 @@ SataControllerStart (
   Private->DisqualifiedModes = AllocateZeroPool ((sizeof 
(EFI_ATA_COLLECTIVE_MODE)) * TotalCount);
   if (Private->DisqualifiedModes == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
-goto Done;
+goto RestorePciAttributes;
   }
 
   Private->IdentifyData = AllocateZeroPool ((sizeof (EFI_IDENTIFY_DATA)) * 
TotalCount);
   if (Private->IdentifyData == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
-goto Done;
+goto FreeDisqualifiedModes;
   }
 
   Private->IdentifyValid = AllocateZeroPool ((sizeof (BOOLEAN)) * TotalCount);
   if (Private->IdentifyValid == NULL) {
 Status = EFI_OUT_OF_RESOURCES;
-goto Done;
+goto FreeIdentifyData;
   }
 
   //
@@ -527,46 +526,37 @@ SataControllerStart (
   NULL
   );
 
-Done:
   if (EFI_ERROR (Status)) {
-gBS->CloseProtocol (
-   Controller,
-   &gEfiPciIoProtocolGuid,
-   This->DriverBindingHandle,
-   Controller
-   );
-if (Private != NULL) {
-  if (Private->DisqualifiedModes != NULL) {
-FreePool (Private->DisqualifiedModes);
-  }
-
-  if (Private->IdentifyData != NULL) {
-FreePool (Private->IdentifyData);
-  }
-
-  if (Private->IdentifyValid != NULL) {
-FreePool (Private->IdentifyValid);
-  }
-
-  if (Private->PciAttributesChanged) {
-//
-// Restore original PCI attributes
-//
-PciIo->Attributes (
- PciIo,
- EfiPciIoAttributeOperationSet,
- Private->OriginalPciAttributes,
- NULL
- );
-  }
-
-  FreePool (Private);
-}
+goto FreeIdentifyValid;
   }
 
   DEBUG ((DEBUG_INFO, "SataControllerStart end with %r\n", Status));
 
   return Status;
+
+FreeIdentifyValid:
+  FreePool (Private->IdentifyValid);
+FreeIdentifyData:
+  FreePool (Private->IdentifyData);
+FreeDisqualifiedModes:
+  FreePool (Private->DisqualifiedModes);
+RestorePciAttributes:
+  //
+  // Restore original PCI attributes
+  //
+  Private->PciIo->Attributes (
+Private->PciIo,
+EfiPciIoAttributeOperationSet,
+Private->OriginalPciAttributes,
+NULL
+);
+FreeSataPrivate:
+  FreePool (Private);
+ClosePciIo:
+  gBS->CloseProtocol (Controller, &gEfiPciIoProtocolGuid, 
This->DriverBindingHandle, Controller);
+Bail:
+  DEBUG ((DEBUG_ERROR, "SataControllerStart error return status = %r\n", 
Status));
+  return Status;
 }
 
 /**
-- 
2.40.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104406):

[edk2-devel] [PATCH v2 03/12] MdeModulePkg/SataControllerDxe: Remove useless null check

[Pedro Falcato]

ASSERT (Private != NULL) already covers this check.
See commit 81310a6.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Mike Maslenkin 
Signed-off-by: Pedro Falcato 
---
 .../Pci/SataControllerDxe/SataController.c| 44 +--
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c 
b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
index 277bc6182db6..f0ffd311d7b9 100644
--- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -626,34 +626,32 @@ SataControllerStop (
 return Status;
   }
 
-  if (Private != NULL) {
-if (Private->DisqualifiedModes != NULL) {
-  FreePool (Private->DisqualifiedModes);
-}
-
-if (Private->IdentifyData != NULL) {
-  FreePool (Private->IdentifyData);
-}
+  if (Private->DisqualifiedModes != NULL) {
+FreePool (Private->DisqualifiedModes);
+  }
 
-if (Private->IdentifyValid != NULL) {
-  FreePool (Private->IdentifyValid);
-}
+  if (Private->IdentifyData != NULL) {
+FreePool (Private->IdentifyData);
+  }
 
-if (Private->PciAttributesChanged) {
-  //
-  // Restore original PCI attributes
-  //
-  Private->PciIo->Attributes (
-Private->PciIo,
-EfiPciIoAttributeOperationSet,
-Private->OriginalPciAttributes,
-NULL
-);
-}
+  if (Private->IdentifyValid != NULL) {
+FreePool (Private->IdentifyValid);
+  }
 
-FreePool (Private);
+  if (Private->PciAttributesChanged) {
+//
+// Restore original PCI attributes
+//
+Private->PciIo->Attributes (
+  Private->PciIo,
+  EfiPciIoAttributeOperationSet,
+  Private->OriginalPciAttributes,
+  NULL
+  );
   }
 
+  FreePool (Private);
+
   //
   // Close protocols opened by Sata Controller driver
   //
-- 
2.40.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104408): https://edk2.groups.io/g/devel/message/104408
Mute This Topic: https://groups.io/mt/98787856/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/12] OvmfPkg: Replace the OVMF-specific SataControllerDxe with the generic one

[Pedro Falcato]

This patch-set replaces the OVMF specific SataControllerDxe with the 
MdeModulePkg/Bus/Pci one.
They were both forked from the same code, and are code-and-functionality 
similar. As such, there
seems to be no need for duplication here.

The first four pages both replay OvmfPkg/SataControllerDxe commits and fix up a 
couple of details.
The rest of the patches (minus the last) replace OvmfPkg/SataControllerDxe with 
the MdeModulePkg variant.
The last patch, finally, removes the thing.

Tested by booting in QEMU (Q35 (AHCI) and PC (IDE)).
More testing from other, alternative platforms is desired, although breakage 
seems unlikely.

This patchset (or at least, the last patch) depends on the edk2-platforms patch 
series to get merged.

(+CC Laszlo as the author of the original SataControllerDxe patches)

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc :Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Cc: Rebecca Cran 
Cc: Peter Grehan 
Cc: Corvin Köhne 
Cc: Sebastien Boeuf 
Cc: Anthony Perard 
Cc: Julien Grall 
Cc: Laszlo Ersek 

Changes:
v2:
  - Address Laszlo's feedback wrt commit to port into MdeModulePkg
  - Address Laszlo's feedback wrt how to split the removal of the driver and 
the patches for each sub-platform maintainer
  - Address Mike Maslenkin's feedback on the preexisting ASSERTs (Private != 
NULL)
  - Add Gerd's ACK and Tested-by (conservatively) to patches 6 and 12 (since 
they are remotely QEMU related) 

Pedro Falcato (12):
  MdeModulePkg/SataControllerDxe: Clean up error handling in Start()
  MdeModulePkg/SataControllerDxe: Log expected errors at DEBUG_INFO
level
  MdeModulePkg/SataControllerDxe: Remove useless null check
  MdeModulePkg/SataControllerDxe: Fix up ASSERTS (Private != NULL)
  OvmfPkg: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/Microvm: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/Bhyve: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/CloudHv: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/IntelTdx: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/AmdSev: Replace the OVMF-specific SataControllerDxe
  OvmfPkg/Xen: Replace the OVMF-specific SataControllerDxe
  OvmfPkg: Remove SataControllerDxe

 .../Pci/SataControllerDxe/SataController.c|  146 ++-
 OvmfPkg/AmdSev/AmdSevX64.dsc  |2 +-
 OvmfPkg/AmdSev/AmdSevX64.fdf  |2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc|2 +-
 OvmfPkg/Bhyve/BhyveX64.fdf|2 +-
 OvmfPkg/CloudHv/CloudHvX64.dsc|2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf|2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc  |2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf  |2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc|2 +-
 OvmfPkg/Microvm/MicrovmX64.fdf|2 +-
 OvmfPkg/OvmfPkgIa32.dsc   |2 +-
 OvmfPkg/OvmfPkgIa32.fdf   |2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc|2 +-
 OvmfPkg/OvmfPkgIa32X64.fdf|2 +-
 OvmfPkg/OvmfPkgX64.dsc|2 +-
 OvmfPkg/OvmfPkgX64.fdf|2 +-
 OvmfPkg/OvmfXen.dsc   |2 +-
 OvmfPkg/OvmfXen.fdf   |2 +-
 OvmfPkg/SataControllerDxe/ComponentName.c |  170 ---
 OvmfPkg/SataControllerDxe/SataController.c| 1112 -
 OvmfPkg/SataControllerDxe/SataController.h|  544 
 .../SataControllerDxe/SataControllerDxe.inf   |   43 -
 23 files changed, 90 insertions(+), 1961 deletions(-)
 delete mode 100644 OvmfPkg/SataControllerDxe/ComponentName.c
 delete mode 100644 OvmfPkg/SataControllerDxe/SataController.c
 delete mode 100644 OvmfPkg/SataControllerDxe/SataController.h
 delete mode 100644 OvmfPkg/SataControllerDxe/SataControllerDxe.inf

-- 
2.40.1



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

[edk2-devel] [PATCH v2 04/12] MdeModulePkg/SataControllerDxe: Fix up ASSERTS (Private != NULL)

[Pedro Falcato]

ASSERT (Private != NULL) (where Private = CR(...)) is ineffective as
CR(Ptr, Type, Member, Sig) either returns Ptr - offsetof(Type, Member),
or ASSERTS on the signature, so it's unlikely to ever return NULL
(must be passed a pointer = member's offset, or in this case, 0x4).

ASSERT on This != NULL instead.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Mike Maslenkin 
Signed-off-by: Pedro Falcato 
---
 MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c 
b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
index f0ffd311d7b9..ea0116071c6a 100644
--- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -611,7 +611,6 @@ SataControllerStop (
   }
 
   Private = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (IdeInit);
-  ASSERT (Private != NULL);
 
   //
   // Uninstall the IDE Controller Init Protocol from this instance
@@ -745,8 +744,8 @@ IdeInitGetChannelInfo (
 {
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *Private;
 
+  ASSERT (This != NULL);
   Private = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (This);
-  ASSERT (Private != NULL);
 
   if (Channel < This->ChannelCount) {
 *Enabled= TRUE;
@@ -845,8 +844,8 @@ IdeInitSubmitData (
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *Private;
   UINTN DeviceIndex;
 
+  ASSERT (This != NULL);
   Private = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (This);
-  ASSERT (Private != NULL);
 
   if ((Channel >= This->ChannelCount) || (Device >= Private->DeviceCount)) {
 return EFI_INVALID_PARAMETER;
@@ -924,8 +923,8 @@ IdeInitDisqualifyMode (
   EFI_SATA_CONTROLLER_PRIVATE_DATA  *Private;
   UINTN DeviceIndex;
 
+  ASSERT (This != NULL);
   Private = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (This);
-  ASSERT (Private != NULL);
 
   if ((Channel >= This->ChannelCount) || (BadModes == NULL) || (Device >= 
Private->DeviceCount)) {
 return EFI_INVALID_PARAMETER;
@@ -1017,8 +1016,8 @@ IdeInitCalculateMode (
   EFI_STATUSStatus;
   UINTN DeviceIndex;
 
+  ASSERT (This != NULL);
   Private = SATA_CONTROLLER_PRIVATE_DATA_FROM_THIS (This);
-  ASSERT (Private != NULL);
 
   if ((Channel >= This->ChannelCount) || (SupportedModes == NULL) || (Device 
>= Private->DeviceCount)) {
 return EFI_INVALID_PARAMETER;
-- 
2.40.1



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

[edk2-devel] [PATCH v2 05/12] OvmfPkg: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/OvmfPkgIa32.dsc| 2 +-
 OvmfPkg/OvmfPkgIa32.fdf| 2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 +-
 OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
 OvmfPkg/OvmfPkgX64.dsc | 2 +-
 OvmfPkg/OvmfPkgX64.fdf | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index e333b8b41803..42cc28f8adce 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -830,7 +830,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index c9c938439759..4c9be963a74d 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -271,7 +271,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 25974230a27e..9f01384d037f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -844,7 +844,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index f52219e0c26d..7f599f15e341 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -272,7 +272,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c1762ffca445..e59871af211b 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -918,7 +918,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 00c7f8849fb8..41912fc1bece 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -297,7 +297,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 06/12] OvmfPkg/Microvm: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Microvm platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/Microvm/MicrovmX64.dsc | 2 +-
 OvmfPkg/Microvm/MicrovmX64.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 5f671bc3840d..8f8db7556667 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -768,7 +768,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index 0d44e8dfbae8..eda24a3ec9bc 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -229,7 +229,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 07/12] OvmfPkg/Bhyve: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Bhyve platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Rebecca Cran 
Cc: Peter Grehan 
Cc: Corvin Köhne 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/Bhyve/BhyveX64.dsc | 2 +-
 OvmfPkg/Bhyve/BhyveX64.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index d0d2712c5662..bb317a50e6af 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -698,7 +698,7 @@
   MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.fdf b/OvmfPkg/Bhyve/BhyveX64.fdf
index 153b3cfeba55..3f6270c048cc 100644
--- a/OvmfPkg/Bhyve/BhyveX64.fdf
+++ b/OvmfPkg/Bhyve/BhyveX64.fdf
@@ -239,7 +239,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 08/12] OvmfPkg/CloudHv: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the CloudHv platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Sebastien Boeuf 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/CloudHv/CloudHvX64.dsc | 2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 2a1139daaa19..fcc07ecc4167 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -787,7 +787,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index 72de7bcdad66..387f305ed8cf 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -262,7 +262,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 09/12] OvmfPkg/IntelTdx: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the IntelTdx platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index d4403f11a7c6..eec41d3f6527 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -667,7 +667,7 @@
   OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index 73dffc104301..69ed7a9bc6f4 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -222,7 +222,7 @@ INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
 INF  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
 INF  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 10/12] OvmfPkg/AmdSev: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the AmdSev platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
 OvmfPkg/AmdSev/AmdSevX64.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 943c4eed9831..4c726fd55529 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -668,7 +668,7 @@
   MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index fec08468d3e0..463bd3e9ef15 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -250,7 +250,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 11/12] OvmfPkg/Xen: Replace the OVMF-specific SataControllerDxe

[Pedro Falcato]

Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the OvmfXen platform.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Anthony Perard 
Cc: Julien Grall 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/OvmfXen.dsc | 2 +-
 OvmfPkg/OvmfXen.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1f44ec86c9c7..fa2a732fe33d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -636,7 +636,7 @@
   MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 8be69338c7b6..bdff7c52d80a 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -279,7 +279,7 @@ INF  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 INF  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
 INF  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-INF  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+INF  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 INF  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
 INF  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
 INF  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
-- 
2.40.1



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

[edk2-devel] [PATCH v2 12/12] OvmfPkg: Remove SataControllerDxe

[Pedro Falcato]

Now that OvmfPkg/SataControllerDxe and its MdeModulePkg counterpart have
been unified, and no in-tree uses of the OVMF variant remain, let's
delete it.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Signed-off-by: Pedro Falcato 
---
 OvmfPkg/SataControllerDxe/ComponentName.c |  170 ---
 OvmfPkg/SataControllerDxe/SataController.c| 1112 -
 OvmfPkg/SataControllerDxe/SataController.h|  544 
 .../SataControllerDxe/SataControllerDxe.inf   |   43 -
 4 files changed, 1869 deletions(-)
 delete mode 100644 OvmfPkg/SataControllerDxe/ComponentName.c
 delete mode 100644 OvmfPkg/SataControllerDxe/SataController.c
 delete mode 100644 OvmfPkg/SataControllerDxe/SataController.h
 delete mode 100644 OvmfPkg/SataControllerDxe/SataControllerDxe.inf

diff --git a/OvmfPkg/SataControllerDxe/ComponentName.c 
b/OvmfPkg/SataControllerDxe/ComponentName.c
deleted file mode 100644
index 7b5912bab822..
--- a/OvmfPkg/SataControllerDxe/ComponentName.c
+++ /dev/null
@@ -1,170 +0,0 @@
-/** @file
-  UEFI Component Name(2) protocol implementation for Sata Controller driver.
-
-  Copyright (c) 2011, Intel Corporation. All rights reserved.
-  SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#include "SataController.h"
-
-//
-/// EFI Component Name Protocol
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  
gSataControllerComponentName = {
-  SataControllerComponentNameGetDriverName,
-  SataControllerComponentNameGetControllerName,
-  "eng"
-};
-
-//
-/// EFI Component Name 2 Protocol
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL  
gSataControllerComponentName2 = {
-  
(EFI_COMPONENT_NAME2_GET_DRIVER_NAME)SataControllerComponentNameGetDriverName,
-  
(EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)SataControllerComponentNameGetControllerName,
-  "en"
-};
-
-//
-/// Driver Name Strings
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE  
mSataControllerDriverNameTable[] = {
-  {
-"eng;en",
-(CHAR16 *)L"Sata Controller Init Driver"
-  },
-  {
-NULL,
-NULL
-  }
-};
-
-///
-/// Controller Name Strings
-///
-GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE  
mSataControllerControllerNameTable[] = {
-  {
-"eng;en",
-(CHAR16 *)L"Sata Controller"
-  },
-  {
-NULL,
-NULL
-  }
-};
-
-/**
-  Retrieves a Unicode string that is the user readable name of the UEFI Driver.
-
-  @param This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
-  @param Language   A pointer to a three character ISO 639-2 language 
identifier.
-This is the language of the driver name that the caller
-is requesting, and it must match one of the languages 
specified
-in SupportedLanguages.  The number of languages 
supported by a
-driver is up to the driver writer.
-  @param DriverName A pointer to the Unicode string to return.  This 
Unicode string
-is the name of the driver specified by This in the 
language
-specified by Language.
-
-  @retval EFI_SUCCESS   The Unicode string for the Driver specified by 
This
-and the language specified by Language was 
returned
-in DriverName.
-  @retval EFI_INVALID_PARAMETER Language is NULL.
-  @retval EFI_INVALID_PARAMETER DriverName is NULL.
-  @retval EFI_UNSUPPORTED   The driver specified by This does not support 
the
-language specified by Language.
-**/
-EFI_STATUS
-EFIAPI
-SataControllerComponentNameGetDriverName (
-  IN EFI_COMPONENT_NAME_PROTOCOL  *This,
-  IN CHAR8*Language,
-  OUT CHAR16  **DriverName
-  )
-{
-  return LookupUnicodeString2 (
-   Language,
-   This->SupportedLanguages,
-   mSataControllerDriverNameTable,
-   DriverName,
-   (BOOLEAN)(This == &gSataControllerComponentName)
-   );
-}
-
-/**
-  Retrieves a Unicode string that is the user readable name of the controller
-  that is being managed by an UEFI Driver.
-
-  @param This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL 
instance.
-  @param ControllerHandle   The handle of a controller that the driver 
specified by
-This is managing.  This handle specifies the 
controller
-whose name is to be returned.
-  @param ChildHandle OPTIONAL   The handle of the child controller to retrieve 
the name
-of.  This is an optional parameter that may be 
NULL.  It
-will be NULL for device drivers.  It will also 
be NULL
-for a bus drivers that wish to retrieve the 
name of the
-bus controller.  It will not be NU

Re: [edk2-devel] [PATCH v2 00/12] OvmfPkg: Replace the OVMF-specific SataControllerDxe with the generic one

[Pedro Falcato]

On Tue, May 9, 2023 at 5:32 PM Pedro Falcato via groups.io
 wrote:
>
> This patch-set replaces the OVMF specific SataControllerDxe with the 
> MdeModulePkg/Bus/Pci one.
> They were both forked from the same code, and are code-and-functionality 
> similar. As such, there
> seems to be no need for duplication here.
>
> The first four pages both replay OvmfPkg/SataControllerDxe commits and fix up 
> a couple of details.
> The rest of the patches (minus the last) replace OvmfPkg/SataControllerDxe 
> with the MdeModulePkg variant.
> The last patch, finally, removes the thing.
>
> Tested by booting in QEMU (Q35 (AHCI) and PC (IDE)).
> More testing from other, alternative platforms is desired, although breakage 
> seems unlikely.
>
> This patchset (or at least, the last patch) depends on the edk2-platforms 
> patch series to get merged.
>
> (+CC Laszlo as the author of the original SataControllerDxe patches)
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc :Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Rebecca Cran 
> Cc: Peter Grehan 
> Cc: Corvin Köhne 
> Cc: Sebastien Boeuf 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Cc: Laszlo Ersek 
>
> Changes:
> v2:
>   - Address Laszlo's feedback wrt commit to port into MdeModulePkg
>   - Address Laszlo's feedback wrt how to split the removal of the driver and 
> the patches for each sub-platform maintainer
>   - Address Mike Maslenkin's feedback on the preexisting ASSERTs (Private != 
> NULL)
>   - Add Gerd's ACK and Tested-by (conservatively) to patches 6 and 12 (since 
> they are remotely QEMU related)
>
> Pedro Falcato (12):
>   MdeModulePkg/SataControllerDxe: Clean up error handling in Start()
>   MdeModulePkg/SataControllerDxe: Log expected errors at DEBUG_INFO
> level
>   MdeModulePkg/SataControllerDxe: Remove useless null check
>   MdeModulePkg/SataControllerDxe: Fix up ASSERTS (Private != NULL)
>   OvmfPkg: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/Microvm: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/Bhyve: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/CloudHv: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/IntelTdx: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/AmdSev: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg/Xen: Replace the OVMF-specific SataControllerDxe
>   OvmfPkg: Remove SataControllerDxe
>
>  .../Pci/SataControllerDxe/SataController.c|  146 ++-
>  OvmfPkg/AmdSev/AmdSevX64.dsc  |2 +-
>  OvmfPkg/AmdSev/AmdSevX64.fdf  |2 +-
>  OvmfPkg/Bhyve/BhyveX64.dsc|2 +-
>  OvmfPkg/Bhyve/BhyveX64.fdf|2 +-
>  OvmfPkg/CloudHv/CloudHvX64.dsc|2 +-
>  OvmfPkg/CloudHv/CloudHvX64.fdf|2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.fdf  |2 +-
>  OvmfPkg/Microvm/MicrovmX64.dsc|2 +-
>  OvmfPkg/Microvm/MicrovmX64.fdf|2 +-
>  OvmfPkg/OvmfPkgIa32.dsc   |2 +-
>  OvmfPkg/OvmfPkgIa32.fdf   |2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc|2 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf|2 +-
>  OvmfPkg/OvmfPkgX64.dsc|2 +-
>  OvmfPkg/OvmfPkgX64.fdf|2 +-
>  OvmfPkg/OvmfXen.dsc   |2 +-
>  OvmfPkg/OvmfXen.fdf   |2 +-
>  OvmfPkg/SataControllerDxe/ComponentName.c |  170 ---
>  OvmfPkg/SataControllerDxe/SataController.c| 1112 -
>  OvmfPkg/SataControllerDxe/SataController.h|  544 
>  .../SataControllerDxe/SataControllerDxe.inf   |   43 -
>  23 files changed, 90 insertions(+), 1961 deletions(-)
>  delete mode 100644 OvmfPkg/SataControllerDxe/ComponentName.c
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataController.c
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataController.h
>  delete mode 100644 OvmfPkg/SataControllerDxe/SataControllerDxe.inf

... I knew I forgot something...
PR + git branch: https://github.com/tianocore/edk2/pull/4370

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104418): https://edk2.groups.io/g/devel/message/104418
Mute This Topic: https://groups.io/mt/98787852/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] SecurityPkg: Add missing break in Tpm2TestParms

[Rebecca Cran]

Add missing break in Tpm2TestParms.

Reported in https://github.com/tianocore/edk2/issues/4073

Signed-off-by: Rebecca Cran 
---
 SecurityPkg/Library/Tpm2CommandLib/Tpm2Capability.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Capability.c 
b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Capability.c
index 9db301ec9a90..f0e6019a47be 100644
--- a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Capability.c
+++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Capability.c
@@ -743,6 +743,7 @@ Tpm2TestParms (
   return EFI_INVALID_PARAMETER;
   }
 
+  break;
 case TPM_ALG_SYMCIPHER:
   WriteUnaligned16 ((UINT16 *)Buffer, SwapBytes16 
(Parameters->parameters.symDetail.algorithm));
   Buffer += sizeof (UINT16);
-- 
2.39.2



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

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: Replace the OVMF-specific SataControllerDxe with the generic one

[Pedro Falcato]

On Tue, May 9, 2023 at 9:06 AM Laszlo Ersek  wrote:
>
> On 5/8/23 23:52, Pedro Falcato wrote:
> > This patch-set replaces the OVMF specific SataControllerDxe with the
> > MdeModulePkg/Bus/Pci one. They were both forked from the same code,
> > and are code-and-functionality similar. As such, there seems to be no
> > need for duplication here.
>
> Man, the *coat-turning* of the MdeModulePkg maintainers is just
> staggering here.
>
> When we first wanted to use SataControllerDxe in OvmfPkg, the driver
> used to exist in DuetPkg. Clearly we attempted to upstream it to
> MdeModulePkg too, and to consume it in OvmfPkg from there. But n,
> the argument was that SataControllerDxe was inherently platform
> specific, and so every platform was going to need its own.
>
> Do read the first paragraph of commit 12e92a23ada7 ("OvmfPkg: copy
> SataControllerDxe from DuetPkg", 2015-09-22):
>
> Edk2 maintainers reached the consensus that SataControllerDxe was
> inherently platform specific, for which reason it was not appropriate for
> either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use
> it, it should either reference it directly from under DuetPkg, or copy it.
>
> Also note the date: September 2015.
>
> And then, less than a year later, Intel introduced a so-called "generic"
> SataController driver, in commit fda951df6827 ("MdeModulePkg: add
> generic SataController driver.", 2016-08-03). Completely useless
> (empty!) commit message of course, as it was usual back then. Splendid
Timeless.

> example of pretending ignorance, of falsifying history, and of *not*
> reaching out to people to trim their platform code now that "we have
> changed our minds". Stay classy, Intel.
>
> (But, I need not tell you, Pedro, this; there's a reason why the Ext4
> driver is not under MdeModulePkg/Universal/Disk, alongside UdfDxe; or at
> least in edk2, alongside FatPkg. Until Intel doesn't need the driver,
> it's not a "generic enough" driver; period.)

:

>
> If you review "Maintainers.txt" exactly at commit fda951df6827, it gets
> funnier. Back then, MdeModulePkg had two maintainers, Feng Tian and Star
> Zeng. The patch was authored by Feng, i.e., one of the package
> maintainers. The other maintainer (Star) didn't review the patch (based
> on the commit message); two other Intel developers did. I see this as a
> lack of accountability.
>
> And then for comparison, consider:
>
> - PciSegmentInfoLib (from commit e457c1f65d18),
>
> - BasePciSegmentLibSegmentInfo and DxeRuntimePciSegmentLibSegmentInfo
>   instances of PciSegmentLib (from child commit 5c9bb86f171c), which
>   consume the above.
>
> These were added to MdePkg in August 2017. And if you check the tree:
>
> - DxeRuntimePciSegmentLibSegmentInfo remains unused *to this day* (even
>   in edk2-platforms!),
>
> - BasePciSegmentLibSegmentInfo was first put to use in edk2 nearly three
>   years later, in UefiPayloadPkg -- in commit 3900a63e3a1b
>   ("UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo
>   HOB", 2020-06-24).
>
> So DxeRuntimePciSegmentLibSegmentInfo has been "generic enough" to be in
> *MdePkg* for 5+ years without a single open source consumer, and
> BasePciSegmentLibSegmentInfo had been generic enough to exist in MdePkg
> for ~3 years without a single open-source consumer.
>
> It's difficult to get used to this double standard.
>
> Anyway, end of history lesson.

Hah. Thanks for the history lesson. I had understood most of the story
behind SataControllerDxe by reading commit messages but those Pci libs
are new to me :v

>
> > First I manually replayed OvmfPkg/SataControllerDxe's patches on top
> > of the generic one. Only one seemed to make sense. The second patch
> > removes OvmfPkg/SataControllerDxe and replaces it for all platforms
> > under OvmfPkg.
>
> bcab71413407 --> 24fee0528c32; OK
> 81310a62be31 --> your patch#1 in this series (which I wasn't CC'd on,
>  apparently)
Sorry for that, CC'd you on all patches now (sorry for the spam!)

> 0b448dd8b27c --> not necessary
> 5dfba97c4d59 --> missing
>
> I disagree with your assessment that commit 5dfba97c4d59 does not make
> sense for the MdeModulePkg driver. If you have a "silent" firmware build
> that only enables the DEBUG_ERROR bit in the debug message mask (I'm too
> lazy to look up the precise PCD name now), then the driver will
> needlessly pollute the error log.
>
> Therefore I suggest porting 5dfba97c4d59 as well.
>
> In turn, 5dfba97c4d59 depends (contextually at least) on commit
> 379b17965f0f ("OvmfPkg: SataControllerDxe: add cascading error handling
> to Start()", 2015-09-22), so you might or might not want to port that
> one too.

Ack. I ported 5dfba97... as you suggested and 379b17... as the error
handling ultimately gets cleaner.
>
> > Tested by booting in QEMU (Q35 (AHCI) and PC (IDE)).
> > More testing from other, alternative platforms is desired, although
> > breakage seems unlikely.
>
> Eliminating code duplic

Re: [edk2-devel] [PATCH v3 1/2] Ext4Pkg: Improve extent node validation on the number of entries

[Pedro Falcato]

Thank you! Merged the patchset as 82f4b39 and 9247980, respectively.

On Tue, May 9, 2023 at 5:07 PM Marvin Häuser  wrote:
>
> Reviewed-by: Marvin Häuser 
>
> > On 9. May 2023, at 17:49, Pedro Falcato  wrote:
> >
> > Improve the extent tree node validation by validating the number of
> > entries the node advertises against the theoretical max (derived from
> > the size of on-disk structs and the block size (or i_data, if inline
> > extents).
> >
> > Previously, we did not validate the number of entries. This could be
> > exploited for out-of-bounds reads and crashes.
> >
> > Cc: Marvin Häuser 
> > Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
> > Reported-by: Savva Mitrofanov 
> > Signed-off-by: Pedro Falcato 
> > ---
> > Features/Ext4Pkg/Ext4Dxe/Extents.c | 32 ++
> > 1 file changed, 28 insertions(+), 4 deletions(-)
> >
> > diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c 
> > b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> > index 9e4364e50d99..2b82417c9e10 100644
> > --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> > +++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> > @@ -1,7 +1,7 @@
> > /** @file
> >   Extent related routines
> >
> > -  Copyright (c) 2021 - 2022 Pedro Falcato All rights reserved.
> > +  Copyright (c) 2021 - 2023 Pedro Falcato All rights reserved.
> >   SPDX-License-Identifier: BSD-2-Clause-Patent
> > **/
> >
> > @@ -80,13 +80,15 @@ Ext4GetInoExtentHeader (
> > /**
> >Checks if an extent header is valid.
> >@param[in]  Header Pointer to the EXT4_EXTENT_HEADER 
> > structure.
> > +   @param[in]  MaxEntries Maximum number of entries possible for 
> > this tree node.
> >
> >@return TRUE if valid, FALSE if not.
> > **/
> > STATIC
> > BOOLEAN
> > Ext4ExtentHeaderValid (
> > -  IN CONST EXT4_EXTENT_HEADER  *Header
> > +  IN CONST EXT4_EXTENT_HEADER  *Header,
> > +  IN UINT16MaxEntries
> >   )
> > {
> >   if (Header->eh_depth > EXT4_EXTENT_TREE_MAX_DEPTH) {
> > @@ -99,6 +101,18 @@ Ext4ExtentHeaderValid (
> > return FALSE;
> >   }
> >
> > +  // Note: We do not need to check eh_entries here, as the next branch 
> > makes sure max >= entries
> > +  if (Header->eh_max > MaxEntries) {
> > +DEBUG ((
> > +  DEBUG_ERROR,
> > +  "[ext4] Invalid extent header max entries (%u eh_max, "
> > +  "theoretical max is %u) (larger than permitted)\n",
> > +  Header->eh_max,
> > +  MaxEntries
> > +  ));
> > +return FALSE;
> > +  }
> > +
> >   if (Header->eh_max < Header->eh_entries) {
> > DEBUG ((
> >   DEBUG_ERROR,
> > @@ -212,6 +226,9 @@ Ext4ExtentIdxLeafBlock (
> >   return LShiftU64 (Index->ei_leaf_hi, 32) | Index->ei_leaf_lo;
> > }
> >
> > +// Results of sizeof(i_data) / sizeof(extent) - 1 = 4
> > +#define EXT4_NR_INLINE_EXTENTS  4
> > +
> > /**
> >Retrieves an extent from an EXT4 inode.
> >@param[in]  Partition Pointer to the opened EXT4 partition.
> > @@ -237,6 +254,7 @@ Ext4GetExtent (
> >   EXT4_EXTENT_HEADER  *ExtHeader;
> >   EXT4_EXTENT_INDEX   *Index;
> >   EFI_STATUS  Status;
> > +  UINT32  MaxExtentsPerNode;
> >   EXT4_BLOCK_NR   BlockNumber;
> >
> >   Inode  = File->Inode;
> > @@ -275,12 +293,17 @@ Ext4GetExtent (
> >
> >   ExtHeader = Ext4GetInoExtentHeader (Inode);
> >
> > -  if (!Ext4ExtentHeaderValid (ExtHeader)) {
> > +  if (!Ext4ExtentHeaderValid (ExtHeader, EXT4_NR_INLINE_EXTENTS)) {
> > return EFI_VOLUME_CORRUPTED;
> >   }
> >
> >   CurrentDepth = ExtHeader->eh_depth;
> >
> > +  // A single node fits into a single block, so we can only have 
> > (BlockSize / sizeof(EXT4_EXTENT)) - 1
> > +  // extents in a single node. Note the -1, because both leaf and internal 
> > node headers are 12 bytes,
> > +  // and so are individual entries.
> > +  MaxExtentsPerNode = (Partition->BlockSize / sizeof (EXT4_EXTENT)) - 1;
> > +
> >   while (ExtHeader->eh_depth != 0) {
> > CurrentDepth--;
> > // While depth != 0, we're traversing the tree itself and not any leaves
> > @@ -309,6 +332,7 @@ Ext4GetExtent (
> > }
> >
> > // Read the leaf block onto the previously-allocated buffer.
> > +
> > Status = Ext4ReadBlocks (Partition, Buffer, 1, BlockNumber);
> > if (EFI_ERROR (Status)) {
> >   FreePool (Buffer);
> > @@ -317,7 +341,7 @@ Ext4GetExtent (
> >
> > ExtHeader = Buffer;
> >
> > -if (!Ext4ExtentHeaderValid (ExtHeader)) {
> > +if (!Ext4ExtentHeaderValid (ExtHeader, MaxExtentsPerNode)) {
> >   FreePool (Buffer);
> >   return EFI_VOLUME_CORRUPTED;
> > }
> > --
> > 2.40.1
> >
>


-- 
Pedro


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

[edk2-devel] Side effects of enabling PML5 in EFI

[Pedro Falcato]

Hi all,

(+CC people vaguely related to the EFI spec, the PML5 implementation
and kernel EFI boot code)

As a result of the latest 5-level paging patches, I've been looking
into how tiano supports PML5.
This raised a question: Doesn't enabling PML5 in-firmware break
compatibility with non-PML5-aware bootloaders and kernels?

>From an architectural point of view:
- PML5 is enabled in CR4.LA57, but may only be toggled when not in
IA32e mode (so, only in 32-bit)
- Trying to mindlessly write to CR4 will #GP, and loading a 4-level
page tables will crash with probable page faults or #GPs

>From an EFI spec point of view:
- Whereas other architectures (arm64 for instance) specify the MMU
state in detail, the x64 bits do not specify anything beyond "Paging
enabled" (see 2.3.4). Which pre-PML5, was obviously well defined.
- When under boot services, this is likely not a problem as page
tables are owned by boot services. Unless they touch them as defined
in "2.3.4.3. Enabling Paging or Alternate Translations in an
Application", which may run into problems.

>From an OS kernel/bootloader point of view:
- A PML5 aware kernel/bootloader will likely correctly identify the
PML5 capability and enable LA57, load 5-level page tables. As such,
this scenario always works.
- A non-PML5-aware one may incorrectly overwrite LA57 (and #GP), or
just load a 4-level paging structure into CR3, and thus disastrously
crash.

So, how is any of this supposed to work?

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104422): https://edk2.groups.io/g/devel/message/104422
Mute This Topic: https://groups.io/mt/98788948/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 V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Isaac Oram]

Rereading that thread and this request, other opinions, etc, I am convinced 
that the simpler interface and board responsibility is the correct short/medium 
term answer.  I don't have an opinion on Mike Kinney's question on encapsulated 
services.  I generally like that design, though I am sensitive to Michael 
Kubacki's feedback that variable services are too complex as it is.  I guess it 
probably depends a lot on the specifics of the proposal.  That said, it is 
pretty easy to migrate from a board specific solution to a more base layer 
solution in the future, so adopting this now doesn't seem harmful to me.

Raghava, can you look at Michael's fix?  It looks nearly identical to yours and 
general convention is to accept the earlier one in case of collision I believe. 
 I like his PCD naming a little better, but both are fine to me.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, May 9, 2023 8:26 AM
To: devel@edk2.groups.io; Kinney, Michael D ; Chiu, 
Chasel ; Oram, Isaac W ; Gudla, 
Raghava 
Cc: Desimone, Nathaniel L ; Kubacki, Michael 
; Chaganty, Rangasai V 

Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

At the surface, this looks similar to the following patch I sent a while
back:

https://edk2.groups.io/g/devel/message/92644

That triggered a thread where we had a similar discussion about 
LargeVariableLib responsibilities, etc.

We still have a fork of SaveMemoryConfig that uses the PCD I sent in the
patch:

https://github.com/microsoft/mu_common_intel_min_platform/blob/release/202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf

I believe a challenge that led to adding compression (in our fork code) to 
SaveMemoryConfig was the fact that the data was produced in pre-mem PEI and 
compression is expensive in CAR.

In general though, I still believe that it is simpler to separate data mutation 
from service APIs. Platforms can manipulate data to achieve their goals whether 
size, security, and so on and the service APIs provide a simple interface to 
store and retrieve that data blob.

I'd also like to see FSP reduce in size and eliminate operations that are not 
essential to its role and can be consolidated/reused in the wrapper.

Thanks,
Michael

On 5/8/2023 5:48 PM, Michael D Kinney wrote:
> When reviewing the Variable feature that adds integrity and 
> confidentiality, I suggested that the interface between the Variable 
> services and the NVStorage could provide an abstraction to 
> encode/decode the stored data that would support encryption, 
> compression, or both.  Could also support a platform policy for which 
> variables the encode/decode operation is applied.
> 
> Wouldn't that be a better abstraction than piecemeal adding these 
> features?
> 
> Doesn't mean that this can't go in as-is.  But would be an opportunity 
> to consolidate in the future.
> 
> Mike
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Chiu, 
>> Chasel
>> Sent: Monday, May 8, 2023 12:37 PM
>> To: Oram, Isaac W ; Gudla, Raghava 
>> ; devel@edk2.groups.io
>> Cc: Desimone, Nathaniel L ; Kubacki, 
>> Michael ; Chaganty, Rangasai V 
>> ; Chiu, Chasel 
>> Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
>> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
>>
>>
>> Hi Isaac,
>>
>> Just my thoughts, I would vote for platform/bootloader to decide 
>> compressing the variable data before saving to NVRAM or not.
>> It should be optional and when platform having big SPI flash they 
>> might not want to do this.
>>
>> Thanks,
>> Chasel
>>
>>
>>> -Original Message-
>>> From: Oram, Isaac W 
>>> Sent: Monday, May 8, 2023 12:15 PM
>>> To: Gudla, Raghava ; devel@edk2.groups.io
>>> Cc: Chiu, Chasel ; Desimone, Nathaniel L 
>>> ; Kubacki, Michael 
>>> ; Chaganty, Rangasai V 
>>> 
>>> Subject: RE: [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig:
>>> Support NVS Data compression.
>>>
>>> The proposed implementation is fine and I will reviewed-by and push 
>>> if that
>> is
>>> the desired direction.
>>>
>>> My question is if we generally like the design of doing compression 
>>> in
>> common
>>> MinPlatform code, decompression in board specific FSP wrapper code.  
>>> The alternative design is to do compression and decompression inside the 
>>> FSP.
>> This
>>> seems like a slightly simpler separation of responsibilities.
>>> The board code is responsible for save/restore, the FSP code is 
>>> responsible
>> for
>>> data blob creation and use.  Data integrity, authentication, 
>>> compression, etc
>> all
>>> can be done based on more detailed knowledge of the silicon
>> implementation
>>> requirements.
>>>
>>> I can see another argument though that doing it inside FSP 
>>> effectively forces both bootloader and FSP to carry 
>>> compression/decompression.  The compression/decompression aren't 
>>> likely to need to be sili

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Michael Kubacki]

Thanks for reraising this. If you need me to rebase or help in anyway 
let me know.


On 5/9/2023 1:41 PM, Gudla, Raghava wrote:

My patch is based on Michael's fix. I took his change to do a PoC a while back 
and totally forgot that his patch is still available. We can proceed to merge 
Michael's patch.

Thanks,
Raghava

-Original Message-
From: Oram, Isaac W 
Sent: Tuesday, May 9, 2023 10:35 AM
To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney, Michael D 
; Chiu, Chasel ; Gudla, Raghava 

Cc: Desimone, Nathaniel L ; Kubacki, Michael 
; Chaganty, Rangasai V 
Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

Rereading that thread and this request, other opinions, etc, I am convinced 
that the simpler interface and board responsibility is the correct short/medium 
term answer.  I don't have an opinion on Mike Kinney's question on encapsulated 
services.  I generally like that design, though I am sensitive to Michael 
Kubacki's feedback that variable services are too complex as it is.  I guess it 
probably depends a lot on the specifics of the proposal.  That said, it is 
pretty easy to migrate from a board specific solution to a more base layer 
solution in the future, so adopting this now doesn't seem harmful to me.

Raghava, can you look at Michael's fix?  It looks nearly identical to yours and 
general convention is to accept the earlier one in case of collision I believe. 
 I like his PCD naming a little better, but both are fine to me.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, May 9, 2023 8:26 AM
To: devel@edk2.groups.io; Kinney, Michael D ; Chiu, Chasel 
; Oram, Isaac W ; Gudla, Raghava 

Cc: Desimone, Nathaniel L ; Kubacki, Michael 
; Chaganty, Rangasai V 
Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

At the surface, this looks similar to the following patch I sent a while
back:

https://edk2.groups.io/g/devel/message/92644

That triggered a thread where we had a similar discussion about 
LargeVariableLib responsibilities, etc.

We still have a fork of SaveMemoryConfig that uses the PCD I sent in the
patch:

https://github.com/microsoft/mu_common_intel_min_platform/blob/release/202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf

I believe a challenge that led to adding compression (in our fork code) to 
SaveMemoryConfig was the fact that the data was produced in pre-mem PEI and 
compression is expensive in CAR.

In general though, I still believe that it is simpler to separate data mutation 
from service APIs. Platforms can manipulate data to achieve their goals whether 
size, security, and so on and the service APIs provide a simple interface to 
store and retrieve that data blob.

I'd also like to see FSP reduce in size and eliminate operations that are not 
essential to its role and can be consolidated/reused in the wrapper.

Thanks,
Michael

On 5/8/2023 5:48 PM, Michael D Kinney wrote:

When reviewing the Variable feature that adds integrity and
confidentiality, I suggested that the interface between the Variable
services and the NVStorage could provide an abstraction to
encode/decode the stored data that would support encryption,
compression, or both.  Could also support a platform policy for which variables 
the encode/decode operation is applied.

Wouldn't that be a better abstraction than piecemeal adding these
features?

Doesn't mean that this can't go in as-is.  But would be an opportunity
to consolidate in the future.

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu,
Chasel
Sent: Monday, May 8, 2023 12:37 PM
To: Oram, Isaac W ; Gudla, Raghava
; devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kubacki,
Michael ; Chaganty, Rangasai V
; Chiu, Chasel 
Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Hi Isaac,

Just my thoughts, I would vote for platform/bootloader to decide
compressing the variable data before saving to NVRAM or not.
It should be optional and when platform having big SPI flash they
might not want to do this.

Thanks,
Chasel



-Original Message-
From: Oram, Isaac W 
Sent: Monday, May 8, 2023 12:15 PM
To: Gudla, Raghava ; devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L
; Kubacki, Michael
; Chaganty, Rangasai V

Subject: RE: [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig:
Support NVS Data compression.

The proposed implementation is fine and I will reviewed-by and push
if that

is

the desired direction.

My question is if we generally like the design of doing compression
in

common

MinPlatform code, decompression in board specific FSP wrapper code.
The alternative design is to do compression and decompression inside the FSP.

This

seems like a slightly simpler separation of responsibilities.
The b

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Gudla, Raghava]

My patch is based on Michael's fix. I took his change to do a PoC a while back 
and totally forgot that his patch is still available. We can proceed to merge 
Michael's patch.

Thanks,
Raghava

-Original Message-
From: Oram, Isaac W  
Sent: Tuesday, May 9, 2023 10:35 AM
To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney, Michael D 
; Chiu, Chasel ; Gudla, 
Raghava 
Cc: Desimone, Nathaniel L ; Kubacki, Michael 
; Chaganty, Rangasai V 

Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

Rereading that thread and this request, other opinions, etc, I am convinced 
that the simpler interface and board responsibility is the correct short/medium 
term answer.  I don't have an opinion on Mike Kinney's question on encapsulated 
services.  I generally like that design, though I am sensitive to Michael 
Kubacki's feedback that variable services are too complex as it is.  I guess it 
probably depends a lot on the specifics of the proposal.  That said, it is 
pretty easy to migrate from a board specific solution to a more base layer 
solution in the future, so adopting this now doesn't seem harmful to me.

Raghava, can you look at Michael's fix?  It looks nearly identical to yours and 
general convention is to accept the earlier one in case of collision I believe. 
 I like his PCD naming a little better, but both are fine to me.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, May 9, 2023 8:26 AM
To: devel@edk2.groups.io; Kinney, Michael D ; Chiu, 
Chasel ; Oram, Isaac W ; Gudla, 
Raghava 
Cc: Desimone, Nathaniel L ; Kubacki, Michael 
; Chaganty, Rangasai V 

Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

At the surface, this looks similar to the following patch I sent a while
back:

https://edk2.groups.io/g/devel/message/92644

That triggered a thread where we had a similar discussion about 
LargeVariableLib responsibilities, etc.

We still have a fork of SaveMemoryConfig that uses the PCD I sent in the
patch:

https://github.com/microsoft/mu_common_intel_min_platform/blob/release/202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf

I believe a challenge that led to adding compression (in our fork code) to 
SaveMemoryConfig was the fact that the data was produced in pre-mem PEI and 
compression is expensive in CAR.

In general though, I still believe that it is simpler to separate data mutation 
from service APIs. Platforms can manipulate data to achieve their goals whether 
size, security, and so on and the service APIs provide a simple interface to 
store and retrieve that data blob.

I'd also like to see FSP reduce in size and eliminate operations that are not 
essential to its role and can be consolidated/reused in the wrapper.

Thanks,
Michael

On 5/8/2023 5:48 PM, Michael D Kinney wrote:
> When reviewing the Variable feature that adds integrity and 
> confidentiality, I suggested that the interface between the Variable 
> services and the NVStorage could provide an abstraction to 
> encode/decode the stored data that would support encryption, 
> compression, or both.  Could also support a platform policy for which 
> variables the encode/decode operation is applied.
> 
> Wouldn't that be a better abstraction than piecemeal adding these 
> features?
> 
> Doesn't mean that this can't go in as-is.  But would be an opportunity 
> to consolidate in the future.
> 
> Mike
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Chiu, 
>> Chasel
>> Sent: Monday, May 8, 2023 12:37 PM
>> To: Oram, Isaac W ; Gudla, Raghava 
>> ; devel@edk2.groups.io
>> Cc: Desimone, Nathaniel L ; Kubacki, 
>> Michael ; Chaganty, Rangasai V 
>> ; Chiu, Chasel 
>> Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
>> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
>>
>>
>> Hi Isaac,
>>
>> Just my thoughts, I would vote for platform/bootloader to decide 
>> compressing the variable data before saving to NVRAM or not.
>> It should be optional and when platform having big SPI flash they 
>> might not want to do this.
>>
>> Thanks,
>> Chasel
>>
>>
>>> -Original Message-
>>> From: Oram, Isaac W 
>>> Sent: Monday, May 8, 2023 12:15 PM
>>> To: Gudla, Raghava ; devel@edk2.groups.io
>>> Cc: Chiu, Chasel ; Desimone, Nathaniel L 
>>> ; Kubacki, Michael 
>>> ; Chaganty, Rangasai V 
>>> 
>>> Subject: RE: [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig:
>>> Support NVS Data compression.
>>>
>>> The proposed implementation is fine and I will reviewed-by and push 
>>> if that
>> is
>>> the desired direction.
>>>
>>> My question is if we generally like the design of doing compression 
>>> in
>> common
>>> MinPlatform code, decompression in board specific FSP wrapper code.  
>>> The alternative design is to do compression and decompression inside the 
>>> FSP.
>> This

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Chiu, Chasel]

Hi Michael Kubacki,

Since Rahava has rebased the patch it might be easier to add " Signed-off-by: 
Michael Kubacki " to Rahave's patch commit 
message so both of you are authors.
What do you think?

By the way, I found a bug in SaveMemoryConfig.c: FreePool() should be FreePages 
(CompressedData, CompressedAllocationPages);
Raghava, please help to fix it by sending V2 patch  (adding -v2 to git 
format-patch command)

Thanks,
Chasel



> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, May 9, 2023 11:06 AM
> To: Gudla, Raghava ; Oram, Isaac W
> ; devel@edk2.groups.io; Kinney, Michael D
> ; Chiu, Chasel 
> Cc: Desimone, Nathaniel L ; Kubacki, Michael
> ; Chaganty, Rangasai V
> 
> Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> 
> Thanks for reraising this. If you need me to rebase or help in anyway let me
> know.
> 
> On 5/9/2023 1:41 PM, Gudla, Raghava wrote:
> > My patch is based on Michael's fix. I took his change to do a PoC a while 
> > back
> and totally forgot that his patch is still available. We can proceed to merge
> Michael's patch.
> >
> > Thanks,
> > Raghava
> >
> > -Original Message-
> > From: Oram, Isaac W 
> > Sent: Tuesday, May 9, 2023 10:35 AM
> > To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney,
> > Michael D ; Chiu, Chasel
> > ; Gudla, Raghava 
> > Cc: Desimone, Nathaniel L ; Kubacki,
> > Michael ; Chaganty, Rangasai V
> > 
> > Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > Rereading that thread and this request, other opinions, etc, I am convinced
> that the simpler interface and board responsibility is the correct 
> short/medium
> term answer.  I don't have an opinion on Mike Kinney's question on
> encapsulated services.  I generally like that design, though I am sensitive to
> Michael Kubacki's feedback that variable services are too complex as it is.  I
> guess it probably depends a lot on the specifics of the proposal.  That said, 
> it is
> pretty easy to migrate from a board specific solution to a more base layer
> solution in the future, so adopting this now doesn't seem harmful to me.
> >
> > Raghava, can you look at Michael's fix?  It looks nearly identical to yours 
> > and
> general convention is to accept the earlier one in case of collision I 
> believe.  I
> like his PCD naming a little better, but both are fine to me.
> >
> > Regards,
> > Isaac
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael
> > Kubacki
> > Sent: Tuesday, May 9, 2023 8:26 AM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > ; Chiu, Chasel ;
> > Oram, Isaac W ; Gudla, Raghava
> > 
> > Cc: Desimone, Nathaniel L ; Kubacki,
> > Michael ; Chaganty, Rangasai V
> > 
> > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > At the surface, this looks similar to the following patch I sent a
> > while
> > back:
> >
> > https://edk2.groups.io/g/devel/message/92644
> >
> > That triggered a thread where we had a similar discussion about
> LargeVariableLib responsibilities, etc.
> >
> > We still have a fork of SaveMemoryConfig that uses the PCD I sent in
> > the
> > patch:
> >
> > https://github.com/microsoft/mu_common_intel_min_platform/blob/release
> >
> /202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.
> in
> > f
> >
> > I believe a challenge that led to adding compression (in our fork code) to
> SaveMemoryConfig was the fact that the data was produced in pre-mem PEI
> and compression is expensive in CAR.
> >
> > In general though, I still believe that it is simpler to separate data 
> > mutation
> from service APIs. Platforms can manipulate data to achieve their goals 
> whether
> size, security, and so on and the service APIs provide a simple interface to 
> store
> and retrieve that data blob.
> >
> > I'd also like to see FSP reduce in size and eliminate operations that are 
> > not
> essential to its role and can be consolidated/reused in the wrapper.
> >
> > Thanks,
> > Michael
> >
> > On 5/8/2023 5:48 PM, Michael D Kinney wrote:
> >> When reviewing the Variable feature that adds integrity and
> >> confidentiality, I suggested that the interface between the Variable
> >> services and the NVStorage could provide an abstraction to
> >> encode/decode the stored data that would support encryption,
> >> compression, or both.  Could also support a platform policy for which
> variables the encode/decode operation is applied.
> >>
> >> Wouldn't that be a better abstraction than piecemeal adding these
> >> features?
> >>
> >> Doesn't mean that this can't go in as-is.  But would be an
> >> opportunity to consolidate in the future.
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: devel@edk2.groups.io  On Behalf Of Chiu,
> >>> Chasel
> >>> Sent: Monday, May 8, 2023 12:37 PM
> >>> To: Oram,

Re: [edk2-devel] [PATCH v11 0/8] Adds AmdSmmCpuFeaturesLib and MmSaveStateLib

[Michael Kubacki]

I haven't followed the whole thread but looking at v11, I wanted to 
check on the following.


1. The library source files (for AmdMmSaveStateLib and 
IntelMmSaveStateLib) include several library headers (particularly in 
MmSaveStateLib/MmSaveState.h) but do not have a [LibraryClasses] section 
in their INF files. Is there a reason?


2. AmdMmSaveStateLib and IntelMmSaveStateLib depend on 
SmmServicesTableLib. Can they depend on MmServicesTableLib instead?


3. It seems resources like the EFER register LMA bit should be defined 
somewhere agnostic to the MmSaveState.h file in MmSaveStateLib. It is 
referenced in MdePkg/Include/Register/Intel/ArchitecturalMsr.h:


https://github.com/tianocore/edk2/blob/5215cd5baf6609e54050c69909273b7f5161c59e/MdePkg/Include/Register/Intel/ArchitecturalMsr.h#L6342

In any case, can the bit be defined in one location?

4. Your change to the SmmCpuFeaturesLib.h interface is not backward 
compatible and a build breaking change. I think that should be called 
out in your cover letter.


Thanks,
Michael

On 5/6/2023 12:06 AM, Abdul Lateef Attar via groups.io wrote:

PR: https://github.com/tianocore/edk2/pull/4341

V11: Delta changes
Drop the OVMF implementation of MmSaveStateLib
V10: Delta changes:
   Addressed review comments from Abner.
V9: Delta changes:
   Addressed review comments.
   Rename to MmSaveStateLib.
   Also rename SMM_ defines to MM_.
   Implemented OVMF MmSaveStateLib.
   Removes SmmCpuFeaturesReadSaveStateRegister and 
SmmCpuFeaturesWriteSaveStateRegister
   function interface.
V8 delta changes:
Addressed review comments from Abner,
Fix the whitespace error.
Seperate the Ovmf changes to another patch
V7 delta changes:
Adds SmmSmramSaveStateLib for Intel processor.
Integrate SmmSmramSaveStateLib library.
V6 delta changes:
Addressed review comments for Ray NI.
removed unnecessary EFIAPI.
V5 delta changes:
rebase to master branch.
updated Reviewed-by
V4 delta changes:
   rebase to master branch.
   added reviewed-by.
V3 delta changes:
   Addressed review comments from Abner chang.
   Re-arranged patch order.

Cc: Paul Grimes 
Cc: Abner Chang 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (8):
   MdePkg: Adds AMD SMRAM save state map
   UefiCpuPkg: Adds MmSaveStateLib library class
   UefiCpuPkg: Implements MmSaveStateLib library instance
   UefiCpuPkg/SmmCpuFeaturesLib: Restructure arch-dependent code
   UefiCpuPkg: Implements SmmCpuFeaturesLib for AMD Family
   UefiCpuPkg: Implements MmSaveStateLib for Intel
   UefiCpuPkg: Removes SmmCpuFeaturesReadSaveStateRegister
   OvmfPkg: Uses MmSaveStateLib library

  UefiCpuPkg/UefiCpuPkg.dec |   4 +
  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
  OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
  OvmfPkg/OvmfPkgX64.dsc|   1 +
  UefiCpuPkg/UefiCpuPkg.dsc |  14 +
  .../MmSaveStateLib/AmdMmSaveStateLib.inf  |  28 +
  .../MmSaveStateLib/IntelMmSaveStateLib.inf|  28 +
  .../AmdSmmCpuFeaturesLib.inf  |  38 +
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf  |   2 +
  .../Include/Register/Amd/SmramSaveStateMap.h  | 194 +
  UefiCpuPkg/Include/Library/MmSaveStateLib.h   |  70 ++
  .../Include/Library/SmmCpuFeaturesLib.h   |  52 --
  .../Library/MmSaveStateLib/MmSaveState.h  | 102 +++
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h|  56 +-
  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 767 --
  .../Library/MmSaveStateLib/AmdMmSaveState.c   | 309 +++
  .../Library/MmSaveStateLib/IntelMmSaveState.c | 413 ++
  .../MmSaveStateLib/MmSaveStateCommon.c| 138 
  .../SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c  | 387 +
  .../IntelSmmCpuFeaturesLib.c  |  70 ++
  .../SmmCpuFeaturesLibCommon.c | 128 ---
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c|  11 +-
  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c| 500 +---
  MdePkg/MdePkg.ci.yaml |   4 +-
  24 files changed, 1812 insertions(+), 1508 deletions(-)
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib.inf
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/IntelMmSaveStateLib.inf
  create mode 100644 
UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf
  create mode 100644 MdePkg/Include/Register/Amd/SmramSaveStateMap.h
  create mode 100644 UefiCpuPkg/Include/Library/MmSaveStateLib.h
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/MmSaveState.h
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/IntelMmSaveState.c
  create mode 100644 UefiCpuPkg/Library/MmSaveStateLib/MmSaveStateCommon.c
  create mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdS

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Michael Kubacki via groups.io]

I haven't done a deep comparison of the changes, but I'd lean toward using what 
is in the branch that I referenced earlier since it has been used for a while 
now.

Is there anything of value in the new set of changes?

Thanks,
Michael

-Original Message-
From: Chiu, Chasel  
Sent: Tuesday, May 9, 2023 2:56 PM
To: Michael Kubacki ; Gudla, Raghava 
; Oram, Isaac W ; 
devel@edk2.groups.io; Kinney, Michael D 
Cc: Desimone, Nathaniel L ; Michael Kubacki 
; Chaganty, Rangasai V 

Subject: [EXTERNAL] RE: [edk2-devel] [edk2-platforms:PATCH V1] 
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Hi Michael Kubacki,

Since Rahava has rebased the patch it might be easier to add " Signed-off-by: 
Michael Kubacki " to Rahave's patch commit 
message so both of you are authors.
What do you think?

By the way, I found a bug in SaveMemoryConfig.c: FreePool() should be FreePages 
(CompressedData, CompressedAllocationPages); Raghava, please help to fix it by 
sending V2 patch  (adding -v2 to git format-patch command)

Thanks,
Chasel



> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, May 9, 2023 11:06 AM
> To: Gudla, Raghava ; Oram, Isaac W 
> ; devel@edk2.groups.io; Kinney, Michael D 
> ; Chiu, Chasel 
> Cc: Desimone, Nathaniel L ; Kubacki, 
> Michael ; Chaganty, Rangasai V 
> 
> Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> 
> Thanks for reraising this. If you need me to rebase or help in anyway 
> let me know.
> 
> On 5/9/2023 1:41 PM, Gudla, Raghava wrote:
> > My patch is based on Michael's fix. I took his change to do a PoC a 
> > while back
> and totally forgot that his patch is still available. We can proceed 
> to merge Michael's patch.
> >
> > Thanks,
> > Raghava
> >
> > -Original Message-
> > From: Oram, Isaac W 
> > Sent: Tuesday, May 9, 2023 10:35 AM
> > To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney, 
> > Michael D ; Chiu, Chasel 
> > ; Gudla, Raghava 
> > Cc: Desimone, Nathaniel L ; Kubacki, 
> > Michael ; Chaganty, Rangasai V 
> > 
> > Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > Rereading that thread and this request, other opinions, etc, I am 
> > convinced
> that the simpler interface and board responsibility is the correct 
> short/medium term answer.  I don't have an opinion on Mike Kinney's 
> question on encapsulated services.  I generally like that design, 
> though I am sensitive to Michael Kubacki's feedback that variable 
> services are too complex as it is.  I guess it probably depends a lot 
> on the specifics of the proposal.  That said, it is pretty easy to 
> migrate from a board specific solution to a more base layer solution in the 
> future, so adopting this now doesn't seem harmful to me.
> >
> > Raghava, can you look at Michael's fix?  It looks nearly identical 
> > to yours and
> general convention is to accept the earlier one in case of collision I 
> believe.  I like his PCD naming a little better, but both are fine to me.
> >
> > Regards,
> > Isaac
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of 
> > Michael Kubacki
> > Sent: Tuesday, May 9, 2023 8:26 AM
> > To: devel@edk2.groups.io; Kinney, Michael D 
> > ; Chiu, Chasel ; 
> > Oram, Isaac W ; Gudla, Raghava 
> > 
> > Cc: Desimone, Nathaniel L ; Kubacki, 
> > Michael ; Chaganty, Rangasai V 
> > 
> > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > At the surface, this looks similar to the following patch I sent a 
> > while
> > back:
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed
> > k2.groups.io%2Fg%2Fdevel%2Fmessage%2F92644&data=05%7C01%7Cmichael.ku
> > backi%40microsoft.com%7C05c93413c875400acef708db50bf197d%7C72f988bf8
> > 6f141af91ab2d7cd011db47%7C1%7C0%7C638192553936149621%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000%7C%7C%7C&sdata=E4hpQLMgLy0BKHngjpec88AI0v3TZ8xgxebjU0
> > SS0FM%3D&reserved=0
> >
> > That triggered a thread where we had a similar discussion about
> LargeVariableLib responsibilities, etc.
> >
> > We still have a fork of SaveMemoryConfig that uses the PCD I sent in 
> > the
> > patch:
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.com%2Fmicrosoft%2Fmu_common_intel_min_platform%2Fblob%2Frelease
> > &data=05%7C01%7Cmichael.kubacki%40microsoft.com%7C05c93413c875400ace
> > f708db50bf197d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63819255
> > 3936305834%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lXFLZV78CPev
> > UL7De1%2B6RtHaKWQcjnXx6IFABcmWJ54%3D&reserved=0
> >
> /202208/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.
> in
> > f
> >
> > I believe a challenge that led to add

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Chiu, Chasel]

Just reviewed the branch code and it is functionality the same so agree we can 
switch to Mike's implementation.
Would you help to rebase and send updated patch for reviewing?

Thanks,
Chasel



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki via groups.io
> Sent: Tuesday, May 9, 2023 12:18 PM
> To: Chiu, Chasel ; Michael Kubacki
> ; Gudla, Raghava ;
> Oram, Isaac W ; devel@edk2.groups.io; Kinney,
> Michael D 
> Cc: Desimone, Nathaniel L ; Chaganty,
> Rangasai V 
> Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> 
> I haven't done a deep comparison of the changes, but I'd lean toward using
> what is in the branch that I referenced earlier since it has been used for a 
> while
> now.
> 
> Is there anything of value in the new set of changes?
> 
> Thanks,
> Michael
> 
> -Original Message-
> From: Chiu, Chasel 
> Sent: Tuesday, May 9, 2023 2:56 PM
> To: Michael Kubacki ; Gudla, Raghava
> ; Oram, Isaac W ;
> devel@edk2.groups.io; Kinney, Michael D 
> Cc: Desimone, Nathaniel L ; Michael Kubacki
> ; Chaganty, Rangasai V
> 
> Subject: [EXTERNAL] RE: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> 
> 
> Hi Michael Kubacki,
> 
> Since Rahava has rebased the patch it might be easier to add " Signed-off-by:
> Michael Kubacki " to Rahave's patch commit
> message so both of you are authors.
> What do you think?
> 
> By the way, I found a bug in SaveMemoryConfig.c: FreePool() should be
> FreePages (CompressedData, CompressedAllocationPages); Raghava, please
> help to fix it by sending V2 patch  (adding -v2 to git format-patch command)
> 
> Thanks,
> Chasel
> 
> 
> 
> > -Original Message-
> > From: Michael Kubacki 
> > Sent: Tuesday, May 9, 2023 11:06 AM
> > To: Gudla, Raghava ; Oram, Isaac W
> > ; devel@edk2.groups.io; Kinney, Michael D
> > ; Chiu, Chasel 
> > Cc: Desimone, Nathaniel L ; Kubacki,
> > Michael ; Chaganty, Rangasai V
> > 
> > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > Thanks for reraising this. If you need me to rebase or help in anyway
> > let me know.
> >
> > On 5/9/2023 1:41 PM, Gudla, Raghava wrote:
> > > My patch is based on Michael's fix. I took his change to do a PoC a
> > > while back
> > and totally forgot that his patch is still available. We can proceed
> > to merge Michael's patch.
> > >
> > > Thanks,
> > > Raghava
> > >
> > > -Original Message-
> > > From: Oram, Isaac W 
> > > Sent: Tuesday, May 9, 2023 10:35 AM
> > > To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney,
> > > Michael D ; Chiu, Chasel
> > > ; Gudla, Raghava 
> > > Cc: Desimone, Nathaniel L ; Kubacki,
> > > Michael ; Chaganty, Rangasai V
> > > 
> > > Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
> > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> > >
> > > Rereading that thread and this request, other opinions, etc, I am
> > > convinced
> > that the simpler interface and board responsibility is the correct
> > short/medium term answer.  I don't have an opinion on Mike Kinney's
> > question on encapsulated services.  I generally like that design,
> > though I am sensitive to Michael Kubacki's feedback that variable
> > services are too complex as it is.  I guess it probably depends a lot
> > on the specifics of the proposal.  That said, it is pretty easy to
> > migrate from a board specific solution to a more base layer solution in the
> future, so adopting this now doesn't seem harmful to me.
> > >
> > > Raghava, can you look at Michael's fix?  It looks nearly identical
> > > to yours and
> > general convention is to accept the earlier one in case of collision I
> > believe.  I like his PCD naming a little better, but both are fine to me.
> > >
> > > Regards,
> > > Isaac
> > >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> > > Michael Kubacki
> > > Sent: Tuesday, May 9, 2023 8:26 AM
> > > To: devel@edk2.groups.io; Kinney, Michael D
> > > ; Chiu, Chasel ;
> > > Oram, Isaac W ; Gudla, Raghava
> > > 
> > > Cc: Desimone, Nathaniel L ; Kubacki,
> > > Michael ; Chaganty, Rangasai V
> > > 
> > > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> > >
> > > At the surface, this looks similar to the following patch I sent a
> > > while
> > > back:
> > >
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed
> > >
> k2.groups.io%2Fg%2Fdevel%2Fmessage%2F92644&data=05%7C01%7Cmichael.
> ku
> > >
> backi%40microsoft.com%7C05c93413c875400acef708db50bf197d%7C72f988bf
> 8
> > >
> 6f141af91ab2d7cd011db47%7C1%7C0%7C638192553936149621%7CUnknown
> %7CTWF
> > >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > >
> 6Mn0%3D%7C3000%7C%7C%7C&sdata=E4hpQLMgLy0BKHngjpec88AI0v3TZ8xg
> xebjU0
> > > SS0FM

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Chiu, Chasel]

Hi Michael,

Please also add CompressLib to CoreCommonLib.dsc to prevent build failure from 
open source platforms.

Thanks,
Chasel


> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, May 9, 2023 12:30 PM
> To: devel@edk2.groups.io; Kubacki, Michael ;
> Michael Kubacki ; Gudla, Raghava
> ; Oram, Isaac W ; Kinney,
> Michael D 
> Cc: Desimone, Nathaniel L ; Chaganty,
> Rangasai V 
> Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
> MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> 
> 
> Just reviewed the branch code and it is functionality the same so agree we can
> switch to Mike's implementation.
> Would you help to rebase and send updated patch for reviewing?
> 
> Thanks,
> Chasel
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael
> > Kubacki via groups.io
> > Sent: Tuesday, May 9, 2023 12:18 PM
> > To: Chiu, Chasel ; Michael Kubacki
> > ; Gudla, Raghava
> > ; Oram, Isaac W ;
> > devel@edk2.groups.io; Kinney, Michael D 
> > Cc: Desimone, Nathaniel L ; Chaganty,
> > Rangasai V 
> > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> > I haven't done a deep comparison of the changes, but I'd lean toward
> > using what is in the branch that I referenced earlier since it has
> > been used for a while now.
> >
> > Is there anything of value in the new set of changes?
> >
> > Thanks,
> > Michael
> >
> > -Original Message-
> > From: Chiu, Chasel 
> > Sent: Tuesday, May 9, 2023 2:56 PM
> > To: Michael Kubacki ; Gudla, Raghava
> > ; Oram, Isaac W ;
> > devel@edk2.groups.io; Kinney, Michael D 
> > Cc: Desimone, Nathaniel L ; Michael
> > Kubacki ; Chaganty, Rangasai V
> > 
> > Subject: [EXTERNAL] RE: [edk2-devel] [edk2-platforms:PATCH V1]
> > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> >
> >
> > Hi Michael Kubacki,
> >
> > Since Rahava has rebased the patch it might be easier to add " 
> > Signed-off-by:
> > Michael Kubacki " to Rahave's patch
> > commit message so both of you are authors.
> > What do you think?
> >
> > By the way, I found a bug in SaveMemoryConfig.c: FreePool() should be
> > FreePages (CompressedData, CompressedAllocationPages); Raghava, please
> > help to fix it by sending V2 patch  (adding -v2 to git format-patch
> > command)
> >
> > Thanks,
> > Chasel
> >
> >
> >
> > > -Original Message-
> > > From: Michael Kubacki 
> > > Sent: Tuesday, May 9, 2023 11:06 AM
> > > To: Gudla, Raghava ; Oram, Isaac W
> > > ; devel@edk2.groups.io; Kinney, Michael D
> > > ; Chiu, Chasel 
> > > Cc: Desimone, Nathaniel L ; Kubacki,
> > > Michael ; Chaganty, Rangasai V
> > > 
> > > Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
> > > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> > >
> > > Thanks for reraising this. If you need me to rebase or help in
> > > anyway let me know.
> > >
> > > On 5/9/2023 1:41 PM, Gudla, Raghava wrote:
> > > > My patch is based on Michael's fix. I took his change to do a PoC
> > > > a while back
> > > and totally forgot that his patch is still available. We can proceed
> > > to merge Michael's patch.
> > > >
> > > > Thanks,
> > > > Raghava
> > > >
> > > > -Original Message-
> > > > From: Oram, Isaac W 
> > > > Sent: Tuesday, May 9, 2023 10:35 AM
> > > > To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney,
> > > > Michael D ; Chiu, Chasel
> > > > ; Gudla, Raghava 
> > > > Cc: Desimone, Nathaniel L ;
> > > > Kubacki, Michael ; Chaganty,
> > > > Rangasai V 
> > > > Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
> > > MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.
> > > >
> > > > Rereading that thread and this request, other opinions, etc, I am
> > > > convinced
> > > that the simpler interface and board responsibility is the correct
> > > short/medium term answer.  I don't have an opinion on Mike Kinney's
> > > question on encapsulated services.  I generally like that design,
> > > though I am sensitive to Michael Kubacki's feedback that variable
> > > services are too complex as it is.  I guess it probably depends a
> > > lot on the specifics of the proposal.  That said, it is pretty easy
> > > to migrate from a board specific solution to a more base layer
> > > solution in the
> > future, so adopting this now doesn't seem harmful to me.
> > > >
> > > > Raghava, can you look at Michael's fix?  It looks nearly identical
> > > > to yours and
> > > general convention is to accept the earlier one in case of collision
> > > I believe.  I like his PCD naming a little better, but both are fine to 
> > > me.
> > > >
> > > > Regards,
> > > > Isaac
> > > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of
> > > > Michael Kubacki
> > > > Sent: Tuesday, May 9, 2023 8:26 AM
> > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > ; Chiu, Chasel
> > > > ; Oram, Isaac W ;
> > > > Gudla, Raghava 
> > > > Cc: Desimone, Nathan

Re: [edk2-devel] [edk2-platforms:PATCH V1] MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

[Michael Kubacki]

Will do. I'll send the patch series soon.

Thanks,
Michael

On 5/9/2023 5:06 PM, Chiu, Chasel wrote:


Hi Michael,

Please also add CompressLib to CoreCommonLib.dsc to prevent build failure from 
open source platforms.

Thanks,
Chasel



-Original Message-
From: Chiu, Chasel
Sent: Tuesday, May 9, 2023 12:30 PM
To: devel@edk2.groups.io; Kubacki, Michael ;
Michael Kubacki ; Gudla, Raghava
; Oram, Isaac W ; Kinney,
Michael D 
Cc: Desimone, Nathaniel L ; Chaganty,
Rangasai V 
Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Just reviewed the branch code and it is functionality the same so agree we can
switch to Mike's implementation.
Would you help to rebase and send updated patch for reviewing?

Thanks,
Chasel




-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael
Kubacki via groups.io
Sent: Tuesday, May 9, 2023 12:18 PM
To: Chiu, Chasel ; Michael Kubacki
; Gudla, Raghava
; Oram, Isaac W ;
devel@edk2.groups.io; Kinney, Michael D 
Cc: Desimone, Nathaniel L ; Chaganty,
Rangasai V 
Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

I haven't done a deep comparison of the changes, but I'd lean toward
using what is in the branch that I referenced earlier since it has
been used for a while now.

Is there anything of value in the new set of changes?

Thanks,
Michael

-Original Message-
From: Chiu, Chasel 
Sent: Tuesday, May 9, 2023 2:56 PM
To: Michael Kubacki ; Gudla, Raghava
; Oram, Isaac W ;
devel@edk2.groups.io; Kinney, Michael D 
Cc: Desimone, Nathaniel L ; Michael
Kubacki ; Chaganty, Rangasai V

Subject: [EXTERNAL] RE: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Hi Michael Kubacki,

Since Rahava has rebased the patch it might be easier to add " Signed-off-by:
Michael Kubacki " to Rahave's patch
commit message so both of you are authors.
What do you think?

By the way, I found a bug in SaveMemoryConfig.c: FreePool() should be
FreePages (CompressedData, CompressedAllocationPages); Raghava, please
help to fix it by sending V2 patch  (adding -v2 to git format-patch
command)

Thanks,
Chasel




-Original Message-
From: Michael Kubacki 
Sent: Tuesday, May 9, 2023 11:06 AM
To: Gudla, Raghava ; Oram, Isaac W
; devel@edk2.groups.io; Kinney, Michael D
; Chiu, Chasel 
Cc: Desimone, Nathaniel L ; Kubacki,
Michael ; Chaganty, Rangasai V

Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]
MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.

Thanks for reraising this. If you need me to rebase or help in
anyway let me know.

On 5/9/2023 1:41 PM, Gudla, Raghava wrote:

My patch is based on Michael's fix. I took his change to do a PoC
a while back

and totally forgot that his patch is still available. We can proceed
to merge Michael's patch.


Thanks,
Raghava

-Original Message-
From: Oram, Isaac W 
Sent: Tuesday, May 9, 2023 10:35 AM
To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney,
Michael D ; Chiu, Chasel
; Gudla, Raghava 
Cc: Desimone, Nathaniel L ;
Kubacki, Michael ; Chaganty,
Rangasai V 
Subject: RE: [edk2-devel] [edk2-platforms:PATCH V1]

MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


Rereading that thread and this request, other opinions, etc, I am
convinced

that the simpler interface and board responsibility is the correct
short/medium term answer.  I don't have an opinion on Mike Kinney's
question on encapsulated services.  I generally like that design,
though I am sensitive to Michael Kubacki's feedback that variable
services are too complex as it is.  I guess it probably depends a
lot on the specifics of the proposal.  That said, it is pretty easy
to migrate from a board specific solution to a more base layer
solution in the

future, so adopting this now doesn't seem harmful to me.


Raghava, can you look at Michael's fix?  It looks nearly identical
to yours and

general convention is to accept the earlier one in case of collision
I believe.  I like his PCD naming a little better, but both are fine to me.


Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of
Michael Kubacki
Sent: Tuesday, May 9, 2023 8:26 AM
To: devel@edk2.groups.io; Kinney, Michael D
; Chiu, Chasel
; Oram, Isaac W ;
Gudla, Raghava 
Cc: Desimone, Nathaniel L ;
Kubacki, Michael ; Chaganty,
Rangasai V 
Subject: Re: [edk2-devel] [edk2-platforms:PATCH V1]

MinPlatformPkg/SaveMemoryConfig: Support NVS Data compression.


At the surface, this looks similar to the following patch I sent a
while
back:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
ed




k2.groups.io%2Fg%2Fdevel%2Fmessage%2F92644&data=05%7C01%7Cmichael.

ku





backi%40microsoft.com%7C05c93413c875400acef708db50bf197d%7C72f988bf

8





6f141af91ab2d7cd011db47%7C1%7C0%7C638192553936149621%7CUnknown

%7CTWF





pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV

Re: [edk2-devel] [PATCH v2 0/2] OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVEL

[Ard Biesheuvel]

(cc Liming)

On Tue, 9 May 2023 at 16:23, Michael Brown  wrote:
>
> On 09/05/2023 14:31, Laszlo Ersek wrote:
> > On 5/9/23 14:09, Michael Brown wrote:
> >> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
> >> specification) and so we should never encounter a situation in which
> >> an interrupt occurs at TPL_HIGH_LEVEL. The specification also
> >> restricts usage of TPL_HIGH_LEVEL to the firmware itself.
> >>
> >> However, nothing actually prevents a UEFI application from calling
> >> gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
> >> enabling interrupts via the STI or equivalent instruction. Some
> >> versions of the Microsoft Windows bootloader are known to do this.
> >>
> >> NestedInterruptTplLib maintains the invariant that interrupts are
> >> disabled at TPL_HIGH_LEVEL (even when performing the dark art of
> >> deliberately manipulating the stack so that IRET will return with
> >> interrupts still disabled), but does not itself rely on external code
> >> maintaining this invariant.
> >>
> >> Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
> >> to an error message, to allow UEFI applications such as these versions
> >> of the Microsoft Windows bootloader to continue to function.
> >>
> >> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
> >> Cc: Laszlo Ersek 
> >> Cc: Gerd Hoffmann 
> >> Cc: Oliver Steffen 
> >> Cc: Pawel Polawski 
> >> Cc: Jiewen Yao 
> >> Cc: Ard Biesheuvel 
> >> Cc: Jordan Justen 
> >>
> >> Michael Brown (2):
> >>OvmfPkg: Clarify invariants for NestedInterruptTplLib
> >>OvmfPkg: Relax assertion that interrupts do not occur at
> >>  TPL_HIGH_LEVEL
> >>
> >>   OvmfPkg/Library/NestedInterruptTplLib/Tpl.c | 31 +
> >>   1 file changed, 26 insertions(+), 5 deletions(-)
> >>
> >
> > series
> > Acked-by: Laszlo Ersek 
>
> Thank you!
>
> Gerd: are you happy for your Reviewed-by to stand, since the only
> changes since v1 were to comment wording?

I'll assume that it stands if that was the only difference.

I've queued this up now - thanks all for the hard work.

(Note to Liming - this is definitely a candidate for the stable tag,
see the bugzilla link for details)


>  (My apologies for forgetting
> to include a v2 description in the cover letter.)
>
> Thanks,
>
> Michael
>
>


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

Re: [edk2-devel] [PATCH edk2-platforms 1/4] QemuOpenBoardPkg: Use MdeModulePkg's SataControllerDxe

[Isaac Oram]

Reviewed-by: Isaac Oram 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Pedro Falcato
Sent: Tuesday, May 9, 2023 9:15 AM
To: devel@edk2.groups.io
Cc: Pedro Falcato ; Oram, Isaac W 
; Theo Jehl 
Subject: [edk2-devel] [PATCH edk2-platforms 1/4] QemuOpenBoardPkg: Use 
MdeModulePkg's SataControllerDxe

As part of an effort to remove OvmfPkg/SataControllerDxe, switch to the generic 
version in MdeModulePkg.

Tested-by: Pedro Falcato 
Cc: Isaac Oram 
Cc: Theo Jehl 
Signed-off-by: Pedro Falcato 
---
 Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc   | 2 +-
 Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc 
b/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
index 283c235b44c0..5a63848f26cd 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
+++ b/Platform/Qemu/QemuOpenBoardPkg/Include/Dsc/Stage4.dsc.inc
@@ -21,7 +21,7 @@
 [Components.$(DXE_ARCH)]
   OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
diff --git a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc 
b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
index f5c317c83e6a..b409a6164412 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
+++ b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dsc
@@ -160,7 +160,7 @@
 [Components.$(DXE_ARCH)]
   MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
-  OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
   MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
diff --git a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf 
b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
index 5af0f0f2faa2..b106828460a9 100644
--- a/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
+++ b/Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.fdf
@@ -266,7 +266,7 @@ SET gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaSize  
   = 0x80
   INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
   INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
 
-  INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
+  INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
 
   INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
   INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
--
2.40.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104433): https://edk2.groups.io/g/devel/message/104433
Mute This Topic: https://groups.io/mt/98787478/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 V1 1/1] WhitleyOpenBoardPkg/DSC: Restore AdvancedFeatures

[Isaac Oram]

Pushed as 92479808e7..fe146bbec1

-Original Message-
From: Chiu, Chasel  
Sent: Tuesday, May 2, 2023 1:06 PM
To: Oram, Isaac W ; devel@edk2.groups.io
Cc: Desimone, Nathaniel L 
Subject: RE: [edk2-devel][edk2-platforms][PATCH V1 1/1] 
WhitleyOpenBoardPkg/DSC: Restore AdvancedFeatures


Reviewed-by: Chasel Chiu 

Thanks,
Chasel


> -Original Message-
> From: Oram, Isaac W 
> Sent: Tuesday, March 7, 2023 4:16 PM
> To: devel@edk2.groups.io
> Cc: Oram, Isaac W ; Desimone, Nathaniel L 
> ; Chiu, Chasel 
> Subject: [edk2-devel][edk2-platforms][PATCH V1 1/1]
> WhitleyOpenBoardPkg/DSC: Restore AdvancedFeatures
> 
> Include for building Advanced Features was mistakenly removed in an 
> earlier commit.
> 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: Isaac Oram 
> ---
>  Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> index c784df0144..9452867edb 100644
> --- a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> +++ b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> @@ -59,6 +59,11 @@
>  [PcdsFixedAtBuild]
>gUsb3DebugFeaturePkgTokenSpaceGuid.PcdUsb3DebugPortLibInstance|1
> 
> +#
> +# Include AdvancedFeatures
> +#
> +!include AdvancedFeaturePkg/Include/AdvancedFeatures.dsc
> +
>#
># Platform On/Off features are defined here
>#
> --
> 2.39.0.windows.1



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

Re: [edk2-devel] [PATCH v3 0/2] Add more google mock library

[Guo, Gua]

Add Reviewed-by message on https://github.com/tianocore/edk2/pull/4335/commits

Wait for push label. It can be checked in.

-Original Message-
From: Kinney, Michael D  
Sent: Tuesday, May 9, 2023 8:17 AM
To: devel@edk2.groups.io; Guo, Gua 
Cc: Kinney, Michael D 
Subject: RE: [edk2-devel] [PATCH v3 0/2] Add more google mock library

Series Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Guo, 
> Gua
> Sent: Monday, May 8, 2023 5:04 PM
> To: devel@edk2.groups.io
> Cc: Guo, Gua 
> Subject: [edk2-devel] [PATCH v3 0/2] Add more google mock library
> 
> From: Gua Guo 
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4443
> 
> PR: https://github.com/tianocore/edk2/pull/4335
> 
> V3
> Remove EBC and fix some coding rule
> 
> V2:
> Fixed Azure build failure
> 
> V1:
> Add google mock support for HobLib
> Add google mock support for PciHostBridgeLib Add google mock support 
> for PeiServicesLib
> 
> Gua Guo (2):
>   MdeModulePkg: Add more PciHostBridgeLib gmock support
>   MdePkg: Add more HobLib/PeiServicesLib gmock support
> 
>  MdeModulePkg/MdeModulePkg.dec |   1 +
>  MdeModulePkg/Test/MdeModulePkgHostTest.dsc|   5 +
>  .../GoogleTest/Library/MockPciHostBridgeLib.h |  40 
>  .../MockPciHostBridgeLib.cpp  |  14 ++
>  .../MockPciHostBridgeLib.inf  |  35 
>  MdePkg/Test/MdePkgHostTest.dsc|   2 +
>  .../Include/GoogleTest/Library/MockHobLib.h   | 150 ++
>  .../GoogleTest/Library/MockPeiServicesLib.h   | 189 ++
>  .../GoogleTest/MockHobLib/MockHobLib.cpp  |  30 +++
>  .../GoogleTest/MockHobLib/MockHobLib.inf  |  33 +++
>  .../MockPeiServicesLib/MockPeiServicesLib.cpp |  36   
> .../MockPeiServicesLib/MockPeiServicesLib.inf |  32 +++
>  12 files changed, 567 insertions(+)
>  create mode 100644
> MdeModulePkg/Test/Mock/Include/GoogleTest/Library/MockPciHostBridgeLib
> .h
>  create mode 100644
> MdeModulePkg/Test/Mock/Library/GoogleTest/MockPciHostBridgeLib/MockP
> ciHostBridgeLib.cpp
>  create mode 100644
> MdeModulePkg/Test/Mock/Library/GoogleTest/MockPciHostBridgeLib/MockP
> ciHostBridgeLib.inf
>  create mode 100644
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockHobLib.h
>  create mode 100644
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockPeiServicesLib.h
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.cpp
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.inf
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServices
> Li
> b.cpp
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServices
> Li
> b.inf
> 
> --
> 2.39.2.windows.1
> 
> 
> 
> 
> 



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