Re: [edk2-devel] [PATCH 1/7] MdePkg: Create TdxLibNull.inf instance

2023-10-26 Thread Ni, Ray 
Please ignore my comments.
That's an existing file for IA32 build. Your patch adds a NULL instance for all 
archs.

Thanks,
Ray

From: Ni, Ray 
Sent: Friday, October 27, 2023 1:54 PM
To: Tan, Dun ; devel@edk2.groups.io 
Cc: Kinney, Michael D ; Gao, Liming 
; Liu, Zhiguang 
Subject: Re: [PATCH 1/7] MdePkg: Create TdxLibNull.inf instance

TdxLibNull.c is missing in the patch.

Thanks,
Ray

From: Tan, Dun 
Sent: Friday, October 27, 2023 1:42 PM
To: devel@edk2.groups.io 
Cc: Kinney, Michael D ; Gao, Liming 
; Liu, Zhiguang ; Ni, Ray 

Subject: [PATCH 1/7] MdePkg: Create TdxLibNull.inf instance

Create null instance for TdxLib. The IoLib instance
BaseIoLibIntrinsic.inf will consume the TdxLibNull
to pass build.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/TdxLib/TdxLibNull.inf | 21 +
 MdePkg/MdePkg.dsc|  1 +
 2 files changed, 22 insertions(+)

diff --git a/MdePkg/Library/TdxLib/TdxLibNull.inf 
b/MdePkg/Library/TdxLib/TdxLibNull.inf
new file mode 100644
index 00..ecf20e12e1
--- /dev/null
+++ b/MdePkg/Library/TdxLib/TdxLibNull.inf
@@ -0,0 +1,21 @@
+## @file
+# Tdx null instance.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = TdxLibNull
+  FILE_GUID  = AA75759C-24E0-42FE-B5A4-83678548FCEF
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TdxLib
+
+[Sources]
+  TdxLibNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 3abd1a1e23..a1be123d80 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -184,6 +184,7 @@
   MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
   MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
   MdePkg/Library/TdxLib/TdxLib.inf
+  MdePkg/Library/TdxLib/TdxLibNull.inf
   MdePkg/Library/MipiSysTLib/MipiSysTLib.inf
   MdePkg/Library/TraceHubDebugSysTLibNull/TraceHubDebugSysTLibNull.inf

--
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110193): https://edk2.groups.io/g/devel/message/110193
Mute This Topic: https://groups.io/mt/102215662/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 1/7] MdePkg: Create TdxLibNull.inf instance

2023-10-26 Thread Ni, Ray 
TdxLibNull.c is missing in the patch.

Thanks,
Ray

From: Tan, Dun 
Sent: Friday, October 27, 2023 1:42 PM
To: devel@edk2.groups.io 
Cc: Kinney, Michael D ; Gao, Liming 
; Liu, Zhiguang ; Ni, Ray 

Subject: [PATCH 1/7] MdePkg: Create TdxLibNull.inf instance

Create null instance for TdxLib. The IoLib instance
BaseIoLibIntrinsic.inf will consume the TdxLibNull
to pass build.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/TdxLib/TdxLibNull.inf | 21 +
 MdePkg/MdePkg.dsc|  1 +
 2 files changed, 22 insertions(+)

diff --git a/MdePkg/Library/TdxLib/TdxLibNull.inf 
b/MdePkg/Library/TdxLib/TdxLibNull.inf
new file mode 100644
index 00..ecf20e12e1
--- /dev/null
+++ b/MdePkg/Library/TdxLib/TdxLibNull.inf
@@ -0,0 +1,21 @@
+## @file
+# Tdx null instance.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = TdxLibNull
+  FILE_GUID  = AA75759C-24E0-42FE-B5A4-83678548FCEF
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TdxLib
+
+[Sources]
+  TdxLibNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 3abd1a1e23..a1be123d80 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -184,6 +184,7 @@
   MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
   MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
   MdePkg/Library/TdxLib/TdxLib.inf
+  MdePkg/Library/TdxLib/TdxLibNull.inf
   MdePkg/Library/MipiSysTLib/MipiSysTLib.inf
   MdePkg/Library/TraceHubDebugSysTLibNull/TraceHubDebugSysTLibNull.inf

--
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110192): https://edk2.groups.io/g/devel/message/110192
Mute This Topic: https://groups.io/mt/102215662/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] question about cxl device enumeration in pci bus driver

2023-10-26 Thread Ni, Ray 
I am not sure which driver is responsible for producing the ACPI tables.

+ Foster


Thanks,
Ray

From: Yoshinoya 
Sent: Friday, October 27, 2023 9:29 AM
To: devel@edk2.groups.io 
Cc: jonathan.came...@huawei.com ; Laszlo Ersek 
; kra...@redhat.com ; Ni, Ray 
; Sayanta Pattanayak 
Subject: Re:Re: [edk2-devel] question about cxl device enumeration in pci bus 
driver



Hi,
Thanks for reply!

I download code from this git https://github.com/SayantaP-arm/edk2-platforms/

For this ARM edk2 sample package, it provided cxldxe driver which being 
executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.

Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such 
as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.

Thanks






At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" 
 wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek"  wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, 
>> >> maybe could be integrated into pci drivers stack.
>> >
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> >
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.
>>
>> (I don't know what "HDM Config" stands for.)
>>
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>>
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>>
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible 
>depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, 
>makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all 
>the
>components in the path to memory + locking them down an EDK2 problem.  They 
>are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR 
>memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL 
>aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in 
>PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for 
>the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it 
>for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree 
>support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>>
>> Laszlo
>>
>>
>>
>>
>>
>>
>
>
>
>
>





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110191): https://edk2.groups.io/g/devel/message/110191
Mute This Topic: https://groups.io/mt/102173204/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/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

2023-10-26 Thread Yao, Jiewen 
HI
Since this impact TDX and SEV, would you please let me know what kind of test 
you have done?
Have you validated TDX and SEV before you submit the patch? Please describe 
that clearly in your patch description.

Also please include AMD SEV reviewer in this patch series.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Friday, October 27, 2023 1:43 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic 
> and
> remove BaseIoLibIntrinsicSev
> 
> The goal is to have single BaseIoLibIntrinsic instance that can also used for 
> sev
> and Tdx.
> In this patch set, string I/O instructions are deleted in IoRead/WriteFifo 
> API.
> Then change the source file of BaseIoLibIntrinsic to also support Tdx and sev
> feature. So BaseIoLibIntrinsicSev and related assembly code can be removed.
> 
> Dun Tan (7):
>   MdePkg: Create TdxLibNull.inf instance
>   MdePkg: Add CcProbeLibNull and TdxLibNull implement
>   MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c
>   MdePkg:support Tdx and sev in BaseIoLibIntrinsic
>   OvmfPkg: Add CcProbeLib in PlatformInitLib.inf
>   OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files
>   MdePkg:remove BaseIoLibIntrinsicSev related code
> 
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf|  14 
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61 
> --
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
> 
> --
> -
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
> --
> --
> --
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |  45
> +
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h| 166 
> 
> --
> 
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120 
> 
> --
> --
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm| 282 
> --
> --
> --
> 
>  MdePkg/Library/TdxLib/TdxLibNull.inf|  21
> +
>  MdePkg/MdeLibs.dsc.inc  |   4 +++-
>  MdePkg/MdePkg.dsc   |   2 +-
>  OvmfPkg/AmdSev/AmdSevX64.dsc|   2 +-
>  OvmfPkg/Bhyve/BhyveX64.dsc  |   2 +-
>  OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc|   2 +-
>  OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf |   3 ++-
>  OvmfPkg/Microvm/MicrovmX64.dsc  |   2 +-
>  OvmfPkg/OvmfPkgIa32.dsc |   2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +-
>  OvmfPkg/OvmfPkgX64.dsc  |   2 +-
>  OvmfPkg/OvmfXen.dsc |   2 +-
>  21 files changed, 83 insertions(+), 1077 deletions(-)
>  delete mode 100644
> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
>  create mode 100644 MdePkg/Library/TdxLib/TdxLibNull.inf
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v2 0/1] StandaloneMmCore finds drivers in uncompressed inner fv.

2023-10-26 Thread Ni, Ray 
Wei,
Thanks for fixing the 3 issues.
Can you kindly separate the one patch to at least 2 patches?
One patch is to fix minor issues.
The other is to add support of nested uncompressed FV.

Thanks,
Ray

From: Xu, Wei6 
Sent: Friday, October 27, 2023 8:59 AM
To: devel@edk2.groups.io 
Cc: Xu, Wei6 ; Laszlo Ersek ; Ard 
Biesheuvel ; Sami Mujawar ; 
Ni, Ray 
Subject: [PATCH v2 0/1] StandaloneMmCore finds drivers in uncompressed inner fv.

V1:
This patch is to fix the issue that StandaloneMmCore fails to detect 
uncompressed inner FV.
PR: https://github.com/tianocore/edk2/pull/4943

V2:
Based on V1, fix some other issues
1. Add Missing object size checks before casting pointers to header types
  a. InnerFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)SectionData;
 This is introduced in V1, add the size check on SectionDataSize against 
EFI_FIRMWARE_VOLUME_HEADER
  b. Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
 Use FfsFindSection instead of FfsFindSectionData to avoid pointer casting.
2. Fix potential memory leak issue that ScratchBuffer is not freed when page 
allocation for DstBuffer fails.
PR: https://github.com/tianocore/edk2/pull/4965

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 

Wei6 Xu (1):
  StandaloneMmPkg: Fix some issues in function MmCoreFfsFindMmDriver.

 StandaloneMmPkg/Core/FwVol.c | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

--
2.29.2.windows.2



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

[edk2-devel] [PATCH 7/7] MdePkg:remove BaseIoLibIntrinsicSev related code

2023-10-26 Thread duntan 
Remove BaseIoLibIntrinsicSev related code in MdePkg.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61 
-
 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
---
 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
-
 MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |   1 -
 MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h| 166 
--
 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120 

 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm| 282 
--
 MdePkg/MdePkg.dsc   |   1 -
 8 files changed, 1055 deletions(-)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
deleted file mode 100644
index e1b8298ac4..00
--- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+++ /dev/null
@@ -1,61 +0,0 @@
-## @file
-#  Instance of I/O Library using compiler intrinsics.
-#
-#  I/O Library that uses compiler intrinsics to perform IN and OUT instructions
-#  for IA-32 and x64.
-#
-#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
-#  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-#  Copyright (c) 2017, AMD Incorporated. All rights reserved.
-#
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = BaseIoLibIntrinsicSev
-  MODULE_UNI_FILE= BaseIoLibIntrinsic.uni
-  FILE_GUID  = 93742f95-6e71-4581-b600-8e1da443f95a
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = IoLib
-
-
-#
-#  VALID_ARCHITECTURES   = IA32 X64
-#
-
-[Sources]
-  IoLibMmioBuffer.c
-  BaseIoLibIntrinsicInternal.h
-  IoHighLevel.c
-  IoLibTdx.h
-  IoLibSev.h
-
-[Sources.IA32]
-  IoLibGcc.c| GCC
-  IoLibMsc.c| MSFT
-  IoLib.c
-  IoLibInternalTdxNull.c
-  Ia32/IoFifoSev.nasm
-
-[Sources.X64]
-  IoLibGcc.c| GCC
-  IoLibMsc.c| MSFT
-  IoLib.c
-  IoLibInternalTdx.c
-  IoLibFifo.c
-  X64/IoFifoSev.nasm
-
-[Packages]
-  MdePkg/MdePkg.dec
-
-[LibraryClasses]
-  DebugLib
-  BaseLib
-  RegisterFilterLib
-  CcProbeLib
-
-[LibraryClasses.X64]
-  TdxLib
diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm 
b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
deleted file mode 100644
index a4ae1a0053..00
--- a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
+++ /dev/null
@@ -1,131 +0,0 @@
-;--
-;
-; Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
-; Copyright (c) 2017, AMD Incorporated. All rights reserved.
-;
-; SPDX-License-Identifier: BSD-2-Clause-Patent
-;
-;--
-
-SECTION .text
-
-;--
-;  VOID
-;  EFIAPI
-;  IoReadFifo8 (
-;IN  UINTN Port,
-;IN  UINTN Size,
-;OUT VOID  *Buffer
-;);
-;--
-global ASM_PFX(IoReadFifo8)
-ASM_PFX(IoReadFifo8):
-pushedi
-cld
-mov dx, [esp + 8]
-mov ecx, [esp + 12]
-mov edi, [esp + 16]
-rep insb
-pop edi
-ret
-
-;--
-;  VOID
-;  EFIAPI
-;  IoReadFifo16 (
-;IN  UINTN Port,
-;IN  UINTN Size,
-;OUT VOID  *Buffer
-;);
-;--
-global ASM_PFX(IoReadFifo16)

[edk2-devel] [PATCH 6/7] OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files

2023-10-26 Thread duntan 
Use BaseIoLibIntrinsic.inf in dsc files. The
BaseIoLibIntrinsic supports Tdx and sev now.
The BaseIoLibIntrinsicSev will be removed in
the following patches.

Signed-off-by: Dun Tan 
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Ray Ni 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc   | 2 +-
 OvmfPkg/CloudHv/CloudHvX64.dsc   | 2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc   | 2 +-
 OvmfPkg/OvmfPkgIa32.dsc  | 2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc   | 2 +-
 OvmfPkg/OvmfPkgX64.dsc   | 2 +-
 OvmfPkg/OvmfXen.dsc  | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 302c90e7c2..06086e0cc5 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -142,7 +142,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
   CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
   MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index 6693342c5f..1376dd7468 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -149,7 +149,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
   CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
   MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 35942e02df..1d2a13dd92 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -159,7 +159,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
   CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
   MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 182ec3705d..6623196c8b 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -146,7 +146,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
   CcProbeLib|OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
   MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 0f26f2a9a9..c76a135f9e 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -157,7 +157,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
   CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
-  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
   MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index fcd3a3fda5..a850465e77 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -162,7 +162,7 @@
   
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
   PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

[edk2-devel] [PATCH 5/7] OvmfPkg: Add CcProbeLib in PlatformInitLib.inf

2023-10-26 Thread duntan 
PlatformInitLib uses the CcProbe API in MemDetect.c
but doensn't add CcProbeLib in .inf LibraryClasses
section. Add CcProbeLib to fix the build error.

Signed-off-by: Dun Tan 
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Ray Ni 
---
 OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf 
b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
index 5a79d95b68..8ff9e699b1 100644
--- a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
+++ b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
@@ -2,7 +2,7 @@
 #  Platform Initialization Lib
 #
 #  This module provides platform specific function to detect boot mode.
-#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -52,6 +52,7 @@
   PcdLib
   PciLib
   PeiHardwareInfoLib
+  CcProbeLib
 
 [LibraryClasses.X64]
   TdxLib
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 4/7] MdePkg:support Tdx and sev in BaseIoLibIntrinsic

2023-10-26 Thread duntan 
Change IA32 and X64 arch source files for
BaseIoLibIntrinsic to support Tdx and sev.
Use IoFifoRead/Write API in IoLibFifo.c and the
IoLibInternalTdx.c instead of IoFifoSev.nasm for
BaseIoLibIntrinsic.
With this change, BaseIoLibIntrinsic can also support
Tdx guest and sev. Then the assembly code and instance
for BaseIoLibIntrinsicSev can be removed.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
index aeb072ee95..e1a2e1eed8 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
@@ -7,7 +7,7 @@
 #  ASSERT(). For ARM, AARCH64, RISCV64 and LoongArch, this I/O library only 
provides
 #  non I/O read and write.
 #
-#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
 #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
 #  Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All 
rights reserved.
@@ -35,24 +35,26 @@
   IoLibMmioBuffer.c
   BaseIoLibIntrinsicInternal.h
   IoHighLevel.c
-  IoLibInternalTdxNull.c
   IoLibTdx.h
 
 [Sources.IA32]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
   IoLib.c
-  Ia32/IoFifo.nasm
+  IoLibFifo.c
+  IoLibInternalTdxNull.c
 
 [Sources.X64]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
   IoLib.c
-  X64/IoFifo.nasm
+  IoLibFifo.c
+  IoLibInternalTdx.c
 
 [Sources.EBC]
   IoLibEbc.c
   IoLib.c
+  IoLibInternalTdxNull.c
 
 [Sources.ARM]
   IoLibNoIo.c
@@ -74,3 +76,7 @@
   BaseLib
   RegisterFilterLib
 
+[LibraryClasses.X64]
+  TdxLib
+  CcProbeLib
+
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 3/7] MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c

2023-10-26 Thread duntan 
Simplify IoRead/WriteFifo implement in IoLibFifo.c
by repeatedly calling IoRead/Write API in C code.
This can avoid calling assembly code to use string
I/O instructions and avoid checking if sev feature
is enabled. Then the code flow is simplified.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c | 44 
+---
 1 file changed, 37 insertions(+), 7 deletions(-)

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c 
b/MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c
index 9a94bc6a05..adce1040f6 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c
+++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c
@@ -1,7 +1,7 @@
 /** @file
   IoFifo read/write routines.
 
-  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  Copyright (c) 2021-2023, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -39,10 +39,15 @@ IoReadFifo8 (
   OUT VOID   *Buffer
   )
 {
+  UINT8  *Buffer8;
+
   if (IsTdxGuest ()) {
 TdIoReadFifo8 (Port, Count, Buffer);
   } else {
-SevIoReadFifo8 (Port, Count, Buffer);
+Buffer8 = (UINT8 *)Buffer;
+while (Count-- > 0) {
+  *Buffer8++ = IoRead8 (Port);
+}
   }
 }
 
@@ -73,10 +78,15 @@ IoWriteFifo8 (
   IN  VOID   *Buffer
   )
 {
+  UINT8  *Buffer8;
+
   if (IsTdxGuest ()) {
 TdIoWriteFifo8 (Port, Count, Buffer);
   } else {
-SevIoWriteFifo8 (Port, Count, Buffer);
+Buffer8 = (UINT8 *)Buffer;
+while (Count-- > 0) {
+  IoWrite8 (Port, *Buffer8++);
+}
   }
 }
 
@@ -107,10 +117,15 @@ IoReadFifo16 (
   OUT VOID   *Buffer
   )
 {
+  UINT16  *Buffer16;
+
   if (IsTdxGuest ()) {
 TdIoReadFifo16 (Port, Count, Buffer);
   } else {
-SevIoReadFifo16 (Port, Count, Buffer);
+Buffer16 = (UINT16 *)Buffer;
+while (Count-- > 0) {
+  *Buffer16++ = IoRead16 (Port);
+}
   }
 }
 
@@ -141,10 +156,15 @@ IoWriteFifo16 (
   IN  VOID   *Buffer
   )
 {
+  UINT16  *Buffer16;
+
   if (IsTdxGuest ()) {
 TdIoWriteFifo16 (Port, Count, Buffer);
   } else {
-SevIoWriteFifo16 (Port, Count, Buffer);
+Buffer16 = (UINT16 *)Buffer;
+while (Count-- > 0) {
+  IoWrite16 (Port, *Buffer16++);
+}
   }
 }
 
@@ -175,10 +195,15 @@ IoReadFifo32 (
   OUT VOID   *Buffer
   )
 {
+  UINT32  *Buffer32;
+
   if (IsTdxGuest ()) {
 TdIoReadFifo32 (Port, Count, Buffer);
   } else {
-SevIoReadFifo32 (Port, Count, Buffer);
+Buffer32 = (UINT32 *)Buffer;
+while (Count-- > 0) {
+  *Buffer32++ = IoRead32 (Port);
+}
   }
 }
 
@@ -209,9 +234,14 @@ IoWriteFifo32 (
   IN  VOID   *Buffer
   )
 {
+  UINT32  *Buffer32;
+
   if (IsTdxGuest ()) {
 TdIoWriteFifo32 (Port, Count, Buffer);
   } else {
-SevIoWriteFifo32 (Port, Count, Buffer);
+Buffer32 = (UINT32 *)Buffer;
+while (Count-- > 0) {
+  IoWrite32 (Port, *Buffer32++);
+}
   }
 }
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 2/7] MdePkg: Add CcProbeLibNull and TdxLibNull implement

2023-10-26 Thread duntan 
Add CcProbeLibNull and TdxLibNull implement in the
MdeLibs.dsc.inc. The IoLib instance BaseIoLibIntrinsic
will consume the two lib instance in the following
patch. Add the two null instance in this file to avoid
build failure.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/MdeLibs.dsc.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/MdeLibs.dsc.inc b/MdePkg/MdeLibs.dsc.inc
index 4580481cb5..0525283cfd 100644
--- a/MdePkg/MdeLibs.dsc.inc
+++ b/MdePkg/MdeLibs.dsc.inc
@@ -5,7 +5,7 @@
 # by using "!include MdePkg/MdeLibs.dsc.inc" to specify the library instances
 # of some EDKII basic/common library classes.
 #
-# Copyright (c) 2021 - 2022, Intel Corporation. All rights reserved.
+# Copyright (c) 2021 - 2023, Intel Corporation. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -16,3 +16,5 @@
   
RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
   CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
   
SmmCpuRendezvousLib|MdePkg/Library/SmmCpuRendezvousLibNull/SmmCpuRendezvousLibNull.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
+  TdxLib|MdePkg/Library/TdxLib/TdxLibNull.inf
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 1/7] MdePkg: Create TdxLibNull.inf instance

2023-10-26 Thread duntan 
Create null instance for TdxLib. The IoLib instance
BaseIoLibIntrinsic.inf will consume the TdxLibNull
to pass build.

Signed-off-by: Dun Tan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
---
 MdePkg/Library/TdxLib/TdxLibNull.inf | 21 +
 MdePkg/MdePkg.dsc|  1 +
 2 files changed, 22 insertions(+)

diff --git a/MdePkg/Library/TdxLib/TdxLibNull.inf 
b/MdePkg/Library/TdxLib/TdxLibNull.inf
new file mode 100644
index 00..ecf20e12e1
--- /dev/null
+++ b/MdePkg/Library/TdxLib/TdxLibNull.inf
@@ -0,0 +1,21 @@
+## @file
+# Tdx null instance.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = TdxLibNull
+  FILE_GUID  = AA75759C-24E0-42FE-B5A4-83678548FCEF
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TdxLib
+
+[Sources]
+  TdxLibNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 3abd1a1e23..a1be123d80 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -184,6 +184,7 @@
   MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
   MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
   MdePkg/Library/TdxLib/TdxLib.inf
+  MdePkg/Library/TdxLib/TdxLibNull.inf
   MdePkg/Library/MipiSysTLib/MipiSysTLib.inf
   MdePkg/Library/TraceHubDebugSysTLibNull/TraceHubDebugSysTLibNull.inf
 
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

2023-10-26 Thread duntan 
The goal is to have single BaseIoLibIntrinsic instance that can also used for 
sev and Tdx. 
In this patch set, string I/O instructions are deleted in IoRead/WriteFifo API.
Then change the source file of BaseIoLibIntrinsic to also support Tdx and sev 
feature. So BaseIoLibIntrinsicSev and related assembly code can be removed.

Dun Tan (7):
  MdePkg: Create TdxLibNull.inf instance
  MdePkg: Add CcProbeLibNull and TdxLibNull implement
  MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c
  MdePkg:support Tdx and sev in BaseIoLibIntrinsic
  OvmfPkg: Add CcProbeLib in PlatformInitLib.inf
  OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files
  MdePkg:remove BaseIoLibIntrinsicSev related code

 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf|  14 
++
 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61 
-
 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
---
 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
-
 MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |  45 
+
 MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h| 166 
--
 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120 

 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm| 282 
--
 MdePkg/Library/TdxLib/TdxLibNull.inf|  21 
+
 MdePkg/MdeLibs.dsc.inc  |   4 +++-
 MdePkg/MdePkg.dsc   |   2 +-
 OvmfPkg/AmdSev/AmdSevX64.dsc|   2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc  |   2 +-
 OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc|   2 +-
 OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf |   3 ++-
 OvmfPkg/Microvm/MicrovmX64.dsc  |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc |   2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +-
 OvmfPkg/OvmfPkgX64.dsc  |   2 +-
 OvmfPkg/OvmfXen.dsc |   2 +-
 21 files changed, 83 insertions(+), 1077 deletions(-)
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
 create mode 100644 MdePkg/Library/TdxLib/TdxLibNull.inf

-- 
2.31.1.windows.1



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

Re: [edk2-devel] [edk2-libc Patch 0/1] fix missing nanf definition in StdLib

2023-10-26 Thread Jayaprakash, N 
Reviewed-by : Jayaprakash Nevara 

Regards,
JP

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Jayaprakash, N
Sent: Thursday, October 26, 2023 9:00 PM
To: devel@edk2.groups.io
Cc: Jayaprakash, N 
Subject: [edk2-devel] [edk2-libc Patch 0/1] fix missing nanf definition in 
StdLib

This patch fixes the issue of missing definition of nanf in StdLib.
This has been extracted from the below PR submitted on edk2-libc.
https://github.com/tianocore/edk2-libc/pull/9

Jayaprakash N (1):
  ek2-libc: fix missing nanf definition in StdLib

 StdLib/LibC/LibC.inf|  1 +
 StdLib/LibC/Main/nanf_ieee754.c | 15 +++
 2 files changed, 16 insertions(+)
 create mode 100644 StdLib/LibC/Main/nanf_ieee754.c

-- 
2.40.0.windows.1








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

[edk2-devel] [PATCH 2/2] StandaloneMmPkg/Core: Consumes Standalone Mm Core Platform Hook Lib.

2023-10-26 Thread Xu, Wei6 
Call platform hooks before and after invoking registered MMI handlers.
Platform can perform specific tasks in the hooks.

Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 
Signed-off-by: Wei6 Xu 
---
 StandaloneMmPkg/Core/StandaloneMmCore.c   | 7 ++-
 StandaloneMmPkg/Core/StandaloneMmCore.h   | 1 +
 StandaloneMmPkg/Core/StandaloneMmCore.inf | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
b/StandaloneMmPkg/Core/StandaloneMmCore.c
index d221f1d1115d..43d8694fa9ef 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.c
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
@@ -351,7 +351,7 @@ MmEntryPoint (
   //
   // Call platform hook before Mm Dispatch
   //
-  // PlatformHookBeforeMmDispatch ();
+  PlatformHookBeforeMmDispatch ();
 
   //
   // If a legacy boot has occurred, then make sure gMmCorePrivate is not 
accessed
@@ -400,6 +400,11 @@ MmEntryPoint (
   //
   MmiManage (NULL, NULL, NULL, NULL);
 
+  //
+  // Call platform hook after Mm Dispatch
+  //
+  PlatformHookAfterMmDispatch ();
+
   //
   // TBD: Do not use private data structure ?
   //
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
b/StandaloneMmPkg/Core/StandaloneMmCore.h
index 822d95358c39..08ea178bfe76 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.h
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index c44b9ff33303..ac2f07610d04 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
   PeCoffLib
   ReportStatusCodeLib
   StandaloneMmCoreEntryPoint
+  StandaloneMmCorePlatformHookLib
 
 [Protocols]
   gEfiDxeMmReadyToLockProtocolGuid ## UNDEFINED # 
SmiHandlerRegister
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH 1/2] StandaloneMmPkg: Add Standalone Mm Core platform hook lib.

2023-10-26 Thread Xu, Wei6 
Add header file for the definition of StandaloneMmCorePlatformHookLib.
Add NULL instance for StandaloneMmCorePlatformHookLib.

This library class defines a set of platform hooks called by the
Standalone Mm Core. With this library, platform can perform specific
tasks before and after invoking registered MMI handlers.

Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 
Signed-off-by: Wei6 Xu 
---
 .../StandaloneMmCorePlatformHookLibNull.c | 45 +++
 .../Library/StandaloneMmCorePlatformHookLib.h | 44 ++
 .../StandaloneMmCorePlatformHookLibNull.inf   | 30 +
 StandaloneMmPkg/StandaloneMmPkg.dec   |  4 ++
 StandaloneMmPkg/StandaloneMmPkg.dsc   |  2 +
 5 files changed, 125 insertions(+)
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.c
 create mode 100644 
StandaloneMmPkg/Include/Library/StandaloneMmCorePlatformHookLib.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.inf

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.c
 
b/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.c
new file mode 100644
index ..dfd781e8c947
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.c
@@ -0,0 +1,45 @@
+/** @file
+  NULL instance of StandaloneMmCorePlatformHookLib.
+
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  Performs platform specific tasks before invoking registered SMI handlers.
+
+  This function performs platform specific tasks before invoking registered 
SMI handlers.
+
+  @retval EFI_SUCCESS   The platform hook completes successfully.
+  @retval Other values  The platform hook cannot complete due to some 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformHookBeforeMmDispatch (
+  VOID
+  )
+{
+  return EFI_SUCCESS;
+}
+
+/**
+  Performs platform specific tasks after invoking registered SMI handlers.
+
+  This function performs platform specific tasks after invoking registered SMI 
handlers.
+
+  @retval EFI_SUCCESS   The platform hook completes successfully.
+  @retval Other values  The platform hook cannot complete due to some 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformHookAfterMmDispatch (
+  VOID
+  )
+{
+  return EFI_SUCCESS;
+}
diff --git a/StandaloneMmPkg/Include/Library/StandaloneMmCorePlatformHookLib.h 
b/StandaloneMmPkg/Include/Library/StandaloneMmCorePlatformHookLib.h
new file mode 100644
index ..37eaa4e8946c
--- /dev/null
+++ b/StandaloneMmPkg/Include/Library/StandaloneMmCorePlatformHookLib.h
@@ -0,0 +1,44 @@
+/** @file
+  Standalone Mm Core Platform Hook Library. This library class defines a set 
of platform
+  hooks called by the Standalone Mm Core.
+
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef STANDALONE_MM_CORE_PLATFORM_HOOK_LIB_
+#define STANDALONE_MM_CORE_PLATFORM_HOOK_LIB_
+
+/**
+  Performs platform specific tasks before invoking registered MMI handlers.
+
+  This function performs platform specific tasks before invoking registered 
MMI handlers.
+
+  @retval EFI_SUCCESS   The platform hook completes successfully.
+  @retval Other values  The platform hook cannot complete due to some 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformHookBeforeMmDispatch (
+  VOID
+  );
+
+/**
+  Performs platform specific tasks after invoking registered MMI handlers.
+
+  This function performs platform specific tasks after invoking registered MMI 
handlers.
+
+  @retval EFI_SUCCESS   The platform hook completes successfully.
+  @retval Other values  The platform hook cannot complete due to some 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformHookAfterMmDispatch (
+  VOID
+  );
+
+#endif
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.inf
 
b/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.inf
new file mode 100644
index ..917f2983c938
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.inf
@@ -0,0 +1,30 @@
+## @file
+#  Standalone MM Core Platform Hook NULL Library instance.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = StandaloneMmCorePlatformHookLibNull
+  FILE_GUID  = A5924660-072B-4188-A850-C45FBED9FCE0
+  MODULE_TYPE= MM_CORE_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+

[edk2-devel] [PATCH 0/2] Add Platform Hook Lib into StandaloneMmCore

2023-10-26 Thread Xu, Wei6 
This patch set is to add StandaloneMmCorePlatformHookLib into StandaloneMmCore.
This library class defines a set of platform hooks called by the Standalone Mm 
Core. With this library, platform can perform specific tasks before and after 
invoking registered MMI handlers.
We need this library to implement our feature.
PR: https://github.com/tianocore/edk2/pull/4949

Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 

Wei6 Xu (2):
  StandaloneMmPkg: Add Standalone Mm Core platform hook lib.
  StandaloneMmPkg/Core: Consumes Standalone Mm Core Platform Hook Lib.

 StandaloneMmPkg/Core/StandaloneMmCore.c   |  7 ++-
 .../StandaloneMmCorePlatformHookLibNull.c | 45 +++
 StandaloneMmPkg/Core/StandaloneMmCore.h   |  1 +
 StandaloneMmPkg/Core/StandaloneMmCore.inf |  1 +
 .../Library/StandaloneMmCorePlatformHookLib.h | 44 ++
 .../StandaloneMmCorePlatformHookLibNull.inf   | 30 +
 StandaloneMmPkg/StandaloneMmPkg.dec   |  4 ++
 StandaloneMmPkg/StandaloneMmPkg.dsc   |  2 +
 8 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.c
 create mode 100644 
StandaloneMmPkg/Include/Library/StandaloneMmCorePlatformHookLib.h
 create mode 100644 
StandaloneMmPkg/Library/StandaloneMmCorePlatformHookLibNull/StandaloneMmCorePlatformHookLibNull.inf

-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH v3 2/5] StarFive/JH7110Pkg: Add SPI protocol and driver support

2023-10-26 Thread John Chew 
This patch include QSPI driver and Flash driver protocol.
QSPI driver:
1. Used indirect read/write
2. Master mode only
3. Require to setup qspi driver after located protocol
4. Require to free device if no longer needed
5. Support command read/write & data read/write
Flash driver:
1. Require QSPI protocol as prerequisite
2. Support for flash read/write/update/erase
3. Require to init flash driver after allocated protocol

Cc: Sunil V L 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Li Yong 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
 | 893 
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.h
 | 188 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.inf  
 |  52 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.c  
 | 571 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.h  
 |  35 +
 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.inf 
|  44 +
 Silicon/StarFive/JH7110Pkg/Include/Protocol/Spi.h  
 | 163 
 Silicon/StarFive/JH7110Pkg/Include/Protocol/SpiFlash.h 
 |  88 ++
 8 files changed, 2034 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c 
b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
new file mode 100755
index ..c345556f8abf
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
@@ -0,0 +1,893 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include "SpiDxe.h"
+
+SPI_MASTER  *mSpiMasterInstance;
+
+STATIC
+VOID
+SpiControllerEnable (
+  IN UINT32  RegBase
+  )
+{
+  UINT32  Reg;
+
+  Reg  = MmioRead32 (RegBase + SPI_REG_CONFIG);
+  Reg |= SPI_REG_CONFIG_ENABLE;
+  MmioWrite32 (RegBase + SPI_REG_CONFIG, Reg);
+}
+
+STATIC
+VOID
+SpiControllerDisable (
+  IN UINT32  RegBase
+  )
+{
+  UINT32  Reg;
+
+  Reg  = MmioRead32 (RegBase + SPI_REG_CONFIG);
+  Reg &= ~SPI_REG_CONFIG_ENABLE;
+  MmioWrite32 (RegBase + SPI_REG_CONFIG, Reg);
+}
+
+STATIC
+VOID
+SpiWriteSpeed (
+  IN SPI_DEVICE_PARAMS  *Slave,
+  IN UINT32 SclkHz,
+  IN SPI_TIMING_PARAMS  *Timing
+  )
+{
+  UINT32  Reg, Div, RefClkNs, SclkNs;
+  UINT32  Tshsl, Tchsh, Tslch, Tsd2d;
+
+  SpiControllerDisable (Slave->RegBase);
+
+  /* Configure baudrate */
+  Reg  = MmioRead32 (Slave->RegBase + SPI_REG_CONFIG);
+  Reg &= ~(SPI_REG_CONFIG_BAUD_MASK << SPI_REG_CONFIG_BAUD_LSB);
+
+  Div = DIV_ROUND_UP (Timing->RefClkHz, SclkHz * 2) - 1;
+
+  if (Div > SPI_REG_CONFIG_BAUD_MASK) {
+Div = SPI_REG_CONFIG_BAUD_MASK;
+  }
+
+  DEBUG (
+ (DEBUG_INFO, "%a(): RefClk %dHz sclk %dHz Div 0x%x, actual %dHz\n", 
__func__,
+  Timing->RefClkHz, SclkHz, Div, Timing->RefClkHz / (2 * (Div + 1)))
+ );
+
+  Reg |= (Div << SPI_REG_CONFIG_BAUD_LSB);
+  MmioWrite32 (Slave->RegBase + SPI_REG_CONFIG, Reg);
+
+  /* Configure delay timing */
+  RefClkNs = DIV_ROUND_UP (10, Timing->RefClkHz);
+  SclkNs = DIV_ROUND_UP (10, SclkHz);
+
+  if (Timing->TshslNs >= SclkNs + RefClkNs) {
+Timing->TshslNs -= SclkNs + RefClkNs;
+  }
+
+  if (Timing->TchshNs >= SclkNs + 3 * RefClkNs) {
+Timing->TchshNs -= SclkNs + 3 * RefClkNs;
+  }
+
+  Tshsl = DIV_ROUND_UP (Timing->TshslNs, RefClkNs);
+  Tchsh = DIV_ROUND_UP (Timing->TchshNs, RefClkNs);
+  Tslch = DIV_ROUND_UP (Timing->TslchNs, RefClkNs);
+  Tsd2d = DIV_ROUND_UP (Timing->Tsd2dNs, RefClkNs);
+
+  Reg = ((Tshsl & SPI_REG_DELAY_TSHSL_MASK)
+ << SPI_REG_DELAY_TSHSL_LSB);
+  Reg |= ((Tchsh & SPI_REG_DELAY_TCHSH_MASK)
+  << SPI_REG_DELAY_TCHSH_LSB);
+  Reg |= ((Tslch & SPI_REG_DELAY_TSLCH_MASK)
+  << SPI_REG_DELAY_TSLCH_LSB);
+  Reg |= ((Tsd2d & SPI_REG_DELAY_TSD2D_MASK)
+  << SPI_REG_DELAY_TSD2D_LSB);
+  MmioWrite32 (Slave->RegBase + SPI_REG_DELAY, Reg);
+
+  SpiControllerEnable (Slave->RegBase);
+}
+
+STATIC
+EFI_STATUS
+SpiWaitIdle (
+  IN UINT32  RegBase
+  )
+{
+  BOOLEAN IsIdle;
+  UINT32  Count = 0;
+  UINT32  TimeoutMs = 500;
+
+  do {
+IsIdle = (BOOLEAN)((MmioRead32(RegBase + SPI_REG_CONFIG) >>
+SPI_REG_CONFIG_IDLE_LSB) & 0x1);
+Count = (IsIdle) ? (Count+1) : 0;
+
+/*
+ * Make sure the QSPI controller is in really idle
+ * for n period of time before proceed
+ */
+if (Count >= SPI_POLL_IDLE_RETRY) {
+  return EFI_SUCCESS;
+}
+
+gBS->Stall (1);
+  } while (TimeoutMs);
+
+  return EFI_TIMEOUT;
+}
+
+STATIC
+EFI_STATUS
+SpiExecFlashCmd (
+  IN UINT32  RegBase,
+  IN UINT32  Reg
+  )
+{
+  EFI_STATUS  Status;
+  UINT32  Retry = SPI_REG_RETRY;
+
+  /* Write the CMDCTRL without start execution */

[edk2-devel] [PATCH v3 3/5] StarFive/JH7110Pkg: Add firmware volume block protocol

2023-10-26 Thread John Chew 
Support for efi variable to store in QSPI flash.
This driver is responsible to initialize both QSPI and Flash driver.

Firmware Volume(FV) Initialization:
1. Copy flash content into allocated shadow buffer (RAM)
2. Check FV header validity
3. If not valid, erase flash based on the region defined in PCDs
   , else skip
4. If erased, write flash with new FV header, else skip
EFI Variable read:
1. Read anbd return the content from the shadow buffer (RAM)
EFI Variable write:
1. Write the data into flash
2. Update shadow buffer (RAM)

Cc: Sunil V L 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Li Yong 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c   | 909 

 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h   | 138 +++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf |  70 ++
 3 files changed, 1117 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c 
b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
new file mode 100644
index ..c30e82ed0871
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
@@ -0,0 +1,909 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include "FvbDxe.h"
+
+STATIC FVB_DEVICE  *mFvbDevice;
+
+STATIC CONST FVB_DEVICE  mFvbFlashInstanceTemplate = {
+  {
+0,/* AddrSize ... NEED TO BE FILLED */
+NULL, /* Read from NOR FLASH ... NEED TO BE FILLED */
+0,/* RegBase ... NEED TO BE FILLED */
+0,/* AbhBase ... NEED TO BE FILLED */
+0,/* FifoWidth ... NEED TO BE FILLED */
+0,/* WriteDelay ... NEED TO BE FILLED */
+  }, /* SPI_DEVICE_PARAMS */
+
+  NULL, /* SpiFlashProtocol ... NEED TO BE FILLED */
+  NULL, /* SpiMasterProtocol ... NEED TO BE FILLED */
+  NULL, /* Handle ... NEED TO BE FILLED */
+
+  FVB_FLASH_SIGNATURE, /* Signature ... NEED TO BE FILLED */
+
+  0, /* ShadowBufBaseAddr ... NEED TO BE FILLED */
+  0, /* ShadowBufSize ... NEED TO BE FILLED */
+  0, /* FvbFlashVarOffset ... NEED TO BE FILLED */
+  0, /* FvbFlashVarSize ... NEED TO BE FILLED */
+  0, /* BlockSize ... NEED TO BE FILLED */
+  0, /* LastBlock ... NEED TO BE FILLED */
+  0, /* StartLba */
+
+  {
+FvbGetAttributes,   /* GetAttributes */
+FvbSetAttributes,   /* SetAttributes */
+FvbGetPhysicalAddress,  /* GetPhysicalAddress */
+FvbGetBlockSize,/* GetBlockSize */
+FvbRead,/* Read */
+FvbWrite,   /* Write */
+FvbEraseBlocks, /* EraseBlocks */
+NULL,   /* ParentHandle */
+  }, /* EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL */
+
+  {
+{
+  {
+HARDWARE_DEVICE_PATH,
+HW_VENDOR_DP,
+{
+  (UINT8)sizeof (VENDOR_DEVICE_PATH),
+  (UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+}
+  },
+  { 0xfc0cb972, 0x21df, 0x44d2, { 0x92, 0xa5, 0x78, 0x98, 0x99, 0xcb, 
0xf6, 0x61 }
+  }
+},
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 }
+}
+  } /* FVB_DEVICE_PATH */
+};
+
+STATIC
+EFI_STATUS
+FvbInitFvAndVariableStoreHeaders (
+  IN FVB_DEVICE  *FlashInstance
+  )
+{
+  EFI_FIRMWARE_VOLUME_HEADER  *FirmwareVolumeHeader;
+  VARIABLE_STORE_HEADER   *VariableStoreHeader;
+  EFI_STATUS  Status;
+  VOID*Headers;
+  UINTN   HeadersLength;
+  UINTN   BlockSize;
+
+  HeadersLength = sizeof (EFI_FIRMWARE_VOLUME_HEADER) +
+  sizeof (EFI_FV_BLOCK_MAP_ENTRY) +
+  sizeof (VARIABLE_STORE_HEADER);
+  Headers = AllocateZeroPool (HeadersLength);
+
+  BlockSize = FlashInstance->BlockSize;
+
+  /* VariableBase -> FtwWOrkingBase -> FtwSpareBase are declared
+   * consecutively in contiguous memory
+   */
+  ASSERT (
+  PcdGet64 (PcdFlashNvStorageVariableBase64) +
+  PcdGet32 (PcdFlashNvStorageVariableSize) ==
+  PcdGet64 (PcdFlashNvStorageFtwWorkingBase64)
+  );
+  ASSERT (
+  PcdGet64 (PcdFlashNvStorageFtwWorkingBase64) +
+  PcdGet32 (PcdFlashNvStorageFtwWorkingSize) ==
+  PcdGet64 (PcdFlashNvStorageFtwSpareBase64)
+  );
+
+  /* Ensure the size of the variable area is at least one block size */
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageVariableSize) > 0) &&
+  (PcdGet32 (PcdFlashNvStorageVariableSize) / BlockSize > 0)
+  );
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageFtwWorkingSize) > 0) &&
+  (PcdGet32 (PcdFlashNvStorageFtwWorkingSize) / BlockSize > 0)
+  );
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageFtwSpareSize) > 0) &&
+

[edk2-devel] [PATCH v3 4/5] StarFive/JH7110Pkg: Add JH7110 Silicon Package

2023-10-26 Thread John Chew 
From: mindachen1987 

- Add a new JH7110 silicon package.
- These files Contain platfrom specific Guids, PCDs and defines
  used for JH7110 SoC.

Cc: Sunil V L 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Li Yong 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h | 21 
 Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec | 57 

 2 files changed, 78 insertions(+)

diff --git a/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h 
b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
new file mode 100644
index ..142e7be10c48
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
@@ -0,0 +1,21 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#ifndef JH7110_H__
+#define JH7110_H__
+
+/* Generic PCI addresses */
+#define PCIE_TOP_OF_MEM_WIN   (FixedPcdGet64 (PcdPciBusMmioAdr))
+#define PCIE_CPU_MMIO_WINDOW  (FixedPcdGet64 (PcdPciCpuMmioAdr))
+#define PCIE_BRIDGE_MMIO_LEN  (FixedPcdGet32 (PcdPciBusMmioLen))
+
+/* PCI root bridge control registers location */
+#define PCIE_REG_BASE (FixedPcdGet64 (PcdPciRegBase))
+#define PCIE_CONFIG_BASE  (FixedPcdGet64 (PcdPciConfigRegBase))
+
+#endif /* JH7110_H__ */
diff --git a/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec 
b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
new file mode 100644
index ..f9dc5ab3781d
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
@@ -0,0 +1,57 @@
+## @file
+#
+#  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = JH7110Pkg
+  PACKAGE_GUID   = D4B585C5-EBCA-4779-B974-05A3CF2F10C4
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
+
+[Guids]
+  gJH7110TokenSpaceGuid = {0x44045e56, 0x7056, 0x4be6, {0x88, 0xc0, 0x49, 
0x0c, 0x67, 0x90, 0x2f, 0xba}}
+
+[PcdsFixedAtBuild.common]
+# Memory map
+  gJH7110TokenSpaceGuid.PcdJH7110FlashVarOffset|0x0|UINT32|0x0001
+
+# PCIe
+  gJH7110TokenSpaceGuid.PcdPciRegBase|0x2b00|UINT64|0x0002
+  gJH7110TokenSpaceGuid.PcdPciBusMmioAdr|0x0|UINT64|0x0003
+  gJH7110TokenSpaceGuid.PcdPciBusMmioLen|0x0|UINT32|0x0004
+  gJH7110TokenSpaceGuid.PcdPciCpuMmioAdr|0x0|UINT64|0x0005
+  gJH7110TokenSpaceGuid.PcdPciConfigRegBase|0x94000|UINT64|0x0006
+  gJH7110TokenSpaceGuid.PcdPciBusMin|0x0|UINT32|0x1007
+  gJH7110TokenSpaceGuid.PcdPciBusMax|0x0|UINT32|0x1008
+  gJH7110TokenSpaceGuid.PcdPciIoBase|0x0|UINT64|0x1009
+  gJH7110TokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x100A
+  gJH7110TokenSpaceGuid.PcdPciIoOffset|0x0|UINT64|0x100B
+  gJH7110TokenSpaceGuid.PcdPci0Mmio32Base|0x0|UINT32|0x100C
+  gJH7110TokenSpaceGuid.PcdPci0Mmio32Size|0x0|UINT32|0x100D
+  gJH7110TokenSpaceGuid.PcdPci0Mmio64Base|0x0|UINT64|0x100E
+  gJH7110TokenSpaceGuid.PcdPci0Mmio64Size|0x0|UINT64|0x100F
+  gJH7110TokenSpaceGuid.PcdPci1Mmio32Base|0x0|UINT32|0x1010
+  gJH7110TokenSpaceGuid.PcdPci1Mmio32Size|0x0|UINT32|0x111
+  gJH7110TokenSpaceGuid.PcdPci1Mmio64Base|0x0|UINT64|0x112
+  gJH7110TokenSpaceGuid.PcdPci1Mmio64Size|0x0|UINT64|0x113
+
+# SPI
+  gJH7110TokenSpaceGuid.PcdSpiFlashRegBase|0|UINT32|0x114
+  gJH7110TokenSpaceGuid.PcdSpiFlashAhbBase|0|UINT64|0x115
+  gJH7110TokenSpaceGuid.PcdSpiFlashFifoWidth|0|UINT8|0x1016
+  gJH7110TokenSpaceGuid.PcdSpiFlashRefClkHz|0|UINT32|0x1017
+  gJH7110TokenSpaceGuid.PcdSpiFlashTshslNs|0|UINT32|0x1018
+  gJH7110TokenSpaceGuid.PcdSpiFlashTsd2dNs|0|UINT32|0x119
+  gJH7110TokenSpaceGuid.PcdSpiFlashTchshNs|0|UINT32|0x11A
+  gJH7110TokenSpaceGuid.PcdSpiFlashTslchNs|0|UINT32|0x11B
+
+[Protocols]
+  gJH7110SpiMasterProtocolGuid = { 0xA33C46E0, 0x4FB6, 0x4AA3, { 0x8E, 0x66, 
0x00, 0x06, 0x9F, 0x3A, 0x11, 0x81 }}
+  gJH7110SpiFlashProtocolGuid  = { 0x5ECECDF6, 0x81DA, 0x4E10, { 0x9D, 0x4B, 
0x26, 0x65, 0x8C, 0x03, 0xAB, 0xBC }}
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110173): https://edk2.groups.io/g/devel/message/110173
Mute This Topic: https://groups.io/mt/102214519/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/5] StarFive/JH7110Pkg: Add Pci controller driver

2023-10-26 Thread John Chew 
From: mindachen1987 

Implement Pci Host Bridge and Pci Segment driver:
JH7110 SoC contains two PCI segment:

- PCI Segment 0 (USB):
32-bit Memory: 0x3000_ ~ 0x3FFF_
64-bit Memory: 0x9__ ~0x9_4000_
- PCI Segment 1 (NVME):
32-bit Memory: 0x3800_ ~ 0x37FF_
64-bit Memory: 0x9_8000_ ~0x9_C000_

Non-prefetachable memory is not used in this configuration.

Cc: Sunil V L 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Li Yong 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
   |  263 
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf   
   |   61 +
 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLibConstructor.c
 |  406 ++
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.c   
   | 1460 
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.inf 
   |   33 +
 5 files changed, 2223 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
new file mode 100644
index ..8b46f6ff58e5
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -0,0 +1,263 @@
+/** @file
+ *
+ * PCI Host Bridge Library instance for StarFive JH7110 SOC
+ *
+ * Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack(1)
+
+typedef PACKED struct {
+  ACPI_HID_DEVICE_PATHAcpiDevicePath;
+  EFI_DEVICE_PATH_PROTOCOLEndDevicePath;
+} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
+
+#pragma pack ()
+
+STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH  mEfiPciRootBridgeDevicePath[] = {
+  {
+{
+  {
+ACPI_DEVICE_PATH,
+ACPI_DP,
+{
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
+}
+  },
+  EISA_PNP_ID (0x0A08), // PCI Express
+  0
+},
+
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  {
+END_DEVICE_PATH_LENGTH,
+0
+  }
+}
+  },
+
+  {
+{
+  {
+ACPI_DEVICE_PATH,
+ACPI_DP,
+{
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
+}
+  },
+  EISA_PNP_ID (0x0A08), // PCI Express
+  1
+},
+
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  {
+END_DEVICE_PATH_LENGTH,
+0
+  }
+}
+  },
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+CHAR16  *mPciHostBridgeLibAcpiAddressSpaceTypeStr[] = {
+  L"Mem", L"I/O", L"Bus"
+};
+
+//
+// See description in MdeModulePkg/Include/Library/PciHostBridgeLib.h
+//
+PCI_ROOT_BRIDGE  mPciRootBridges[] = {
+  {
+0,  // Segment
+0,  // Supports
+0,  // Attributes
+FALSE,  // DmaAbove4G
+FALSE,  // NoExtendedConfigSpace (true=256 
byte config, false=4k)
+FALSE,  // ResourceAssigned
+EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
+EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
+{
+  // Bus
+  FixedPcdGet32 (PcdPciBusMin),
+  FixedPcdGet32 (PcdPciBusMax)
+}, {
+  // Io
+  FixedPcdGet64 (PcdPciIoBase),
+  FixedPcdGet64 (PcdPciIoBase) + FixedPcdGet64 (PcdPciIoSize) - 1,
+  MAX_UINT64 - FixedPcdGet64 (PcdPciIoOffset) + 1
+}, {
+  // Mem
+  FixedPcdGet32 (PcdPci0Mmio32Base),
+  FixedPcdGet32 (PcdPci0Mmio32Base) + FixedPcdGet32 (PcdPci0Mmio32Size) - 1
+}, {
+  // MemAbove4G
+  FixedPcdGet64 (PcdPci0Mmio64Base),
+  FixedPcdGet64 (PcdPci0Mmio64Base) + FixedPcdGet64 (PcdPci0Mmio64Size) - 1
+},
+{
+  // Pefetchable Mem
+  MAX_UINT32,
+  0x0
+}, {
+  // Pefetchable MemAbove4G
+  MAX_UINT64,
+  0x0
+},
+(EFI_DEVICE_PATH_PROTOCOL *)[0]
+  },
+  {
+1,  // Segment
+0,  // Supports
+0,  // Attributes
+FALSE,  // DmaAbove4G
+FALSE,  // NoExtendedConfigSpace (true=256 
byte config, false=4k)
+FALSE,  // ResourceAssigned
+EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
+EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
+{
+  // Bus
+  FixedPcdGet32 (PcdPciBusMin),
+  FixedPcdGet32 (PcdPciBusMax)
+}, {
+  // Io
+  FixedPcdGet64

[edk2-devel] [PATCH v3 0/5] StarFive/VisionFive2: Add VisionFive 2 platform

2023-10-26 Thread John Chew 
v3:
  - Combine "Add VisionFive 2 platform" patch series with
"Patches for JH7110 SoC platform" patch series [Sunil]
  - Change commit message for [1/5], [4/5], [5/5] in this patch series
[Sunil]

v2:
  - Change PlatformBootManagerLib to:
  Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf
[Sunil]
  - Added PCIE PCDs
PcdPciBusMin, PcdPciBusMax, PcdPciIoBase, PcdPciIoSize
PcdPciIoOffset, PcdPci0Mmio32Base, PcdPci0Mmio32Size
PcdPci0Mmio64Base, PcdPci0Mmio64Size, PcdPci1Mmio32Base
PcdPci1Mmio32Size, PcdPci1Mmio64Base, PcdPci1Mmio64Size
[John Chew]
  - Include all maintainer in all patches in this series [Sunil]
  - Added missing commit message to patches 1/6, 2/6, 6/6 [Sunil]
  - Remove commented code in JH7110.h [Sunil]
  - Remove BootServicesDxe/BootServicesDxe.inf, as it is not required 
anymore because memory allocation is handle by MMC driver [Sunil]
  - Remove PlatformBootManagerLib.inf and change PlatformBootManagerLib to
"Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf" [Sunil] 
  - Added PCDs for PCIE (Please refer to patch 0001 for details) [John Chew]

v1:
  - Added new platform support for VisionFive2 SBC.
  - Boot flow in VF2 using EDK2 as bootloader:
BootROM -> U-Boot SPL -> OpenSBI -> EDK2 -> Linux -> OS
  - Supported boot source for Linux from EDK2:
  - SD Card
  - eMMC
  - NVMe
  - USB
  - In this patches it include all the platform specific drivers/protocol
that is being use for JH7110 SoC platform. All the drivers includes:
  1. PCIE driver for NVME and USB (GT710 graphic in progress)
  2. QSPI Flash driver for efi variable
  3. FVB driver for efi variable
  4. Boot service memory allocation driver
  5. Platform boot manager for graphical console display

Cc: Sunil V L 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Li Yong 
Cc: mindachen1987 

John Chew (2):
  StarFive/JH7110Pkg: Add SPI protocol and driver support
  StarFive/JH7110Pkg: Add firmware volume block protocol

mindachen1987 (3):
  StarFive/JH7110Pkg: Add Pci controller driver
  StarFive/JH7110Pkg: Add JH7110 Silicon Package
  StarFive/VisionFive2: Add VisionFive 2 platform

 Platform/StarFive/VisionFive2/DeviceTree/Gpio.h
   |   42 +
 Platform/StarFive/VisionFive2/DeviceTree/Irq.h 
   |   20 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkGen.h
   |  398 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkIsp.h
   |   57 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkVout.h   
   |   68 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110PinCtrl.h   
   | 1573 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110Power.h 
   |   22 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110Rst.h   
   |  228 +++
 Platform/StarFive/VisionFive2/DeviceTree/Led.h 
   |   90 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveClk.dtsi  
   |  130 ++
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveHdmi.dtsi 
   |   28 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveJH7110.dtsi   
   | 1812 
 Platform/StarFive/VisionFive2/DeviceTree/StarFivePwmDac.dtsi   
   |   26 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dts   
   |  211 +++
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dtsi  
   |  838 +
 Platform/StarFive/VisionFive2/DeviceTree/Thermal.h 
   |   16 +
 Platform/StarFive/VisionFive2/DeviceTree/VisionFive2DeviceTree.inf 
   |   36 +
 Platform/StarFive/VisionFive2/VarStore.fdf.inc 
   |   77 +
 Platform/StarFive/VisionFive2/VisionFive2.dsc  
   |  596 +++
 Platform/StarFive/VisionFive2/VisionFive2.fdf  
   |  284 +++
 Platform/StarFive/VisionFive2/VisionFive2.fdf.inc  
   |   48 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
   |  909 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h
   |  138 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf  
   |   70 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
   |  893 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.h
   |  188 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.inf  
   |   52 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.c  
   |  571 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.h  
   |   35 +

Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update

2023-10-26 Thread Michael D Kinney 
Merged: https://github.com/tianocore/edk2/pull/4957


> -Original Message-
> From: Vivian Nowka-Keane 
> Sent: Thursday, October 26, 2023 2:08 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update
> 
> Yes the sign-off is supposed to be the same, thanks for catching that.
> And I'll update my git config for the future!
> 
> The PR looks good
> 
> Thanks,
> - Vivian
> 
> On 10/25/2023 11:08 AM, Michael D Kinney wrote:
> > I also noticed that the Author was not set correctly on
> > these patches.  I updated using the same name/email from
> > your Signed-off-by tag.
> >
> > Please review your git config to match for future patches.
> >
> > I have started EDK II CI with the following PR:
> >
> > https://github.com/tianocore/edk2/pull/4957
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: Kinney, Michael D 
> >> Sent: Wednesday, October 25, 2023 10:11 AM
> >> To: Vivian Nowka-Keane ;
> >> devel@edk2.groups.io
> >> Cc: Kinney, Michael D 
> >> Subject: RE: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> update
> >>
> >> Hi Vivian,
> >>
> >> I am working on this.  However, I noticed that Patch 6/7 was
> >> missing Signed-off-by tag.  Is that supposed to be the same
> >> as the other 6 patches?
> >>
> >> Signed-off-by: Vivian Nowka-Keane 
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: Vivian Nowka-Keane 
> >>> Sent: Tuesday, October 24, 2023 1:35 PM
> >>> To: devel@edk2.groups.io; Kinney, Michael D
> >>> 
> >>> Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> >> update
> >>> Hi, following up to see if there's any update on this.
> >>>
> >>> Thanks for your help,
> >>>
> >>> - Vivian
> >>>
> >>> On 9/27/2023 12:43 PM, Vivian Nowka-Keane wrote:
>  Hi Mike,
> 
>  Can you help merge this? Looks like it has all of the reviews.
> 
>  Thank you!
>  - Vivian
> 
>  On 9/12/2023 7:42 AM, Michael D Kinney wrote:
> > Series Reviewed-by: Michael D Kinney
> >
> >> -Original Message-
> >> From:devel@edk2.groups.io    On Behalf Of
> >> VivianNK
> >> Sent: Wednesday, August 16, 2023 2:15 PM
> >> To:devel@edk2.groups.io
> >> Subject: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> >> update
> >> v1 -> v2:
> >>    - Update commit message to explain the audit only mode
> change
> >> is
> >>      temporary to prevent intermediate CI failures.
> >>    - Format patch Cc's correctly
> >>
> >> v1 archive:https://edk2.groups.io/g/devel/message/107665
> >>
> >> VivianNK (7):
> >>     .pytool: Set uncrustify check to audit only (temporary)
> >>     .pytool: Add cpp support to uncrustify plugin
> >>     MdeModulePkg: Apply uncrustify formatting to relevant
> files.
> >>     MdePkg: Apply uncrustify formatting to relevant files
> >>     SecurityPkg: Apply uncrustify formatting to relevant files
> >>     UnitTestFrameworkPkg: Apply uncrustify formatting to
> relevant
> >>> files
> >>     .pytool: Undo uncrustify check change
> >>
> >>    .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> >> |   2 +-
> >>    .pytool/Plugin/UncrustifyCheck/uncrustify.cfg
> >> |   4 +-
> >>
> >>
> MdeModulePkg/Library/UefiSortLib/GoogleTest/UefiSortLibGoogleTest.cpp
> >> |  37 +-
> >>
> >>
> MdeModulePkg/Test/Mock/Include/GoogleTest/Library/MockPciHostBridgeLib
> >>> .h
> >> |   4 +-
> >>
> >>
> >>
> MdeModulePkg/Test/Mock/Library/GoogleTest/MockPciHostBridgeLib/MockPci
> >>> HostBri
> >> dgeLib.cpp |   8 +-
> >>
> >>
> >>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> >>> ests32.
> >> cpp    | 114 ++--
> >>
> >>
> >>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> >>> ests64.
> >> cpp    | 114 ++--
> >>
> >>>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.cpp
> >> | 563 ++--
> >>    MdePkg/Test/Mock/Include/GoogleTest/Library/MockHobLib.h
> >> |   6 +-
> >>
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockPeiServicesLib.h
> >> |   6 +-
> >>    MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiLib.h
> >> |   4 +-
> >>
> >>
> >>
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> >>> leLib.h
> >> |   4 +-
> >> MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.cpp
> >> |  40 +-
> >>
> >>
> >>
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServices
> >>> Lib.cpp
> >> |  52 +-
> >> MdePkg/Test/Mock/Library/GoogleTest/MockUefiLib/MockUefiLib.cpp
> >> |   6 +-
> >>
> >>
> >>
> MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> >>> ckUefiR
> >> untimeServicesTableLib.cpp |  12 +-
> >>
> >>
> >>
>

Re: [edk2-devel] [edk2-redfish-client][PATCH v2 11/11] RedfishFeatureCoreDxe: add check for memory allocation failure

2023-10-26 Thread Chang, Abner via groups.io 
[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Mike Maslenkin 
> Sent: Friday, October 27, 2023 7:54 AM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; nick...@nvidia.com;
> ig...@ami.com; Mike Maslenkin 
> Subject: [edk2-redfish-client][PATCH v2 11/11] RedfishFeatureCoreDxe: add
> check for memory allocation failure
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Signed-off-by: Mike Maslenkin 
> ---
>  .../RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c   | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> index f71b12e4b5e0..d9aa6e1a8145 100644
> --- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> +++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> @@ -331,6 +331,12 @@ NewInternalInstance (
>}
>
>
>
>NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
>
> +  if (NewInternalData->NodeName == NULL) {
>
> +DEBUG ((DEBUG_ERROR, "%a: No memory for NodeName\n", __func__));
>
> +FreePool (NewInternalData);
>
> +return EFI_OUT_OF_RESOURCES;
>
> +  }
>
> +
>
>StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1, (CONST
> CHAR16 *)NodeName, StrLen (NodeName));
>
>NewInternalData->SiblingList = NULL;
>
>NewInternalData->ChildList   = NULL;
>
> --
> 2.32.0 (Apple Git-132)



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

Re: [edk2-devel] [edk2-redfish-client][PATCH v2 09/11] RedfishClientPkg: fix StrnCpyS arguments

2023-10-26 Thread Chang, Abner via groups.io 
[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Mike Maslenkin 
> Sent: Friday, October 27, 2023 7:54 AM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; nick...@nvidia.com;
> ig...@ami.com; Mike Maslenkin 
> Subject: [edk2-redfish-client][PATCH v2 09/11] RedfishClientPkg: fix StrnCpyS
> arguments
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> StrnCpyS accepts string length in characters, not in bytes.
>
> Signed-off-by: Mike Maslenkin 
> ---
>  RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> index 8ac165dec59e..c19d4a46d6af 100644
> --- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> +++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> @@ -331,7 +331,7 @@ NewInternalInstance (
>}
>
>
>
>NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
>
> -  StrnCpyS (NewInternalData->NodeName, StrSize (NodeName), (CONST
> CHAR16 *)NodeName, StrLen (NodeName));
>
> +  StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1, (CONST
> CHAR16 *)NodeName, StrLen (NodeName));
>
>NewInternalData->SiblingList = NULL;
>
>NewInternalData->ChildList   = NULL;
>
>if (NodeIsCollection) {
>
> --
> 2.32.0 (Apple Git-132)



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

Re: [edk2-devel] [PATCH 9/9] RedfishClientPkg: fix StrnCpyS arguments

2023-10-26 Thread Chang, Abner via groups.io 
[AMD Official Use Only - General]

> -Original Message-
> From: Mike Maslenkin 
> Sent: Friday, October 27, 2023 7:51 AM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io; nick...@nvidia.com; ig...@ami.com
> Subject: Re: [PATCH 9/9] RedfishClientPkg: fix StrnCpyS arguments
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Oct 2, 2023 at 5:56 AM Chang, Abner 
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Mike Maslenkin 
> > > Sent: Saturday, September 30, 2023 5:59 AM
> > > To: devel@edk2.groups.io
> > > Cc: Chang, Abner ; nick...@nvidia.com;
> > > ig...@ami.com; Mike Maslenkin 
> > > Subject: [PATCH 9/9] RedfishClientPkg: fix StrnCpyS arguments
> > >
> > > Caution: This message originated from an External Source. Use proper
> caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > StrnCpyS accepts string length in characters, not in bytes.
> > >
> > > Signed-off-by: Mike Maslenkin 
> > > ---
> > >  RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > > b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > > index 8ac165dec59e..c19d4a46d6af 100644
> > > --- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > > +++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > > @@ -331,7 +331,7 @@ NewInternalInstance (
> > >}
> > >
> > >
> > >
> > >NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
> > >
> > > -  StrnCpyS (NewInternalData->NodeName, StrSize (NodeName), (CONST
> > > CHAR16 *)NodeName, StrLen (NodeName));
> > >
> > > +  StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1,
> (CONST
> > > CHAR16 *)NodeName, StrLen (NodeName));
> > The original code is already the size of string that includes NULL 
> > terminator.
> However, we should check if NewInternalData->NodeName is NULL or not
> before copying the string. Mike, could you please help to add this check?
> >
> > Thanks
> > Abner
> >
> Hi, Abner
>
> The problem is not with NULL terminator
> The problem is that StrnCpyS takes a number of unicode chars as a
> second parameter, not a string size in bytes returned by StrSize().
Yeah got it.

>
> So I left this patch unmodified and added two additional patches
> required for NULL pointer check.
Ok

Abner
>
> Thanks,
> Mike.


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

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg: Fix the failure to find uncompressed inner FV.

2023-10-26 Thread Xu, Wei6 
Hi Laszlo,

Thanks a lot for the review.

I send review the patch v2 to fix:
- memory leaks on error paths
- missing object size checks before casting pointers to header types
(https://edk2.groups.io/g/devel/message/110160)

Regarding to 'unbounded recursion', I couldn't come up with a good solution to 
fix the problem, let's fix the others first.


BR,
Wei

-Original Message-
From: Laszlo Ersek  
Sent: Tuesday, October 24, 2023 8:03 PM
To: devel@edk2.groups.io; Xu, Wei6 
Cc: Ard Biesheuvel ; Sami Mujawar 
; Ni, Ray 
Subject: Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg: Fix the failure to find 
uncompressed inner FV.

On 10/24/23 07:53, Xu, Wei6 wrote:
> The MmCoreFfsFindMmDriver only checks for encapsulated compressed FVs.
> When an inner FV is uncompressed, StandaloneMmCore will miss the FV 
> and all the MM drivers in the FV will not be dispatched.
> Add checks for uncompressed inner FV to fix this issue.
> 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Ray Ni 
> Signed-off-by: Wei6 Xu 
> ---
>  StandaloneMmPkg/Core/FwVol.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/StandaloneMmPkg/Core/FwVol.c 
> b/StandaloneMmPkg/Core/FwVol.c index 1f6d7714ba97..1a85d80eb9f7 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -104,6 +104,17 @@ MmCoreFfsFindMmDriver (
>break;
>  }
>  
> +Status = FfsFindSectionData (
> +   EFI_SECTION_FIRMWARE_VOLUME_IMAGE,
> +   FileHeader,
> +   ,
> +   
> +   );
> +if (!EFI_ERROR (Status)) {
> +  InnerFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)SectionData;
> +  MmCoreFfsFindMmDriver (InnerFvHeader);
> +}
> +
>  Status = FfsFindSectionData (
> EFI_SECTION_GUID_DEFINED,
> FileHeader,

I'd recommend fixing other, more foundational issues first, in this function, 
such as:

- memory leaks on error paths

- unbounded recursion

- missing object size checks before casting pointers to header types

At the same time I agree that this change doesn't seem to make things worse 
than they are.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110166): https://edk2.groups.io/g/devel/message/110166
Mute This Topic: https://groups.io/mt/102152694/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 2/2] OutOfBandManagement/IpmiFeaturePKg: Remove IpmiCommandLib.h from IpmiFeaturePkg

2023-10-26 Thread Chang, Abner via groups.io 
[AMD Official Use Only - General]

Hi Liming and Nate
Please review this change, which removes duplicated IpmiCommandLib.h from 
IpmiFeaturePkg. This is also similar to the patch that removes IpmiCommandLib.h 
from ManageabilityPkg.

Thanks
Abner

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang,
> Abner via groups.io
> Sent: Wednesday, October 18, 2023 12:53 PM
> To: devel@edk2.groups.io; Chang, Abner 
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Isaac
> Oram ; Nickle Wang ; Nate
> DeSimone ; Liming Gao
> 
> Subject: Re: [edk2-devel] [edk2-platforms][PATCH 2/2]
> OutOfBandManagement/IpmiFeaturePKg: Remove IpmiCommandLib.h from
> IpmiFeaturePkg
>
> [AMD Official Use Only - General]
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> [AMD Official Use Only - General]
>
> Hi Nate and Liming,
> Please help to review this patch.
>
> Thanks
> Abner
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Chang,
> > Abner via groups.io
> > Sent: Tuesday, October 10, 2023 4:22 PM
> > To: devel@edk2.groups.io
> > Cc: Attar, AbdulLateef (Abdul Lateef) ; Isaac
> > Oram ; Nickle Wang ; Nate
> > DeSimone 
> > Subject: [edk2-devel] [edk2-platforms][PATCH 2/2]
> > OutOfBandManagement/IpmiFeaturePKg: Remove IpmiCommandLib.h
> from
> > IpmiFeaturePkg
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > From: Abner Chang 
> >
> > Remove duplicate IpmiCommandLib.h and use the one
> > under MdeModulePKg instead.
> >
> > Signed-off-by: Abner Chang 
> > Cc: Abdul Lateef Attar 
> > Cc: Isaac Oram 
> > Cc: Nickle Wang 
> > Cc: Isaac Oram 
> > Cc: Nate DeSimone 
> > ---
> >  .../IpmiFeaturePkg/BmcElog/BmcElog.inf|   1 +
> >  .../IpmiFeaturePkg/Frb/FrbPei.inf |   1 +
> >  .../GenericIpmi/Dxe/GenericIpmi.inf   |   1 +
> >  .../GenericIpmi/Pei/PeiGenericIpmi.inf|   1 +
> >  .../GenericIpmi/Smm/SmmGenericIpmi.inf|   1 +
> >  .../IpmiFeaturePkg/IpmiFru/IpmiFru.inf|   1 +
> >  .../IpmiFeaturePkg/OsWdt/OsWdt.inf|   1 +
> >  .../IpmiFeaturePkg/SolStatus/SolStatus.inf|   1 +
> >  .../Include/Library/IpmiCommandLib.h  | 314 --
> >  9 files changed, 8 insertions(+), 314 deletions(-)
> >  delete mode 100644
> >
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Library/Ipm
> > iCommandLib.h
> >
> > diff --git
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/BmcElog/BmcElo
> > g.inf
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/BmcElog/BmcElo
> > g.inf
> > index 388dd2740c..1e7a7658b7 100644
> > ---
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/BmcElog/BmcElo
> > g.inf
> > +++
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/BmcElog/BmcElo
> > g.inf
> > @@ -21,6 +21,7 @@
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >IpmiFeaturePkg/IpmiFeaturePkg.dec
> >
> >  [LibraryClasses]
> > diff --git
> > a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Frb/FrbPei.inf
> > b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Frb/FrbPei.inf
> > index 797dbe6a07..bfd80d4a98 100644
> > ---
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Frb/FrbPei.inf
> > +++
> > b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Frb/FrbPei.inf
> > @@ -20,6 +20,7 @@
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >IpmiFeaturePkg/IpmiFeaturePkg.dec
> >
> >  [LibraryClasses]
> > diff --git
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/
> > GenericIpmi.inf
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/
> > GenericIpmi.inf
> > index 1564ceb08a..d37d1c5046 100644
> > ---
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/
> > GenericIpmi.inf
> > +++
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/
> > GenericIpmi.inf
> > @@ -37,6 +37,7 @@
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >IpmiFeaturePkg/IpmiFeaturePkg.dec
> >
> >  [LibraryClasses]
> > diff --git
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Pei/
> P
> > eiGenericIpmi.inf
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Pei/
> > PeiGenericIpmi.inf
> > index 3a73180ce6..d7fb7f1c5b 100644
> > ---
> >
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Pei/
> P
> > eiGenericIpmi.inf
> > +++
> >
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Pei/
> > PeiGenericIpmi.inf
> > @@ -36,6 +36,7 @@
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >IpmiFeaturePkg/IpmiFeaturePkg.dec
> >
> >  [LibraryClasses]
> > diff --git
> > a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Sm
> >

Re: [edk2-devel] [PATCH v2 1/1] StarFive/VisionFive2: Add VisionFive 2 platform

2023-10-26 Thread John Chew 
Hi Sunil,

Actually, I submitted 3 series for ease of reviewing which are:

1. DesignWare MMC (5 patches)

2. JH7110 SoC (4 patches)

3. VisionFive 2 (1 patch)

Ouh!! I misunderstood the guidelines. Let me correct the commit message in v3.

v3 todo:

1. Update the following patch commit message:

- StarFive/JH7110Pkg: Add JH7110 Silicon Package    [1/4]
- StarFive/JH7110Pkg: Add Pci controller driver            [4/4]

2. Move the patch changes to the cover letter.

2. Combine JH7110 SoC and VisionFive 2 patches into 1 series.

Thank you for your time =D

John


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

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

2023-10-26 Thread Yoshinoya 



Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being 
executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could not match these describes with standard UEFI BIOS Boot flow, such 
as dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks
















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" 
 wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek"  wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, 
>> >> maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible 
>depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, 
>makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all 
>the
>components in the path to memory + locking them down an EDK2 problem.  They 
>are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR 
>memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL 
>aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in 
>PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for 
>the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it 
>for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree 
>support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>



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

Re: [edk2-devel] question about cxl device enumeration in pci bus driver

2023-10-26 Thread Yoshinoya 
Hi,
Thanks for reply!


I download code from this git https://github.com/SayantaP-arm/edk2-platforms/


For this ARM edk2 sample package, it provided cxldxe driver which being 
executed after UEFI DXE PciBus enumeration finishes.
This ppt (https://lpc.events/event/16/contributions/1254/) describes good.


Intel also provied a CXL Type 3 memory device software guide.
This guide also describes system firmware boot sequence and uefi boot sequence.
But i could match these describes with standard UEFI BIOS Boot flow, such as 
dxe phase's standard pci enumeration driver.
It sees needing add some cxl discovery code into dxe pci bus driver.


Thanks
















At 2023-10-26 21:35:38, "Jonathan Cameron via groups.io" 
 wrote:
>On Thu, 26 Oct 2023 11:49:28 +0200
>"Laszlo Ersek"  wrote:
>
>> On 10/26/23 10:33, Gerd Hoffmann wrote:
>> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
>> >   
>> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, 
>> >> maybe could be integrated into pci drivers stack.  
>> > 
>> > Point being?  Can or should the firmware do anything useful with
>> > the CXL hardware?  If so, what exactly and why?
>> > 
>> > Current state of affairs is that the PCI stack does the usual PCI
>> > initialization (enumerate, assign resources to PCI bars) and leaves
>> > everything else to the OS.  
>> 
>> (I don't know what "HDM Config" stands for.)
>> 
>> The only utility for driving CXL devices from the firmware could be, AFAICT:
>> 
>> - booting off of such a device (or at least "supporting OS boot" in some
>> manner)
>> 
>> - using such a device for UEFI console purposes
>
>There are different models for how to use CXL devices and what's possible 
>depends on the
>version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
>EDK2 platform logic basically has to do everything.
>
>The one mostly expected for early CXL servers, for backwards compatibility, 
>makes
>setting up the CXL memory decoders (Host managed Device Memory - HDM) in all 
>the
>components in the path to memory + locking them down an EDK2 problem.  They 
>are then
>presented in the memory map and in SRAT, HMAT etc the same as normal DDR 
>memory.
>Idea being that an old OS will be fine with that and doesn't have to be CXL 
>aware
>at all.  Note this also involves walking the CDAT tables via DOE mailboxes in 
>PCI
>config space to get the magic numbers needed to compute HMAT.
>
>The other model is to do very little in EDK2 and make entirely a problem for 
>the OS.
>The logic is necessary anyway if you want to support hotplug etc, so use it 
>for the
>cold plug paths 2.  That's all we've currently supported on QEMU.
>
>There was a presentation at Linux Plumbers last year on some out of tree 
>support
>from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
>https://lpc.events/event/16/contributions/1254/
>But I guess it never went upstream.
>https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3
>
>+CC Sayanta
>
>Jonathan
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110162): https://edk2.groups.io/g/devel/message/110162
Mute This Topic: https://groups.io/mt/102173204/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/1] StandaloneMmPkg: Fix some issues in function MmCoreFfsFindMmDriver.

2023-10-26 Thread Xu, Wei6 
1. The MmCoreFfsFindMmDriver only checks for encapsulated compressed
FVs. When an inner FV is uncompressed, StandaloneMmCore will miss the
FV and all the MM drivers in the FV will not be dispatched. Add checks
for uncompressed inner FV to fix this issue.
2. If FileHeader is an EFI_FFS_FILE_HEADER2, 'FileHeader + 1' will get
a wrong section address. Use FfsFindSection to get the section directly,
instead of 'FileHeader + 1' to avoid this issue.
3. ScratchBuffer is not freed in the error return path that DstBuffer
page allocation fails. Free ScratchBuffer before return with error.

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 
Signed-off-by: Wei6 Xu 
---
 StandaloneMmPkg/Core/FwVol.c | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
index 1f6d7714ba97..fb483bd62696 100644
--- a/StandaloneMmPkg/Core/FwVol.c
+++ b/StandaloneMmPkg/Core/FwVol.c
@@ -104,23 +104,40 @@ MmCoreFfsFindMmDriver (
   break;
 }
 
+//
+// Check uncompressed firmware volumes
+//
 Status = FfsFindSectionData (
-   EFI_SECTION_GUID_DEFINED,
+   EFI_SECTION_FIRMWARE_VOLUME_IMAGE,
FileHeader,
,

);
+if (!EFI_ERROR (Status)) {
+  if (SectionDataSize > sizeof (EFI_FIRMWARE_VOLUME_HEADER)) {
+InnerFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)SectionData;
+MmCoreFfsFindMmDriver (InnerFvHeader);
+  }
+}
+
+//
+// Check compressed firmware volumes
+//
+Status = FfsFindSection (
+   EFI_SECTION_GUID_DEFINED,
+   FileHeader,
+   
+   );
 if (EFI_ERROR (Status)) {
   break;
 }
 
-Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
-Status  = ExtractGuidedSectionGetInfo (
-Section,
-,
-,
-
-);
+Status = ExtractGuidedSectionGetInfo (
+   Section,
+   ,
+   ,
+   
+   );
 if (EFI_ERROR (Status)) {
   break;
 }
@@ -138,6 +155,7 @@ MmCoreFfsFindMmDriver (
 //
 DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
(DstBufferSize));
 if (DstBuffer == NULL) {
+  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
   return EFI_OUT_OF_RESOURCES;
 }
 
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110161): https://edk2.groups.io/g/devel/message/110161
Mute This Topic: https://groups.io/mt/102212658/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/1] StandaloneMmCore finds drivers in uncompressed inner fv.

2023-10-26 Thread Xu, Wei6 
V1:
This patch is to fix the issue that StandaloneMmCore fails to detect 
uncompressed inner FV.
PR: https://github.com/tianocore/edk2/pull/4943

V2:
Based on V1, fix some other issues
1. Add Missing object size checks before casting pointers to header types
  a. InnerFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)SectionData; 
 This is introduced in V1, add the size check on SectionDataSize against 
EFI_FIRMWARE_VOLUME_HEADER
  b. Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
 Use FfsFindSection instead of FfsFindSectionData to avoid pointer casting.
2. Fix potential memory leak issue that ScratchBuffer is not freed when page 
allocation for DstBuffer fails.
PR: https://github.com/tianocore/edk2/pull/4965

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Ray Ni 

Wei6 Xu (1):
  StandaloneMmPkg: Fix some issues in function MmCoreFfsFindMmDriver.

 StandaloneMmPkg/Core/FwVol.c | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110160): https://edk2.groups.io/g/devel/message/110160
Mute This Topic: https://groups.io/mt/102212657/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/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

2023-10-26 Thread sunceping 
From: Ceping Sun 

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

According to section 3.2 of the [GHCI] document, if the result of MapGPA
is "TDG.VP.VMCALL_RETRY", TDVF must retry mapping for pages in that region,
starting with the GPA specified in R11.

Reference:
[GHCI]: TDX Guest-Host-Communication Interface v1.0
https://cdrdv2.intel.com/v1/dl/getContent/726790

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Cc: Gerd Hoffmann 
Signed-off-by: Ceping Sun 
---
 .../BaseMemEncryptTdxLib.inf  |  1 +
 .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 36 ++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf 
b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
index 11768825f8ca..742b65a289ce 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
@@ -30,6 +30,7 @@
 [Sources]
   VirtualMemory.h
   MemoryEncryption.c
+  X64/TdVmCallMapGPA.nasm
 
 [LibraryClasses]
   BaseLib
diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c 
b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
index b47f56b391a5..1f29f9194c30 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
@@ -38,6 +38,10 @@ typedef enum {
 
 STATIC PAGE_TABLE_POOL  *mPageTablePool = NULL;
 
+#define TDVMCALL_STATUS_RETRY  0x1
+
+#define MAX_RETRIES_PER_PAGE  3
+
 /**
   This function is used to help request the host VMM to map a GPA range as
   private or shared-memory mappings.
@@ -546,6 +550,13 @@ SetOrClearSharedBit (
   EFI_STATUSStatus;
   EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
 
+  UINT64  MapGpaRetryaddr;
+  UINT32  RetryCount;
+  UINT64  EndAddress;
+
+  MapGpaRetryaddr = 0;
+  RetryCount  = 0;
+
   AddressEncMask = GetMemEncryptionAddressMask ();
 
   //
@@ -559,7 +570,30 @@ SetOrClearSharedBit (
 PhysicalAddress   &= ~AddressEncMask;
   }
 
-  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL);
+  while (RetryCount < MAX_RETRIES_PER_PAGE) {
+TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, );
+if (TdStatus != TDVMCALL_STATUS_RETRY) {
+  break;
+}
+
+DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is 
%llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr));
+
+EndAddress = PhysicalAddress + Length;
+if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > EndAddress)) 
{
+  DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed Retry PhysicalAddress 
is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, 
MapGpaRetryaddr));
+  break;
+}
+
+if (MapGpaRetryaddr == PhysicalAddress) {
+  RetryCount++;
+  continue;
+}
+
+PhysicalAddress = MapGpaRetryaddr;
+Length  = EndAddress - PhysicalAddress;
+RetryCount  = 0;
+  }
+
   if (TdStatus != 0) {
 DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n", __func__, 
TdStatus));
 ASSERT (FALSE);
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110159): https://edk2.groups.io/g/devel/message/110159
Mute This Topic: https://groups.io/mt/102212640/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/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA

2023-10-26 Thread sunceping 
From: Ceping Sun 

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

According to section 3.2 of the [GHCI] spec, if the return status
is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the
pages in the region starting at the GPA specified in R11.

Currently, TDVF has not handled the retry results of MapGPA. For this,
TDVF should add the API to output the GPA at which MapGPA failed in R11
to handle the retry results.

Reference:
[GHCI]: TDX Guest-Host-Communication Interface v1.0
https://cdrdv2.intel.com/v1/dl/getContent/726790

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Cc: Gerd Hoffmann 
Signed-off-by: Ceping Sun 
---
 .../BaseMemEncryptTdxLib/MemoryEncryption.c   |  19 +++
 .../X64/TdVmCallMapGPA.nasm   | 130 ++
 2 files changed, 149 insertions(+)
 create mode 100644 OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm

diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c 
b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
index a01dc98852b8..b47f56b391a5 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
@@ -38,6 +38,25 @@ typedef enum {
 
 STATIC PAGE_TABLE_POOL  *mPageTablePool = NULL;
 
+/**
+  This function is used to help request the host VMM to map a GPA range as
+  private or shared-memory mappings.
+  @param[in] Address 4K aligned start GPA of address range.
+  @param[in] Length  Size of GPA region to be mapped.
+  @param[in,out] Results Returned result of the GPA at which MapGPA failed
+
+  @return 0   A successful mapping
+  @return Other   Some errors occurred while mapping
+**/
+
+UINTN
+EFIAPI
+TdVmCallMapGPA (
+  IN UINT64Address,
+  IN UINT64Length,
+  IN OUT VOID  *Results
+  );
+
 /**
   Returns boolean to indicate whether to indicate which, if any, memory 
encryption is enabled
 
diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm 
b/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm
new file mode 100644
index ..37186bd0a0dd
--- /dev/null
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm
@@ -0,0 +1,130 @@
+;--
+;*
+;* Copyright (c) 2020 - 2021, Intel Corporation. All rights reserved.
+;* SPDX-License-Identifier: BSD-2-Clause-Patent
+;*
+;*
+;--
+
+DEFAULT REL
+SECTION .text
+
+%define TDVMCALL_EXPOSE_REGS_MASK   0xffec
+%define TDVMCALL0x0
+%define TDVMCALL_MAPGPA 0x10001
+%define TDVMCALL_STATUS_RETRY   0x1
+
+%macro tdcall 0
+db 0x66,0x0f,0x01,0xcc
+%endmacro
+
+%macro tdcall_push_regs 0
+push rbp
+mov  rbp, rsp
+push r15
+push r14
+push r13
+push r12
+push rbx
+push rsi
+push rdi
+%endmacro
+
+%macro tdcall_pop_regs 0
+pop rdi
+pop rsi
+pop rbx
+pop r12
+pop r13
+pop r14
+pop r15
+pop rbp
+%endmacro
+
+%macro tdcall_regs_preamble 2
+mov rax, %1
+
+xor rcx, rcx
+mov ecx, %2
+
+; R10 = 0 (standard TDVMCALL)
+
+xor r10d, r10d
+
+; Zero out unused (for standard TDVMCALL) registers to avoid leaking
+; secrets to the VMM.
+
+xor ebx, ebx
+xor esi, esi
+xor edi, edi
+
+xor edx, edx
+xor ebp, ebp
+xor r8d, r8d
+xor r9d, r9d
+%endmacro
+
+%macro tdcall_regs_postamble 0
+xor ebx, ebx
+xor esi, esi
+xor edi, edi
+
+xor ecx, ecx
+xor edx, edx
+xor r8d,  r8d
+xor r9d,  r9d
+xor r10d, r10d
+xor r11d, r11d
+%endmacro
+
+;--
+; 0   => RAX = TDCALL leaf
+; M   => RCX = TDVMCALL register behavior
+; 1   => R10 = standard vs. vendor
+; 0xa => R11 = TDVMCALL function / MapGPA
+; RCX => R12 = p1
+; RDX => R13 = p2
+
+;  UINT64
+;  EFIAPI
+;  TdVmCallMapGPA (
+;UINT64  Address,  // Rcx
+;UINT64  Length,   // Rdx
+;UINT64  *Results  // r8
+;)
+global ASM_PFX(TdVmCallMapGPA)
+ASM_PFX(TdVmCallMapGPA):
+   tdcall_push_regs
+
+   mov r11, TDVMCALL_MAPGPA
+   mov r12, rcx
+   mov r13, rdx
+
+   push r8
+
+   tdcall_regs_preamble TDVMCALL, TDVMCALL_EXPOSE_REGS_MASK
+
+   tdcall
+
+   ; ignore return dataif TDCALL reports failure.
+   test rax, rax
+   jnz .no_return_data
+
+   ; Propagate TDVMCALL success/failure to return value.
+   mov rax, r10
+
+   ; Retrieve the Val pointer.
+   pop r8
+   test r8, r8
+   jz .no_return_data
+
+   ; On Retry, propagate TDVMCALL output value to output param
+   cmp  rax, TDVMCALL_STATUS_RETRY
+   jnz .no_return_data
+   mov [r8], r11
+.no_return_data:
+   tdcall_regs_postamble
+
+   tdcall_pop_regs
+
+   ret
--

[edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

2023-10-26 Thread sunceping 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572

According to section 3.2 of the [GHCI] documentation, if the result is
"TDG.VP.VMCALL_RETRY" for TDG.VP.VMCALL, TD must retry the mapping for
the pages in the region starting at the GPA specified in r11.

Currently, TDVF does not properly handle the retry results of MapGPA.
For this, TDVF should add the API to return the value in R11 and must 
retry the mapping for the pages by the value.

How to verify the retry for MapGPA in TDVF:
Note: Since the range size of MapGPA in QEMU is limited to 64MB and 
TDVF always maps 1.5GB( 2GB~3.5GB) MMIO to shared-memory for TD guest, 
the retry action is triggered always.
Pre-Config:
QEMU:
https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream | tag: 
tdx-qemu-upstream-2023.10.20-v8.1.0
KERNEL:
https://github.com/intel/tdx/tree/kvm-upstream-2023.10.16-v6.6-rc2

Step:
Boot with TD guest and check the log with TdVmcall(MAPGPA). Would See the line 
as below:
TdxDxe:SetMemorySharedOrPrivate: Cr3Base=0x0 Physical=0x8000 
Length=0x6000 Mode=Shared
SetOrClearSharedBit: TdVmcall(MAPGPA) Retry PhysicalAddress is 88000, 
MapGpaRetryaddr is 88400

Reference:
[GHCI]: TDX Guest-Host-Communication Interface v1.0
https://cdrdv2.intel.com/v1/dl/getContent/726790

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Cc: Gerd Hoffmann 
Signed-off-by: Ceping Sun 

Ceping Sun (2):
  OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA
  OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

 .../BaseMemEncryptTdxLib.inf  |   1 +
 .../BaseMemEncryptTdxLib/MemoryEncryption.c   |  55 +++-
 .../X64/TdVmCallMapGPA.nasm   | 130 ++
 3 files changed, 185 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110157): https://edk2.groups.io/g/devel/message/110157
Mute This Topic: https://groups.io/mt/102212634/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 v2 10/11] RedfishFeatureCoreDxe: replace __FUNCTION__ with __func__

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c  | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c 
b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
index c19d4a46d6af..f71b12e4b5e0 100644
--- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
+++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
@@ -319,14 +319,14 @@ NewInternalInstance (
   REDFISH_FEATURE_INTERNAL_DATA  *NewInternalData;
 
   if ((PtrToNewInternalData == NULL) || (NodeName == NULL)) {
-DEBUG ((DEBUG_ERROR, "%a: Inproper given parameters\n", __FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: Inproper given parameters\n", __func__));
 return EFI_INVALID_PARAMETER;
   }
 
   *PtrToNewInternalData = NULL;
   NewInternalData   = AllocateZeroPool (sizeof 
(REDFISH_FEATURE_INTERNAL_DATA));
   if (NewInternalData == NULL) {
-DEBUG ((DEBUG_ERROR, "%a: No memory for REDFISH_FEATURE_INTERNAL_DATA\n", 
__FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: No memory for REDFISH_FEATURE_INTERNAL_DATA\n", 
__func__));
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -377,12 +377,12 @@ InsertRedfishFeatureUriNode (
 
   *MatchNodeEntry = NULL;
   if (NodeName == NULL) {
-DEBUG ((DEBUG_ERROR, "%a: Node name is NULL.\n", __FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: Node name is NULL.\n", __func__));
 return EFI_INVALID_PARAMETER;
   }
 
   if (NextNodeEntry == NULL) {
-DEBUG ((DEBUG_ERROR, "%a: NextNodeEntry can't be NULL.\n", __FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: NextNodeEntry can't be NULL.\n", __func__));
 return EFI_INVALID_PARAMETER;
   }
 
@@ -487,7 +487,7 @@ RedfishFeatureRegister (
   BOOLEANItsCollection;
 
   if ((FeatureManagedUri == NULL) || (Callback == NULL)) {
-DEBUG ((DEBUG_ERROR, "%a: The given parameter is invalid\n", 
__FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: The given parameter is invalid\n", __func__));
 return EFI_INVALID_PARAMETER;
   }
 
@@ -503,7 +503,7 @@ RedfishFeatureRegister (
   while ((Index < UriLength)) {
 if ((Index - AnchorIndex + 1) >= MaxNodeNameLength) {
   // Increase one for the NULL terminator
-  DEBUG ((DEBUG_ERROR, "%a: the length of node name is >= 
MaxNodeNameLength\n", __FUNCTION__));
+  DEBUG ((DEBUG_ERROR, "%a: the length of node name is >= 
MaxNodeNameLength\n", __func__));
   ASSERT (FALSE);
 }
 
@@ -568,7 +568,7 @@ RedfishFeatureRegister (
 //
 // No URI node was created
 //
-DEBUG ((DEBUG_ERROR, "%a: No URI node is added\n", __FUNCTION__));
+DEBUG ((DEBUG_ERROR, "%a: No URI node is added\n", __func__));
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110155): https://edk2.groups.io/g/devel/message/110155
Mute This Topic: https://groups.io/mt/102211779/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 v2 11/11] RedfishFeatureCoreDxe: add check for memory allocation failure

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c   | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c 
b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
index f71b12e4b5e0..d9aa6e1a8145 100644
--- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
+++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
@@ -331,6 +331,12 @@ NewInternalInstance (
   }
 
   NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
+  if (NewInternalData->NodeName == NULL) {
+DEBUG ((DEBUG_ERROR, "%a: No memory for NodeName\n", __func__));
+FreePool (NewInternalData);
+return EFI_OUT_OF_RESOURCES;
+  }
+
   StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1, (CONST CHAR16 
*)NodeName, StrLen (NodeName));
   NewInternalData->SiblingList = NULL;
   NewInternalData->ChildList   = NULL;
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110156): https://edk2.groups.io/g/devel/message/110156
Mute This Topic: https://groups.io/mt/102211780/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 v2 08/11] RedfishClientPkg: fix pragma pack usage

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 RedfishClientPkg/HiiToRedfishBiosDxe/HiiToRedfishBiosData.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/RedfishClientPkg/HiiToRedfishBiosDxe/HiiToRedfishBiosData.h 
b/RedfishClientPkg/HiiToRedfishBiosDxe/HiiToRedfishBiosData.h
index 7e1bc9cefbac..9d5b10a7e909 100644
--- a/RedfishClientPkg/HiiToRedfishBiosDxe/HiiToRedfishBiosData.h
+++ b/RedfishClientPkg/HiiToRedfishBiosDxe/HiiToRedfishBiosData.h
@@ -31,7 +31,7 @@ extern EFI_GUID  gHiiToRedfishBiosFormsetGuid;
 #define ID_STRING_MAX  15
 #define ID_STRING_MAX_WITH_TERMINATOR  16
 
-#pragma pack()
+#pragma pack(1)
 
 //
 // Definiton of HII_TO_REDFISH_BIOS_VARSTORE_DATA
@@ -44,4 +44,5 @@ typedef struct {
   UINT8 Reserved;
 } HII_TO_REDFISH_BIOS_EFI_VARSTORE_DATA;
 
+#pragma pack()
 #endif
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110153): https://edk2.groups.io/g/devel/message/110153
Mute This Topic: https://groups.io/mt/102211777/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 v2 09/11] RedfishClientPkg: fix StrnCpyS arguments

2023-10-26 Thread Mike Maslenkin 
StrnCpyS accepts string length in characters, not in bytes.

Signed-off-by: Mike Maslenkin 
---
 RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c 
b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
index 8ac165dec59e..c19d4a46d6af 100644
--- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
+++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
@@ -331,7 +331,7 @@ NewInternalInstance (
   }
 
   NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
-  StrnCpyS (NewInternalData->NodeName, StrSize (NodeName), (CONST CHAR16 
*)NodeName, StrLen (NodeName));
+  StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1, (CONST CHAR16 
*)NodeName, StrLen (NodeName));
   NewInternalData->SiblingList = NULL;
   NewInternalData->ChildList   = NULL;
   if (NodeIsCollection) {
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110154): https://edk2.groups.io/g/devel/message/110154
Mute This Topic: https://groups.io/mt/102211778/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 v2 07/11] RedfishClientPkg: fix memory leak

2023-10-26 Thread Mike Maslenkin 
This patch fixes leak in RedfishExternalResourceResourceFeatureCallback
function.

Signed-off-by: Mike Maslenkin 
---
 RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c 
b/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c
index 32dca964aa0a..9b336d3de479 100644
--- a/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c
+++ b/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.c
@@ -718,6 +718,7 @@ RedfishExternalResourceResourceFeatureCallback (
   Private->Uri = RedfishGetUri (ResourceUri);
   if (Private->Uri == NULL) {
 ASSERT (FALSE);
+FreePool (ResourceUri);
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -727,6 +728,7 @@ RedfishExternalResourceResourceFeatureCallback (
   }
 
   FreePool (Private->Uri);
+  FreePool (ResourceUri);
   return Status;
 }
 
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110152): https://edk2.groups.io/g/devel/message/110152
Mute This Topic: https://groups.io/mt/102211776/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 v2 05/11] RedfishClientPkg: reduce identation level by adding early return

2023-10-26 Thread Mike Maslenkin 
This functions contain memory leaks.
Less identation helps to solve this issues.

Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureUtilityLib.c| 289 +-
 1 file changed, 146 insertions(+), 143 deletions(-)

diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 8fa1dc2c3535..0941f33fd73a 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -763,68 +763,69 @@ ApplyFeatureSettingsStringArrayType (
   Status = RedfishPlatformConfigGetValue (Schema, Version, ConfigureLang, 
);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s failed: %r\n", __func__, Schema, 
Version, ConfigureLang, Status));
-  } else {
-if (RedfishValue.Type != RedfishValueTypeStringArray) {
-  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not string array type\n", 
__func__, Schema, Version, ConfigureLang));
-  return EFI_DEVICE_ERROR;
-}
+return Status;
+  }
+
+  if (RedfishValue.Type != RedfishValueTypeStringArray) {
+DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not string array type\n", 
__func__, Schema, Version, ConfigureLang));
+return EFI_DEVICE_ERROR;
+  }
 
+  //
+  // If there is no change in array, do nothing
+  //
+  if (!CompareRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount)) {
 //
-// If there is no change in array, do nothing
+// Apply settings from redfish
 //
-if (!CompareRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount)) {
-  //
-  // Apply settings from redfish
-  //
-  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
-  FreeArrayTypeRedfishValue ();
+DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
+FreeArrayTypeRedfishValue ();
 
-  //
-  // Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
-  //
-  RedfishValue.ArrayCount = 0;
-  Buffer  = ArrayHead;
-  while (Buffer != NULL) {
-RedfishValue.ArrayCount += 1;
-Buffer   = Buffer->Next;
-  }
+//
+// Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
+//
+RedfishValue.ArrayCount = 0;
+Buffer  = ArrayHead;
+while (Buffer != NULL) {
+  RedfishValue.ArrayCount += 1;
+  Buffer   = Buffer->Next;
+}
 
-  //
-  // Allocate pool for new values
-  //
-  RedfishValue.Value.StringArray = AllocatePool (RedfishValue.ArrayCount 
*sizeof (CHAR8 *));
-  if (RedfishValue.Value.StringArray == NULL) {
+//
+// Allocate pool for new values
+//
+RedfishValue.Value.StringArray = AllocatePool (RedfishValue.ArrayCount 
*sizeof (CHAR8 *));
+if (RedfishValue.Value.StringArray == NULL) {
+  ASSERT (FALSE);
+  return EFI_OUT_OF_RESOURCES;
+}
+
+Buffer = ArrayHead;
+Index  = 0;
+while (Buffer != NULL) {
+  RedfishValue.Value.StringArray[Index] = AllocateCopyPool (AsciiStrSize 
(Buffer->ArrayValue), Buffer->ArrayValue);
+  if (RedfishValue.Value.StringArray[Index] == NULL) {
 ASSERT (FALSE);
 return EFI_OUT_OF_RESOURCES;
   }
 
-  Buffer = ArrayHead;
-  Index  = 0;
-  while (Buffer != NULL) {
-RedfishValue.Value.StringArray[Index] = AllocateCopyPool (AsciiStrSize 
(Buffer->ArrayValue), Buffer->ArrayValue);
-if (RedfishValue.Value.StringArray[Index] == NULL) {
-  ASSERT (FALSE);
-  return EFI_OUT_OF_RESOURCES;
-}
-
-Buffer = Buffer->Next;
-Index++;
-  }
+  Buffer = Buffer->Next;
+  Index++;
+}
 
-  ASSERT (Index <= RedfishValue.ArrayCount);
+ASSERT (Index <= RedfishValue.ArrayCount);
 
-  Status = RedfishPlatformConfigSetValue (Schema, Version, ConfigureLang, 
RedfishValue);
-  if (!EFI_ERROR (Status)) {
-//
-// Configuration changed. Enable system reboot flag.
-//
-REDFISH_ENABLE_SYSTEM_REBOOT ();
-  } else {
-DEBUG ((DEBUG_ERROR, "%a, apply %s array failed: %r\n", __func__, 
ConfigureLang, Status));
-  }
+Status = RedfishPlatformConfigSetValue (Schema, Version, ConfigureLang, 
RedfishValue);
+if (!EFI_ERROR (Status)) {
+  //
+  // Configuration changed. Enable system reboot flag.
+  //
+  REDFISH_ENABLE_SYSTEM_REBOOT ();
 } else {
-  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s array value has no change\n", 
__func__, Schema, Version, ConfigureLang));
+  DEBUG ((DEBUG_ERROR, "%a, apply %s array failed: %r\n", __func__, 
ConfigureLang, Status));
 }
+  } else {
+DEBUG ((DEBUG_ERROR, "%a, %a.%a

[edk2-devel] [edk2-redfish-client][PATCH v2 06/11] RedfishClientPkg: fix memory leaks while applying feature settings

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureUtilityLib.c| 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 0941f33fd73a..e189987850f7 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -806,6 +806,7 @@ ApplyFeatureSettingsStringArrayType (
   RedfishValue.Value.StringArray[Index] = AllocateCopyPool (AsciiStrSize 
(Buffer->ArrayValue), Buffer->ArrayValue);
   if (RedfishValue.Value.StringArray[Index] == NULL) {
 ASSERT (FALSE);
+FreePool (RedfishValue.Value.StringArray);
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -828,6 +829,12 @@ ApplyFeatureSettingsStringArrayType (
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s array value has no change\n", __func__, 
Schema, Version, ConfigureLang));
   }
 
+  for (Index = 0; Index < RedfishValue.ArrayCount; Index++) {
+FreePool (RedfishValue.Value.StringArray[Index]);
+  }
+
+  FreePool (RedfishValue.Value.StringArray);
+
   return Status;
 }
 
@@ -927,6 +934,8 @@ ApplyFeatureSettingsNumericArrayType (
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s array value has no change\n", __func__, 
Schema, Version, ConfigureLang));
   }
 
+  FreePool (RedfishValue.Value.IntegerArray);
+
   return Status;
 }
 
@@ -1026,6 +1035,8 @@ ApplyFeatureSettingsBooleanArrayType (
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s array value has no change\n", __func__, 
Schema, Version, ConfigureLang));
   }
 
+  FreePool (RedfishValue.Value.BooleanArray);
+
   return Status;
 }
 
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110151): https://edk2.groups.io/g/devel/message/110151
Mute This Topic: https://groups.io/mt/102211775/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 v2 04/11] RedfishClientPkg: RedfishFeatureUtilityLib: fix memory leaks

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureUtilityLib.c| 30 +++
 1 file changed, 30 insertions(+)

diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 35e342c817b7..8fa1dc2c3535 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -515,6 +515,7 @@ ApplyFeatureSettingsVagueType (
   Status = UnicodeStrToAsciiStrS (ConfigureLang, ConfigureLangAscii, StrLen 
(ConfigureLang) + 1);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, Convert the configureLang of vague key of %a.%a 
%s failed: %r\n", __func__, Schema, Version, ConfigureLang, Status));
+FreePool (ConfigureLangAscii);
 return Status;
   }
 
@@ -1972,6 +1973,7 @@ RedfishGetUri (
 //
 if (*Target == '\0') {
   DEBUG ((DEBUG_ERROR, "%a, invalid format: %s\n", __func__, ConfigLang));
+  FreePool (ResultStr);
   return NULL;
 }
 
@@ -1983,6 +1985,7 @@ RedfishGetUri (
 TempStrSize  = (ConfigLangLen - RemainingLen + 1) * sizeof (CHAR16);
 TempStr  = AllocateCopyPool (TempStrSize, Head);
 if (TempStr == NULL) {
+  FreePool (ResultStr);
   return NULL;
 }
 
@@ -1996,6 +1999,8 @@ RedfishGetUri (
);
 if (EFI_ERROR (Status)) {
   DEBUG ((DEBUG_ERROR, "%a, Can not find: %s\n", __func__, TempStr));
+  FreePool (ResultStr);
+  FreePool (TempStr);
   return NULL;
 }
 
@@ -2102,10 +2107,14 @@ GetConfigureLang (
 
   Status = AsciiStrToUnicodeStrS (Uri, UnicodeUri, StringSize);
   if (EFI_ERROR (Status)) {
+FreePool (UnicodeUri);
 return NULL;
   }
 
   ConfigLang = RedfishGetConfigLanguage (UnicodeUri);
+
+  FreePool (UnicodeUri);
+
   if (ConfigLang == NULL) {
 return NULL;
   }
@@ -2117,11 +2126,14 @@ GetConfigureLang (
   StringSize = StrSize (ConfigLang) + ((AsciiStrLen (PropertyName) + 1) * 
sizeof (CHAR16));
   ResultStr  = AllocatePool (StringSize);
   if (ResultStr == NULL) {
+FreePool (ConfigLang);
 return NULL;
   }
 
   UnicodeSPrint (ResultStr, StringSize, L"%s/%a", ConfigLang, PropertyName);
 
+  FreePool (ConfigLang);
+
   return ResultStr;
 }
 
@@ -2296,9 +2308,12 @@ GetPropertyStringValue (
   Status = RedfishPlatformConfigGetValue (Schema, Version, 
ConfigureLangBuffer, );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a query current setting for %s failed: 
%r\n", __func__, Schema, Version, ConfigureLangBuffer, Status));
+FreePool (ConfigureLangBuffer);
 return NULL;
   }
 
+  FreePool (ConfigureLangBuffer);
+
   if (RedfishValue.Type != RedfishValueTypeString) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not string type\n", __func__, 
Schema, Version, ConfigureLang));
 return NULL;
@@ -2354,9 +2369,12 @@ GetPropertyNumericValue (
   Status = RedfishPlatformConfigGetValue (Schema, Version, 
ConfigureLangBuffer, );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a query current setting for %s failed: 
%r\n", __func__, Schema, Version, ConfigureLangBuffer, Status));
+FreePool (ConfigureLangBuffer);
 return NULL;
   }
 
+  FreePool (ConfigureLangBuffer);
+
   if (RedfishValue.Type != RedfishValueTypeInteger) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not numeric type\n", __func__, 
Schema, Version, ConfigureLang));
 return NULL;
@@ -2416,9 +2434,12 @@ GetPropertyBooleanValue (
   Status = RedfishPlatformConfigGetValue (Schema, Version, 
ConfigureLangBuffer, );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a query current setting for %s failed: 
%r\n", __func__, Schema, Version, ConfigureLangBuffer, Status));
+FreePool (ConfigureLangBuffer);
 return NULL;
   }
 
+  FreePool (ConfigureLangBuffer);
+
   if (RedfishValue.Type != RedfishValueTypeBoolean) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not boolean type\n", __func__, 
Schema, Version, ConfigureLang));
 return NULL;
@@ -2517,9 +2538,12 @@ GetPropertyStringArrayValue (
   Status = RedfishPlatformConfigGetValue (Schema, Version, 
ConfigureLangBuffer, );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a query current setting for %s failed: 
%r\n", __func__, Schema, Version, ConfigureLangBuffer, Status));
+FreePool (ConfigureLangBuffer);
 return NULL;
   }
 
+  FreePool (ConfigureLangBuffer);
+
   if (RedfishValue.Type != RedfishValueTypeStringArray) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not string array type\n", 
__func__, Schema, Version, ConfigureLang));
 return NULL;
@@ -2588,9 +2612,12 @@ GetPropertyNumericArrayValue (
   Status = RedfishPlatformConfigGetValue (Schema, Version, 
ConfigureLangBuffer, );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a query current setting for %s failed: 
%r\n",

[edk2-devel] [edk2-redfish-client][PATCH v2 02/11] RedfishClientPkg: fix DEBUG macro arguments

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 .../RedfishFeatureUtilityLib.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 1e5c3f110de6..35e342c817b7 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -332,7 +332,7 @@ ApplyFeatureSettingsStringType (
 DEBUG ((DEBUG_ERROR, "%a, apply %s to %s failed: %r\n", __func__, 
ConfigureLang, FeatureValue, Status));
   }
 } else {
-  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is: %s\n", __func__, Schema, 
Version, ConfigureLang, RedfishValue.Value.Buffer, Status));
+  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is: %a\n", __func__, Schema, 
Version, ConfigureLang, RedfishValue.Value.Buffer));
 }
   }
 
@@ -462,7 +462,7 @@ ApplyFeatureSettingsBooleanType (
 DEBUG ((DEBUG_ERROR, "%a, apply %s to %a failed: %r\n", __func__, 
ConfigureLang, (FeatureValue ? "True" : "False"), Status));
   }
 } else {
-  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is: %a\n", __func__, Schema, 
Version, ConfigureLang, (RedfishValue.Value.Boolean ? "True" : "False"), 
Status));
+  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is: %a\n", __func__, Schema, 
Version, ConfigureLang, (RedfishValue.Value.Boolean ? "True" : "False")));
 }
   }
 
@@ -585,7 +585,7 @@ ApplyFeatureSettingsVagueType (
 DEBUG ((DEBUG_ERROR, "%a, apply %a to %a failed: %r\n", __func__, 
ConfigureKeyLang, CurrentVagueValuePtr->Value->DataValue.CharPtr, Status));
   }
 } else {
-  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: %a\n", 
__func__, Schema, Version, ConfigureKeyLang, RedfishValue.Value.Buffer, 
Status));
+  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: %a\n", 
__func__, Schema, Version, ConfigureKeyLang, RedfishValue.Value.Buffer));
 }
   } else if (PropertyDatatype == RedfishValueTypeBoolean) {
 //
@@ -617,7 +617,7 @@ ApplyFeatureSettingsVagueType (
 DEBUG ((DEBUG_ERROR, "%a, apply %s to %a failed: %r\n", __func__, 
ConfigureKeyLang, (*CurrentVagueValuePtr->Value->DataValue.BoolPtr ? "True" : 
"False"), Status));
   }
 } else {
-  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: %a\n", 
__func__, Schema, Version, ConfigureKeyLang, (RedfishValue.Value.Boolean ? 
"True" : "False"), Status));
+  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: %a\n", 
__func__, Schema, Version, ConfigureKeyLang, (RedfishValue.Value.Boolean ? 
"True" : "False")));
 }
   } else if (PropertyDatatype == RedfishValueTypeInteger) {
 //
@@ -640,7 +640,7 @@ ApplyFeatureSettingsVagueType (
 DEBUG ((DEBUG_ERROR, "%a, apply %s to 0x%x failed: %r\n", 
__func__, ConfigureKeyLang, *CurrentVagueValuePtr->Value->DataValue.Int64Ptr, 
Status));
   }
 } else {
-  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: 0x%x\n", 
__func__, Schema, Version, ConfigureKeyLang, RedfishValue.Value.Integer, 
Status));
+  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a %s value is: 0x%x\n", 
__func__, Schema, Version, ConfigureKeyLang, RedfishValue.Value.Integer));
 }
   } else {
 DEBUG ((DEBUG_ERROR, "%a, %a.%a %s Unsupported Redfish property data 
type\n", __func__, Schema, Version, ConfigureLang));
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110147): https://edk2.groups.io/g/devel/message/110147
Mute This Topic: https://groups.io/mt/102211771/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 v2 03/11] RedfishLib: remove redudant zeroing

2023-10-26 Thread Mike Maslenkin 
Memory allocated by calloc() is filled with bytes of value zero.

Signed-off-by: Mike Maslenkin 
---
 .../PrivateLibrary/RedfishLib/edk2libredfish/src/service.c   | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/src/service.c 
b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/src/service.c
index a38bdfbea65f..0ffc23725d37 100644
--- a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/src/service.c
+++ b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/src/service.c
@@ -1773,7 +1773,6 @@ createServiceEnumeratorNoAuth (
   char*HostStart;
 
   ret = (redfishService *)calloc (1, sizeof (redfishService));
-  ZeroMem (ret, sizeof (redfishService));
   if (initRest (ret, restProtocol) != 0) {
 free (ret);
 return NULL;
-- 
2.32.0 (Apple Git-132)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110148): https://edk2.groups.io/g/devel/message/110148
Mute This Topic: https://groups.io/mt/102211772/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 v2 0/11] RedfishClientPkg: various minor fixes

2023-10-26 Thread Mike Maslenkin 
This patchset contains fixes of wrong format and number of arguments
passed to DEBUG macro.

Also a number of memory leaks were fixed.

Here is a link to PR:
https://github.com/tianocore/edk2-redfish-client/pull/52

Cc: Abner Chang 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Signed-off-by: Mike Maslenkin 
---
Changes in v2:
added patches 10,11.




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110145): https://edk2.groups.io/g/devel/message/110145
Mute This Topic: https://groups.io/mt/102211769/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 v2 01/11] RedfishClientPkg: fix format used for output __func__

2023-10-26 Thread Mike Maslenkin 
Signed-off-by: Mike Maslenkin 
---
 RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c 
b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
index a969557ddfdb..f96c90cc945c 100644
--- a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
+++ b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
@@ -788,7 +788,7 @@ HandleResource (
   // Check and see if this is target resource that we want to handle.
   // Some resource is handled by other provider so we have to make sure this 
first.
   //
-  DEBUG ((REDFISH_DEBUG_TRACE, "%s Identify for %s\n", __func__, Uri));
+  DEBUG ((REDFISH_DEBUG_TRACE, "%a Identify for %s\n", __func__, Uri));
   ConfigLang = RedfishGetConfigLanguage (Uri);
   if (ConfigLang == NULL) {
 Status = EdkIIRedfishResourceConfigIdentify (, Uri, 
Private->InformationExchange);
-- 
2.32.0 (Apple Git-132)



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

Re: [edk2-devel] [PATCH 9/9] RedfishClientPkg: fix StrnCpyS arguments

2023-10-26 Thread Mike Maslenkin 
On Mon, Oct 2, 2023 at 5:56 AM Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: Mike Maslenkin 
> > Sent: Saturday, September 30, 2023 5:59 AM
> > To: devel@edk2.groups.io
> > Cc: Chang, Abner ; nick...@nvidia.com;
> > ig...@ami.com; Mike Maslenkin 
> > Subject: [PATCH 9/9] RedfishClientPkg: fix StrnCpyS arguments
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > StrnCpyS accepts string length in characters, not in bytes.
> >
> > Signed-off-by: Mike Maslenkin 
> > ---
> >  RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > index 8ac165dec59e..c19d4a46d6af 100644
> > --- a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > +++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> > @@ -331,7 +331,7 @@ NewInternalInstance (
> >}
> >
> >
> >
> >NewInternalData->NodeName = AllocateZeroPool (StrSize (NodeName));
> >
> > -  StrnCpyS (NewInternalData->NodeName, StrSize (NodeName), (CONST
> > CHAR16 *)NodeName, StrLen (NodeName));
> >
> > +  StrnCpyS (NewInternalData->NodeName, StrLen (NodeName) + 1, (CONST
> > CHAR16 *)NodeName, StrLen (NodeName));
> The original code is already the size of string that includes NULL 
> terminator. However, we should check if NewInternalData->NodeName is NULL or 
> not before copying the string. Mike, could you please help to add this check?
>
> Thanks
> Abner
>
Hi, Abner

The problem is not with NULL terminator
The problem is that StrnCpyS takes a number of unicode chars as a
second parameter, not a string size in bytes returned by StrSize().

So I left this patch unmodified and added two additional patches
required for NULL pointer check.

Thanks,
Mike.


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

[edk2-devel] EDK II Release Planning: update content for edk2-stable202311

2023-10-26 Thread Laszlo Ersek 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable202311-tag-planning

I've scanned the edk2 git commit range edk2-stable202308..f945b72331d7,
and collected (and when necessary, closed/updated) TianoCore BZs. When
TianoCore BZs were not available, I tried capturing other bug tracker
references, or at least those (larger) mailing list patch sets that had
been merged.

Wiki commit 0ea77aeccca8.

If anyone is missing a feature or bugfix they'd like to see on the list,
please go ahead and update the wiki, or (if you don't have permission?)
comment in this thread.

There is still more than a week until the Soft Feature Freeze, so it
would be nice to update the planning page immediately whenever a feature
or an important bugfix is merged. The QEMU project policy is generally
that, whenever a pull request is merged, important changes are
immediately documented by the maintainer on the upcoming release's
Planning wiki page. That tends to work much better than retroactively
collecting tickets (... because in many cases we don't even file
tickets) or scraping the commit history (... because the commit history
is long, and doesn't capture cover letters).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110143): https://edk2.groups.io/g/devel/message/110143
Mute This Topic: https://groups.io/mt/102210493/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 17:21, Ard Biesheuvel wrote:
> On Thu, 26 Oct 2023 at 17:19, Laszlo Ersek  wrote:
>>
>> On 10/26/23 16:21, Peter Maydell wrote:
>>> On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
 On 10/10/23 09:43, Ard Biesheuvel wrote:
> Thanks for looking into this - a cleanup was overdue here.
>
> I will take a look in more detail later, but one thing that occurred
> to me when reading this overview is that having a separate DEBUG
> serial port would permit us to
>
> a) remove it from the DT

 ... as in, hide it from Linux, I assume?

> b) add a runtime mapping for it
> c) keep using it after ExitBootServices
>
> This could be useful for debugging issues with the variable store etc.
>
> Not saying this is something to address in this series, but I'd like
> to hear your take on this.
>

 Sounds like a useful feature.

 I see four challenges:


 (1) We'd have to coordinate it with Peter. If we hide any one of the
 serial ports from Linux, that may not be what QEMU intends for Linux to
 happen. Linux currently ties getties to all serial ports -- via the
 serial* aliases, IIUC. Thus, some "positive identification" in the DT
 could be necessary (i.e., that edk2 was welcome to hide that port from
 Linux).
>>>
>>> The potential awkwardness here is that what the guest thinks about
>>> the serial ports depends on the ACPI table fragments which QEMU
>>> provides. EDK2 would need to edit the table fragment to remove any
>>> mention of the second UART if it wanted to hide it from the kernel.
>>> I don't know how hard that would be in EDK2.
>>>
>>> (As far as I'm aware usually a boot via EDK2 doesn't pass the
>>> dtb on to Linux, though I guess there's no reason it can't.)
>>>
>>> From QEMU's point of view, we provide two UARTs to the guest, and we
>>> don't really care whether that means one is used by EDK2 and one by
>>> Linux, or both are used as getty terminals by Linux, or whether the
>>> Linux guest uses one serial as a terminal and leaves the other to its
>>> userspace programs  -- it's all just guest software to us :-)
>>>
>>> [snip other technical stuff]
>>
>> Thanks, good point -- I wasn't aware of the ACPI impact.
>>
>> We don't edit / patch QEMU's ACPI tables, ever. (Beyond obeying the ACPI
>> linker/loader script.) That's a principle we've upheld many times.
>> Whenever ACPI content needs to change, that implies a QEMU patch.
>>
>> So, for this purpose, only the following could have a chance of working:
>>
>> - Expose a new config option on the QEMU command line to the user,
>> regarding the intended use of the serial port(s). This could be of any
>> tolerable form (machine property, front-end (device) property, whatever
>> -- anything that QEMU reviewers can accept).
>>
>> - In QEMU, generate both the DT and the ACPI tables accordingly. The
>> ACPI tables would have to immediately *not* contain the UART-to-hide (so
>> as to keep it secret from the guest OS). The DT at the same time would
>> still have to expose the "runtime DEBUG UART", because edk2 would have
>> to know where that UART was (and that it was meant specifically for OS
>> runtime debug output).
>>
>> - Edk2 would have to patch the DT (we tend to do that already), because
>> (in some configs) we do forward the DT to the guest OS. This need for
>> patching could be lifted if QEMU adopted such a form of expression for
>> the "runtime DEBUG UART" that would be ignored by Linux out of the box.
>>
>>>
 All in all, I think the implementation would be quite a steep divergence
 from, or on top of, this patch set. :)
>>>
>>> I agree with this and with Ard's "not something to address in this
>>> series" comment above; it doesn't sound like this is something that
>>> needs to hold up the patchset we have currently.
>>
>> Right; I'd like to flush this one. The runtime debug UART seems to need
>> more joint pondering.
>>
>>>
>>> Does anybody have time to review Laszlo's code? It would be nice
>>> to be able to get this into the next EDK2 release.
>>
> 
> I'm happy for this to go in if it covers our needs.
> 
> Acked-by: Ard Biesheuvel 

Thank you, Ard! Merged as commit range 74c687cc2f2f..f945b72331d7 via
.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110141): https://edk2.groups.io/g/devel/message/110141
Mute This Topic: https://groups.io/mt/101834880/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] BaseTools/GenFw: Change opcode when converting ADR to ADRP

2023-10-26 Thread Pedro Falcato 
On Thu, Oct 26, 2023 at 4:32 PM Jake Garver via groups.io
 wrote:
>
> In the R_AARCH64_ADR_GOT_PAGE case on AARCH64, be sure to change the
> opcode to ADRP.  Prior to this change, we updated the address, but not
> the opcode.
>
> This resolves an issue experienced when building a StandaloneMm image
> with stack protection enabled on GCC 10.5.  This scenario generates an
> ADR where an ADRP is more common in other versions of GCC tested.  That
> explains the obscurity of the issue.  However, an ADR is valid and
> should be handled by GenFw.

Is this not a toolchain bug?
The aarch64 ELF ABI
(https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst)
says:
"Set the immediate value of an ADRP to bits [32:12] of X; check that
–232 <= X < 232"

So it mentions this relocation pointing *to an ADRP* specifically. And
AFAIK there's no way
Page(G(GDAT(S+A)))-Page(P)

would ever make sense if we're looking at an adr and not an adrp.

Can you post the full disassembly for the function, plus relevant relocations?

-- 
Pedro


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

Re: [edk2-devel] [Patch V3] UefiCpuPkg/MpInitLib: Wait for all APs to finish initialization

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 15:41, Laszlo Ersek wrote:
> On 10/25/23 13:42, Yuanhao Xie wrote:
>> Aim:
>> - To solve the assertion that checks if CpuMpData->FinishedCount
>> equals (CpuMpData->CpuCount - 1). The assertion arises from a timing
>> discrepancy between the BSP's completion of startup signal checks and
>> the APs' incrementation of the FinishedCount.
>> - This patch also ensures that "finished" reporting from the APs is as
>> later as possible.
>>
>> More specifially:
>>
>> In the SwitchApContext() function, the BSP trigers
>> the startup signal and check whether the APs have received it. After
>> completing this check, the BSP then verifies if the FinishedCount is
>> equal to CpuCount-1.
>>
>> On the AP side, upon receiving the startup signal, they invoke
>> SwitchContextPerAp() and increase the FinishedCount to indicate their
>> activation. However, even when all APs have received the startup signal,
>> they might not have finished incrementing the FinishedCount. This timing
>> gap results in the triggering of the assertion.
>>
>> Solution:
>> Instead of assertion, use while loop to waits until all the APs have
>> incremented the FinishedCount.
>>
>> Fixes: 964a4f032dcd
>>
>> Signed-off-by: Yuanhao Xie 
>> Cc: Ray Ni 
>> Cc: Eric Dong 
>> Cc: Rahul Kumar 
>> Cc: Tom Lendacky 
>> ---
>>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 +++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
>> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>> index 6f1456cfe1..9a6ec5db5c 100644
>> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
>> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>> @@ -913,8 +913,8 @@ DxeApEntryPoint (
>>UINTN  ProcessorNumber;
>>  
>>GetProcessorNumber (CpuMpData, );
>> -  InterlockedIncrement ((UINT32 *)>FinishedCount);
>>RestoreVolatileRegisters (>CpuData[0].VolatileRegisters, 
>> FALSE);
>> +  InterlockedIncrement ((UINT32 *)>FinishedCount);
>>PlaceAPInMwaitLoopOrRunLoop (
>>  CpuMpData->ApLoopMode,
>>  CpuMpData->CpuData[ProcessorNumber].StartupApSignal,
>> @@ -2201,7 +2201,12 @@ MpInitLibInitialize (
>>// looping process there.
>>//
>>SwitchApContext (MpHandOff);
>> -  ASSERT (CpuMpData->FinishedCount == (CpuMpData->CpuCount - 1));
>> +  //
>> +  // Wait for all APs finished initialization
>> +  //
>> +  while (CpuMpData->FinishedCount < (CpuMpData->CpuCount - 1)) {
>> +CpuPause ();
>> +  }
>>  
>>//
>>// Set Apstate as Idle, otherwise Aps cannot be waken-up again.
> 
> https://github.com/tianocore/edk2/pull/4964
> 
> (in progress)

Commit 74c687cc2f2f.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110139): https://edk2.groups.io/g/devel/message/110139
Mute This Topic: https://groups.io/mt/102176057/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 edk2-platforms v6 4/4] SbsaQemu: disable XHCI in DSDT if not present

2023-10-26 Thread Leif Lindholm 
On Thu, Oct 26, 2023 at 19:33:52 +0200, Marcin Juszkiewicz wrote:
> We need platform version to be at least 0.3 to have XHCI
> in virtual hardware. On older platforms there is non-working
> EHCI which we ignore.
> 
> Set DSDT node to be disabled so operating system will not try
> to initialize not-existing hardware.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 74 
> +++-
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
>  3 files changed, 79 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> index 7c7e08e0fd3a..291743b19115 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> @@ -29,6 +29,7 @@ [Packages]
>Silicon/Qemu/SbsaQemu/SbsaQemu.dec
>  
>  [LibraryClasses]
> +  AcpiLib
>ArmLib
>BaseMemoryLib
>BaseLib
> @@ -49,6 +50,8 @@ [Pcd]
>gArmTokenSpaceGuid.PcdGicDistributorBase
>gArmTokenSpaceGuid.PcdGicRedistributorsBase
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
>  
>  [Depex]
> @@ -58,6 +61,7 @@ [Guids]
>gEdkiiPlatformHasAcpiGuid
>  
>  [Protocols]
> +  gEfiAcpiSdtProtocolGuid
>gEfiAcpiTableProtocolGuid   ## CONSUMES
>  
>  [FixedPcd]
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index fd849ca1594b..523d9035e0c1 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -682,6 +683,72 @@ AddGtdtTable (
>return Status;
>  }
>  
> +/*
> + * A function to disable XHCI node on Platform Version lower than 0.3
> + */
> +STATIC
> +EFI_STATUS
> +DisableXhciOnOlderPlatVer (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_ACPI_SDT_PROTOCOL*AcpiSdtProtocol;
> +  EFI_ACPI_DESCRIPTION_HEADER  *Table;
> +  UINTNTableKey;
> +  UINTNTableIndex;
> +  EFI_ACPI_HANDLE  TableHandle;
> +
> +  Status = EFI_SUCCESS;
> +
> +  if ( PLATFORM_VERSION_LESS_THAN (0, 3)) {
> +DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
> +Status = gBS->LocateProtocol (
> +  ,
> +  NULL,
> +  (VOID **)
> +  );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
> +  return Status;
> +}
> +
> +Status = AcpiLocateTableBySignature (
> + AcpiSdtProtocol,
> + 
> EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
> + ,
> + ,
> + 
> + );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  return Status;
> +}
> +
> +Status = AcpiSdtProtocol->OpenSdt (TableKey, );
> +if (EFI_ERROR (Status)) {
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
> "\\_SB.USB0.XHCI", 0x0);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +AcpiSdtProtocol->Close (TableHandle);
> +AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
> +  }
> +
> +  return Status;
> +}
> +
> +
>  EFI_STATUS
>  EFIAPI
>  InitializeSbsaQemuAcpiDxe (
> @@ -738,5 +805,10 @@ InitializeSbsaQemuAcpiDxe (
>  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
>}
>  
> -  return EFI_SUCCESS;
> +  Status = DisableXhciOnOlderPlatVer ();
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Failed to handle XHCI enablement\n"));
> +  }
> +
> +  return Status;

Right, this isn't what I asked for though.
There is nothing valid about returning a bad status here - it is the
entry point of the module. If we wanted some sort of error handling,
we would need to plumb that in

[edk2-devel] [PATCH edk2-platforms v6 1/4] SbsaQemu: introduce macro to compare platform version

2023-10-26 Thread Marcin Juszkiewicz 
We want to check "if platver < 0.3" in an easy way.

Signed-off-by: Marcin Juszkiewicz 
---
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
 1 file changed, 25 insertions(+)

diff --git 
a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
new file mode 100644
index ..dd2483787002
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
@@ -0,0 +1,25 @@
+/** @file
+*
+*  Copyright (c) Linaro Limited. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SBSAQEMUPLATFORM_VERSION_H
+#define SBSAQEMUPLATFORM_VERSION_H
+
+/*
+ * Compare PlatformVersion
+ *
+ */
+
+#define PLATFORM_VERSION_LESS_THAN(Major, Minor) ( \
+  (\
+( PcdGet32 (PcdPlatformVersionMajor) < Major)   || \
+(  \
+  ( PcdGet32 (PcdPlatformVersionMajor) == Major) && \
+  ( PcdGet32 (PcdPlatformVersionMinor) < Minor)\
+)  \
+  )\
+)
+#endif

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110134): https://edk2.groups.io/g/devel/message/110134
Mute This Topic: https://groups.io/mt/102205080/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 v6 4/4] SbsaQemu: disable XHCI in DSDT if not present

2023-10-26 Thread Marcin Juszkiewicz 
We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 74 +++-
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 3 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..291743b19115 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
   Silicon/Qemu/SbsaQemu/SbsaQemu.dec
 
 [LibraryClasses]
+  AcpiLib
   ArmLib
   BaseMemoryLib
   BaseLib
@@ -49,6 +50,8 @@ [Pcd]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
 
 [Depex]
@@ -58,6 +61,7 @@ [Guids]
   gEdkiiPlatformHasAcpiGuid
 
 [Protocols]
+  gEfiAcpiSdtProtocolGuid
   gEfiAcpiTableProtocolGuid   ## CONSUMES
 
 [FixedPcd]
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..523d9035e0c1 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -682,6 +683,72 @@ AddGtdtTable (
   return Status;
 }
 
+/*
+ * A function to disable XHCI node on Platform Version lower than 0.3
+ */
+STATIC
+EFI_STATUS
+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  EFI_ACPI_SDT_PROTOCOL*AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER  *Table;
+  UINTNTableKey;
+  UINTNTableIndex;
+  EFI_ACPI_HANDLE  TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN (0, 3)) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+Status = AcpiLocateTableBySignature (
+ AcpiSdtProtocol,
+ 
EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+ ,
+ ,
+ 
+ );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, );
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
 EFI_STATUS
 EFIAPI
 InitializeSbsaQemuAcpiDxe (
@@ -738,5 +805,10 @@ InitializeSbsaQemuAcpiDxe (
 DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
   }
 
-  return EFI_SUCCESS;
+  Status = DisableXhciOnOlderPlatVer ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Failed to handle XHCI enablement\n"));
+  }
+
+  return Status;
 }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 6661bc8195ee..b55ad6c5cc07 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x00)// _UID: Unique ID
 Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
 Method (_STA)

[edk2-devel] [PATCH edk2-platforms v6 3/4] SbsaQemu: initialize XHCI only if it exists

2023-10-26 Thread Marcin Juszkiewicz 
We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 49 +++-
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
index 36ada4270bbf..4ebbe7c93a19 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -57,28 +58,6 @@ InitializeSbsaQemuPlatformDxe (
 return Status;
   }
 
-  Base = (VOID*)(UINTN)PcdGet64 (PcdPlatformXhciBase);
-  ASSERT (Base != NULL);
-  Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
-  ASSERT (Size != 0);
-
-  DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
-  __FUNCTION__, Base, Size));
-
-  Status = RegisterNonDiscoverableMmioDevice (
-   NonDiscoverableDeviceTypeXhci,
-   NonDiscoverableDeviceDmaTypeCoherent,
-   NULL,
-   NULL,
-   1,
-   Base, Size);
-
-  if (EFI_ERROR(Status)) {
-DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device @%p 
(Staus == %r)\n",
-__FUNCTION__, Base, Status));
-return Status;
-  }
-
   SmcResult = ArmCallSmc0 (SIP_SVC_VERSION, , , NULL);
   if (SmcResult == SMC_ARCH_CALL_SUCCESS) {
 Result = PcdSet32S (PcdPlatformVersionMajor, Arg0);
@@ -118,5 +97,31 @@ InitializeSbsaQemuPlatformDxe (
 
   DEBUG ((DEBUG_INFO, "GICI base: 0x%x\n", Arg0));
 
+  if (!PLATFORM_VERSION_LESS_THAN (0, 3)) {
+Base = (VOID *)(UINTN)PcdGet64 (PcdPlatformXhciBase);
+ASSERT (Base != NULL);
+Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
+ASSERT (Size != 0);
+
+DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
+__FUNCTION__, Base, Size));
+
+Status = RegisterNonDiscoverableMmioDevice (
+NonDiscoverableDeviceTypeXhci,
+
NonDiscoverableDeviceDmaTypeCoherent,
+NULL,
+NULL,
+1,
+Base,
+Size
+);
+
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device 
@%p (Status == %r)\n",
+  __FUNCTION__, Base, Status));
+  return Status;
+}
+  }
+
   return EFI_SUCCESS;
 }

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110136): https://edk2.groups.io/g/devel/message/110136
Mute This Topic: https://groups.io/mt/102205082/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 v6 2/4] SbsaQemu: add AcpiLib

2023-10-26 Thread Marcin Juszkiewicz 
It will be needed for playing with disabling XHCI later.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 806651fc55a0..fa85bd8dab89 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -172,6 +172,8 @@ [LibraryClasses.common]
 
   
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
 
+  AcpiLib|EmbeddedPkg/Library/AcpiLib/AcpiLib.inf
+
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110135): https://edk2.groups.io/g/devel/message/110135
Mute This Topic: https://groups.io/mt/102205081/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 v6 0/4] Provide XHCI USB controller only for newer hardware

2023-10-26 Thread Marcin Juszkiewicz 
Platform version 0.3 introduced XHCI USB controller instead of EHCI one.
But we did it in a way that there is no in-EDK2 check for platform
version (XHCI is always given).

This behaviour works with Linux as it complains about being unable to
initialize EHCI and goes on. Free/Net/Open BSD systems hang in such
situation.

Now we check are we on Platform Version 0.3 at least and then initialize
XHCI controller. Otherwise we disable it's node in DSDT table.

I checked several ways to handle the situation. 

SSDT overlay enabling with LocateAndInstallAcpiFromFvConfitional() was
first one but this function had only DBG2 and FACP tables.

Then looked at trying to detect XHCI from _STA method. But this is
sysbus device which is there or not without way to discover it.

Next attempt was to have variable in DSDT and to use it in _STA. Too
much trouble.

Then looked again at code from
Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiDsdt.c and noticed
UpdateStatusMethodObject() function. Copied some code and it worked.

Booting OpenBSD reminded me to update table checksum.

Nhi Pham pointed me to AcpiLib/AcpiAmlObjectUpdateInteger() function. So
v3 got AML variable (called XHCI) which is set to 0xF (enabled, working)
by default or to 0x0 (disabled, ignore) on Platform Version below 0.3
one.

This allowed to remove copy of UpdateStatusMethodObject() function.

---
Changes in v6:
- made DisableXhciOnOlderPlatVer() static
- added usual "if EFI_ERROR(Status)" dance

Changes in v5:
- added missing s-o-b lines
- run uncrustify on changed code
- fixed typos
- added comments

Changes in v4:
- make use of DisableXhciOnOlderPlatVer() return value

Changes in v3:
- use AML variable in DSDT

Changes in v2:
- XHCI initialized only on PlatVer 0.3+
- XHCI disabled in DSDT for older platforms
- no SSDT overlays for EHCI/XHCI
- no EHCI at all (it does not work anyway)
- no Pcd renaming

---
Marcin Juszkiewicz (4):
  SbsaQemu: introduce macro to compare platform version
  SbsaQemu: add AcpiLib
  SbsaQemu: initialize XHCI only if it exists
  SbsaQemu: disable XHCI in DSDT if not present

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  2 +
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 +++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 74 +++-
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 49 +++--
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 6 files changed, 133 insertions(+), 24 deletions(-)
---
base-commit: 74b9eacfd453c56b8bcc5ac68b3bf5ca243d60a9
change-id: 20231013-ehci-xhci-fix-c529356a7a8f

Best regards,
-- 
Marcin Juszkiewicz 



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

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

2023-10-26 Thread jacopo . r00ta 
In order to install the certificate I did something very naive:

1) I deployed an OS to the machine
2) Stored rootCA.der under /boot/efi/EFI/BOOT/

3) Restarted the machine

4) press F2 and install the certificate as it was available in the storage

5) select HTTPS boot in the boot list.

My nginx server is pretty simple, and it's configured as

server {

listen [::]:5248;

listen 5248;

server_name 192.168.120.1 ;

ssl_certificate path_to_myip.crt;

ssl_certificate_key path_to_myip.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers HIGH:!aNULL:!MD5;


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110132): https://edk2.groups.io/g/devel/message/110132
Mute This Topic: https://groups.io/mt/102201552/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/1] SbsaQemu: PCI node in DSDT does not need _ADR

2023-10-26 Thread Leif Lindholm 
On Wed, Oct 18, 2023 at 14:38:26 +0200, Marcin Juszkiewicz wrote:
> 190: Device (PCI0) Warning  3073 -
> Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
> 
> PCI Firmware specification does not require _ADR for Host bridges.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 74b9eacfd453.

Thanks!

> ---
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
> b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> index ba3eefc975a5..b55ad6c5cc07 100644
> --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> @@ -191,7 +191,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
>Name (_CID, EISAID ("PNP0A03")) // Compatible PCI Root Bridge
>Name (_SEG, Zero) // PCI Segment Group number
>Name (_BBN, Zero) // PCI Base Bus Number
> -  Name (_ADR, Zero)
>Name (_UID, "PCI0")
>Name (_CCA, One)// Initially mark the PCI coherent (for JunoR1)
>  
> -- 
> 2.41.0
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110131): https://edk2.groups.io/g/devel/message/110131
Mute This Topic: https://groups.io/mt/102037894/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] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

2023-10-26 Thread jacopo . r00ta 
Hi Laszlo,

First of all thank you very much for your reply!

I'm using QEMU with OVMF. All the steps to reproduce this are:

* generate the root key

> 
> openssl genrsa -out rootCA.key 4096

* create and sign the root certificate
> 
> openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out
> rootCA.crt

* Create a config file with the following content (I basically want a 
self-signed certificate for the IP 192.168.120.1 )

> 
> [req]
> default_bits = 4096
> default_md = sha256
> distinguished_name = req_distinguished_name
> x509_extensions = v3_req
> prompt = no
> [req_distinguished_name]
> C = US
> ST = VA
> L = SomeCity
> O = MyCompany
> OU = MyDivision
> CN = 192.168.120.1
> [v3_req]
> keyUsage = keyEncipherment, dataEncipherment
> extendedKeyUsage = serverAuth
> subjectAltName = @alt_names
> [alt_names]
> IP.1 = 192.168.120.1

* create the key
> 
> openssl genrsa -out myip.key 2048

* create the csr
> 
> openssl req -new -key myip.key -out myip.csr -config config

* sign the csr
> 
> openssl x509 -req -in myip.csr -CA rootCA.crt -CAkey rootCA.key
> -CAcreateserial -out myip.crt -days 500 -sha256

* Then, I generate the.der certificate to be installed using the UEFI UI
> 
> openssl x509 -in rootCA.crt -outform der -out rootCA.der
> 

* Then, I use the UI to install it (the rootCA.der one)

I've uploaded all the files here in case 
(https://drive.google.com/drive/folders/19Yo3sWZJBe43augVIFFvEXNQU8rIqGIV?usp=sharing)
 .

The dump of rootCA.crt is

> 
> 
> 
> openssl x509 -in rootCA.crt -text -noout
> 
> 

> 
> 
> 
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 3b:b2:13:59:44:8a:2a:d2:ba:29:a0:e9:25:e1:32:6d:5a:e6:24:7b
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
> Validity
> Not Before: Oct 25 12:45:16 2023 GMT
> Not After : Aug 14 12:45:16 2026 GMT
> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (4096 bit)
> Modulus:
> 00:90:9f:da:83:ac:88:44:4d:5c:1e:e7:8d:21:4b:
> 98:18:c9:d9:c0:b7:db:d4:f7:e1:54:b6:e4:e5:a8:
> c7:78:1f:47:f1:09:a6:fe:b5:08:c5:75:84:c5:26:
> 6d:c9:d2:9c:86:2d:09:3b:7e:10:ee:c6:21:fe:c1:
> b1:6c:f8:84:6c:e4:9f:92:29:46:9c:98:d6:9e:60:
> 39:b9:35:6c:2c:85:11:75:6b:e1:92:64:81:43:6e:
> cc:57:c5:eb:bd:a5:d3:40:99:d5:d0:db:6a:f0:51:
> 52:ed:72:31:c4:8a:06:19:d7:d4:1b:3b:d7:fc:a7:
> c4:25:b0:54:a0:10:c3:f5:0a:7b:25:36:95:84:b4:
> a4:85:66:9c:5c:93:af:ab:0a:6f:76:12:57:ed:b5:
> e3:09:93:a6:a3:3c:cc:f7:2e:83:25:1b:d2:3c:46:
> 36:3b:0d:17:87:84:dd:2e:88:7a:bb:ad:9d:5f:62:
> 78:68:d2:46:8f:21:08:53:ba:20:c0:15:28:7b:9a:
> f7:82:5d:27:46:0c:0f:5e:48:0e:f2:75:0b:22:98:
> 32:c6:e7:b3:21:3b:a1:e6:1b:f0:63:e2:6a:b6:ff:
> 94:d7:09:52:be:38:d0:a5:96:f6:1f:bb:b5:9f:11:
> 2b:ab:1d:39:dc:88:d5:ae:79:f3:9f:8c:72:5c:6c:
> b7:a1:51:62:af:69:2e:b4:ad:85:23:85:a0:7f:6d:
> 69:18:86:bd:07:f2:25:e2:4b:db:af:32:d0:bf:c7:
> a2:32:1f:7a:c9:bc:74:11:1c:a7:fb:99:5c:33:9b:
> 98:9a:fc:94:e3:40:2f:47:a6:b0:1f:28:23:4f:66:
> 3e:e6:84:47:8c:ed:f9:d0:8f:a6:b0:b5:37:77:91:
> bd:7d:cb:c0:f4:6e:07:e3:a2:c1:2e:16:1d:60:46:
> b9:66:6b:59:f8:83:91:17:21:20:ce:58:a6:a9:5b:
> fa:32:e6:47:32:b9:e5:5d:11:a0:d0:22:1e:2c:79:
> 42:d9:e4:99:55:6c:3d:9d:b2:94:7d:b9:09:7b:e2:
> 85:a5:bc:87:9e:50:2f:09:08:f9:f9:fd:0e:95:bb:
> 35:6d:f5:10:b7:81:e5:92:79:e5:23:55:48:7f:ce:
> 3f:cd:5f:4a:68:1f:33:25:7b:06:07:f1:74:76:de:
> 32:2e:89:10:0f:53:97:85:c7:c5:8a:e1:1a:8b:d7:
> 56:3b:d6:ab:07:a7:aa:e8:94:06:ba:ba:23:a5:87:
> f1:e1:fd:a6:2b:d0:63:54:f6:68:c2:be:d3:1a:d2:
> eb:6c:28:65:dd:c3:97:cb:23:d2:9e:f7:49:3e:da:
> 50:bf:98:0b:ec:96:50:9d:c4:4c:e7:81:05:ff:8c:
> 9a:ea:29
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> 31:18:EA:B2:10:C7:11:64:D6:5E:39:91:91:BE:D6:A4:10:24:9D:69
> X509v3 Authority Key Identifier:
> 31:18:EA:B2:10:C7:11:64:D6:5E:39:91:91:BE:D6:A4:10:24:9D:69
> X509v3 Basic Constraints: critical
> CA:TRUE
> Signature Algorithm: sha256WithRSAEncryption
> Signature Value:
> 37:76:7a:0c:12:d2:37:91:5a:8f:5a:20:34:bb:f5:3e:cc:f8:
> a3:e8:53:85:d8:99:2a:76:17:c5:e5:ae:fe:17:c9:f6:a1:ab:
> 15:4b:23:d8:84:f3:97:b8:c3:6c:30:1e:9f:2f:e3:3c:40:44:
> 5c:99:d3:d0:1b:47:fc:20:20:82:7c:58:61:d7:5e:fd:f4:73:
> da:a6:a1:65:e9:f9:48:b1:6f:9a:85:c6:fa:58:0e:39:78:2f:
> dd:dd:ff:ad:23:b7:df:fe:c0:a6:33:f2:25:ca:a5:2e:d9:99:
> 65:bb:6f:dc:cc:1f:23:07:99:87:fc:02:4b:fa:b6:25:34:56:
> c2:1a:2b:f2:04:8d:82:1f:d3:8c:46:32:0f:9b:32:31:b3:b5:
> d2:87:50:5e:13:f6:10:80:d2:d4:bc:b2:96:db:db:f1:c2:3a:
> f7:9c:a4:04:59:3a:db:a8:6f:f5:f0:46:7e:00:20:b9:6c:4e:
> f6:49:05:20:97:3d:73:6c:c2:2b:d6:c2:70:ea:46:cf:60:9f:
> c3:82:46:cc:ab:e0:c0:cb:b4:e5:62:72:d4:28:77:56:e9:97:
> ea:bc:d1:40:89:20:75:86:5f:1e:06:cc:d5:0f:49:dc:3a:cc:
> fe:70:32:a1:9a:d2:ab:e4:30:f4:34:5b:cc:93:02:00:26:68:
> 71:85:93:86:f7:d3:9d:91:c7:fb:21:e3:13:bd:8f:8c:05:f7:
> da:5f:8d:88:68:37:c0:5f:bc:62:94:96:bc:b3:8d:b3:d3:0d:
>

Re: [edk2-devel] [PATCH edk2-platforms v5 4/4] SbsaQemu: disable XHCI in DSDT if not present

2023-10-26 Thread Leif Lindholm 
Couple of minor comments on this patch, rest of set good to go:

On Wed, Oct 18, 2023 at 13:55:41 +0200, Marcin Juszkiewicz wrote:
> We need platform version to be at least 0.3 to have XHCI
> in virtual hardware. On older platforms there is non-working
> EHCI which we ignore.
> 
> Set DSDT node to be disabled so operating system will not try
> to initialize not-existing hardware.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 68 
> +++-
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
>  3 files changed, 73 insertions(+), 2 deletions(-)
> 

> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index fd849ca1594b..464119de1457 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -682,6 +683,71 @@ AddGtdtTable (
>return Status;
>  }
>  
> +/*
> + * A function to disable XHCI node on Platform Version lower than 0.3
> + */

STATIC

> +EFI_STATUS
> +DisableXhciOnOlderPlatVer (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_ACPI_SDT_PROTOCOL*AcpiSdtProtocol;
> +  EFI_ACPI_DESCRIPTION_HEADER  *Table;
> +  UINTNTableKey;
> +  UINTNTableIndex;
> +  EFI_ACPI_HANDLE  TableHandle;
> +
> +  Status = EFI_SUCCESS;
> +
> +  if ( PLATFORM_VERSION_LESS_THAN (0, 3)) {
> +DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
> +Status = gBS->LocateProtocol (
> +  ,
> +  NULL,
> +  (VOID **)
> +  );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
> +  return Status;
> +}
> +
> +Status = AcpiLocateTableBySignature (
> + AcpiSdtProtocol,
> + 
> EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
> + ,
> + ,
> + 
> + );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  return Status;
> +}
> +
> +Status = AcpiSdtProtocol->OpenSdt (TableKey, );
> +if (EFI_ERROR (Status)) {
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
> "\\_SB.USB0.XHCI", 0x0);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +AcpiSdtProtocol->Close (TableHandle);
> +AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
> +  }
> +
> +  return Status;
> +}
> +
> +
>  EFI_STATUS
>  EFIAPI
>  InitializeSbsaQemuAcpiDxe (
> @@ -738,5 +804,5 @@ InitializeSbsaQemuAcpiDxe (
>  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
>}
>  
> -  return EFI_SUCCESS;
> +  return DisableXhciOnOlderPlatVer ();

Replacing the normal exit path like this unnecessarily ties this call
to the end of the function.

Please add another boring "if (EFI_ERROR ..." stanza instead.

/
Leif

>  }
> diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
> b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> index 543b5782580a..ba3eefc975a5 100644
> --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> @@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
>  Name (_HID, "PNP0D10")  // _HID: Hardware ID
>  Name (_UID, 0x00)// _UID: Unique ID
>  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
> +Name (XHCI, 0xF)// will be set using AcpiLib
>  Method (_STA) {
> -  Return (0xF)
> +  Return (XHCI)
>  }
>  Method (_CRS, 0x0, Serialized) {
>  Name (RBUF, ResourceTemplate() {
> 
> -- 
> 2.41.0
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110129): https://edk2.groups.io/g/devel/message/110129
Mute This Topic: https://groups.io/mt/102037246/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] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 18:19, Laszlo Ersek wrote:
> On 10/26/23 15:53, Neal Gompa wrote:
>> From: Neal Gompa 
>>
>> Currently, the ReadyToBoot event is only signaled when a formal Boot
>> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>
>> However, the introduction of Platform Recovery in UEFI 2.5 makes it
>> necessary to signal ReadyToBoot when a Platform Recovery boot loader
>> runs because otherwise it may lead to the execution of a boot loader
>> that has similar requirements to a regular one that is not launched
>> as a Boot Manager option.
>>
>> This is especially critical to ensuring that the graphical console
>> is actually usable during platform recovery, as some platforms do
>> rely on the ConsolePrefDxe driver, which only performs console
>> initialization after ReadyToBoot is triggered.
>>
>> This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
>> in EfiBootManagerProcessLoadOption (), which is the function that sets
>> up the platform recovery boot process.
>>
>> The expected behavior has been clarified in the UEFI 2.10 specification
>> to explicitly indicate this behavior is required for correct operation.
>>
>> This is a rebased version of the patch originally written by Pete Batard.
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
>>
>> Cc: Pete Batard 
>> Cc: Daniel P. Berrangé 
>> Cc: Gerd Hoffmann 
>> Cc: Samer El-Haj-Mahmoud 
>>
>> Co-authored-by: Pete Batard 
>> Signed-off-by: Neal Gompa 
>> ---
>>  MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> index 2087f0b91d..31ed608817 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> @@ -1416,6 +1416,15 @@ EfiBootManagerProcessLoadOption (
>>  return EFI_SUCCESS;
>>}
>>  
>> +  //
>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load 
>> and execute the boot option.
>> +  //
>> +  EfiSignalEventReadyToBoot ();
>> +  //
>> +  // Report Status Code to indicate ReadyToBoot was signalled
>> +  //
>> +  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>> +
>>//
>>// Load and start the load option.
>>//
> 
> While the patch does the right thing for the latest UEFI spec language,
> it does a bit too much.
> 
> The spec says (v2.10), under 7.1.2 "EFI_BOOT_SERVICES.CreateEventEx()":
> 
> ---
> EFI_EVENT_GROUP_READY_TO_BOOT
> 
> This event group is notified by the system right before notifying
> EFI_EVENT_GROUP_AFTER_READY_TO_BOOT event group when the Boot Manager is
> about to load and execute a boot option or a platform or OS recovery
> option. The event group presents the last chance to modify device or
> system configuration prior to passing control to a boot option.
> ---
> 
> NB "boot option", or "platform or OS recovery option".
> 
> However, EfiBootManagerProcessLoadOption() is also used for launching
> Driver and SysPrep options.
> 
> EfiBootManagerProcessLoadOption() has two call sites:
> 
> (1) in ProcessLoadOptions() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> 
> (2) near the end of BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> 
> Call site (2) bears the comment "When platform recovery is not enabled,
> still boot to platform default file path", so I figure signaling
> ready-to-boot at that point is fine.
> 
> Call site (1) requires further investigation. Namely,
> ProcessLoadOptions() itself is called from three locations, all inside
> BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]:
> 
> (1.1) under comment "Execute Driver Options", for "LoadOptionTypeDriver"
> type load options
> 
> (1.2) under comment "Execute SysPrep", for "LoadOptionTypeSysPrep"
> type load options
> 
> (1.3) for "LoadOptionTypePlatformRecovery" type load options.
> 
> I figure the intended extension is for case (1.3), but the patch, as
> proposed, will also affect (1.1) and (1.2); that is, when Driver and
> SysPrep options are processes. That's beyond what the spec says, in
> my opinion.
> 
> Now, EfiBootManagerProcessLoadOption() takes a pointer to an
> EFI_BOOT_MANAGER_LOAD_OPTION structure. This structure has a field
> called OptionType (of type EFI_BOOT_MANAGER_LOAD_OPTION_TYPE). You might
> want to restrict the signaling and the status code reporting to when
> LoadOption->OptionType is either LoadOptionTypeBoot or
> LoadOptionTypePlatformRecovery (i.e., exclude LoadOptionTypeDriver and
> LoadOptionTypeSysPrep).

In fact,

EfiBootManagerProcessLoadOption() already checks
"LoadOption->OptionType" higher up, and if its LoadOptionTypeBoot, then
the function returns early, with EFI_UNSUPPORTED.

Therefore, IMO, you need to restrict the logic you are proposing to

  LoadOption->OptionType ==

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 14:37, jacopo.r0...@gmail.com wrote:
> Hi there,
> 
> I was trying to HTTPs boot a virtual machine with the following scenario:
> 
> 1) I have a self signed root CA /root.crt /and then I use it to sign
> another self signed certificate /myip.crt /for the IP address X.X.X.X
> 2) I have an NGINX server configured to use SSL with the /myip.crt
> /certificate and its key.
> 3) I have a UEFI virtual machine configured to HTTPs boot and trust the
> CA certificate /root.crt /.

How exactly did you configure your VM (runnig presumably ArmVirtQemu or
OVMF) to accept the root certificate?

See the SetCaCerts() function in
"OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c".

See also the "HTTPS Boot" section in "OvmfPkg/README"

If you build OVMF with DEBUG_VERBOSE enabled (pass
"--pcd=gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel=0x8040004F" to
"build"), and attach the firmware log (search "OvmfPkg/README" for
"debugcon"), that might help with the analysis.

It's quite possible that the certificate chain you've created is not
accepted by how edk2 uses OpenSSL, but we need to check more closely to
determine that. Can you include a textual dump of your CA cert / server
cert, too?

Laszlo

> 
> Unfortunately the machine fails in the SSL handshake step and then the
> UEFI config page is shown again. Using for example /curl --cacert
> root.crt X.X.X.X /it works perfectly fine (also forcing curl to use tls
> 1.2).
> 
> In addition to that, if I do not use a root certificate for the server's
> IP (i.e. I do not build a chain of certificates), the machine boots fine.
> 
> Unfortunately I don't have a physical server to make a real test. Is
> this a missing feature, a bug, or am I doing it completely wrong?
> 
> Thank you very much!
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110127): https://edk2.groups.io/g/devel/message/110127
Mute This Topic: https://groups.io/mt/102201552/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] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 15:53, Neal Gompa wrote:
> From: Neal Gompa 
> 
> Currently, the ReadyToBoot event is only signaled when a formal Boot
> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> 
> However, the introduction of Platform Recovery in UEFI 2.5 makes it
> necessary to signal ReadyToBoot when a Platform Recovery boot loader
> runs because otherwise it may lead to the execution of a boot loader
> that has similar requirements to a regular one that is not launched
> as a Boot Manager option.
> 
> This is especially critical to ensuring that the graphical console
> is actually usable during platform recovery, as some platforms do
> rely on the ConsolePrefDxe driver, which only performs console
> initialization after ReadyToBoot is triggered.
> 
> This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
> in EfiBootManagerProcessLoadOption (), which is the function that sets
> up the platform recovery boot process.
> 
> The expected behavior has been clarified in the UEFI 2.10 specification
> to explicitly indicate this behavior is required for correct operation.
> 
> This is a rebased version of the patch originally written by Pete Batard.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
> 
> Cc: Pete Batard 
> Cc: Daniel P. Berrangé 
> Cc: Gerd Hoffmann 
> Cc: Samer El-Haj-Mahmoud 
> 
> Co-authored-by: Pete Batard 
> Signed-off-by: Neal Gompa 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 2087f0b91d..31ed608817 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1416,6 +1416,15 @@ EfiBootManagerProcessLoadOption (
>  return EFI_SUCCESS;
>}
>  
> +  //
> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
> execute the boot option.
> +  //
> +  EfiSignalEventReadyToBoot ();
> +  //
> +  // Report Status Code to indicate ReadyToBoot was signalled
> +  //
> +  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> +
>//
>// Load and start the load option.
>//

While the patch does the right thing for the latest UEFI spec language,
it does a bit too much.

The spec says (v2.10), under 7.1.2 "EFI_BOOT_SERVICES.CreateEventEx()":

---
EFI_EVENT_GROUP_READY_TO_BOOT

This event group is notified by the system right before notifying
EFI_EVENT_GROUP_AFTER_READY_TO_BOOT event group when the Boot Manager is
about to load and execute a boot option or a platform or OS recovery
option. The event group presents the last chance to modify device or
system configuration prior to passing control to a boot option.
---

NB "boot option", or "platform or OS recovery option".

However, EfiBootManagerProcessLoadOption() is also used for launching
Driver and SysPrep options.

EfiBootManagerProcessLoadOption() has two call sites:

(1) in ProcessLoadOptions() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]

(2) near the end of BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]

Call site (2) bears the comment "When platform recovery is not enabled,
still boot to platform default file path", so I figure signaling
ready-to-boot at that point is fine.

Call site (1) requires further investigation. Namely,
ProcessLoadOptions() itself is called from three locations, all inside
BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]:

(1.1) under comment "Execute Driver Options", for "LoadOptionTypeDriver"
type load options

(1.2) under comment "Execute SysPrep", for "LoadOptionTypeSysPrep"
type load options

(1.3) for "LoadOptionTypePlatformRecovery" type load options.

I figure the intended extension is for case (1.3), but the patch, as
proposed, will also affect (1.1) and (1.2); that is, when Driver and
SysPrep options are processes. That's beyond what the spec says, in
my opinion.

Now, EfiBootManagerProcessLoadOption() takes a pointer to an
EFI_BOOT_MANAGER_LOAD_OPTION structure. This structure has a field
called OptionType (of type EFI_BOOT_MANAGER_LOAD_OPTION_TYPE). You might
want to restrict the signaling and the status code reporting to when
LoadOption->OptionType is either LoadOptionTypeBoot or
LoadOptionTypePlatformRecovery (i.e., exclude LoadOptionTypeDriver and
LoadOptionTypeSysPrep).

(

I've made an attempt to check the above-noted four call paths (i.e.,
(1.1) through (1.3), and (2)), and I *think* the OptionType field is
populated on all of them; thus, the check I recommend should be safe.

Call paths (1.1) through (1.3) call EfiBootManagerGetLoadOptions(),
which sets the OptionType field in each returned structure according to
the input parameter "LoadOptionType" (note the tricky call to
EfiBootManagerVariableToLoadOption()).

And (2) relies on

Re: [edk2-devel] [edk2-platforms PATCH v1 1/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm 
On Thu, Oct 26, 2023 at 16:35:52 +0100, Leif Lindholm wrote:
> On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> > From: Narinder Dhillon 
> > 
> > Current Marvell package structure makes it difficult to add new silicon
> > packages that reuse common elements without creating nested DEC files.
> > 
> > This patch creates a new MarvellSiliconPkg folder and moves the current
> > common elements inside it.
> > 
> > Also gMarvellTokenSpaceGuid has been renamed to
> > gMarvellSiliconTokenSpaceGuid to align with new package name.
> 
> Ah, I also note this patch breaks bisect since it does not change the
> path in the affected .inf files:
> Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf:
> Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf:
> Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf:
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf:
> Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf:
> Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/SolidRun/Cn913xCEx7Eval/BoardDescriptionLib/BoardDescriptionLib.inf:
> Platform/SolidRun/Cn913xCEx7Eval/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> 
> That change needs to be squashed into this patch instead of introduced
> in 3/4.

Actually, belay that.
2, 3, 4 all need to be squashed into 1.
One of these years I'll learn to read through an entire set before
responding.

/
Leif

> /
> Leif
> 
> > Signed-off-by: Narinder Dhillon 
> > ---
> >  Silicon/Marvell/Marvell.dec   | 208 -
> >  .../Include/IndustryStandard/MvSmc.h  |   0
> >  .../Include/Library/ArmadaBoardDescLib.h  |   0
> >  .../Include/Library/ArmadaIcuLib.h|   0
> >  .../Include/Library/ArmadaSoCDescLib.h|   0
> >  .../Include/Library/MppLib.h  |   0
> >  .../Include/Library/MvComPhyLib.h |   0
> >  .../Include/Library/MvGpioLib.h   |   0
> >  .../Include/Library/NonDiscoverableInitLib.h  |   0
> >  .../Include/Library/SampleAtResetLib.h|   0
> >  .../Include/Library/UtmiPhyLib.h  |   0
> >  .../Include/Protocol/BoardDesc.h  |   0
> >  .../Include/Protocol/Eeprom.h |   0
> >  .../Include/Protocol/Mdio.h   |   0
> >  .../Include/Protocol/MvI2c.h  |   0
> >  .../Include/Protocol/MvPhy.h  |   0
> >  .../Include/Protocol/Spi.h|   0
> >  .../Include/Protocol/SpiFlash.h   |   0
> >  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++
> >  19 files changed, 211 insertions(+), 208 deletions(-)
> >  delete mode 100644 Silicon/Marvell/Marvell.dec
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> > (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/MvComPhyLib.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> > (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Protocol/BoardDesc.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Spi.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/SpiFlash.h 
> > (100%)
> >  create mode 100644 Silicon/Marvell/MarvellSiliconPkg/MarvellSiliconPkg.dec
> > 
> > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> > deleted file mode 100644
> > index 482a90da25..00
> > --- a/Silicon/Marvell/Marvell.dec
> > +++ /dev/null
> > @@ -1,208

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: realpath function signature doesn't match the standard

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 16:17, Jayaprakash, N wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4574
> 
> This commit is for processing the below PR on edk2-libc repo
> https://github.com/tianocore/edk2-libc/pull/10
> The realpath function signature in stdlib of edk2-libc doesn't match
> signature as per the standard definition of this function given below
> https://pubs.opengroup.org/onlinepubs/009695399/functions/realpath.html
> This patch extracted from the above pull request fixes this issue.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Kloper Dimitry 
> ---
>  StdLib/Include/stdlib.h   | 4 ++--
>  StdLib/LibC/StdLib/realpath.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/StdLib/Include/stdlib.h b/StdLib/Include/stdlib.h
> index 0b9dfd3..022ddbd 100644
> --- a/StdLib/Include/stdlib.h
> +++ b/StdLib/Include/stdlib.h
> @@ -74,7 +74,7 @@
> const wchar_t * __restrict src, size_t limit);
>  
>    Miscelaneous functions for *nix compatibility
> -char   *realpath(char *file_name, char *resolved_name);
> +char   *realpath(const char *file_name, char *resolved_name);
>  const char *getprogname (void);
>  voidsetprogname (const char *progname);
>  
> @@ -875,7 +875,7 @@ size_t  wcstombs(char * __restrict Dest, const wchar_t * 
> __restrict Src, size_t
>  @retval NULLAn error occured.
>  @retval resolved_name.
>  **/
> -char * realpath(char *file_name, char *resolved_name);
> +char * realpath(const char *file_name, char *resolved_name);
>  
>  /** The getprogname() function returns the name of the program.  If the name
>  has not been set yet, it will return NULL.
> diff --git a/StdLib/LibC/StdLib/realpath.c b/StdLib/LibC/StdLib/realpath.c
> index 3d4118d..29abe9a 100644
> --- a/StdLib/LibC/StdLib/realpath.c
> +++ b/StdLib/LibC/StdLib/realpath.c
> @@ -34,7 +34,7 @@
>  **/
>  char *
>  realpath(
> -  char *file_name,
> +  const char *file_name,
>char *resolved_name
>)
>  {

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110124): https://edk2.groups.io/g/devel/message/110124
Mute This Topic: https://groups.io/mt/102200532/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 16:55, Ard Biesheuvel wrote:
> On Thu, 26 Oct 2023 at 16:46, Julien Grall  wrote:
>>
>> Hi,
>>
>> On 26/10/2023 15:21, Peter Maydell wrote:
>>> On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
 On 10/10/23 09:43, Ard Biesheuvel wrote:
> Thanks for looking into this - a cleanup was overdue here.
>
> I will take a look in more detail later, but one thing that occurred
> to me when reading this overview is that having a separate DEBUG
> serial port would permit us to
>
> a) remove it from the DT

 ... as in, hide it from Linux, I assume?

> b) add a runtime mapping for it
> c) keep using it after ExitBootServices
>
> This could be useful for debugging issues with the variable store etc.
>
> Not saying this is something to address in this series, but I'd like
> to hear your take on this.
>

 Sounds like a useful feature.

 I see four challenges:


 (1) We'd have to coordinate it with Peter. If we hide any one of the
 serial ports from Linux, that may not be what QEMU intends for Linux to
 happen. Linux currently ties getties to all serial ports -- via the
 serial* aliases, IIUC. Thus, some "positive identification" in the DT
 could be necessary (i.e., that edk2 was welcome to hide that port from
 Linux).
>>>
>>> The potential awkwardness here is that what the guest thinks about
>>> the serial ports depends on the ACPI table fragments which QEMU
>>> provides. EDK2 would need to edit the table fragment to remove any
>>> mention of the second UART if it wanted to hide it from the kernel.
>>> I don't know how hard that would be in EDK2.
>>
>> I am not sure if it would help EDK2 in this case. But we had a similar
>> problem when adding support for ACPI in Xen. It was not trivial to
>> remove the UART from the ACPI tables provided by the host. So we ended
>> up to introduce the STAO table [1]. This is used to describe which
>> device will be hidden to the OS.
>>
> 
> I'd much rather have an implementation of the _STA method on those
> devices where the underlying AML queries the fwcfg MMIO device

Yes, this is possible too; the AML generated by QEMU need not be
constant, it can interact at OS runtime with QEMU. An example for this
is the VCPU hotplug register block. The hot(un)plug AML is super
sophisticated, it connects the guest kernel, QEMU (via the register
block) and the firmware (via raising SMIs).

One word of caution against accessing fw_cfg specifically, from AML:
fw_cfg is already exposed via guest sysfs (IIRC -- see
"drivers/firmware/qemu_fw_cfg.c"), because fw_cfg ended up being
"abused" (IMO) as a generic info channel from the host-side user to
guest OS + applications. (I call this "abuse" because "fw_cfg" literally
says "firmware configuration" in the name, and this particular use case
is anything *but* firmware configuration.) Accessing the same device
from AML may not be without risks.

But "non-fw_cfg platform registers" might work well with AML.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110123): https://edk2.groups.io/g/devel/message/110123
Mute This Topic: https://groups.io/mt/101834880/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] [edk2-platforms PATCH v1 1/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm 
On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> From: Narinder Dhillon 
> 
> Current Marvell package structure makes it difficult to add new silicon
> packages that reuse common elements without creating nested DEC files.
> 
> This patch creates a new MarvellSiliconPkg folder and moves the current
> common elements inside it.
> 
> Also gMarvellTokenSpaceGuid has been renamed to
> gMarvellSiliconTokenSpaceGuid to align with new package name.

Ah, I also note this patch breaks bisect since it does not change the
path in the affected .inf files:
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf:
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf:
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf:
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf:
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf:
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/SolidRun/Cn913xCEx7Eval/BoardDescriptionLib/BoardDescriptionLib.inf:
Platform/SolidRun/Cn913xCEx7Eval/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:

That change needs to be squashed into this patch instead of introduced
in 3/4.

/
Leif

> Signed-off-by: Narinder Dhillon 
> ---
>  Silicon/Marvell/Marvell.dec   | 208 -
>  .../Include/IndustryStandard/MvSmc.h  |   0
>  .../Include/Library/ArmadaBoardDescLib.h  |   0
>  .../Include/Library/ArmadaIcuLib.h|   0
>  .../Include/Library/ArmadaSoCDescLib.h|   0
>  .../Include/Library/MppLib.h  |   0
>  .../Include/Library/MvComPhyLib.h |   0
>  .../Include/Library/MvGpioLib.h   |   0
>  .../Include/Library/NonDiscoverableInitLib.h  |   0
>  .../Include/Library/SampleAtResetLib.h|   0
>  .../Include/Library/UtmiPhyLib.h  |   0
>  .../Include/Protocol/BoardDesc.h  |   0
>  .../Include/Protocol/Eeprom.h |   0
>  .../Include/Protocol/Mdio.h   |   0
>  .../Include/Protocol/MvI2c.h  |   0
>  .../Include/Protocol/MvPhy.h  |   0
>  .../Include/Protocol/Spi.h|   0
>  .../Include/Protocol/SpiFlash.h   |   0
>  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++
>  19 files changed, 211 insertions(+), 208 deletions(-)
>  delete mode 100644 Silicon/Marvell/Marvell.dec
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvComPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/BoardDesc.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Spi.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/SpiFlash.h 
> (100%)
>  create mode 100644 Silicon/Marvell/MarvellSiliconPkg/MarvellSiliconPkg.dec
> 
> diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> deleted file mode 100644
> index 482a90da25..00
> --- a/Silicon/Marvell/Marvell.dec
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -# Copyright (C) 2016 Marvell International Ltd.
> -#
> -# SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -
> -[Defines]
> -  DEC_SPECIFICATION  = 0x00010005
> -  PACKAGE_NAME   = OpenPlatformMarvellPkg
> -  PACKAGE_GUID   = c372916e-83ad-4b2a-8410-bbc31bd9e68f
> -  PACKAGE_VERSION= 0.1
> -
>

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: realpath function signature doesn't match the standard

2023-10-26 Thread Jayaprakash, N 
Reviewed-by: Jayaprakash Nevara 
It's simple fix to align the function signature as per the standards.

Regards,
JP
-Original Message-
From: Jayaprakash, N  
Sent: Thursday, October 26, 2023 7:47 PM
To: devel@edk2.groups.io
Cc: Jayaprakash, N ; Rebecca Cran ; 
Kinney, Michael D ; Kloper, Dimitry 

Subject: [edk2-libc Patch 1/1] ek2-libc: realpath function signature doesn't 
match the standard

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

This commit is for processing the below PR on edk2-libc repo
https://github.com/tianocore/edk2-libc/pull/10
The realpath function signature in stdlib of edk2-libc doesn't match signature 
as per the standard definition of this function given below 
https://pubs.opengroup.org/onlinepubs/009695399/functions/realpath.html
This patch extracted from the above pull request fixes this issue.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Kloper Dimitry 
---
 StdLib/Include/stdlib.h   | 4 ++--
 StdLib/LibC/StdLib/realpath.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Include/stdlib.h b/StdLib/Include/stdlib.h index 
0b9dfd3..022ddbd 100644
--- a/StdLib/Include/stdlib.h
+++ b/StdLib/Include/stdlib.h
@@ -74,7 +74,7 @@
const wchar_t * __restrict src, size_t limit);
 
   Miscelaneous functions for *nix compatibility
-char   *realpath(char *file_name, char *resolved_name);
+char   *realpath(const char *file_name, char *resolved_name);
 const char *getprogname (void);
 voidsetprogname (const char *progname);
 
@@ -875,7 +875,7 @@ size_t  wcstombs(char * __restrict Dest, const wchar_t * 
__restrict Src, size_t
 @retval NULLAn error occured.
 @retval resolved_name.
 **/
-char * realpath(char *file_name, char *resolved_name);
+char * realpath(const char *file_name, char *resolved_name);
 
 /** The getprogname() function returns the name of the program.  If the name
 has not been set yet, it will return NULL.
diff --git a/StdLib/LibC/StdLib/realpath.c b/StdLib/LibC/StdLib/realpath.c 
index 3d4118d..29abe9a 100644
--- a/StdLib/LibC/StdLib/realpath.c
+++ b/StdLib/LibC/StdLib/realpath.c
@@ -34,7 +34,7 @@
 **/
 char *
 realpath(
-  char *file_name,
+  const char *file_name,
   char *resolved_name
   )
 {
--
2.40.0.windows.1



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

[edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP

2023-10-26 Thread Jake Garver via groups.io 
In the R_AARCH64_ADR_GOT_PAGE case on AARCH64, be sure to change the
opcode to ADRP.  Prior to this change, we updated the address, but not
the opcode.

This resolves an issue experienced when building a StandaloneMm image
with stack protection enabled on GCC 10.5.  This scenario generates an
ADR where an ADRP is more common in other versions of GCC tested.  That
explains the obscurity of the issue.  However, an ADR is valid and
should be handled by GenFw.

Using the stack protection scenario as an example, the following code is
being generated by the toolchain:

# Load to set the stack canary
2ffc:   10028020adr x0, 8000 
3008:   f940d400ldr x0, [x0, #424]

# Load to check the stack canary
30cc:   b020adrpx0, 8000 
30d0:   f940d400ldr x0, [x0, #424]

GenFw rewrote that to:

# Load to set the stack canary
2ffc:   1480adr x0, 0x308c
3008:   912ec000add x0, x0, #0xbb0

# Load to check the stack canary
30cc:   f460adrpx0, 0x92000
30d0:   912ec000add x0, x0, #0xbb0

Note that we're now setting the stack canary from the wrong address,
resulting in an erroneous stack fault.

After this fix, the opcode is also updated, so GenFw rewrites it to:

2ffc:   9480adrpx0, 0x92000
3008:   912ec000add x0, x0, #0xbb0

And the stack canary is set correctly.

Signed-off-by: Jake Garver 
---
 BaseTools/Source/C/GenFw/Elf64Convert.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 9911db65af..4669ac3a2d 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -1565,6 +1565,7 @@ WriteSections64 (
 Offset = (Sym->st_value - (Rel->r_offset & ~0xfff)) >> 12;
 
 *(UINT32 *)Targ &= 0x901f;
+*(UINT32 *)Targ |= 0x9000;
 *(UINT32 *)Targ |= ((Offset & 0x1c) << (5 - 2)) | ((Offset & 
0x3) << 29);
 
 /* fall through */
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110120): https://edk2.groups.io/g/devel/message/110120
Mute This Topic: https://groups.io/mt/102202314/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 16:46, Julien Grall wrote:
> Hi,
> 
> On 26/10/2023 15:21, Peter Maydell wrote:
>> On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
>>> On 10/10/23 09:43, Ard Biesheuvel wrote:
 Thanks for looking into this - a cleanup was overdue here.

 I will take a look in more detail later, but one thing that occurred
 to me when reading this overview is that having a separate DEBUG
 serial port would permit us to

 a) remove it from the DT
>>>
>>> ... as in, hide it from Linux, I assume?
>>>
 b) add a runtime mapping for it
 c) keep using it after ExitBootServices

 This could be useful for debugging issues with the variable store etc.

 Not saying this is something to address in this series, but I'd like
 to hear your take on this.

>>>
>>> Sounds like a useful feature.
>>>
>>> I see four challenges:
>>>
>>>
>>> (1) We'd have to coordinate it with Peter. If we hide any one of the
>>> serial ports from Linux, that may not be what QEMU intends for Linux to
>>> happen. Linux currently ties getties to all serial ports -- via the
>>> serial* aliases, IIUC. Thus, some "positive identification" in the DT
>>> could be necessary (i.e., that edk2 was welcome to hide that port from
>>> Linux).
>>
>> The potential awkwardness here is that what the guest thinks about
>> the serial ports depends on the ACPI table fragments which QEMU
>> provides. EDK2 would need to edit the table fragment to remove any
>> mention of the second UART if it wanted to hide it from the kernel.
>> I don't know how hard that would be in EDK2.
> 
> I am not sure if it would help EDK2 in this case. But we had a similar
> problem when adding support for ACPI in Xen. It was not trivial to
> remove the UART from the ACPI tables provided by the host. So we ended
> up to introduce the STAO table [1]. This is used to describe which
> device will be hidden to the OS.
> 
> Cheers,
> 
> [1] https://wiki.xenproject.org/images/0/02/Status-override-table.pdf
> 

This is a very interesting document. It states the problem well, but the
solution Xen seems to have chosen is the opposite of QEMU's. The
document states that AML generation is difficult, so simple override
tables such as STAO are preferred. QEMU on the other hand has grown a
full-blown runtime AML generator, plus an "ACPI linker/loader script"
language that allows guest firmware to cross-link and install the "tree
of tables", also updating their checksums (under SeaBIOS), all the while
being completely blind to the actual contents of the tables.

This means that under QEMU, the sole source of "ACPI truth" is QEMU.

Laszlo



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

[edk2-devel] [edk2-libc Patch 0/1] fix missing nanf definition in StdLib

2023-10-26 Thread Jayaprakash, N 
This patch fixes the issue of missing definition of nanf in StdLib.
This has been extracted from the below PR submitted on edk2-libc.
https://github.com/tianocore/edk2-libc/pull/9

Jayaprakash N (1):
  ek2-libc: fix missing nanf definition in StdLib

 StdLib/LibC/LibC.inf|  1 +
 StdLib/LibC/Main/nanf_ieee754.c | 15 +++
 2 files changed, 16 insertions(+)
 create mode 100644 StdLib/LibC/Main/nanf_ieee754.c

-- 
2.40.0.windows.1



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

[edk2-devel] [edk2-libc Patch 1/1] ek2-libc: fix missing nanf definition in StdLib

2023-10-26 Thread Jayaprakash, N 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4576

File StdLib/Include/math.h:406 defines NAN constant as __nanf.__val.
The problem is that __nanf is never defined.
Fix is simple: define __nanf in similar way as __infinityf

This fix has been provided through the below PR on edk2-libc repo
https://github.com/tianocore/edk2-libc/pull/9.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Kloper Dimitry 
---
 StdLib/LibC/LibC.inf|  1 +
 StdLib/LibC/Main/nanf_ieee754.c | 15 +++
 2 files changed, 16 insertions(+)
 create mode 100644 StdLib/LibC/Main/nanf_ieee754.c

diff --git a/StdLib/LibC/LibC.inf b/StdLib/LibC/LibC.inf
index ad6a117..93e32e8 100644
--- a/StdLib/LibC/LibC.inf
+++ b/StdLib/LibC/LibC.inf
@@ -34,6 +34,7 @@
   Main/isnand_ieee754.c
   Main/isnanf_ieee754.c
   Main/infinityf_ieee754.c
+  Main/nanf_ieee754.c
   Main/Main.c
   Main/HtoNtoH.c
   Main/ByteSwap.c
diff --git a/StdLib/LibC/Main/nanf_ieee754.c b/StdLib/LibC/Main/nanf_ieee754.c
new file mode 100644
index 000..8e56d32
--- /dev/null
+++ b/StdLib/LibC/Main/nanf_ieee754.c
@@ -0,0 +1,15 @@
+/*
+ * IEEE-compatible nanf.c -- public domain.
+ */
+#include  
+#include 
+
+#include 
+#include 
+
+const union __float_u __nanf =
+#if BYTE_ORDER == BIG_ENDIAN
+  { { 0x7f, 0xc0, 0,0 } };
+#else
+  { {0,0,  0xc0, 0x7f } };
+#endif
-- 
2.40.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110117): https://edk2.groups.io/g/devel/message/110117
Mute This Topic: https://groups.io/mt/102202277/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/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm 
Hi Nharinder,

Apologies for delay in responding - this was sent out during UEFI
plugfest, and then I brought home a cold from there.

On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> From: Narinder Dhillon 
> 
> Current Marvell package structure makes it difficult to add new silicon
> packages that reuse common elements without creating nested DEC files.
> 
> This patch creates a new MarvellSiliconPkg folder and moves the current
> common elements inside it.
> 
> Also gMarvellTokenSpaceGuid has been renamed to
> gMarvellSiliconTokenSpaceGuid to align with new package name.
> 
> Signed-off-by: Narinder Dhillon 
> ---
>  Silicon/Marvell/Marvell.dec   | 208 -
>  .../Include/IndustryStandard/MvSmc.h  |   0
>  .../Include/Library/ArmadaBoardDescLib.h  |   0
>  .../Include/Library/ArmadaIcuLib.h|   0
>  .../Include/Library/ArmadaSoCDescLib.h|   0
>  .../Include/Library/MppLib.h  |   0
>  .../Include/Library/MvComPhyLib.h |   0
>  .../Include/Library/MvGpioLib.h   |   0
>  .../Include/Library/NonDiscoverableInitLib.h  |   0
>  .../Include/Library/SampleAtResetLib.h|   0
>  .../Include/Library/UtmiPhyLib.h  |   0
>  .../Include/Protocol/BoardDesc.h  |   0
>  .../Include/Protocol/Eeprom.h |   0
>  .../Include/Protocol/Mdio.h   |   0
>  .../Include/Protocol/MvI2c.h  |   0
>  .../Include/Protocol/MvPhy.h  |   0
>  .../Include/Protocol/Spi.h|   0
>  .../Include/Protocol/SpiFlash.h   |   0
>  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++

I was curious as to what caused 208 lines to be deleted and 211 added.
A diff shows the below:

+  UtmiPhyLib|Include/Library/UtmiPhyLib.h
+  MppLib|Include/Library/MppLib.h
+  MvComPhyLib|Include/Library/MvComPhyLib.h

While it was clearly a bug that these were previously unlisted, I
think that should be changed by a separate patch, preceding this,
rather than as part of a rename operation.
There is also a trailing newline at the end of the.dec that would be
nice to get rid of. (Could be addressed in the same ".dec cleanup" patch.)

/
Leif

>  19 files changed, 211 insertions(+), 208 deletions(-)
>  delete mode 100644 Silicon/Marvell/Marvell.dec
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvComPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/BoardDesc.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Spi.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/SpiFlash.h 
> (100%)
>  create mode 100644 Silicon/Marvell/MarvellSiliconPkg/MarvellSiliconPkg.dec
> 
> diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> deleted file mode 100644
> index 482a90da25..00
> --- a/Silicon/Marvell/Marvell.dec
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -# Copyright (C) 2016 Marvell International Ltd.
> -#
> -# SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -
> -[Defines]
> -  DEC_SPECIFICATION  = 0x00010005
> -  PACKAGE_NAME   = OpenPlatformMarvellPkg
> -  PACKAGE_GUID   = c372916e-83ad-4b2a-8410-bbc31bd9e68f
> -  PACKAGE_VERSION= 0.1
> -
> -
> -#
> -# Include Section - list of Include Paths that are provided by this package.
> -#   Comments are used for Keywords and Module Types.
> -#
> -# Supported Module Types:
> -#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
> DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
> -#
>

Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Ard Biesheuvel 
On Thu, 26 Oct 2023 at 17:19, Laszlo Ersek  wrote:
>
> On 10/26/23 16:21, Peter Maydell wrote:
> > On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
> >> On 10/10/23 09:43, Ard Biesheuvel wrote:
> >>> Thanks for looking into this - a cleanup was overdue here.
> >>>
> >>> I will take a look in more detail later, but one thing that occurred
> >>> to me when reading this overview is that having a separate DEBUG
> >>> serial port would permit us to
> >>>
> >>> a) remove it from the DT
> >>
> >> ... as in, hide it from Linux, I assume?
> >>
> >>> b) add a runtime mapping for it
> >>> c) keep using it after ExitBootServices
> >>>
> >>> This could be useful for debugging issues with the variable store etc.
> >>>
> >>> Not saying this is something to address in this series, but I'd like
> >>> to hear your take on this.
> >>>
> >>
> >> Sounds like a useful feature.
> >>
> >> I see four challenges:
> >>
> >>
> >> (1) We'd have to coordinate it with Peter. If we hide any one of the
> >> serial ports from Linux, that may not be what QEMU intends for Linux to
> >> happen. Linux currently ties getties to all serial ports -- via the
> >> serial* aliases, IIUC. Thus, some "positive identification" in the DT
> >> could be necessary (i.e., that edk2 was welcome to hide that port from
> >> Linux).
> >
> > The potential awkwardness here is that what the guest thinks about
> > the serial ports depends on the ACPI table fragments which QEMU
> > provides. EDK2 would need to edit the table fragment to remove any
> > mention of the second UART if it wanted to hide it from the kernel.
> > I don't know how hard that would be in EDK2.
> >
> > (As far as I'm aware usually a boot via EDK2 doesn't pass the
> > dtb on to Linux, though I guess there's no reason it can't.)
> >
> > From QEMU's point of view, we provide two UARTs to the guest, and we
> > don't really care whether that means one is used by EDK2 and one by
> > Linux, or both are used as getty terminals by Linux, or whether the
> > Linux guest uses one serial as a terminal and leaves the other to its
> > userspace programs  -- it's all just guest software to us :-)
> >
> > [snip other technical stuff]
>
> Thanks, good point -- I wasn't aware of the ACPI impact.
>
> We don't edit / patch QEMU's ACPI tables, ever. (Beyond obeying the ACPI
> linker/loader script.) That's a principle we've upheld many times.
> Whenever ACPI content needs to change, that implies a QEMU patch.
>
> So, for this purpose, only the following could have a chance of working:
>
> - Expose a new config option on the QEMU command line to the user,
> regarding the intended use of the serial port(s). This could be of any
> tolerable form (machine property, front-end (device) property, whatever
> -- anything that QEMU reviewers can accept).
>
> - In QEMU, generate both the DT and the ACPI tables accordingly. The
> ACPI tables would have to immediately *not* contain the UART-to-hide (so
> as to keep it secret from the guest OS). The DT at the same time would
> still have to expose the "runtime DEBUG UART", because edk2 would have
> to know where that UART was (and that it was meant specifically for OS
> runtime debug output).
>
> - Edk2 would have to patch the DT (we tend to do that already), because
> (in some configs) we do forward the DT to the guest OS. This need for
> patching could be lifted if QEMU adopted such a form of expression for
> the "runtime DEBUG UART" that would be ignored by Linux out of the box.
>
> >
> >> All in all, I think the implementation would be quite a steep divergence
> >> from, or on top of, this patch set. :)
> >
> > I agree with this and with Ard's "not something to address in this
> > series" comment above; it doesn't sound like this is something that
> > needs to hold up the patchset we have currently.
>
> Right; I'd like to flush this one. The runtime debug UART seems to need
> more joint pondering.
>
> >
> > Does anybody have time to review Laszlo's code? It would be nice
> > to be able to get this into the next EDK2 release.
>

I'm happy for this to go in if it covers our needs.

Acked-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110115): https://edk2.groups.io/g/devel/message/110115
Mute This Topic: https://groups.io/mt/101834880/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Laszlo Ersek 
On 10/26/23 16:21, Peter Maydell wrote:
> On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
>> On 10/10/23 09:43, Ard Biesheuvel wrote:
>>> Thanks for looking into this - a cleanup was overdue here.
>>>
>>> I will take a look in more detail later, but one thing that occurred
>>> to me when reading this overview is that having a separate DEBUG
>>> serial port would permit us to
>>>
>>> a) remove it from the DT
>>
>> ... as in, hide it from Linux, I assume?
>>
>>> b) add a runtime mapping for it
>>> c) keep using it after ExitBootServices
>>>
>>> This could be useful for debugging issues with the variable store etc.
>>>
>>> Not saying this is something to address in this series, but I'd like
>>> to hear your take on this.
>>>
>>
>> Sounds like a useful feature.
>>
>> I see four challenges:
>>
>>
>> (1) We'd have to coordinate it with Peter. If we hide any one of the
>> serial ports from Linux, that may not be what QEMU intends for Linux to
>> happen. Linux currently ties getties to all serial ports -- via the
>> serial* aliases, IIUC. Thus, some "positive identification" in the DT
>> could be necessary (i.e., that edk2 was welcome to hide that port from
>> Linux).
> 
> The potential awkwardness here is that what the guest thinks about
> the serial ports depends on the ACPI table fragments which QEMU
> provides. EDK2 would need to edit the table fragment to remove any
> mention of the second UART if it wanted to hide it from the kernel.
> I don't know how hard that would be in EDK2.
> 
> (As far as I'm aware usually a boot via EDK2 doesn't pass the
> dtb on to Linux, though I guess there's no reason it can't.)
> 
> From QEMU's point of view, we provide two UARTs to the guest, and we
> don't really care whether that means one is used by EDK2 and one by
> Linux, or both are used as getty terminals by Linux, or whether the
> Linux guest uses one serial as a terminal and leaves the other to its
> userspace programs  -- it's all just guest software to us :-)
> 
> [snip other technical stuff]

Thanks, good point -- I wasn't aware of the ACPI impact.

We don't edit / patch QEMU's ACPI tables, ever. (Beyond obeying the ACPI
linker/loader script.) That's a principle we've upheld many times.
Whenever ACPI content needs to change, that implies a QEMU patch.

So, for this purpose, only the following could have a chance of working:

- Expose a new config option on the QEMU command line to the user,
regarding the intended use of the serial port(s). This could be of any
tolerable form (machine property, front-end (device) property, whatever
-- anything that QEMU reviewers can accept).

- In QEMU, generate both the DT and the ACPI tables accordingly. The
ACPI tables would have to immediately *not* contain the UART-to-hide (so
as to keep it secret from the guest OS). The DT at the same time would
still have to expose the "runtime DEBUG UART", because edk2 would have
to know where that UART was (and that it was meant specifically for OS
runtime debug output).

- Edk2 would have to patch the DT (we tend to do that already), because
(in some configs) we do forward the DT to the guest OS. This need for
patching could be lifted if QEMU adopted such a form of expression for
the "runtime DEBUG UART" that would be ignored by Linux out of the box.

> 
>> All in all, I think the implementation would be quite a steep divergence
>> from, or on top of, this patch set. :)
> 
> I agree with this and with Ard's "not something to address in this
> series" comment above; it doesn't sound like this is something that
> needs to hold up the patchset we have currently.

Right; I'd like to flush this one. The runtime debug UART seems to need
more joint pondering.

> 
> Does anybody have time to review Laszlo's code? It would be nice
> to be able to get this into the next EDK2 release.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110114): https://edk2.groups.io/g/devel/message/110114
Mute This Topic: https://groups.io/mt/101834880/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 edk2-platforms 1/1] Platform/SbsaQemu: use non-deprecated BaseRngLibTimerLib

2023-10-26 Thread Leif Lindholm 
On Mon, Oct 09, 2023 at 09:36:58 +0200, Marcin Juszkiewicz wrote:
> During boot of debug build I noticed this message:
> 
> Warning: This BaseRngTimerLib implementation will be deprecated.
> Please use the MdeModulePkg implementation equivalent.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 865a31472475.

Thanks!

> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 36723e21d7b5..806651fc55a0 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -148,7 +148,7 @@ [LibraryClasses.common]
>#
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> -  RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
> +  RngLib|MdeModulePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>  
>#
> -- 
> 2.41.0
> 


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

[edk2-devel] [PATCH v1 0/1] UefiPayloadPkg: Fix incorrect code on FIT function.

2023-10-26 Thread brucex . wang 
From: "Brucex.Wang" 

v1: 1.MultiImage[Index] should be deleted if fv path of MultiImage[Index] not 
exist. 2.Remove redundant code.


Brucex.Wang (1):
  UefiPayloadPkg: Fix incorrect code on Fit function.

 UefiPayloadPkg/Tools/MkFitImage.py  |  2 ++
 UefiPayloadPkg/UniversalPayloadBuild.py | 10 --
 2 files changed, 2 insertions(+), 10 deletions(-)

-- 
2.39.1.windows.1



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

[edk2-devel] [PATCH v1 1/1] UefiPayloadPkg: Fix incorrect code on Fit function.

2023-10-26 Thread brucex . wang 
From: "Brucex.Wang" 

1. MultiImage[Index] should be deleted if fv path of MultiImage[Index] not 
exist.
2. Remove redundant code.

Cc: Guo Dong 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 

Signed-off-by: BruceX Wang 
---
 UefiPayloadPkg/Tools/MkFitImage.py  |  2 ++
 UefiPayloadPkg/UniversalPayloadBuild.py | 10 --
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/UefiPayloadPkg/Tools/MkFitImage.py 
b/UefiPayloadPkg/Tools/MkFitImage.py
index 82ab933d6d..afa1630244 100644
--- a/UefiPayloadPkg/Tools/MkFitImage.py
+++ b/UefiPayloadPkg/Tools/MkFitImage.py
@@ -130,6 +130,8 @@ def BuildFitImage(Fdt, InfoHeader):
 MultiImage[Index][-2] = BinaryData
 MultiImage[Index][-1] = DataOffset
 DataOffset += len (BinaryData)
+else:
+del MultiImage[Index]
 libfdt.fdt_setprop_u32(Fdt, 0, 'size', DataOffset)
 posix_time = int(time.time())
 libfdt.fdt_setprop_u32(Fdt, 0, 'timestamp', posix_time)
diff --git a/UefiPayloadPkg/UniversalPayloadBuild.py 
b/UefiPayloadPkg/UniversalPayloadBuild.py
index 6f57fa6df6..046c62e21c 100644
--- a/UefiPayloadPkg/UniversalPayloadBuild.py
+++ b/UefiPayloadPkg/UniversalPayloadBuild.py
@@ -146,16 +146,6 @@ def BuildUniversalPayload(Args):
 ModuleReportPath = os.path.join(BuildDir, "UefiUniversalPayloadEntry.txt")
 UpldInfoFile = os.path.join(BuildDir, "UniversalPayloadInfo.bin")
 
-if "CLANG_BIN" in os.environ:
-LlvmObjcopyPath = os.path.join(os.environ["CLANG_BIN"], "llvm-objcopy")
-else:
-LlvmObjcopyPath = "llvm-objcopy"
-try:
-RunCommand('"%s" --version'%LlvmObjcopyPath)
-except:
-print("- Failed - Please check if LLVM is installed or if CLANG_BIN is 
set correctly")
-sys.exit(1)
-
 Pcds = ""
 if (Args.pcd != None):
 for PcdItem in Args.pcd:
-- 
2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110110): https://edk2.groups.io/g/devel/message/110110
Mute This Topic: https://groups.io/mt/102201551/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Peter Maydell 
On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
> On 10/10/23 09:43, Ard Biesheuvel wrote:
> > Thanks for looking into this - a cleanup was overdue here.
> >
> > I will take a look in more detail later, but one thing that occurred
> > to me when reading this overview is that having a separate DEBUG
> > serial port would permit us to
> >
> > a) remove it from the DT
>
> ... as in, hide it from Linux, I assume?
>
> > b) add a runtime mapping for it
> > c) keep using it after ExitBootServices
> >
> > This could be useful for debugging issues with the variable store etc.
> >
> > Not saying this is something to address in this series, but I'd like
> > to hear your take on this.
> >
>
> Sounds like a useful feature.
>
> I see four challenges:
>
>
> (1) We'd have to coordinate it with Peter. If we hide any one of the
> serial ports from Linux, that may not be what QEMU intends for Linux to
> happen. Linux currently ties getties to all serial ports -- via the
> serial* aliases, IIUC. Thus, some "positive identification" in the DT
> could be necessary (i.e., that edk2 was welcome to hide that port from
> Linux).

The potential awkwardness here is that what the guest thinks about
the serial ports depends on the ACPI table fragments which QEMU
provides. EDK2 would need to edit the table fragment to remove any
mention of the second UART if it wanted to hide it from the kernel.
I don't know how hard that would be in EDK2.

(As far as I'm aware usually a boot via EDK2 doesn't pass the
dtb on to Linux, though I guess there's no reason it can't.)

>From QEMU's point of view, we provide two UARTs to the guest, and we
don't really care whether that means one is used by EDK2 and one by
Linux, or both are used as getty terminals by Linux, or whether the
Linux guest uses one serial as a terminal and leaves the other to its
userspace programs  -- it's all just guest software to us :-)

[snip other technical stuff]

> All in all, I think the implementation would be quite a steep divergence
> from, or on top of, this patch set. :)

I agree with this and with Ard's "not something to address in this
series" comment above; it doesn't sound like this is something that
needs to hold up the patchset we have currently.

Does anybody have time to review Laszlo's code? It would be nice
to be able to get this into the next EDK2 release.

thanks
-- PMM


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

[edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

2023-10-26 Thread jacopo . r00ta 
Hi there,

I was trying to HTTPs boot a virtual machine with the following scenario:

1) I have a self signed root CA root.crt and then I use it to sign another self 
signed certificate myip.crt for the IP address X.X.X.X
2) I have an NGINX server configured to use SSL with the myip.crt certificate 
and its key.
3) I have a UEFI virtual machine configured to HTTPs boot and trust the CA 
certificate root.crt.

Unfortunately the machine fails in the SSL handshake step and then the UEFI 
config page is shown again. Using for example curl --cacert root.crt X.X.X.X it 
works perfectly fine (also forcing curl to use tls 1.2).

In addition to that, if I do not use a root certificate for the server's IP 
(i.e. I do not build a chain of certificates), the machine boots fine.

Unfortunately I don't have a physical server to make a real test. Is this a 
missing feature, a bug, or am I doing it completely wrong?

Thank you very much!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110111): https://edk2.groups.io/g/devel/message/110111
Mute This Topic: https://groups.io/mt/102201552/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Ard Biesheuvel 
On Thu, 26 Oct 2023 at 16:46, Julien Grall  wrote:
>
> Hi,
>
> On 26/10/2023 15:21, Peter Maydell wrote:
> > On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:
> >> On 10/10/23 09:43, Ard Biesheuvel wrote:
> >>> Thanks for looking into this - a cleanup was overdue here.
> >>>
> >>> I will take a look in more detail later, but one thing that occurred
> >>> to me when reading this overview is that having a separate DEBUG
> >>> serial port would permit us to
> >>>
> >>> a) remove it from the DT
> >>
> >> ... as in, hide it from Linux, I assume?
> >>
> >>> b) add a runtime mapping for it
> >>> c) keep using it after ExitBootServices
> >>>
> >>> This could be useful for debugging issues with the variable store etc.
> >>>
> >>> Not saying this is something to address in this series, but I'd like
> >>> to hear your take on this.
> >>>
> >>
> >> Sounds like a useful feature.
> >>
> >> I see four challenges:
> >>
> >>
> >> (1) We'd have to coordinate it with Peter. If we hide any one of the
> >> serial ports from Linux, that may not be what QEMU intends for Linux to
> >> happen. Linux currently ties getties to all serial ports -- via the
> >> serial* aliases, IIUC. Thus, some "positive identification" in the DT
> >> could be necessary (i.e., that edk2 was welcome to hide that port from
> >> Linux).
> >
> > The potential awkwardness here is that what the guest thinks about
> > the serial ports depends on the ACPI table fragments which QEMU
> > provides. EDK2 would need to edit the table fragment to remove any
> > mention of the second UART if it wanted to hide it from the kernel.
> > I don't know how hard that would be in EDK2.
>
> I am not sure if it would help EDK2 in this case. But we had a similar
> problem when adding support for ACPI in Xen. It was not trivial to
> remove the UART from the ACPI tables provided by the host. So we ended
> up to introduce the STAO table [1]. This is used to describe which
> device will be hidden to the OS.
>

I'd much rather have an implementation of the _STA method on those
devices where the underlying AML queries the fwcfg MMIO device


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110108): https://edk2.groups.io/g/devel/message/110108
Mute This Topic: https://groups.io/mt/101834880/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/9] ArmVirtPkg: support two PL011 UARTs

2023-10-26 Thread Julien Grall 

Hi,

On 26/10/2023 15:21, Peter Maydell wrote:

On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek  wrote:

On 10/10/23 09:43, Ard Biesheuvel wrote:

Thanks for looking into this - a cleanup was overdue here.

I will take a look in more detail later, but one thing that occurred
to me when reading this overview is that having a separate DEBUG
serial port would permit us to

a) remove it from the DT


... as in, hide it from Linux, I assume?


b) add a runtime mapping for it
c) keep using it after ExitBootServices

This could be useful for debugging issues with the variable store etc.

Not saying this is something to address in this series, but I'd like
to hear your take on this.



Sounds like a useful feature.

I see four challenges:


(1) We'd have to coordinate it with Peter. If we hide any one of the
serial ports from Linux, that may not be what QEMU intends for Linux to
happen. Linux currently ties getties to all serial ports -- via the
serial* aliases, IIUC. Thus, some "positive identification" in the DT
could be necessary (i.e., that edk2 was welcome to hide that port from
Linux).


The potential awkwardness here is that what the guest thinks about
the serial ports depends on the ACPI table fragments which QEMU
provides. EDK2 would need to edit the table fragment to remove any
mention of the second UART if it wanted to hide it from the kernel.
I don't know how hard that would be in EDK2.


I am not sure if it would help EDK2 in this case. But we had a similar 
problem when adding support for ACPI in Xen. It was not trivial to 
remove the UART from the ACPI tables provided by the host. So we ended 
up to introduce the STAO table [1]. This is used to describe which 
device will be hidden to the OS.


Cheers,

[1] https://wiki.xenproject.org/images/0/02/Status-override-table.pdf

--
Julien Grall


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

[edk2-devel] [edk2-libc Patch 1/1] ek2-libc: realpath function signature doesn't match the standard

2023-10-26 Thread Jayaprakash, N 
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4574

This commit is for processing the below PR on edk2-libc repo
https://github.com/tianocore/edk2-libc/pull/10
The realpath function signature in stdlib of edk2-libc doesn't match
signature as per the standard definition of this function given below
https://pubs.opengroup.org/onlinepubs/009695399/functions/realpath.html
This patch extracted from the above pull request fixes this issue.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Kloper Dimitry 
---
 StdLib/Include/stdlib.h   | 4 ++--
 StdLib/LibC/StdLib/realpath.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Include/stdlib.h b/StdLib/Include/stdlib.h
index 0b9dfd3..022ddbd 100644
--- a/StdLib/Include/stdlib.h
+++ b/StdLib/Include/stdlib.h
@@ -74,7 +74,7 @@
const wchar_t * __restrict src, size_t limit);
 
   Miscelaneous functions for *nix compatibility
-char   *realpath(char *file_name, char *resolved_name);
+char   *realpath(const char *file_name, char *resolved_name);
 const char *getprogname (void);
 voidsetprogname (const char *progname);
 
@@ -875,7 +875,7 @@ size_t  wcstombs(char * __restrict Dest, const wchar_t * 
__restrict Src, size_t
 @retval NULLAn error occured.
 @retval resolved_name.
 **/
-char * realpath(char *file_name, char *resolved_name);
+char * realpath(const char *file_name, char *resolved_name);
 
 /** The getprogname() function returns the name of the program.  If the name
 has not been set yet, it will return NULL.
diff --git a/StdLib/LibC/StdLib/realpath.c b/StdLib/LibC/StdLib/realpath.c
index 3d4118d..29abe9a 100644
--- a/StdLib/LibC/StdLib/realpath.c
+++ b/StdLib/LibC/StdLib/realpath.c
@@ -34,7 +34,7 @@
 **/
 char *
 realpath(
-  char *file_name,
+  const char *file_name,
   char *resolved_name
   )
 {
-- 
2.40.0.windows.1



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

[edk2-devel] [edk2-libc Patch 0/1] realpath function signature doesn't match standard

2023-10-26 Thread Jayaprakash, N 
This patch fixes the function signature of realpath to match with the standard
defined signature. This patch bas been extracted from the  below pull request
raised on edk2-libc. 
https://github.com/tianocore/edk2-libc/pull/10

Jayaprakash N (1):
  ek2-libc: realpath function signature doesn't match the standard

 StdLib/Include/stdlib.h   | 4 ++--
 StdLib/LibC/StdLib/realpath.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.40.0.windows.1



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

[edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-10-26 Thread Neal Gompa 
From: Neal Gompa 

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.

This is especially critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do
rely on the ConsolePrefDxe driver, which only performs console
initialization after ReadyToBoot is triggered.

This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption (), which is the function that sets
up the platform recovery boot process.

The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.

This is a rebased version of the patch originally written by Pete Batard.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831

Cc: Pete Batard 
Cc: Daniel P. Berrangé 
Cc: Gerd Hoffmann 
Cc: Samer El-Haj-Mahmoud 

Co-authored-by: Pete Batard 
Signed-off-by: Neal Gompa 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 2087f0b91d..31ed608817 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1416,6 +1416,15 @@ EfiBootManagerProcessLoadOption (
 return EFI_SUCCESS;
   }
 
+  //
+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled
+  //
+  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
   //
   // Load and start the load option.
   //
-- 
2.41.0



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

Re: [edk2-devel] [Patch V3] UefiCpuPkg/MpInitLib: Wait for all APs to finish initialization

2023-10-26 Thread Laszlo Ersek 
On 10/25/23 13:42, Yuanhao Xie wrote:
> Aim:
> - To solve the assertion that checks if CpuMpData->FinishedCount
> equals (CpuMpData->CpuCount - 1). The assertion arises from a timing
> discrepancy between the BSP's completion of startup signal checks and
> the APs' incrementation of the FinishedCount.
> - This patch also ensures that "finished" reporting from the APs is as
> later as possible.
> 
> More specifially:
> 
> In the SwitchApContext() function, the BSP trigers
> the startup signal and check whether the APs have received it. After
> completing this check, the BSP then verifies if the FinishedCount is
> equal to CpuCount-1.
> 
> On the AP side, upon receiving the startup signal, they invoke
> SwitchContextPerAp() and increase the FinishedCount to indicate their
> activation. However, even when all APs have received the startup signal,
> they might not have finished incrementing the FinishedCount. This timing
> gap results in the triggering of the assertion.
> 
> Solution:
> Instead of assertion, use while loop to waits until all the APs have
> incremented the FinishedCount.
> 
> Fixes: 964a4f032dcd
> 
> Signed-off-by: Yuanhao Xie 
> Cc: Ray Ni 
> Cc: Eric Dong 
> Cc: Rahul Kumar 
> Cc: Tom Lendacky 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 6f1456cfe1..9a6ec5db5c 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -913,8 +913,8 @@ DxeApEntryPoint (
>UINTN  ProcessorNumber;
>  
>GetProcessorNumber (CpuMpData, );
> -  InterlockedIncrement ((UINT32 *)>FinishedCount);
>RestoreVolatileRegisters (>CpuData[0].VolatileRegisters, FALSE);
> +  InterlockedIncrement ((UINT32 *)>FinishedCount);
>PlaceAPInMwaitLoopOrRunLoop (
>  CpuMpData->ApLoopMode,
>  CpuMpData->CpuData[ProcessorNumber].StartupApSignal,
> @@ -2201,7 +2201,12 @@ MpInitLibInitialize (
>// looping process there.
>//
>SwitchApContext (MpHandOff);
> -  ASSERT (CpuMpData->FinishedCount == (CpuMpData->CpuCount - 1));
> +  //
> +  // Wait for all APs finished initialization
> +  //
> +  while (CpuMpData->FinishedCount < (CpuMpData->CpuCount - 1)) {
> +CpuPause ();
> +  }
>  
>//
>// Set Apstate as Idle, otherwise Aps cannot be waken-up again.

https://github.com/tianocore/edk2/pull/4964

(in progress)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110102): https://edk2.groups.io/g/devel/message/110102
Mute This Topic: https://groups.io/mt/102176057/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 V3] UefiCpuPkg/MpInitLib: Wait for all APs to finish initialization

2023-10-26 Thread Laszlo Ersek 
On 10/25/23 13:42, Yuanhao Xie wrote:
> Aim:
> - To solve the assertion that checks if CpuMpData->FinishedCount
> equals (CpuMpData->CpuCount - 1). The assertion arises from a timing
> discrepancy between the BSP's completion of startup signal checks and
> the APs' incrementation of the FinishedCount.
> - This patch also ensures that "finished" reporting from the APs is as
> later as possible.
> 
> More specifially:
> 
> In the SwitchApContext() function, the BSP trigers
> the startup signal and check whether the APs have received it. After
> completing this check, the BSP then verifies if the FinishedCount is
> equal to CpuCount-1.
> 
> On the AP side, upon receiving the startup signal, they invoke
> SwitchContextPerAp() and increase the FinishedCount to indicate their
> activation. However, even when all APs have received the startup signal,
> they might not have finished incrementing the FinishedCount. This timing
> gap results in the triggering of the assertion.
> 
> Solution:
> Instead of assertion, use while loop to waits until all the APs have
> incremented the FinishedCount.
> 
> Fixes: 964a4f032dcd
> 
> Signed-off-by: Yuanhao Xie 
> Cc: Ray Ni 
> Cc: Eric Dong 
> Cc: Rahul Kumar 
> Cc: Tom Lendacky 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 6f1456cfe1..9a6ec5db5c 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -913,8 +913,8 @@ DxeApEntryPoint (
>UINTN  ProcessorNumber;
>  
>GetProcessorNumber (CpuMpData, );
> -  InterlockedIncrement ((UINT32 *)>FinishedCount);
>RestoreVolatileRegisters (>CpuData[0].VolatileRegisters, FALSE);
> +  InterlockedIncrement ((UINT32 *)>FinishedCount);
>PlaceAPInMwaitLoopOrRunLoop (
>  CpuMpData->ApLoopMode,
>  CpuMpData->CpuData[ProcessorNumber].StartupApSignal,
> @@ -2201,7 +2201,12 @@ MpInitLibInitialize (
>// looping process there.
>//
>SwitchApContext (MpHandOff);
> -  ASSERT (CpuMpData->FinishedCount == (CpuMpData->CpuCount - 1));
> +  //
> +  // Wait for all APs finished initialization
> +  //
> +  while (CpuMpData->FinishedCount < (CpuMpData->CpuCount - 1)) {
> +CpuPause ();
> +  }
>  
>//
>// Set Apstate as Idle, otherwise Aps cannot be waken-up again.

Reviewed-by: Laszlo Ersek 

The change is not testable using OVMF, because OVMF (intentionally) uses
ApLoopMode=ApInHltLoop, and in that case, neither hunk is reachable.
(Accordingly, the log message reports WaitLoopExecutionMode as zero.)

I've still regression-tested this change, with my usual configs:

- OVMF IA32 with SMM_REQUIRE, on q35
- OVMF IA32X64 with SMM_REQUIRE, on q35
- OVMF X64 without SMM_REQUIRE, on pc (i440fx)

The test goes like

- boot with 1 cold-plugged plus 2 more hot-pluggable VCPUs
- [*]
- hotplug 2 VCPUs
- [*]
- hot-unplug 2 VCPUs
- [*]
- poweroff

where [*] stands for:
- run efibootmgr, bound to each online VCPU in separation
- ACPI S3 suspend/resume
- run efibootmgr, bound to each online VCPU in separation

I used Fedora and RHEL guests.

So:

Regression-tested-by: Laszlo Ersek 

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110101): https://edk2.groups.io/g/devel/message/110101
Mute This Topic: https://groups.io/mt/102176057/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] question about cxl device enumeration in pci bus driver

2023-10-26 Thread Jonathan Cameron via groups.io 
On Thu, 26 Oct 2023 11:49:28 +0200
"Laszlo Ersek"  wrote:

> On 10/26/23 10:33, Gerd Hoffmann wrote:
> > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote:
> >   
> >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config, 
> >> maybe could be integrated into pci drivers stack.  
> > 
> > Point being?  Can or should the firmware do anything useful with
> > the CXL hardware?  If so, what exactly and why?
> > 
> > Current state of affairs is that the PCI stack does the usual PCI
> > initialization (enumerate, assign resources to PCI bars) and leaves
> > everything else to the OS.  
> 
> (I don't know what "HDM Config" stands for.)
> 
> The only utility for driving CXL devices from the firmware could be, AFAICT:
> 
> - booting off of such a device (or at least "supporting OS boot" in some
> manner)
> 
> - using such a device for UEFI console purposes

There are different models for how to use CXL devices and what's possible 
depends on the
version of CXL.  CXL 1.1 wasn't great for standards defined discovery, so
EDK2 platform logic basically has to do everything.

The one mostly expected for early CXL servers, for backwards compatibility, 
makes
setting up the CXL memory decoders (Host managed Device Memory - HDM) in all the
components in the path to memory + locking them down an EDK2 problem.  They are 
then
presented in the memory map and in SRAT, HMAT etc the same as normal DDR memory.
Idea being that an old OS will be fine with that and doesn't have to be CXL 
aware
at all.  Note this also involves walking the CDAT tables via DOE mailboxes in 
PCI
config space to get the magic numbers needed to compute HMAT.

The other model is to do very little in EDK2 and make entirely a problem for 
the OS.
The logic is necessary anyway if you want to support hotplug etc, so use it for 
the
cold plug paths 2.  That's all we've currently supported on QEMU.

There was a presentation at Linux Plumbers last year on some out of tree support
from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2 
https://lpc.events/event/16/contributions/1254/
But I guess it never went upstream.
https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3

+CC Sayanta

Jonathan
> 
> Laszlo
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller

2023-10-26 Thread Igor Kulchytskyy via groups.io 
Reviewed-by: Igor Kulchytskyy 
Reviewed the whole PATCH

-Original Message-
From: Nickle Wang 
Sent: Thursday, October 26, 2023 9:20 AM
To: Igor Kulchytskyy ; Chang, Abner ; 
devel@edk2.groups.io
Cc: Nick Ramirez 
Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP 
headers to caller

According to my experience, BIOS Redfish is usually the owner to handle Redfish 
task request, not the user to create task. So, I think that BIOS has no chance 
to read HTTP header in DELETE request/response.

But from specification perspective, Redfish task URI can be returned in HTTP 
header in DELETE request.

Regards,
Nickle

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, October 26, 2023 9:09 PM
> To: Nickle Wang ; Chang, Abner
> ; devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
>
> External email: Use caution opening links or attachments
>
>
> You mean, for the Redfish task functionality other functions will be used?
> Thank you,
> Igor
>
> -Original Message-
> From: Nickle Wang 
> Sent: Thursday, October 26, 2023 8:58 AM
> To: Igor Kulchytskyy ; Chang, Abner ;
> devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
>
> Hi Igor,
>
> If the DELETE request to BMC is handled by Redfish task, we need to return 
> HTTP
> header to caller so caller can get Task URI. But from BIOS Redfish 
> perspective, I
> don't see this use case yet.
>
> Thanks,
> Nickle
>
> > -Original Message-
> > From: Igor Kulchytskyy 
> > Sent: Thursday, October 26, 2023 8:50 PM
> > To: Chang, Abner ; Nickle Wang
> > ; devel@edk2.groups.io
> > Cc: Nick Ramirez 
> > Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return
> > HTTP headers to caller
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Nickle,
> > Just one quick question.
> > Is there any sense to return the headers for DELETE request?
> > Thank you,
> > Igor
> >
> > -Original Message-
> > From: Chang, Abner 
> > Sent: Thursday, October 26, 2023 2:10 AM
> > To: Nickle Wang ; devel@edk2.groups.io
> > Cc: Igor Kulchytskyy ; Nick Ramirez
> > 
> > Subject: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> > headers to caller
> >
> >
> > **CAUTION: The e-mail below is from an external source. Please
> > exercise caution before opening attachments, clicking links, or
> > following guidance.**
> >
> > [AMD Official Use Only - General]
> >
> > Reviewed-by: Abner Chang 
> >
> > > -Original Message-
> > > From: Nickle Wang 
> > > Sent: Tuesday, October 24, 2023 4:40 PM
> > > To: devel@edk2.groups.io
> > > Cc: Chang, Abner ; Igor Kulchytskyy
> > > ; Nick Ramirez 
> > > Subject: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to
> > > caller
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > Call Ex interface to get HTTP headers and return to caller.
> > >
> > > Signed-off-by: Nickle Wang 
> > > Cc: Abner Chang 
> > > Cc: Igor Kulchytskyy 
> > > Cc: Nick Ramirez 
> > > ---
> > >  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > index f4045044829a..5e06d516ba84 100644
> > > --- a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > +++ b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > @@ -356,7 +356,7 @@ RedfishGetByUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue= getUriFromService (RedfishService, Uri, 
> > > 
> > > >StatusCode);
> > > +  JsonValue= getUriFromServiceEx (RedfishService, Uri,
> 
> > > >Headers, >HeaderCount, >StatusCode);
> > >RedResponse->Payload = createRedfishPayload (JsonValue,
> > > RedfishService);
> > >
> > >//
> > > @@ -498,10 +498,12 @@ RedfishPatchToUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue = (EDKII_JSON_VALUE)patchUriFromService (
> > > +  JsonValue = (EDKII_JSON_VALUE)patchUriFromServiceEx (
> > >RedfishService,
> > >Uri,
> > >Content,
> > > +  &(RedResponse->Headers),
> > > +  &(RedResponse->HeaderCount),
> > >&(RedResponse->StatusCode)
> > >);
> > >
> > > @@ -661,12 +663,14 @@ RedfishPostToUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue = (EDKII_JSON_VALUE)postUriFromService (
> > > +  JsonValue =

Re: [edk2-devel] [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller

2023-10-26 Thread Nickle Wang via groups.io 
According to my experience, BIOS Redfish is usually the owner to handle Redfish 
task request, not the user to create task. So, I think that BIOS has no chance 
to read HTTP header in DELETE request/response. 

But from specification perspective, Redfish task URI can be returned in HTTP 
header in DELETE request.

Regards,
Nickle

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, October 26, 2023 9:09 PM
> To: Nickle Wang ; Chang, Abner
> ; devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
> 
> External email: Use caution opening links or attachments
> 
> 
> You mean, for the Redfish task functionality other functions will be used?
> Thank you,
> Igor
> 
> -Original Message-
> From: Nickle Wang 
> Sent: Thursday, October 26, 2023 8:58 AM
> To: Igor Kulchytskyy ; Chang, Abner ;
> devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
> 
> Hi Igor,
> 
> If the DELETE request to BMC is handled by Redfish task, we need to return 
> HTTP
> header to caller so caller can get Task URI. But from BIOS Redfish 
> perspective, I
> don't see this use case yet.
> 
> Thanks,
> Nickle
> 
> > -Original Message-
> > From: Igor Kulchytskyy 
> > Sent: Thursday, October 26, 2023 8:50 PM
> > To: Chang, Abner ; Nickle Wang
> > ; devel@edk2.groups.io
> > Cc: Nick Ramirez 
> > Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return
> > HTTP headers to caller
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Nickle,
> > Just one quick question.
> > Is there any sense to return the headers for DELETE request?
> > Thank you,
> > Igor
> >
> > -Original Message-
> > From: Chang, Abner 
> > Sent: Thursday, October 26, 2023 2:10 AM
> > To: Nickle Wang ; devel@edk2.groups.io
> > Cc: Igor Kulchytskyy ; Nick Ramirez
> > 
> > Subject: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> > headers to caller
> >
> >
> > **CAUTION: The e-mail below is from an external source. Please
> > exercise caution before opening attachments, clicking links, or
> > following guidance.**
> >
> > [AMD Official Use Only - General]
> >
> > Reviewed-by: Abner Chang 
> >
> > > -Original Message-
> > > From: Nickle Wang 
> > > Sent: Tuesday, October 24, 2023 4:40 PM
> > > To: devel@edk2.groups.io
> > > Cc: Chang, Abner ; Igor Kulchytskyy
> > > ; Nick Ramirez 
> > > Subject: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to
> > > caller
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > Call Ex interface to get HTTP headers and return to caller.
> > >
> > > Signed-off-by: Nickle Wang 
> > > Cc: Abner Chang 
> > > Cc: Igor Kulchytskyy 
> > > Cc: Nick Ramirez 
> > > ---
> > >  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > index f4045044829a..5e06d516ba84 100644
> > > --- a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > +++ b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > > @@ -356,7 +356,7 @@ RedfishGetByUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue= getUriFromService (RedfishService, Uri, 
> > > 
> > > >StatusCode);
> > > +  JsonValue= getUriFromServiceEx (RedfishService, Uri,
> 
> > > >Headers, >HeaderCount, >StatusCode);
> > >RedResponse->Payload = createRedfishPayload (JsonValue,
> > > RedfishService);
> > >
> > >//
> > > @@ -498,10 +498,12 @@ RedfishPatchToUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue = (EDKII_JSON_VALUE)patchUriFromService (
> > > +  JsonValue = (EDKII_JSON_VALUE)patchUriFromServiceEx (
> > >RedfishService,
> > >Uri,
> > >Content,
> > > +  &(RedResponse->Headers),
> > > +  &(RedResponse->HeaderCount),
> > >&(RedResponse->StatusCode)
> > >);
> > >
> > > @@ -661,12 +663,14 @@ RedfishPostToUri (
> > >
> > >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> > >
> > > -  JsonValue = (EDKII_JSON_VALUE)postUriFromService (
> > > +  JsonValue = (EDKII_JSON_VALUE)postUriFromServiceEx (
> > >RedfishService,
> > >Uri,
> > >Content,
> > >ContentSize,
> > >ContentType,
> > > +

Re: [edk2-devel] [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller

2023-10-26 Thread Igor Kulchytskyy via groups.io 
You mean, for the Redfish task functionality other functions will be used?
Thank you,
Igor

-Original Message-
From: Nickle Wang 
Sent: Thursday, October 26, 2023 8:58 AM
To: Igor Kulchytskyy ; Chang, Abner ; 
devel@edk2.groups.io
Cc: Nick Ramirez 
Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP 
headers to caller

Hi Igor,

If the DELETE request to BMC is handled by Redfish task, we need to return HTTP 
header to caller so caller can get Task URI. But from BIOS Redfish perspective, 
I don't see this use case yet.

Thanks,
Nickle

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, October 26, 2023 8:50 PM
> To: Chang, Abner ; Nickle Wang
> ; devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
>
> External email: Use caution opening links or attachments
>
>
> Hi Nickle,
> Just one quick question.
> Is there any sense to return the headers for DELETE request?
> Thank you,
> Igor
>
> -Original Message-
> From: Chang, Abner 
> Sent: Thursday, October 26, 2023 2:10 AM
> To: Nickle Wang ; devel@edk2.groups.io
> Cc: Igor Kulchytskyy ; Nick Ramirez 
> Subject: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
>
>
> **CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.**
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Abner Chang 
>
> > -Original Message-
> > From: Nickle Wang 
> > Sent: Tuesday, October 24, 2023 4:40 PM
> > To: devel@edk2.groups.io
> > Cc: Chang, Abner ; Igor Kulchytskyy
> > ; Nick Ramirez 
> > Subject: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to
> > caller
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > Call Ex interface to get HTTP headers and return to caller.
> >
> > Signed-off-by: Nickle Wang 
> > Cc: Abner Chang 
> > Cc: Igor Kulchytskyy 
> > Cc: Nick Ramirez 
> > ---
> >  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > index f4045044829a..5e06d516ba84 100644
> > --- a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > +++ b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > @@ -356,7 +356,7 @@ RedfishGetByUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue= getUriFromService (RedfishService, Uri, 
> > 
> > >StatusCode);
> > +  JsonValue= getUriFromServiceEx (RedfishService, Uri, 
> > 
> > >Headers, >HeaderCount, >StatusCode);
> >RedResponse->Payload = createRedfishPayload (JsonValue,
> > RedfishService);
> >
> >//
> > @@ -498,10 +498,12 @@ RedfishPatchToUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue = (EDKII_JSON_VALUE)patchUriFromService (
> > +  JsonValue = (EDKII_JSON_VALUE)patchUriFromServiceEx (
> >RedfishService,
> >Uri,
> >Content,
> > +  &(RedResponse->Headers),
> > +  &(RedResponse->HeaderCount),
> >&(RedResponse->StatusCode)
> >);
> >
> > @@ -661,12 +663,14 @@ RedfishPostToUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue = (EDKII_JSON_VALUE)postUriFromService (
> > +  JsonValue = (EDKII_JSON_VALUE)postUriFromServiceEx (
> >RedfishService,
> >Uri,
> >Content,
> >ContentSize,
> >ContentType,
> > +  &(RedResponse->Headers),
> > +  &(RedResponse->HeaderCount),
> >&(RedResponse->StatusCode)
> >);
> >
> > --
> > 2.17.1
>
> -The information contained in this message may be confidential and proprietary
> to American Megatrends (AMI). This communication is intended to be read only 
> by
> the individual or entity to whom it is addressed or by their designee. If the 
> reader
> of this message is not the intended recipient, you are on notice that any
> distribution of this message, in any form, is strictly prohibited. Please 
> promptly
> notify the sender by reply e-mail or by telephone at 770-246-8600, and then
> delete or destroy all copies of the transmission.
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This

Re: [edk2-devel] [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller

2023-10-26 Thread Nickle Wang via groups.io 
Hi Igor,

If the DELETE request to BMC is handled by Redfish task, we need to return HTTP 
header to caller so caller can get Task URI. But from BIOS Redfish perspective, 
I don't see this use case yet.

Thanks,
Nickle

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, October 26, 2023 8:50 PM
> To: Chang, Abner ; Nickle Wang
> ; devel@edk2.groups.io
> Cc: Nick Ramirez 
> Subject: RE: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Nickle,
> Just one quick question.
> Is there any sense to return the headers for DELETE request?
> Thank you,
> Igor
> 
> -Original Message-
> From: Chang, Abner 
> Sent: Thursday, October 26, 2023 2:10 AM
> To: Nickle Wang ; devel@edk2.groups.io
> Cc: Igor Kulchytskyy ; Nick Ramirez 
> Subject: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP
> headers to caller
> 
> 
> **CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.**
> 
> [AMD Official Use Only - General]
> 
> Reviewed-by: Abner Chang 
> 
> > -Original Message-
> > From: Nickle Wang 
> > Sent: Tuesday, October 24, 2023 4:40 PM
> > To: devel@edk2.groups.io
> > Cc: Chang, Abner ; Igor Kulchytskyy
> > ; Nick Ramirez 
> > Subject: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to
> > caller
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > Call Ex interface to get HTTP headers and return to caller.
> >
> > Signed-off-by: Nickle Wang 
> > Cc: Abner Chang 
> > Cc: Igor Kulchytskyy 
> > Cc: Nick Ramirez 
> > ---
> >  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > index f4045044829a..5e06d516ba84 100644
> > --- a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > +++ b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> > @@ -356,7 +356,7 @@ RedfishGetByUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue= getUriFromService (RedfishService, Uri, 
> > 
> > >StatusCode);
> > +  JsonValue= getUriFromServiceEx (RedfishService, Uri, 
> > 
> > >Headers, >HeaderCount, >StatusCode);
> >RedResponse->Payload = createRedfishPayload (JsonValue,
> > RedfishService);
> >
> >//
> > @@ -498,10 +498,12 @@ RedfishPatchToUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue = (EDKII_JSON_VALUE)patchUriFromService (
> > +  JsonValue = (EDKII_JSON_VALUE)patchUriFromServiceEx (
> >RedfishService,
> >Uri,
> >Content,
> > +  &(RedResponse->Headers),
> > +  &(RedResponse->HeaderCount),
> >&(RedResponse->StatusCode)
> >);
> >
> > @@ -661,12 +663,14 @@ RedfishPostToUri (
> >
> >ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
> >
> > -  JsonValue = (EDKII_JSON_VALUE)postUriFromService (
> > +  JsonValue = (EDKII_JSON_VALUE)postUriFromServiceEx (
> >RedfishService,
> >Uri,
> >Content,
> >ContentSize,
> >ContentType,
> > +  &(RedResponse->Headers),
> > +  &(RedResponse->HeaderCount),
> >&(RedResponse->StatusCode)
> >);
> >
> > --
> > 2.17.1
> 
> -The information contained in this message may be confidential and proprietary
> to American Megatrends (AMI). This communication is intended to be read only 
> by
> the individual or entity to whom it is addressed or by their designee. If the 
> reader
> of this message is not the intended recipient, you are on notice that any
> distribution of this message, in any form, is strictly prohibited. Please 
> promptly
> notify the sender by reply e-mail or by telephone at 770-246-8600, and then
> delete or destroy all copies of the transmission.


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

Re: [edk2-devel] [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller

2023-10-26 Thread Igor Kulchytskyy via groups.io 
Hi Nickle,
Just one quick question.
Is there any sense to return the headers for DELETE request?
Thank you,
Igor

-Original Message-
From: Chang, Abner 
Sent: Thursday, October 26, 2023 2:10 AM
To: Nickle Wang ; devel@edk2.groups.io
Cc: Igor Kulchytskyy ; Nick Ramirez 
Subject: [EXTERNAL] RE: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers 
to caller


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Nickle Wang 
> Sent: Tuesday, October 24, 2023 4:40 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Igor Kulchytskyy
> ; Nick Ramirez 
> Subject: [PATCH 3/3] RedfishPkg/RedfishLib: return HTTP headers to caller
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Call Ex interface to get HTTP headers and return to caller.
>
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> ---
>  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> index f4045044829a..5e06d516ba84 100644
> --- a/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> +++ b/RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> @@ -356,7 +356,7 @@ RedfishGetByUri (
>
>ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
>
> -  JsonValue= getUriFromService (RedfishService, Uri, 
> 
> >StatusCode);
> +  JsonValue= getUriFromServiceEx (RedfishService, Uri, 
> 
> >Headers, >HeaderCount, >StatusCode);
>RedResponse->Payload = createRedfishPayload (JsonValue, RedfishService);
>
>//
> @@ -498,10 +498,12 @@ RedfishPatchToUri (
>
>ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
>
> -  JsonValue = (EDKII_JSON_VALUE)patchUriFromService (
> +  JsonValue = (EDKII_JSON_VALUE)patchUriFromServiceEx (
>RedfishService,
>Uri,
>Content,
> +  &(RedResponse->Headers),
> +  &(RedResponse->HeaderCount),
>&(RedResponse->StatusCode)
>);
>
> @@ -661,12 +663,14 @@ RedfishPostToUri (
>
>ZeroMem (RedResponse, sizeof (REDFISH_RESPONSE));
>
> -  JsonValue = (EDKII_JSON_VALUE)postUriFromService (
> +  JsonValue = (EDKII_JSON_VALUE)postUriFromServiceEx (
>RedfishService,
>Uri,
>Content,
>ContentSize,
>ContentType,
> +  &(RedResponse->Headers),
> +  &(RedResponse->HeaderCount),
>&(RedResponse->StatusCode)
>);
>
> --
> 2.17.1

-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110095): https://edk2.groups.io/g/devel/message/110095
Mute This Topic: https://groups.io/mt/102154017/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] MdePkg/Include: Definitions of IPMI Get System Interface Capabilities

2023-10-26 Thread Nickle Wang via groups.io 


Reviewed-by: Nickle Wang 

Regards,
Nickle

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang, Abner
> via groups.io
> Sent: Tuesday, October 10, 2023 4:36 PM
> To: devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Michael D
> Kinney ; Liming Gao ;
> Zhiguang Liu 
> Subject: [edk2-devel] [PATCH 1/2] MdePkg/Include: Definitions of IPMI Get
> System Interface Capabilities
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> From: Abner Chang 
> 
> Define the structure for IPMI Get System Interface Capabilities command (0x57)
> 
> Signed-off-by: Abner Chang 
> Cc: Abdul Lateef Attar 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/IndustryStandard/IpmiNetFnApp.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> index b6bc91f46c2..d973b7155b3 100644
> --- a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> +++ b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> @@ -1092,6 +1092,14 @@ typedef struct {
>UINT8  InputMaxMsgSize;
>  } IPMI_GET_SYSTEM_INTERFACE_KCS_SMIC_CAPABILITIES_RESPONSE;
> 
> +//
> +// Response of interface capability of SSIF/KCS/SMIC.
> +//
> +typedef union {
> +  IPMI_GET_SYSTEM_INTERFACE_SSIF_CAPABILITIES_RESPONSE
> *InterfaceSsifCapability;
> +  IPMI_GET_SYSTEM_INTERFACE_KCS_SMIC_CAPABILITIES_RESPONSE
> +*InterfaceKcsSmicCapability; }
> +IPMI_GET_SYSTEM_INTERFACE_CAPABILITIES_RESPONSE;
> +
>  //
>  //  Definitions for Get System Interface Capabilities command SSIF 
> transaction
> support  //
> --
> 2.37.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110094): https://edk2.groups.io/g/devel/message/110094
Mute This Topic: https://groups.io/mt/101870986/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] MdeModulePkg/Include: API of IPMI Get System Interface Capabilities

2023-10-26 Thread Nickle Wang via groups.io 


Reviewed-by: Nickle Wang 

Regards,
Nickle

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang, Abner
> via groups.io
> Sent: Tuesday, October 10, 2023 4:36 PM
> To: devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Jian J Wang
> ; Liming Gao 
> Subject: [edk2-devel] [PATCH 2/2] MdeModulePkg/Include: API of IPMI Get
> System Interface Capabilities
> 
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
> 
> 
> From: Abner Chang 
> 
> Define the API for IPMI Get System Interface
> Capabilities command (0x57)
> 
> Signed-off-by: Abner Chang 
> Cc: Abdul Lateef Attar 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> ---
>  MdeModulePkg/Include/Library/IpmiCommandLib.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/MdeModulePkg/Include/Library/IpmiCommandLib.h
> b/MdeModulePkg/Include/Library/IpmiCommandLib.h
> index 7edaf36cbe5..a84124c01e9 100644
> --- a/MdeModulePkg/Include/Library/IpmiCommandLib.h
> +++ b/MdeModulePkg/Include/Library/IpmiCommandLib.h
> @@ -249,6 +249,23 @@ IpmiGetChannelInfo (
>OUT UINT32  *GetChannelInfoResponseSize
>);
> 
> +/**
> +  This function gets system interface capability
> +
> +  @param[in]  InterfaceCapabilityRequestGet system interface capability
> request.
> +  @param[out] InterfaceCapabilityResponse   The response of system interface
> capability.
> +
> +  @retval EFI_SUCCESSCommand is sent successfully.
> +  @retval Other  Failure.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +IpmiGetSystemInterfaceCapability (
> +  IN  IPMI_GET_SYSTEM_INTERFACE_CAPABILITIES_REQUEST
> *InterfaceCapabilityRequest,
> +  OUT IPMI_GET_SYSTEM_INTERFACE_CAPABILITIES_RESPONSE
> *InterfaceCapabilityResponse
> +  );
> +
>  //
>  // IPMI NetFnTransport
>  //
> --
> 2.37.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110093): https://edk2.groups.io/g/devel/message/110093
Mute This Topic: https://groups.io/mt/102198829/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 11/11] DynamicTablesPkg: Remove check for _CPC field

2023-10-26 Thread Leif Lindholm 
On Wed, Oct 25, 2023 at 13:25:40 +0200, pierre.gond...@arm.com wrote:
> From: Pierre Gondois 
> 
> When generating _CPC objects, some fields are mandatory.

Mandatory by spec or mandatory by current API?
If the former, could we either warn or add a Pcd to enable the more
lenient behaviour?

/
Leif

> Some fields cannot be supported by a the Juno platform, which is used
> to test the _CPC generation. Therefore, don't prevent from generating
> _CPC objects if the fields below are missing, and let the OS handle
> the missing information.
> 
> _CPC fields that are exempted from checks:
> - PerformanceLimitedRegister
> - ReferencePerformanceCounterRegister
> - DeliveredPerformanceCounterRegister
> 
> Signed-off-by: Pierre Gondois 
> ---
>  .../Common/AmlLib/CodeGen/AmlCodeGen.c| 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
> b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> index f350083b148c..423e64f12606 100644
> --- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> +++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> @@ -3531,6 +3531,11 @@ AmlCreateCpcNode (
>  return EFI_INVALID_PARAMETER;
>}
>  
> +  // The following fields are theoretically mandatory, but not supported
> +  // by some platforms. Don't check them:
> +  // - PerformanceLimitedRegister
> +  // - ReferencePerformanceCounterRegister
> +  // - DeliveredPerformanceCounterRegister
>if ((IsNullGenericAddress (>HighestPerformanceBuffer) &&
> (CpcInfo->HighestPerformanceInteger == 0)) ||
>(IsNullGenericAddress (>NominalPerformanceBuffer) &&
> @@ -3539,13 +3544,19 @@ AmlCreateCpcNode (
> (CpcInfo->LowestNonlinearPerformanceInteger == 0)) ||
>(IsNullGenericAddress (>LowestPerformanceBuffer) &&
> (CpcInfo->LowestPerformanceInteger == 0)) ||
> -  IsNullGenericAddress (>DesiredPerformanceRegister) ||
> -  IsNullGenericAddress (>ReferencePerformanceCounterRegister) ||
> -  IsNullGenericAddress (>DeliveredPerformanceCounterRegister) ||
> -  IsNullGenericAddress (>PerformanceLimitedRegister))
> +  IsNullGenericAddress (>DesiredPerformanceRegister))
>{
>  ASSERT (0);
>  return EFI_INVALID_PARAMETER;
> +  } else if ((IsNullGenericAddress (>HighestPerformanceBuffer) &&
> +  (CpcInfo->HighestPerformanceInteger == 0)) ||
> + (IsNullGenericAddress (>NominalPerformanceBuffer) &&
> +  (CpcInfo->NominalPerformanceInteger == 0)))
> +  {
> +DEBUG ((
> +  DEBUG_WARN,
> +  "Missing Reference|Delivered performance field in _CPC object\n"
> +  ));
>}
>  
>CpcPackage = NULL;
> -- 
> 2.25.1
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110092): https://edk2.groups.io/g/devel/message/110092
Mute This Topic: https://groups.io/mt/102175822/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 10/11] DynamicTablesPkg: Add ArmScmiInfoLib

2023-10-26 Thread Leif Lindholm 
On Wed, Oct 25, 2023 at 13:25:39 +0200, PierreGondois wrote:
> From: Pierre Gondois 
> 
> The SCP holds some power information that could be advertised
> through the _CPC object. The communication with the SCP is done
> through SCMI protocols (c.f. ArmScmiDxe).
> 
> Use the SCMI protocols to query information and feed it to
> the DynamicTablesPkg.

Couple of questions:
With a generic name like ArmScmiInfoLib, does is belong in ArmPkg or
MdeModulePkg?

Or if it's more tightly integrated with DynamicTablesPkg (not
blatantly obvious from a quick skim below), should that be reflected
by the library name?

/
Leif

> Signed-off-by: Pierre Gondois 
> ---
>  DynamicTablesPkg/DynamicTables.dsc.inc|   1 +
>  DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
>  DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
>  .../Include/Library/ArmScmiInfoLib.h  |  33 ++
>  .../Library/ArmScmiInfoLib/ArmScmiInfoLib.c   | 294 ++
>  .../Library/ArmScmiInfoLib/ArmScmiInfoLib.inf |  31 ++
>  6 files changed, 363 insertions(+)
>  create mode 100644 DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
>  create mode 100644 DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c
>  create mode 100644 DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
> 
> diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
> b/DynamicTablesPkg/DynamicTables.dsc.inc
> index 9d4312c4e87d..be40ebc4b472 100644
> --- a/DynamicTablesPkg/DynamicTables.dsc.inc
> +++ b/DynamicTablesPkg/DynamicTables.dsc.inc
> @@ -15,6 +15,7 @@ [BuildOptions]
>  [LibraryClasses.common]
>
> AcpiHelperLib|DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>AmlLib|DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
> +  ArmScmiInfoLib|DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
>
> SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
>
> SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
>
> TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
> b/DynamicTablesPkg/DynamicTablesPkg.dec
> index cfbcbb9569f1..26498e5fec53 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dec
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dec
> @@ -42,6 +42,9 @@ [LibraryClasses]
>##  @libraryclass  Defines a set of SMBIOS string helper methods.
>SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
>  
> +  ##  @libraryclass  Defines a set of APIs to populate CmObj using SCMI.
> +  ArmScmiInfoLib|Include/Library/ArmScmiInfoLib.h
> +
>  [Protocols]
># Configuration Manager Protocol GUID
>gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82, 0x4894, { 
> 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc 
> b/DynamicTablesPkg/DynamicTablesPkg.dsc
> index bd5084a9008f..6ea86c9efdb0 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dsc
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
> @@ -39,6 +39,7 @@ [LibraryClasses.ARM, LibraryClasses.AARCH64]
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
>  [Components.common]
> +  DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
>DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
>DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
> diff --git a/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h 
> b/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
> new file mode 100644
> index ..8d3fb31df13c
> --- /dev/null
> +++ b/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
> @@ -0,0 +1,33 @@
> +/** @file
> +  Arm SCMI Info Library.
> +
> +  Copyright (c) 2022 - 2023, Arm Limited. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef ARM_SCMI_INFO_LIB_H_
> +#define ARM_SCMI_INFO_LIB_H_
> +
> +#include 
> +
> +/** Populate a AML_CPC_INFO object based on SCMI information.
> +
> +  @param[in]  DomainIdIdentifier for the performance domain.
> +  @param[out] CpcInfo If success, this structure was populated from
> +  information queried to the SCP.
> +
> +  @retval EFI_SUCCESS Success.
> +  @retval EFI_DEVICE_ERRORDevice error.
> +  @retval EFI_INVALID_PARAMETER   Invalid parameter.
> +  @retval EFI_TIMEOUT Time out.
> +  @retval EFI_UNSUPPORTED Unsupported.
> +**/
> +EFI_STATUS
> +EFIAPI
> +ArmScmiInfoGetFastChannel (
> +  IN  UINT32DomainId,
> +  OUT AML_CPC_INFO  *CpcInfo
> +  );
> +
> +#endif // ARM_SCMI_INFO_LIB_H_
> diff --git a/DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c 
> b/DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c
> new file mode 100644
> index ..c23bff63bb6f
> --- /dev/null
> +++

  1   2   >