date:20231004

Re: [edk2-devel] [PATCH v2] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Sunil V L

On Wed, Oct 04, 2023 at 11:34:26AM -0700, Tuan Phan wrote:
> Introduce a PCD to control the maximum SATP mode that MMU allowed
> to use. This PCD helps RISC-V platform set bare or minimum SATP mode
> during bring up to debug memory map issue.
> 
> Signed-off-by: Tuan Phan 
> Reviewed-by: Dhaval Sharma 
> ---
> Changes:
> V2
> - Changed default mode to SV57 
> 
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
>  UefiCpuPkg/UefiCpuPkg.dec  | 8 
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c 
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 9cca5fc128af..826a1d32a1d4 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,7 +36,7 @@
>  #define PTE_PPN_SHIFT 10
>  #define RISCV_MMU_PAGE_SHIFT  12
>  
> -STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
> SATP_MODE_SV39 };
> +STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
> SATP_MODE_SV39, SATP_MODE_OFF };
>  STATIC UINTN  mMaxRootTableLevel;
>  STATIC UINTN  mBitPerLevel;
>  STATIC UINTN  mTableEntryCount;
> @@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
>UINTNIndex;
>EFI_STATUS   Status;
>  
> +  if (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>switch (SatpMode) {
>  case SATP_MODE_OFF:
>return EFI_SUCCESS;
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf 
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 9b28a98cb346..51ebe1750e97 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -25,3 +25,6 @@
>  
>  [LibraryClasses]
>BaseLib
> +
> +[Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ## CONSUMES
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index 68473fc640e6..0b5431dbf70a 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -396,6 +396,14 @@
># @Prompt Access to non-SMRAM memory is restricted to reserved, runtime 
> and ACPI NVS type after SmmReadyToLock.
>
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|BOOLEAN|0x3213210F
>  
> +[PcdsFixedAtBuild.RISCV64]
> +  ## Indicate the maximum SATP mode allowed.
> +  #  0 - Bare mode.
> +  #  8 - 39bit mode.
> +  #  9 - 48bit mode.
> +  #  10 - 57bit mode.
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|10|UINT32|0x6021
> +
LGTM. Thanks!

Reviewed-by: Sunil V L 

>  [PcdsDynamic, PcdsDynamicEx]
>## Contains the pointer to a CPU S3 data buffer of structure ACPI_CPU_DATA.
># @Prompt The pointer to a CPU S3 data buffer.
> -- 
> 2.25.1
> 


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

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

2023-10-04 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

> -Original Message-
> From: disc...@edk2.groups.io  On Behalf Of
> Konstantin Aladyshev via groups.io
> Sent: Thursday, October 5, 2023 1:57 AM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io; disc...@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> > That is great, and I'm surprised there are some build errors at your end.
>
> I'm surprised your compiler didn't catch that since it is all basic
> syntax errors.
> I've used your https://github.com/changab/edk2-
> platforms/tree/MCTP_OVER_KCS_UPDATE
> directly.

Ah I know why, I forget to rebuild the changes of both PEC and MCTP EID after I 
verifying the functionality of IPMI on the new KbcCommonLib.c. Yes, I do see 
the build error now and was fixed at my end. My fault.

>
> > How do you think we just send it to the mailing list for review and keep
> working on other problems based on it.?
> > Could you please send the patches out, with you as the author and I'm the
> coauthor?  I will review it again on dev mailing list.
>
> No problem, I can send a patch to the 'edk2-devel' mailing list.
> But before that I think I'll write a test app to check if PLDM
> protocols work correctly.
Ok.

>
> Also earlier I've pointed to a fact that 'MctpSourceEndpointId' and
> 'MctpDestinationEndpointId' aren't actually used in the
> 'MctpSubmitMessage' function.
> EIDs are always taken from the PCDs:
> https://github.com/changab/edk2-
> platforms/blob/1c8d0d3fa403b47a34667f7f690add7822163111/Features/
> ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.
> c#L178
> What can we do about that?
Ah yes, we should update the algorithm, it is done here: 
https://github.com/changab/edk2-platforms/tree/MCTP_OVER_KCS_UPDATE. You have 
to update your code here: 
https://github.com/Kostr/PLDM/blob/master/PldmMessage/PldmMessage.c
And we also need the fix the typo on edk2, 
https://github.com/changab/edk2/tree/MCTP_OVER_KCS_UPDATE

>
> > Btw, how long do you think I would take to merge your changes on
> openBMC?
>
> So as I've described in the https://github.com/Kostr/PLDM/tree/master
> there are basically 2 approaches for the MCTP stack in OpenBMC:
> (1) userspace approach (legacy, shouldn't be really used now)
> (2) kernel approach
>
> It is hard to tell if OpenBMC patches for the (1) approach will be
> merged. Since I've developed the Linux kernel driver (2) nobody really
> cares about (1).
>
> For the (2) there are a couple of OpenBMC patches which I've helped to
> develop, but I'm just a coathor in them. So it is hard for me to tell
> when they would be merged. For me it looks like they are mostly ready:
> 66591: transport: af-mctp: Add pldm_transport_af_mctp_bind() |
> https://gerrit.openbmc.org/c/openbmc/libpldm/+/66591
> 63652: pldm: Convert to using libpldm transport APIs |
> https://gerrit.openbmc.org/c/openbmc/pldm/+/63652
>
> For the (2) I also need to push the mctp Linux kernel driver upstream.
> Linux kernel development is not what I do every day, so I'm not sure
> how long it would take. But I'm pretty determined to finish the work
> and push my driver upstream. Currently there are some questions
> regarding Linux KCS subsystem, so along with the KCS subsystem creator
> we have to figure out how to rewrite the subsystem correctly. So this
> can take some time.
> After the code is pushed to the torvalds/linux, it would be picked up
> by the openbmc/linux automatically.
Ok, I got it. Thanks for the detailed information.

Regards,
Abner

>
> Best regards,
> Konstantin Aladyshev
>
> On Wed, Oct 4, 2023 at 7:12 PM Chang, Abner 
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> >
> > That is great, and I'm surprised there are some build errors at your end.
> > How do you think we just send it to the mailing list for review and keep
> working on other problems based on it.?
> > Could you please send the patches out, with you as the author and I'm the
> coauthor?  I will review it again on dev mailing list.
> >
> > I will take a look on kernal change. Btw, how long do you think I would take
> to merge your changes on openBMC?
> >
> > Thanks
> > Abner
> >
> > Get Outlook for Android
> >
> > 
> > From: Konstantin Aladyshev 
> > Sent: Wednesday, October 4, 2023 11:59:16 PM
> > To: Chang, Abner 
> > Cc: devel@edk2.groups.io ;
> disc...@edk2.groups.io 
> > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
> >
> > Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> >
> >
> > Hi Chang!
> >
> > Thanks!
> > There were a couple of trivial compilation errors, but after I've
> > fixed them everything seems to work fine!
> > Just in case I've tested the OpenBMC side with the mctp Linux kernel
> > driver

Re: [edk2-devel] reg: Two IAID assignment for single MAC Address

2023-10-04 Thread Clark-williams, Zachary

Hello Siva,

When looking into the NetworkPkg Ip6ConfigImpl.c and PxeBcDriver.c we are 
setting the IAID as you stated below, though Ip6ConfigImpl does check if the 
IAID IpSb Instance is already created before it generates its own.

Because the PxeBcDriver creates the Instance and profile first there should not 
be 2 IAID’s during that operational flow.

Thanks,
Zack

From: Sivaraman Nainar 
Sent: Tuesday, October 3, 2023 10:49 AM
To: devel@edk2.groups.io; Kasbekar, Saloni ; 
Clark-williams, Zachary 
Cc: Santhosh Kumar V ; Mike Su (蘇得緣) ; 
Dhanaraj V 
Subject: RE: reg: Two IAID assignment for single MAC Address

+ Saloni and Zachary.

From: Sivaraman Nainar
Sent: Tuesday, October 3, 2023 10:39 PM
To: devel@edk2.groups.io; Maciej Rabeda 
mailto:maciej.rab...@linux.intel.com>>
Cc: Santhosh Kumar V mailto:santhoshkum...@ami.com>>; 
Mike Su (蘇得緣) mailto:mik...@ami.com>>; Dhanaraj V 
mailto:vdhana...@ami.com>>
Subject: reg: Two IAID assignment for single MAC Address

Hello Maciej:

When IPV6 PXE Boot performed in the environment where client and server are 
connected behind Routers, there are two SARR process happens, and both are 
using different IAID’s.

During the PXE Boot IPV6, SARR Process Initiated to get the Boot File 
information. During that time one IAID Created (ff76fdbd). 
PxeBcCreateIp6Children()
During the Router Advertisement , SARR Process Initiated to get the Boot File. 
Ip6ConfigInitInstance()

Besides, according to the definition of 
IA(RFC-3315):

An "identity-association" (IA) is a construct through which a server
and a client can identify, group, and manage a set of related IPv6
addresses. Each IA consists of an IAID and associated configuration
information.

A client must associate at least one distinct IA with each of its
network interfaces for which it is to request the assignment of IPv6
addresses from a DHCP server. The client uses the IAs assigned to an
interface to obtain configuration information from a server for that
interface. Each IA must be associated with exactly one interface.

But as per EDK2 Network Implementation it defines two IA IDs for same client.  
Is there any reasoning behind this implementation?

What if both the process uses Same IAID?

Thanks
Siva
-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 (#109338): https://edk2.groups.io/g/devel/message/109338
Mute This Topic: https://groups.io/mt/101738223/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 3/3] PlatformHookLib: Set PcdSerialClockRate using HOB data

2023-10-04 Thread MrChromebox

Fixes serial output on platforms using coreboot and a non-default
clock rate such as AMD Picasso and newer Zen-based platforms.

Signed-off-by: Matt DeVillier 
Change-Id: I91290397852176754e9a34ec6e5829044f41d15a
---
 UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c   | 5 +
 UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf | 1 +
 2 files changed, 6 insertions(+)

diff --git a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c 
b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
index 60a17b8fc2..e3d47ac2fa 100644
--- a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
+++ b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
@@ -90,6 +90,11 @@ PlatformHookSerialPortInitialize (
   return Status;
 }
 
+Status = PcdSet32S (PcdSerialClockRate, SerialPortInfo->ClockRate);
+if (RETURN_ERROR (Status)) {
+  return Status;
+}
+
 return RETURN_SUCCESS;
   }
 
diff --git a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf 
b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
index 7ac6bfa1b1..e2908cfbca 100644
--- a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
+++ b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
@@ -38,3 +38,4 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase## PRODUCES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate## PRODUCES
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride  ## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate   ## PRODUCES
-- 
2.34.1



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

[edk2-devel] [PATCH 2/3] UefiPayloadEntry: Set serial ClockRate from parsed SerialInfo

2023-10-04 Thread MrChromebox

Extract and use the serial port clock rate provided by coreboot via
the InputHertz field.

Signed-off-by: Matt DeVillier 
Change-Id: If764bd7c0b691cf887205471d0343fdf62372141
---
 UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 030a5baed9..91dfac0d76 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -431,6 +431,7 @@ _ModuleEntryPoint (
 UniversalSerialPort->UseMmio = (SerialPortInfo.Type == 1) ? FALSE 
: TRUE;
 UniversalSerialPort->RegisterBase= SerialPortInfo.BaseAddr;
 UniversalSerialPort->BaudRate= SerialPortInfo.Baud;
+UniversalSerialPort->ClockRate   = SerialPortInfo.InputHertz;
 UniversalSerialPort->RegisterStride  = (UINT8)SerialPortInfo.RegWidth;
   }
 
-- 
2.34.1



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

[edk2-devel] [PATCH 1/3] MdeModulePkg: Add ClockRate field to SerialPortInfo

2023-10-04 Thread MrChromebox

Add the ClockRate field to the UNIVERSAL_PAYLOAD_SERIAL_PORT_INFO
struct, so that the field can be used by UefiPayloadPkg to properly
set up the serial port on boards using a non-standard clock rate.

Signed-off-by: Matt DeVillier 
Change-Id: I9bcaf03ab63f6a45d2cf25a580f7a2eba388cbbd
---
 MdeModulePkg/Include/UniversalPayload/SerialPortInfo.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Include/UniversalPayload/SerialPortInfo.h 
b/MdeModulePkg/Include/UniversalPayload/SerialPortInfo.h
index 3c4459e2c0..e3c9f93654 100644
--- a/MdeModulePkg/Include/UniversalPayload/SerialPortInfo.h
+++ b/MdeModulePkg/Include/UniversalPayload/SerialPortInfo.h
@@ -19,6 +19,7 @@ typedef struct {
   BOOLEAN UseMmio;
   UINT8   RegisterStride;
   UINT32  BaudRate;
+  UINT32  ClockRate;
   EFI_PHYSICAL_ADDRESSRegisterBase;
 } UNIVERSAL_PAYLOAD_SERIAL_PORT_INFO;
 #pragma pack()
-- 
2.34.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Andrei Warkentin

Looks good to me.

Reviewed-by: Andrei Warkentin 


From: Tuan Phan 
Sent: Wednesday, October 4, 2023 1:44 PM
To: devel@edk2.groups.io; Warkentin, Andrei 
Cc: Kinney, Michael D ; Gao, Liming 
; Liu, Zhiguang ; 
suni...@ventanamicro.com; g...@danielschaefer.me; ardb+tianoc...@kernel.org
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for 
SATP mode

https://github.com/pttuan/edk2.git
branch: tphan/riscv_mmu_new_pcd

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Andrei 
Warkentin mailto:andrei.warken...@intel.com>>
Date: Wednesday, October 4, 2023 at 11:42 AM
To: Tuan Phan mailto:tp...@ventanamicro.com>>, 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>, Gao, Liming 
mailto:gaolim...@byosoft.com.cn>>, Liu, Zhiguang 
mailto:zhiguang@intel.com>>, 
suni...@ventanamicro.com 
mailto:suni...@ventanamicro.com>>, 
g...@danielschaefer.me 
mailto:g...@danielschaefer.me>>, 
ardb+tianoc...@kernel.org 
mailto:ardb+tianoc...@kernel.org>>
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for 
SATP mode
Do you happen to have a link to a Github tree?

A

> -Original Message-
> From: Tuan Phan mailto:tp...@ventanamicro.com>>
> Sent: Tuesday, October 3, 2023 4:00 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Gao, Liming
> mailto:gaolim...@byosoft.com.cn>>; Liu, Zhiguang 
> mailto:zhiguang@intel.com>>;
> suni...@ventanamicro.com; 
> g...@danielschaefer.me; Warkentin, Andrei
> mailto:andrei.warken...@intel.com>>; 
> ardb+tianoc...@kernel.org; Tuan Phan
> mailto:tp...@ventanamicro.com>>
> Subject: [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode
>
> Introduce a PCD to control the maximum SATP mode that MMU allowed to
> use. This PCD helps RISC-V platform set bare or minimum SATA mode during
> bring up to debug memory map issue.
>
> Signed-off-by: Tuan Phan 
> mailto:tp...@ventanamicro.com>>
> ---
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
>  UefiCpuPkg/UefiCpuPkg.dec  | 8 
>  3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 9cca5fc128af..826a1d32a1d4 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,7 +36,7 @@
>  #define PTE_PPN_SHIFT 10 #define RISCV_MMU_PAGE_SHIFT  12 -
> STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39 };+STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57,
> SATP_MODE_SV48, SATP_MODE_SV39, SATP_MODE_OFF }; STATIC UINTN
> mMaxRootTableLevel; STATIC UINTN  mBitPerLevel; STATIC UINTN
> mTableEntryCount;@@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
>UINTNIndex;   EFI_STATUS   
> Status; +  if
> (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {+return
> EFI_DEVICE_ERROR;+  }+   switch (SatpMode) { case SATP_MODE_OFF:
> return EFI_SUCCESS;diff --git
> a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 9b28a98cb346..51ebe1750e97 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -25,3 +25,6 @@
>   [LibraryClasses]   BaseLib++[Pcd]+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ##
> CONSUMESdiff --git a/UefiCpuPkg/UefiCpuPkg.dec
> b/UefiCpuPkg/UefiCpuPkg.dec
> index 68473fc640e6..79191af18a05 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -396,6 +396,14 @@
># @Prompt Access to non-SMRAM memory is restricted to reserved,
> runtime and ACPI NVS type after SmmReadyToLock.
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|B
> OOLEAN|0x3213210F +[PcdsFixedAtBuild.RISCV64]+  ## Indicate the
> maximum SATP mode allowed.+  #  0 - Bare mode.+  #  8 - 39bit mode.+  #  9 -
> 48bit mode.+  #  10 - 57bit mode.+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|0|UINT32|0x6
> 021+ [PcdsDynamic, PcdsDynamicEx]   ## Contains the pointer to a CPU
> S3 data buffer of structure ACPI_CPU_DATA.   # @Prompt The pointer to a CPU
> S3 data buffer.--
> 2.25.1






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109334): https://edk2.groups.io/g/devel/message/109334
Mute This Topic: https://groups.io/mt/101742937/21656
Group

Re: [edk2-devel] [PATCH v1 2/2] MdeModulePkg/Bus/Usb/UsbMouseDxe: Fix MISSING_BREAK Coverity issues

2023-10-04 Thread Michael D Kinney

I do not prefer special comments for one static analyzer.

Is there an alternative design/implementation of this code
to make it more readable and not trigger any static analysis
false positives?

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ranbir
> Singh
> Sent: Tuesday, October 3, 2023 10:48 PM
> To: devel@edk2.groups.io; rsi...@ventanamicro.com
> Cc: Wu, Hao A ; Ni, Ray ;
> Veeresh Sangolli 
> Subject: [edk2-devel] [PATCH v1 2/2] MdeModulePkg/Bus/Usb/UsbMouseDxe:
> Fix MISSING_BREAK Coverity issues
> 
> From: Ranbir Singh 
> 
> The function GetNextHidItem has a switch-case code in which the
> case 1: falls through to case 2: and then case 2: falls through
> to case 3: in the block.
> 
> While this may be intentional, it is not evident to any general
> code reader as well as any static analyzer tool. Just adding
> 
> // No break; here as this is an intentional fallthrough.
> 
> as comment in between makes a reader as well as Coverity happy.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4222
> 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Usb/UsbMouseDxe/MouseHid.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Usb/UsbMouseDxe/MouseHid.c
> b/MdeModulePkg/Bus/Usb/UsbMouseDxe/MouseHid.c
> index acc19acd98e0..bc9a4824208b 100644
> --- a/MdeModulePkg/Bus/Usb/UsbMouseDxe/MouseHid.c
> +++ b/MdeModulePkg/Bus/Usb/UsbMouseDxe/MouseHid.c
> @@ -89,6 +89,10 @@ GetNextHidItem (
>return StartPos;
> 
>  }
> 
> 
> 
> +//
> 
> +// No break; here as this is an intentional fallthrough
> 
> +//
> 
> +
> 
>case 2:
> 
>  //
> 
>  // 2-byte data
> 
> @@ -99,6 +103,10 @@ GetNextHidItem (
>return StartPos;
> 
>  }
> 
> 
> 
> +//
> 
> +// No break; here as this is an intentional fallthrough
> 
> +//
> 
> +
> 
>case 3:
> 
>  //
> 
>  // 4-byte data, adjust size
> 
> --
> 2.34.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#109309):
> https://edk2.groups.io/g/devel/message/109309
> Mute This Topic: https://groups.io/mt/101750274/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109333): https://edk2.groups.io/g/devel/message/109333
Mute This Topic: https://groups.io/mt/101750274/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] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Tuan Phan

https://github.com/pttuan/edk2.git
branch: tphan/riscv_mmu_new_pcd

From: devel@edk2.groups.io  on behalf of Andrei Warkentin 

Date: Wednesday, October 4, 2023 at 11:42 AM
To: Tuan Phan , devel@edk2.groups.io 

Cc: Kinney, Michael D , Gao, Liming 
, Liu, Zhiguang , 
suni...@ventanamicro.com , g...@danielschaefer.me 
, ardb+tianoc...@kernel.org 
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for 
SATP mode
Do you happen to have a link to a Github tree?

A

> -Original Message-
> From: Tuan Phan 
> Sent: Tuesday, October 3, 2023 4:00 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> suni...@ventanamicro.com; g...@danielschaefer.me; Warkentin, Andrei
> ; ardb+tianoc...@kernel.org; Tuan Phan
> 
> Subject: [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode
>
> Introduce a PCD to control the maximum SATP mode that MMU allowed to
> use. This PCD helps RISC-V platform set bare or minimum SATA mode during
> bring up to debug memory map issue.
>
> Signed-off-by: Tuan Phan 
> ---
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
>  UefiCpuPkg/UefiCpuPkg.dec  | 8 
>  3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 9cca5fc128af..826a1d32a1d4 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,7 +36,7 @@
>  #define PTE_PPN_SHIFT 10 #define RISCV_MMU_PAGE_SHIFT  12 -
> STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39 };+STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57,
> SATP_MODE_SV48, SATP_MODE_SV39, SATP_MODE_OFF }; STATIC UINTN
> mMaxRootTableLevel; STATIC UINTN  mBitPerLevel; STATIC UINTN
> mTableEntryCount;@@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
>UINTNIndex;   EFI_STATUS   
> Status; +  if
> (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {+return
> EFI_DEVICE_ERROR;+  }+   switch (SatpMode) { case SATP_MODE_OFF:
> return EFI_SUCCESS;diff --git
> a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 9b28a98cb346..51ebe1750e97 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -25,3 +25,6 @@
>   [LibraryClasses]   BaseLib++[Pcd]+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ##
> CONSUMESdiff --git a/UefiCpuPkg/UefiCpuPkg.dec
> b/UefiCpuPkg/UefiCpuPkg.dec
> index 68473fc640e6..79191af18a05 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -396,6 +396,14 @@
># @Prompt Access to non-SMRAM memory is restricted to reserved,
> runtime and ACPI NVS type after SmmReadyToLock.
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|B
> OOLEAN|0x3213210F +[PcdsFixedAtBuild.RISCV64]+  ## Indicate the
> maximum SATP mode allowed.+  #  0 - Bare mode.+  #  8 - 39bit mode.+  #  9 -
> 48bit mode.+  #  10 - 57bit mode.+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|0|UINT32|0x6
> 021+ [PcdsDynamic, PcdsDynamicEx]   ## Contains the pointer to a CPU
> S3 data buffer of structure ACPI_CPU_DATA.   # @Prompt The pointer to a CPU
> S3 data buffer.--
> 2.25.1







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

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Andrei Warkentin

Do you happen to have a link to a Github tree?

A

> -Original Message-
> From: Tuan Phan 
> Sent: Tuesday, October 3, 2023 4:00 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> suni...@ventanamicro.com; g...@danielschaefer.me; Warkentin, Andrei
> ; ardb+tianoc...@kernel.org; Tuan Phan
> 
> Subject: [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode
> 
> Introduce a PCD to control the maximum SATP mode that MMU allowed to
> use. This PCD helps RISC-V platform set bare or minimum SATA mode during
> bring up to debug memory map issue.
> 
> Signed-off-by: Tuan Phan 
> ---
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
>  UefiCpuPkg/UefiCpuPkg.dec  | 8 
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 9cca5fc128af..826a1d32a1d4 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,7 +36,7 @@
>  #define PTE_PPN_SHIFT 10 #define RISCV_MMU_PAGE_SHIFT  12 -
> STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39 };+STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57,
> SATP_MODE_SV48, SATP_MODE_SV39, SATP_MODE_OFF }; STATIC UINTN
> mMaxRootTableLevel; STATIC UINTN  mBitPerLevel; STATIC UINTN
> mTableEntryCount;@@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
>UINTNIndex;   EFI_STATUS   
> Status; +  if
> (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {+return
> EFI_DEVICE_ERROR;+  }+   switch (SatpMode) { case SATP_MODE_OFF:
> return EFI_SUCCESS;diff --git
> a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 9b28a98cb346..51ebe1750e97 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -25,3 +25,6 @@
>   [LibraryClasses]   BaseLib++[Pcd]+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ##
> CONSUMESdiff --git a/UefiCpuPkg/UefiCpuPkg.dec
> b/UefiCpuPkg/UefiCpuPkg.dec
> index 68473fc640e6..79191af18a05 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -396,6 +396,14 @@
># @Prompt Access to non-SMRAM memory is restricted to reserved,
> runtime and ACPI NVS type after SmmReadyToLock.
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|B
> OOLEAN|0x3213210F +[PcdsFixedAtBuild.RISCV64]+  ## Indicate the
> maximum SATP mode allowed.+  #  0 - Bare mode.+  #  8 - 39bit mode.+  #  9 -
> 48bit mode.+  #  10 - 57bit mode.+
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|0|UINT32|0x6
> 021+ [PcdsDynamic, PcdsDynamicEx]   ## Contains the pointer to a CPU
> S3 data buffer of structure ACPI_CPU_DATA.   # @Prompt The pointer to a CPU
> S3 data buffer.--
> 2.25.1



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

[edk2-devel] [PATCH v2] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Tuan Phan

Introduce a PCD to control the maximum SATP mode that MMU allowed
to use. This PCD helps RISC-V platform set bare or minimum SATP mode
during bring up to debug memory map issue.

Signed-off-by: Tuan Phan 
Reviewed-by: Dhaval Sharma 
---
Changes:
V2
- Changed default mode to SV57 

 UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
 UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
 UefiCpuPkg/UefiCpuPkg.dec  | 8 
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c 
b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
index 9cca5fc128af..826a1d32a1d4 100644
--- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
+++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
@@ -36,7 +36,7 @@
 #define PTE_PPN_SHIFT 10
 #define RISCV_MMU_PAGE_SHIFT  12
 
-STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
SATP_MODE_SV39 };
+STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
SATP_MODE_SV39, SATP_MODE_OFF };
 STATIC UINTN  mMaxRootTableLevel;
 STATIC UINTN  mBitPerLevel;
 STATIC UINTN  mTableEntryCount;
@@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
   UINTNIndex;
   EFI_STATUS   Status;
 
+  if (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {
+return EFI_DEVICE_ERROR;
+  }
+
   switch (SatpMode) {
 case SATP_MODE_OFF:
   return EFI_SUCCESS;
diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf 
b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
index 9b28a98cb346..51ebe1750e97 100644
--- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
+++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
@@ -25,3 +25,6 @@
 
 [LibraryClasses]
   BaseLib
+
+[Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ## CONSUMES
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 68473fc640e6..0b5431dbf70a 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -396,6 +396,14 @@
   # @Prompt Access to non-SMRAM memory is restricted to reserved, runtime and 
ACPI NVS type after SmmReadyToLock.
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|BOOLEAN|0x3213210F
 
+[PcdsFixedAtBuild.RISCV64]
+  ## Indicate the maximum SATP mode allowed.
+  #  0 - Bare mode.
+  #  8 - 39bit mode.
+  #  9 - 48bit mode.
+  #  10 - 57bit mode.
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|10|UINT32|0x6021
+
 [PcdsDynamic, PcdsDynamicEx]
   ## Contains the pointer to a CPU S3 data buffer of structure ACPI_CPU_DATA.
   # @Prompt The pointer to a CPU S3 data buffer.
-- 
2.25.1



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

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

2023-10-04 Thread Konstantin Aladyshev

> That is great, and I'm surprised there are some build errors at your end.

I'm surprised your compiler didn't catch that since it is all basic
syntax errors.
I've used your 
https://github.com/changab/edk2-platforms/tree/MCTP_OVER_KCS_UPDATE
directly.

> How do you think we just send it to the mailing list for review and keep 
> working on other problems based on it.?
> Could you please send the patches out, with you as the author and I'm the 
> coauthor?  I will review it again on dev mailing list.

No problem, I can send a patch to the 'edk2-devel' mailing list.
But before that I think I'll write a test app to check if PLDM
protocols work correctly.

Also earlier I've pointed to a fact that 'MctpSourceEndpointId' and
'MctpDestinationEndpointId' aren't actually used in the
'MctpSubmitMessage' function.
EIDs are always taken from the PCDs:
https://github.com/changab/edk2-platforms/blob/1c8d0d3fa403b47a34667f7f690add7822163111/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c#L178
What can we do about that?

> Btw, how long do you think I would take to merge your changes on openBMC?

So as I've described in the https://github.com/Kostr/PLDM/tree/master
there are basically 2 approaches for the MCTP stack in OpenBMC:
(1) userspace approach (legacy, shouldn't be really used now)
(2) kernel approach

It is hard to tell if OpenBMC patches for the (1) approach will be
merged. Since I've developed the Linux kernel driver (2) nobody really
cares about (1).

For the (2) there are a couple of OpenBMC patches which I've helped to
develop, but I'm just a coathor in them. So it is hard for me to tell
when they would be merged. For me it looks like they are mostly ready:
66591: transport: af-mctp: Add pldm_transport_af_mctp_bind() |
https://gerrit.openbmc.org/c/openbmc/libpldm/+/66591
63652: pldm: Convert to using libpldm transport APIs |
https://gerrit.openbmc.org/c/openbmc/pldm/+/63652

For the (2) I also need to push the mctp Linux kernel driver upstream.
Linux kernel development is not what I do every day, so I'm not sure
how long it would take. But I'm pretty determined to finish the work
and push my driver upstream. Currently there are some questions
regarding Linux KCS subsystem, so along with the KCS subsystem creator
we have to figure out how to rewrite the subsystem correctly. So this
can take some time.
After the code is pushed to the torvalds/linux, it would be picked up
by the openbmc/linux automatically.

Best regards,
Konstantin Aladyshev

On Wed, Oct 4, 2023 at 7:12 PM Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
>
> That is great, and I'm surprised there are some build errors at your end.
> How do you think we just send it to the mailing list for review and keep 
> working on other problems based on it.?
> Could you please send the patches out, with you as the author and I'm the 
> coauthor?  I will review it again on dev mailing list.
>
> I will take a look on kernal change. Btw, how long do you think I would take 
> to merge your changes on openBMC?
>
> Thanks
> Abner
>
> Get Outlook for Android
>
> 
> From: Konstantin Aladyshev 
> Sent: Wednesday, October 4, 2023 11:59:16 PM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io ; disc...@edk2.groups.io 
> 
> Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
>
> Caution: This message originated from an External Source. Use proper caution 
> when opening attachments, clicking links, or responding.
>
>
> Hi Chang!
>
> Thanks!
> There were a couple of trivial compilation errors, but after I've
> fixed them everything seems to work fine!
> Just in case I've tested the OpenBMC side with the mctp Linux kernel
> driver approach
> (https://github.com/Kostr/PLDM/tree/master/mctp-kernel)
> The latest kernel patches can be found here:
> https://lore.kernel.org/lkml/20231003131505.337-1-aladyshe...@gmail.com/
>
> Here is a fix for the build errors that I've found:
> ```
> diff --git 
> a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
> b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
> index 79501d27aa..345c6da81a 100644
> --- 
> a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
> +++ 
> b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
> @@ -193,7 +193,7 @@ SetupMctpRequestTransportPacket (
>
>  //
>  // Generate PEC follow SMBUS 2.0 specification.
> -*MctpKcsTrailer->Pec = HelperManageabilityGenerateCrc8
> (MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage,
> MctpKcsHeader->ByteCount);
> +MctpKcsTrailer->Pec = HelperManageabilityGenerateCrc8
> (MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage,
> MctpKcsHeader->ByteCount);
>  *PacketBody= (UINT8 *)ThisPackage;
>  *PacketBodySize= MctpKcsHeader->ByteCount;
>  *PacketTrailer = (MANAGEABILITY_TRANSPORT_TRAILER)MctpKcsTrailer;
> diff --git 
>

Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib

2023-10-04 Thread Taylor Beebe




On 10/4/23 1:46 AM, Gerd Hoffmann wrote:

On Fri, Sep 29, 2023 at 12:52:35PM -0700, Taylor Beebe wrote:

I can also update ArmVirtPkg to disable execution protection
for EfiLoaderData by default until fw_cfg parsing
support is added to ArmVirtPkg. Let me know if you think
this is necessary.

With MemoryProtectionConfigLib adding fw_cfg parsing support to
ArmVirtPkg should be easy, so maybe just do that?


From what I see, the QemuFwCfgLib instance compatible with Arm requires

UefiBootServicesTableLib so fw_cfg cannot be parsed early enough to set

the memory protection policy on ArmVirt.


An Arm compatible PEIM instance of QemuFwCfgLib will need to be created.

I'm happy to look into it, but I don't want to hang up this patch series on

that addition. Instead, I'll set the protection policy for ArmVirtPkg to the

equivalent of the new GrubCompat profile in this series.


Please let me know if I'm missing an obvious route to PEI fw_cfg

parsing on Arm.


-Taylor



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109328): https://edk2.groups.io/g/devel/message/109328
Mute This Topic: https://groups.io/mt/101469960/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] MdePkg/DxeRngLib: Add missing GUID declaration in inf

2023-10-04 Thread Leif Lindholm

On Wed, Oct 04, 2023 at 16:30:44 +0100, Leif Lindholm wrote:
> On Wed, Oct 04, 2023 at 14:56:55 +, Ard Biesheuvel wrote:
> > On Tue, 3 Oct 2023 at 17:22, Leif Lindholm  
> > wrote:
> > >
> > > +Zhiguang
> > >
> > > Tested-by: Leif Lindholm 
> > >
> > > MdePkg maintainers - this is currently breaking several platforms in
> > > edk2-platforms.
> > >
> > 
> > Acked-by: Ard Biesheuvel 
> > 
> > Please just merge this - it is an obvious and trivial bugfix, and it
> > is affecting multiple platforms.
> 
> Yeah, good call.
> I've submitted it as https://github.com/tianocore/edk2/pull/4887

Merged as d073a5451191.

/
Leif

> > > On Fri, Sep 29, 2023 at 13:08:50 +, Sami Mujawar wrote:
> > > > Hi Pierre,
> > > >
> > > > Thank you for this fix.
> > > >
> > > > Unfortunately, this did not get trapped by the edk2 CI as well.
> > > >
> > > > Reviewed-by: Sami Mujawar 
> > > >
> > > > Regards,
> > > >
> > > > Sami Mujawar
> > > >
> > > > On 29/09/2023, 13:30, "pierre.gond...@arm.com 
> > > > "  > > > > wrote:
> > > >
> > > >
> > > > From: Pierre Gondois  > > > >
> > > >
> > > >
> > > > Add missing GUID declaration in DxeRngLib.inf.
> > > >
> > > >
> > > > Fixes: bd1f0eecc1df ("MdePkg/DxeRngLib: Request raw algorithm
> > > > instead of default")
> > > >
> > > >
> > > > Signed-off-by: Pierre Gondois  > > > >
> > > > ---
> > > > MdePkg/Library/DxeRngLib/DxeRngLib.inf | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > >
> > > > diff --git a/MdePkg/Library/DxeRngLib/DxeRngLib.inf 
> > > > b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > > index 9c11959f8aeb..281fec46502f 100644
> > > > --- a/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > > +++ b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > > @@ -36,3 +36,4 @@ [Guids]
> > > > gEfiRngAlgorithmSp80090Ctr256Guid
> > > > gEfiRngAlgorithmSp80090Hash256Guid
> > > > gEfiRngAlgorithmSp80090Hmac256Guid
> > > > + gEfiRngAlgorithmRaw
> > > > --
> > > > 2.25.1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > 
> > >
> > >
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109326): https://edk2.groups.io/g/devel/message/109326
Mute This Topic: https://groups.io/mt/101656295/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-discuss] PLDM messages via MCTP over KCS

2023-10-04 Thread Konstantin Aladyshev

Hi Chang!

Thanks!
There were a couple of trivial compilation errors, but after I've
fixed them everything seems to work fine!
Just in case I've tested the OpenBMC side with the mctp Linux kernel
driver approach
(https://github.com/Kostr/PLDM/tree/master/mctp-kernel)
The latest kernel patches can be found here:
https://lore.kernel.org/lkml/20231003131505.337-1-aladyshe...@gmail.com/

Here is a fix for the build errors that I've found:
```
diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index 79501d27aa..345c6da81a 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -193,7 +193,7 @@ SetupMctpRequestTransportPacket (

 //
 // Generate PEC follow SMBUS 2.0 specification.
-*MctpKcsTrailer->Pec = HelperManageabilityGenerateCrc8
(MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage,
MctpKcsHeader->ByteCount);
+MctpKcsTrailer->Pec = HelperManageabilityGenerateCrc8
(MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage,
MctpKcsHeader->ByteCount);
 *PacketBody= (UINT8 *)ThisPackage;
 *PacketBodySize= MctpKcsHeader->ByteCount;
 *PacketTrailer = (MANAGEABILITY_TRANSPORT_TRAILER)MctpKcsTrailer;
diff --git a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
index 863b8d471c..247d032b9b 100644
--- a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
+++ b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
@@ -79,17 +79,17 @@ MctpSubmitMessage (
   }

   //
-  // Chec source EID and destination EDI.
+  // Check source EID and destination EID
   //
   if ((MctpSourceEndpointId >= MCTP_RESERVED_ENDPOINT_START_ID) &&
-   MctpSourceEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
+  (MctpSourceEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
   ) {
 DEBUG ((DEBUG_ERROR, "%a: The value of MCTP source EID (%x) is
reserved.\n", func, MctpSourceEndpointId));
 return EFI_INVALID_PARAMETER;
   }

   if ((MctpDestinationEndpointId >= MCTP_RESERVED_ENDPOINT_START_ID) &&
-   MctpDestinationEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
+  (MctpDestinationEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
   ) {
 DEBUG ((DEBUG_ERROR, "%a: The value of MCTP destination EID (%x)
is reserved.\n", func, MctpDestinationEndpointId));
 return EFI_INVALID_PARAMETER;
```

Best regards,
Konstantin Aladyshev

On Wed, Oct 4, 2023 at 2:52 PM Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
> Hi Aladyshev,
> I have updated the change you made and put those code on below link,
> https://github.com/changab/edk2-platforms/commit/1c8d0d3fa403b47a34667f7f690add7822163111
>
> I combined MCTP over KCS changes and IPMI over KCS functionality in 
> KcsCommonLib.c. I also created MANAGEABILITY_MCTP_KCS_TRAILER as you 
> suggested. The source EID and destination EID are checked in 
> MctpSubmitCommand as well. IPMI/KCS functionality is verified and works fine 
> after this change.
> As I am no able to use the corresponding change you made on OpenBMC site at 
> my end, could you please help to verify my updates on your machine? Let's see 
> how it works.
> I also consider to migrate the code that generates MCTP over KCS 
> header/trailer from MctpProtocolCommon.c to KcsCommonLib.c, maybe after we 
> verifying PLDM->MCTP->KCS route works well on ManageabilityPkg.
>
> Thank you
> Abner
>
>
> > -Original Message-
> > From: Konstantin Aladyshev 
> > Sent: Friday, September 29, 2023 2:18 AM
> > To: Chang, Abner 
> > Cc: devel@edk2.groups.io; disc...@edk2.groups.io
> > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > Hi, Chang!
> >
> > Did you have time to test libmctp MCTP KCS binding solution?
> >
> > Here are some updates from my end. As I was saying, I was working on
> > the Linux kernel binding solution.
> > And now I've finished the initial implementation of the Linux kernel
> > binding driver for the MCTP-over-KCS binding and proposed all the
> > patches upstream
> > (https://www.spinics.net/lists/kernel/msg4949173.html).
> > I've also updated instructions in my repo
> > https://github.com/Kostr/PLDM (the guide for the kernel binding
> > solution and all the necessary Linux kernel patches can be found here
> > https://github.com/Kostr/PLDM/tree/master/mctp-kernel).
> > So now you can use Linux driver instead of the libmctp utility on the BMC 
> > side.
> >
> > Couple of things that I've noticed in the development process:
> > - `MctpSubmitCommand` receives
> > 'MctpSourceEndpointId'/'MctpDestinationEndpointId' as arguments. But
> > these

Re: [edk2-devel] [PATCH 1/1] MdePkg/DxeRngLib: Add missing GUID declaration in inf

2023-10-04 Thread Leif Lindholm

On Wed, Oct 04, 2023 at 14:56:55 +, Ard Biesheuvel wrote:
> On Tue, 3 Oct 2023 at 17:22, Leif Lindholm  wrote:
> >
> > +Zhiguang
> >
> > Tested-by: Leif Lindholm 
> >
> > MdePkg maintainers - this is currently breaking several platforms in
> > edk2-platforms.
> >
> 
> Acked-by: Ard Biesheuvel 
> 
> Please just merge this - it is an obvious and trivial bugfix, and it
> is affecting multiple platforms.

Yeah, good call.
I've submitted it as https://github.com/tianocore/edk2/pull/4887

/
Leif

> > On Fri, Sep 29, 2023 at 13:08:50 +, Sami Mujawar wrote:
> > > Hi Pierre,
> > >
> > > Thank you for this fix.
> > >
> > > Unfortunately, this did not get trapped by the edk2 CI as well.
> > >
> > > Reviewed-by: Sami Mujawar 
> > >
> > > Regards,
> > >
> > > Sami Mujawar
> > >
> > > On 29/09/2023, 13:30, "pierre.gond...@arm.com 
> > > "  > > > wrote:
> > >
> > >
> > > From: Pierre Gondois  > > >
> > >
> > >
> > > Add missing GUID declaration in DxeRngLib.inf.
> > >
> > >
> > > Fixes: bd1f0eecc1df ("MdePkg/DxeRngLib: Request raw algorithm
> > > instead of default")
> > >
> > >
> > > Signed-off-by: Pierre Gondois  > > >
> > > ---
> > > MdePkg/Library/DxeRngLib/DxeRngLib.inf | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > >
> > > diff --git a/MdePkg/Library/DxeRngLib/DxeRngLib.inf 
> > > b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > index 9c11959f8aeb..281fec46502f 100644
> > > --- a/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > +++ b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > > @@ -36,3 +36,4 @@ [Guids]
> > > gEfiRngAlgorithmSp80090Ctr256Guid
> > > gEfiRngAlgorithmSp80090Hash256Guid
> > > gEfiRngAlgorithmSp80090Hmac256Guid
> > > + gEfiRngAlgorithmRaw
> > > --
> > > 2.25.1
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > 
> >
> >
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109324): https://edk2.groups.io/g/devel/message/109324
Mute This Topic: https://groups.io/mt/101656295/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] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Tuan Phan

If we agree that default should be 10 then i will change it in the next
version.

On Wed, Oct 4, 2023 at 4:36 AM Sunil V L  wrote:

> Hi Tuan,
>
> Thanks for the patch!. Adding UefiCpuPkg maintainers.
>
> On Tue, Oct 03, 2023 at 02:00:21PM -0700, Tuan Phan wrote:
> > Introduce a PCD to control the maximum SATP mode that MMU allowed
> > to use. This PCD helps RISC-V platform set bare or minimum SATA mode
>
> SATA -> SATP
>
> > during bring up to debug memory map issue.
> >
> > Signed-off-by: Tuan Phan 
> > ---
> >  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
> >  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
> >  UefiCpuPkg/UefiCpuPkg.dec  | 8 
> >  3 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > index 9cca5fc128af..826a1d32a1d4 100644
> > --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > @@ -36,7 +36,7 @@
> >  #define PTE_PPN_SHIFT 10
> >  #define RISCV_MMU_PAGE_SHIFT  12
> >
> > -STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39 };
> > +STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39, SATP_MODE_OFF };
> >  STATIC UINTN  mMaxRootTableLevel;
> >  STATIC UINTN  mBitPerLevel;
> >  STATIC UINTN  mTableEntryCount;
> > @@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
> >UINTNIndex;
> >EFI_STATUS   Status;
> >
> > +  if (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {
> > +return EFI_DEVICE_ERROR;
> > +  }
> > +
> >switch (SatpMode) {
> >  case SATP_MODE_OFF:
> >return EFI_SUCCESS;
> > diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> > index 9b28a98cb346..51ebe1750e97 100644
> > --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> > +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> > @@ -25,3 +25,6 @@
> >
> >  [LibraryClasses]
> >BaseLib
> > +
> > +[Pcd]
> > +  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ## CONSUMES
> > diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> > index 68473fc640e6..79191af18a05 100644
> > --- a/UefiCpuPkg/UefiCpuPkg.dec
> > +++ b/UefiCpuPkg/UefiCpuPkg.dec
> > @@ -396,6 +396,14 @@
> ># @Prompt Access to non-SMRAM memory is restricted to reserved,
> runtime and ACPI NVS type after SmmReadyToLock.
> >
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|BOOLEAN|0x3213210F
> >
> > +[PcdsFixedAtBuild.RISCV64]
> > +  ## Indicate the maximum SATP mode allowed.
> > +  #  0 - Bare mode.
> > +  #  8 - 39bit mode.
> > +  #  9 - 48bit mode.
> > +  #  10 - 57bit mode.
> > +
> gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|0|UINT32|0x6021
> > +
> Shouldn't the default value be 10?
>
> Thanks,
> Sunil
>
> >  [PcdsDynamic, PcdsDynamicEx]
> >## Contains the pointer to a CPU S3 data buffer of structure
> ACPI_CPU_DATA.
> ># @Prompt The pointer to a CPU S3 data buffer.
> > --
> > 2.25.1
> >
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109323): https://edk2.groups.io/g/devel/message/109323
Mute This Topic: https://groups.io/mt/101742937/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] MdePkg/DxeRngLib: Add missing GUID declaration in inf

2023-10-04 Thread Ard Biesheuvel

On Tue, 3 Oct 2023 at 17:22, Leif Lindholm  wrote:
>
> +Zhiguang
>
> Tested-by: Leif Lindholm 
>
> MdePkg maintainers - this is currently breaking several platforms in
> edk2-platforms.
>

Acked-by: Ard Biesheuvel 

Please just merge this - it is an obvious and trivial bugfix, and it
is affecting multiple platforms.


> On Fri, Sep 29, 2023 at 13:08:50 +, Sami Mujawar wrote:
> > Hi Pierre,
> >
> > Thank you for this fix.
> >
> > Unfortunately, this did not get trapped by the edk2 CI as well.
> >
> > Reviewed-by: Sami Mujawar 
> >
> > Regards,
> >
> > Sami Mujawar
> >
> > On 29/09/2023, 13:30, "pierre.gond...@arm.com 
> > "  > > wrote:
> >
> >
> > From: Pierre Gondois  > >
> >
> >
> > Add missing GUID declaration in DxeRngLib.inf.
> >
> >
> > Fixes: bd1f0eecc1df ("MdePkg/DxeRngLib: Request raw algorithm
> > instead of default")
> >
> >
> > Signed-off-by: Pierre Gondois  > >
> > ---
> > MdePkg/Library/DxeRngLib/DxeRngLib.inf | 1 +
> > 1 file changed, 1 insertion(+)
> >
> >
> > diff --git a/MdePkg/Library/DxeRngLib/DxeRngLib.inf 
> > b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > index 9c11959f8aeb..281fec46502f 100644
> > --- a/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > +++ b/MdePkg/Library/DxeRngLib/DxeRngLib.inf
> > @@ -36,3 +36,4 @@ [Guids]
> > gEfiRngAlgorithmSp80090Ctr256Guid
> > gEfiRngAlgorithmSp80090Hash256Guid
> > gEfiRngAlgorithmSp80090Hmac256Guid
> > + gEfiRngAlgorithmRaw
> > --
> > 2.25.1
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> 
>
>


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

Re: [edk2-devel] [PATCH] MdeModulePkg/DxeCore: Allow relocation of images with large address

2023-10-04 Thread Jeff Brasen via groups.io

Anyone have any thoughts on this patch?

Thanks,
Jeff


> -Original Message-
> From: Jeff Brasen 
> Sent: Monday, September 11, 2023 2:14 PM
> To: devel@edk2.groups.io
> Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> dandan...@intel.com; Ashish Singhal 
> Subject: RE: [PATCH] MdeModulePkg/DxeCore: Allow relocation of images
> with large address
> 
> Any  thoughts/feedback on this patch?
> 
> Thanks,
> Jeff
> 
> 
> > -Original Message-
> > From: Jeff Brasen 
> > Sent: Monday, May 15, 2023 5:49 PM
> > To: devel@edk2.groups.io
> > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > dandan...@intel.com; Jeff Brasen ; Ashish Singhal
> > 
> > Subject: [PATCH] MdeModulePkg/DxeCore: Allow relocation of images
> with
> > large address
> >
> > Add PCD to control if modules with start addresses in PE/COFF >
> > 0x10 attempt to load at specified address.
> > If a module has an address in this range and there is untested memory
> > DxeCore will attempt to promote all memory to tested which bypasses
> > any memory testing that would occur later in boot.
> >
> > There are several existing AARCH64 option roms that have base
> > addresses of 0x18000.
> >
> > Signed-off-by: Jeff Brasen 
> > Reviewed-by: Ashish Singhal 
> > ---
> >  MdeModulePkg/Core/Dxe/DxeMain.inf   | 1 +
> >  MdeModulePkg/Core/Dxe/Image/Image.c | 4 +++-
> >  MdeModulePkg/MdeModulePkg.dec   | 7 +++
> >  3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > index 35d5bf0dee..16871f2021 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > @@ -187,6 +187,7 @@
> >gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
> > ## CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  
> >  ##
> > CONSUMES
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth
> > ## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdImageLargeAddressLoad
> > ## CONSUMES
> >
> >  # [Hob]
> >  # RESOURCE_DESCRIPTOR   ## CONSUMES
> > diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c
> > b/MdeModulePkg/Core/Dxe/Image/Image.c
> > index 9dbfb2a1fa..6bc3a549ae 100644
> > --- a/MdeModulePkg/Core/Dxe/Image/Image.c
> > +++ b/MdeModulePkg/Core/Dxe/Image/Image.c
> > @@ -680,7 +680,9 @@ CoreLoadPeImage (
> > );
> >}
> >  } else {
> > -  if ((Image->ImageContext.ImageAddress >= 0x10) || Image-
> > >ImageContext.RelocationsStripped) {
> > +  if ((PcdGetBool (PcdImageLargeAddressLoad) && ((Image-
> > >ImageContext.ImageAddress) >= 0x10)) ||
> > +  Image->ImageContext.RelocationsStripped)
> > +  {
> >  Status = CoreAllocatePages (
> > AllocateAddress,
> > (EFI_MEMORY_TYPE)(Image-
> > >ImageContext.ImageCodeMemoryType),
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > b/MdeModulePkg/MdeModulePkg.dec index 95dd077e19..6fd1bd7b8f
> > 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -1116,6 +1116,13 @@
> ># @Prompt Output MMIO address of Trace Hub message.
> >
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdTraceHubDebugMmioAddress|0|UI
> N
> > T64|0x30001058
> >
> > +  ## Indicates if images with large load address (>0x10) should
> > attempted to load at specified location.
> > +  #  If enabled, attempt to allocate at specfied location will be
> > + attempted with
> > a fall back to any address.
> > +  #   TRUE  - UEFI will attempt to load at specified location.
> > +  #   FALSE - UEFI will load at any address
> > +  # @Prompt Enable large address image loading.
> > +
> > +
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdImageLargeAddressLoad|TRUE|BO
> OL
> > EAN|0
> > + x30001059
> > +
> >  [PcdsFixedAtBuild, PcdsPatchableInModule]
> >## Dynamic type PCD can be registered callback function for Pcd
> > setting action.
> >#  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum
> > number of callback function
> > --
> > 2.25.1



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

Re: [edk2-devel] [PATCH] ArmPkg/ArmPsciMpServices Add EFI_NOT_READY return

2023-10-04 Thread Jeff Brasen via groups.io

Anything else needed on this to get it merged?

Thanks,
Jeff

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, September 7, 2023 8:17 AM
> To: devel@edk2.groups.io; Jeff Brasen 
> Cc: quic_llind...@quicinc.com; ardb+tianoc...@kernel.org;
> rebe...@bsdio.com
> Subject: Re: [edk2-devel] [PATCH] ArmPkg/ArmPsciMpServices Add
> EFI_NOT_READY return
> 
> External email: Use caution opening links or attachments
> 
> 
> On Thu, 29 Jun 2023 at 22:47, Jeff Brasen via groups.io
>  wrote:
> >
> > Add EFI_NOT_READY return if the CPU can not be enabled if the
> > processor is already on.
> >
> > This can occur in normal use if the CPU is still being turned off from
> > a previous call when this is called again.
> >
> > Signed-off-by: Jeff Brasen 
> 
> Acked-by: Ard Biesheuvel 
> 
> I'll queue this up - thanks.
> 
> > ---
> >  ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c | 4
> +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > index f822a9877c..e7f4223513 100644
> > --- a/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > +++ b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > @@ -103,7 +103,9 @@ DispatchCpu (
> >
> >ArmCallSmc ();
> >
> > -  if (Args.Arg0 != ARM_SMC_PSCI_RET_SUCCESS) {
> > +  if (Args.Arg0 == ARM_SMC_PSCI_RET_ALREADY_ON) {
> > +Status = EFI_NOT_READY;
> > +  } else if (Args.Arg0 != ARM_SMC_PSCI_RET_SUCCESS) {
> >  DEBUG ((DEBUG_ERROR, "PSCI_CPU_ON call failed: %d\n", Args.Arg0));
> >  Status = EFI_DEVICE_ERROR;
> >}
> > --
> > 2.25.1
> >
> >
> > 
> >
> >


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

Re: [edk2-devel] [PATCH v2 0/2] dp command without ACPI

2023-10-04 Thread Jeff Brasen via groups.io

Anything else needed on this to get it merged?

Thanks,
Jeff

> -Original Message-
> From: gaoliming 
> Sent: Tuesday, September 12, 2023 6:59 AM
> To: Jeff Brasen ; devel@edk2.groups.io
> Cc: jian.j.w...@intel.com; dandan...@intel.com; zhichao@intel.com
> Subject: 回复: [PATCH v2 0/2] dp command without ACPI
> 
> External email: Use caution opening links or attachments
> 
> 
> For the change in MdeModulePkg, Reviewed-by: Liming Gao
> 
> 
> > -邮件原件-
> > 发件人: Jeff Brasen 
> > 发送时间: 2023年9月12日 4:39
> > 收件人: devel@edk2.groups.io
> > 抄送: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > dandan...@intel.com; zhichao@intel.com
> > 主题: RE: [PATCH v2 0/2] dp command without ACPI
> >
> >
> > Any additional thoughts/feedback on this patch series?
> >
> > Thanks,
> > Jeff
> >
> >
> > > -Original Message-
> > > From: Jeff Brasen 
> > > Sent: Friday, June 30, 2023 11:30 AM
> > > To: devel@edk2.groups.io
> > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > dandan...@intel.com;
> > > zhichao@intel.com; Jeff Brasen 
> > > Subject: [PATCH v2 0/2] dp command without ACPI
> > >
> > > Systems that do not boot with ACPI (system that use device tree for
> > example)
> > > can not use the shell dp command. This patch adds this to the
> configuration
> > > table so that dp command can get this without the FPDT table.
> > >
> > > I am open to other ways for this to be passed if desired (Installed
> protocol,
> > > handler of the status code, etc) but wanted to post this to at least
> > > get thoughts on this.
> > >
> > > Change Log
> > > v2 - Fix missing cast for IA32 builds
> > >
> > > -Jeff
> > >
> > > Jeff Brasen (2):
> > >   MdeModulePkg/DxeCorePerformanceLib: Install BPDT in config table
> > >   ShellPkg/Dp: Allow dp command to work without ACPI
> > >
> > >  ShellPkg/DynamicCommand/DpDynamicCommand/DpApp.inf|  1 +
> > >  .../DpDynamicCommand/DpDynamicCommand.inf |  1 +
> > >  .../DxeCorePerformanceLib/DxeCorePerformanceLib.c |  2 ++
> > >  ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c | 11
> > -
> > > --
> > >  4 files changed, 12 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 2.25.1
> 
> 



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

[edk2-devel] Event: TianoCore edk2-test Bug Triage Meeting - Thursday, October 5, 2023 #cal-reminder

2023-10-04 Thread Group Notification

*Reminder: TianoCore edk2-test Bug Triage Meeting*

*When:*
Thursday, October 5, 2023
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

*Where:*
https://armltd.zoom.us/j/91247522013?pwd=ei9nUndTbG9oWEROS2M1aVREZkpiQT09=addon

*Organizer:* Edhaya Chandran edhaya.chand...@arm.com ( 
edhaya.chand...@arm.com?subject=Re:%20Event:%20TianoCore%20edk2-test%20Bug%20Triage%20Meeting
 )

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2043511 )

*Description:*


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

Re: [edk2-devel] [PATCH v2 1/1] CryptoPkg/TlsLib: fix tls cipher configuration

2023-10-04 Thread Laszlo Ersek

On 10/4/23 11:20, Gerd Hoffmann wrote:
> Trying to configure the TLS ciphers can lead to TLS handshake failures
> because TlsCipherMappingTable is not in line with the ciphers actually
> supported by OpensslLib.
> 
> Fix that by removing TlsCipherMappingTable altogether.  Use
> SSL_get_ciphers() instead to get the stack of ciphers supported by
> openssl.  Name and ID of the ciphers can be queried using the
> SSL_CIPHER_get_name() and SSL_CIPHER_get_protocol_id() functions,
> which allows us to map IDs to names without a hard-code table.
> 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2541
> Signed-off-by: Gerd Hoffmann 
> ---
>  CryptoPkg/Library/TlsLib/TlsConfig.c | 164 ++-
>  1 file changed, 36 insertions(+), 128 deletions(-)
> 
> diff --git a/CryptoPkg/Library/TlsLib/TlsConfig.c 
> b/CryptoPkg/Library/TlsLib/TlsConfig.c
> index f9333165a913..29d24abdca0f 100644
> --- a/CryptoPkg/Library/TlsLib/TlsConfig.c
> +++ b/CryptoPkg/Library/TlsLib/TlsConfig.c
> @@ -9,65 +9,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  #include "InternalTlsLib.h"
>  
> -typedef struct {
> -  //
> -  // IANA/IETF defined Cipher Suite ID
> -  //
> -  UINT16 IanaCipher;
> -  //
> -  // OpenSSL-used Cipher Suite String
> -  //
> -  CONST CHAR8*OpensslCipher;
> -  //
> -  // Length of OpensslCipher
> -  //
> -  UINTN  OpensslCipherLength;
> -} TLS_CIPHER_MAPPING;
> -
> -//
> -// Create a TLS_CIPHER_MAPPING initializer from IanaCipher and OpensslCipher 
> so
> -// that OpensslCipherLength is filled in automatically. IanaCipher must be an
> -// integer constant expression, and OpensslCipher must be a string literal.
> -//
> -#define MAP(IanaCipher, OpensslCipher) \
> -  { (IanaCipher), (OpensslCipher), sizeof (OpensslCipher) - 1 }
> -
> -//
> -// The mapping table between IANA/IETF Cipher Suite definitions and
> -// OpenSSL-used Cipher Suite name.
> -//
> -// Keep the table uniquely sorted by the IanaCipher field, in increasing 
> order.
> -//
> -STATIC CONST TLS_CIPHER_MAPPING  TlsCipherMappingTable[] = {
> -  MAP (0x0001, "NULL-MD5"), /// TLS_RSA_WITH_NULL_MD5
> -  MAP (0x0002, "NULL-SHA"), /// TLS_RSA_WITH_NULL_SHA
> -  MAP (0x0004, "RC4-MD5"),  /// 
> TLS_RSA_WITH_RC4_128_MD5
> -  MAP (0x0005, "RC4-SHA"),  /// 
> TLS_RSA_WITH_RC4_128_SHA
> -  MAP (0x000A, "DES-CBC3-SHA"), /// 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA, mandatory TLS 1.1
> -  MAP (0x0016, "DHE-RSA-DES-CBC3-SHA"), /// 
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> -  MAP (0x002F, "AES128-SHA"),   /// 
> TLS_RSA_WITH_AES_128_CBC_SHA, mandatory TLS 1.2
> -  MAP (0x0030, "DH-DSS-AES128-SHA"),/// 
> TLS_DH_DSS_WITH_AES_128_CBC_SHA
> -  MAP (0x0031, "DH-RSA-AES128-SHA"),/// 
> TLS_DH_RSA_WITH_AES_128_CBC_SHA
> -  MAP (0x0033, "DHE-RSA-AES128-SHA"),   /// 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> -  MAP (0x0035, "AES256-SHA"),   /// 
> TLS_RSA_WITH_AES_256_CBC_SHA
> -  MAP (0x0036, "DH-DSS-AES256-SHA"),/// 
> TLS_DH_DSS_WITH_AES_256_CBC_SHA
> -  MAP (0x0037, "DH-RSA-AES256-SHA"),/// 
> TLS_DH_RSA_WITH_AES_256_CBC_SHA
> -  MAP (0x0039, "DHE-RSA-AES256-SHA"),   /// 
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> -  MAP (0x003B, "NULL-SHA256"),  /// 
> TLS_RSA_WITH_NULL_SHA256
> -  MAP (0x003C, "AES128-SHA256"),/// 
> TLS_RSA_WITH_AES_128_CBC_SHA256
> -  MAP (0x003D, "AES256-SHA256"),/// 
> TLS_RSA_WITH_AES_256_CBC_SHA256
> -  MAP (0x003E, "DH-DSS-AES128-SHA256"), /// 
> TLS_DH_DSS_WITH_AES_128_CBC_SHA256
> -  MAP (0x003F, "DH-RSA-AES128-SHA256"), /// 
> TLS_DH_RSA_WITH_AES_128_CBC_SHA256
> -  MAP (0x0067, "DHE-RSA-AES128-SHA256"),/// 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> -  MAP (0x0068, "DH-DSS-AES256-SHA256"), /// 
> TLS_DH_DSS_WITH_AES_256_CBC_SHA256
> -  MAP (0x0069, "DH-RSA-AES256-SHA256"), /// 
> TLS_DH_RSA_WITH_AES_256_CBC_SHA256
> -  MAP (0x006B, "DHE-RSA-AES256-SHA256"),/// 
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> -  MAP (0x009F, "DHE-RSA-AES256-GCM-SHA384"),/// 
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> -  MAP (0xC02B, "ECDHE-ECDSA-AES128-GCM-SHA256"),/// 
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> -  MAP (0xC02C, "ECDHE-ECDSA-AES256-GCM-SHA384"),/// 
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> -  MAP (0xC030, "ECDHE-RSA-AES256-GCM-SHA384"),  /// 
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> -};
> -
>  typedef struct {
>//
>// TLS Algorithm
> @@ -96,54 +37,6 @@ STATIC CONST TLS_ALGO_TO_NAME  TlsSignatureAlgoToName[] = {
>{ TlsSignatureAlgoEcdsa, "ECDSA" },
>  };
>  
> -/**
> -  Gets the OpenSSL cipher suite mapping for the supplied IANA TLS cipher 
> suite.
> -
> -  @param[in]  CipherIdThe supplied IANA TLS

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

2023-10-04 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

Hi Aladyshev,
I have updated the change you made and put those code on below link,
https://github.com/changab/edk2-platforms/commit/1c8d0d3fa403b47a34667f7f690add7822163111

I combined MCTP over KCS changes and IPMI over KCS functionality in 
KcsCommonLib.c. I also created MANAGEABILITY_MCTP_KCS_TRAILER as you suggested. 
The source EID and destination EID are checked in MctpSubmitCommand as well. 
IPMI/KCS functionality is verified and works fine after this change.
As I am no able to use the corresponding change you made on OpenBMC site at my 
end, could you please help to verify my updates on your machine? Let's see how 
it works.
I also consider to migrate the code that generates MCTP over KCS header/trailer 
from MctpProtocolCommon.c to KcsCommonLib.c, maybe after we verifying 
PLDM->MCTP->KCS route works well on ManageabilityPkg.

Thank you
Abner


> -Original Message-
> From: Konstantin Aladyshev 
> Sent: Friday, September 29, 2023 2:18 AM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io; disc...@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Hi, Chang!
>
> Did you have time to test libmctp MCTP KCS binding solution?
>
> Here are some updates from my end. As I was saying, I was working on
> the Linux kernel binding solution.
> And now I've finished the initial implementation of the Linux kernel
> binding driver for the MCTP-over-KCS binding and proposed all the
> patches upstream
> (https://www.spinics.net/lists/kernel/msg4949173.html).
> I've also updated instructions in my repo
> https://github.com/Kostr/PLDM (the guide for the kernel binding
> solution and all the necessary Linux kernel patches can be found here
> https://github.com/Kostr/PLDM/tree/master/mctp-kernel).
> So now you can use Linux driver instead of the libmctp utility on the BMC 
> side.
>
> Couple of things that I've noticed in the development process:
> - `MctpSubmitCommand` receives
> 'MctpSourceEndpointId'/'MctpDestinationEndpointId' as arguments. But
> these values aren't actually used. The current code just uses EIDs
> that were set via PCDs
> (https://github.com/tianocore/edk2-
> platforms/blob/d03a60523a6086d200d3eb1e2f25530bf1cb790e/Features/
> ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.
> c#L178)
> - According to the specification DSP0236 (section 8.2) MCTP EID 0 to 7
> are reserved. It is critical that we do not use them since MCTP Linux
> kernel subsystem checks that part. So we probably need to add some
> check to the `MctpSubmitCommand` that would verify that we don't use
> reserved EIDs.
>
> Best regards,
> Konstantin Aladyshev
>
> On Thu, Sep 21, 2023 at 5:32 AM Chang, Abner 
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Hi Aladyshev,
> > Thanks for providing the details, I will take a look at your code first,
> implement it at my end and then response to your question.
> >
> > Abner
> >
> > > -Original Message-
> > > From: Konstantin Aladyshev 
> > > Sent: Friday, September 8, 2023 8:57 PM
> > > To: Chang, Abner 
> > > Cc: devel@edk2.groups.io; disc...@edk2.groups.io
> > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over
> KCS
> > >
> > > Caution: This message originated from an External Source. Use proper
> caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > Hi, Chang!
> > >
> > > I've finished my initial implementation of the MCTP over KCS binding.
> > > You can find 'edk2-platform' patches and 'openbmc' patches along with
> > > all of the instructions in my repository
> > > https://github.com/Kostr/PLDM. I hope you'll be able to reproduce
> > > everything on your hardware configuration. Feel free to ask any
> > > questions.
> > > Also I've sent all the openbmc patches upstream, hope they will get
> > > accepted soon.
> > > As for the 'edk2-platform' patches, right now I don't fully understand
> > > how to write them correctly to keep IPMI over KCS stack working. I
> > > think here I would need your help. Right now I've commited them to my
> > > `edk2-platforms` fork
> > > https://github.com/tianocore/edk2-
> > > platforms/commit/99a6c98a63b37f955c0d0480149b84fcc3a03f74
> > >
> > > Couple of questions/notices:
> > > 1) You've said that we can differentiate MCTP by the transfer token,
> > > but it is not passed to the 'KcsTransportSendCommand' function
> > > https://github.com/tianocore/edk2-
> > >
> platforms/blob/bb6841e3fd1c60b3f8510b4fc0a380784e05d326/Features/
> > >
> ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsComm
> > > on.c#L414
> > >
> > > 2) What function should know about the
> > > MANAGEABILITY_MCTP_KCS_HEADER?
> > > Keep in mind that this header includes 'ByteCount' for the incoming
> > > data size that we need to read.
> > > - KcsTransportSendCommand or

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

2023-10-04 Thread Sunil V L

Hi Tuan,

Thanks for the patch!. Adding UefiCpuPkg maintainers.

On Tue, Oct 03, 2023 at 02:00:21PM -0700, Tuan Phan wrote:
> Introduce a PCD to control the maximum SATP mode that MMU allowed
> to use. This PCD helps RISC-V platform set bare or minimum SATA mode

SATA -> SATP

> during bring up to debug memory map issue.
> 
> Signed-off-by: Tuan Phan 
> ---
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c   | 6 +-
>  UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf | 3 +++
>  UefiCpuPkg/UefiCpuPkg.dec  | 8 
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c 
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 9cca5fc128af..826a1d32a1d4 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,7 +36,7 @@
>  #define PTE_PPN_SHIFT 10
>  #define RISCV_MMU_PAGE_SHIFT  12
>  
> -STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
> SATP_MODE_SV39 };
> +STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
> SATP_MODE_SV39, SATP_MODE_OFF };
>  STATIC UINTN  mMaxRootTableLevel;
>  STATIC UINTN  mBitPerLevel;
>  STATIC UINTN  mTableEntryCount;
> @@ -590,6 +590,10 @@ RiscVMmuSetSatpMode  (
>UINTNIndex;
>EFI_STATUS   Status;
>  
> +  if (SatpMode > PcdGet32 (PcdCpuRiscVMmuMaxSatpMode)) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
>switch (SatpMode) {
>  case SATP_MODE_OFF:
>return EFI_SUCCESS;
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf 
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 9b28a98cb346..51ebe1750e97 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -25,3 +25,6 @@
>  
>  [LibraryClasses]
>BaseLib
> +
> +[Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ## CONSUMES
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index 68473fc640e6..79191af18a05 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -396,6 +396,14 @@
># @Prompt Access to non-SMRAM memory is restricted to reserved, runtime 
> and ACPI NVS type after SmmReadyToLock.
>
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmRestrictedMemoryAccess|TRUE|BOOLEAN|0x3213210F
>  
> +[PcdsFixedAtBuild.RISCV64]
> +  ## Indicate the maximum SATP mode allowed.
> +  #  0 - Bare mode.
> +  #  8 - 39bit mode.
> +  #  9 - 48bit mode.
> +  #  10 - 57bit mode.
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|0|UINT32|0x6021
> +
Shouldn't the default value be 10?

Thanks,
Sunil

>  [PcdsDynamic, PcdsDynamicEx]
>## Contains the pointer to a CPU S3 data buffer of structure ACPI_CPU_DATA.
># @Prompt The pointer to a CPU S3 data buffer.
> -- 
> 2.25.1
> 


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

Re: [edk2-devel] [PATCH] BaseStackCheckLib: Fix STACK FAULT message

2023-10-04 Thread Jake Garver via groups.io

Thanks.  I'll submit a v2 with that change.

From: Kinney, Michael D 
Sent: Tuesday, October 3, 2023 12:00 PM
To: Name j...@nvidia.com ; devel@edk2.groups.io 

Cc: Gao, Liming ; Liu, Zhiguang 
; Jake Garver ; Kinney, Michael D 

Subject: RE: [PATCH] BaseStackCheckLib: Fix STACK FAULT message

External email: Use caution opening links or attachments


I think the macro RETURN_ADDRESS from Base.h should be used instead of
direct use of the builtin.

Mike

> -Original Message-
> From: Name j...@nvidia.com 
> Sent: Tuesday, October 3, 2023 6:20 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Jake
> Garver 
> Subject: [PATCH] BaseStackCheckLib: Fix STACK FAULT message
>
> From: Jake Garver 
>
> __builtin_return_address returns a pointer, not a string.  Fix the STACK
> FAULT message in BaseStackCheckLib appropriately.
>
> Signed-off-by: Jake Garver 
> ---
>  MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> index 0d2918668e..3b970391b7 100644
> --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> @@ -34,7 +34,7 @@ __stack_chk_fail (
>  {
>UINT8  DebugPropertyMask;
>
> -  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow in function %a.\n",
> __builtin_return_address (0)));
> +  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow at 0x%p.\n",
> __builtin_return_address (0)));
>
>//
>// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings even if
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109313): https://edk2.groups.io/g/devel/message/109313
Mute This Topic: https://groups.io/mt/101736789/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] CryptoPkg/TlsLib: fix tls cipher configuration

2023-10-04 Thread Gerd Hoffmann

Trying to configure the TLS ciphers can lead to TLS handshake failures
because TlsCipherMappingTable is not in line with the ciphers actually
supported by OpensslLib.

Fix that by removing TlsCipherMappingTable altogether.  Use
SSL_get_ciphers() instead to get the stack of ciphers supported by
openssl.  Name and ID of the ciphers can be queried using the
SSL_CIPHER_get_name() and SSL_CIPHER_get_protocol_id() functions,
which allows us to map IDs to names without a hard-code table.

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2541
Signed-off-by: Gerd Hoffmann 
---
 CryptoPkg/Library/TlsLib/TlsConfig.c | 164 ++-
 1 file changed, 36 insertions(+), 128 deletions(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsConfig.c 
b/CryptoPkg/Library/TlsLib/TlsConfig.c
index f9333165a913..29d24abdca0f 100644
--- a/CryptoPkg/Library/TlsLib/TlsConfig.c
+++ b/CryptoPkg/Library/TlsLib/TlsConfig.c
@@ -9,65 +9,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #include "InternalTlsLib.h"
 
-typedef struct {
-  //
-  // IANA/IETF defined Cipher Suite ID
-  //
-  UINT16 IanaCipher;
-  //
-  // OpenSSL-used Cipher Suite String
-  //
-  CONST CHAR8*OpensslCipher;
-  //
-  // Length of OpensslCipher
-  //
-  UINTN  OpensslCipherLength;
-} TLS_CIPHER_MAPPING;
-
-//
-// Create a TLS_CIPHER_MAPPING initializer from IanaCipher and OpensslCipher so
-// that OpensslCipherLength is filled in automatically. IanaCipher must be an
-// integer constant expression, and OpensslCipher must be a string literal.
-//
-#define MAP(IanaCipher, OpensslCipher) \
-  { (IanaCipher), (OpensslCipher), sizeof (OpensslCipher) - 1 }
-
-//
-// The mapping table between IANA/IETF Cipher Suite definitions and
-// OpenSSL-used Cipher Suite name.
-//
-// Keep the table uniquely sorted by the IanaCipher field, in increasing order.
-//
-STATIC CONST TLS_CIPHER_MAPPING  TlsCipherMappingTable[] = {
-  MAP (0x0001, "NULL-MD5"), /// TLS_RSA_WITH_NULL_MD5
-  MAP (0x0002, "NULL-SHA"), /// TLS_RSA_WITH_NULL_SHA
-  MAP (0x0004, "RC4-MD5"),  /// 
TLS_RSA_WITH_RC4_128_MD5
-  MAP (0x0005, "RC4-SHA"),  /// 
TLS_RSA_WITH_RC4_128_SHA
-  MAP (0x000A, "DES-CBC3-SHA"), /// 
TLS_RSA_WITH_3DES_EDE_CBC_SHA, mandatory TLS 1.1
-  MAP (0x0016, "DHE-RSA-DES-CBC3-SHA"), /// 
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-  MAP (0x002F, "AES128-SHA"),   /// 
TLS_RSA_WITH_AES_128_CBC_SHA, mandatory TLS 1.2
-  MAP (0x0030, "DH-DSS-AES128-SHA"),/// 
TLS_DH_DSS_WITH_AES_128_CBC_SHA
-  MAP (0x0031, "DH-RSA-AES128-SHA"),/// 
TLS_DH_RSA_WITH_AES_128_CBC_SHA
-  MAP (0x0033, "DHE-RSA-AES128-SHA"),   /// 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-  MAP (0x0035, "AES256-SHA"),   /// 
TLS_RSA_WITH_AES_256_CBC_SHA
-  MAP (0x0036, "DH-DSS-AES256-SHA"),/// 
TLS_DH_DSS_WITH_AES_256_CBC_SHA
-  MAP (0x0037, "DH-RSA-AES256-SHA"),/// 
TLS_DH_RSA_WITH_AES_256_CBC_SHA
-  MAP (0x0039, "DHE-RSA-AES256-SHA"),   /// 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-  MAP (0x003B, "NULL-SHA256"),  /// 
TLS_RSA_WITH_NULL_SHA256
-  MAP (0x003C, "AES128-SHA256"),/// 
TLS_RSA_WITH_AES_128_CBC_SHA256
-  MAP (0x003D, "AES256-SHA256"),/// 
TLS_RSA_WITH_AES_256_CBC_SHA256
-  MAP (0x003E, "DH-DSS-AES128-SHA256"), /// 
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
-  MAP (0x003F, "DH-RSA-AES128-SHA256"), /// 
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
-  MAP (0x0067, "DHE-RSA-AES128-SHA256"),/// 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
-  MAP (0x0068, "DH-DSS-AES256-SHA256"), /// 
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
-  MAP (0x0069, "DH-RSA-AES256-SHA256"), /// 
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
-  MAP (0x006B, "DHE-RSA-AES256-SHA256"),/// 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
-  MAP (0x009F, "DHE-RSA-AES256-GCM-SHA384"),/// 
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
-  MAP (0xC02B, "ECDHE-ECDSA-AES128-GCM-SHA256"),/// 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
-  MAP (0xC02C, "ECDHE-ECDSA-AES256-GCM-SHA384"),/// 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
-  MAP (0xC030, "ECDHE-RSA-AES256-GCM-SHA384"),  /// 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-};
-
 typedef struct {
   //
   // TLS Algorithm
@@ -96,54 +37,6 @@ STATIC CONST TLS_ALGO_TO_NAME  TlsSignatureAlgoToName[] = {
   { TlsSignatureAlgoEcdsa, "ECDSA" },
 };
 
-/**
-  Gets the OpenSSL cipher suite mapping for the supplied IANA TLS cipher suite.
-
-  @param[in]  CipherIdThe supplied IANA TLS cipher suite ID.
-
-  @return  The corresponding OpenSSL cipher suite mapping if found,
-   NULL otherwise.
-
-**/
-STATIC
-CONST TLS_CIPHER_MAPPING *
-TlsGetCipherMapping (
-  IN UINT16  CipherId
-  )
-{
-  INTN  Left;
-  INTN  Right;
-  INTN  Middle;
-
-  //
-  // Binary Search

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/TlsLib: fix tls cipher configuration

2023-10-04 Thread Gerd Hoffmann

  Hi,

> > +  CHAR8 *CipherString;
> > +  CHAR8 *CipherStringPosition;
> > +
> > +  STACK_OF (SSL_CIPHER)  *OpensslCipherStack;
> 
> Surprisingly, this does pass uncrustify. :) OK.

Wasn't my idea, uncrustify actually formatted it that way for me ;)

> > -Mapping = TlsGetCipherMapping (CipherId[Index]);
> > -if (Mapping == NULL) {
> > +for (StackIdx = 0; StackIdx < sk_SSL_CIPHER_num (OpensslCipherStack); 
> > StackIdx++) {
> 
> Surprisingly, StackIdx really does have to be INT32 type here; through
> multiple macro definitions, sk_SSL_CIPHER_num() seems to expand to
> OPENSSL_sk_num(), and that returns a plain "int". OK.

Yep.  Initially I had UINTN, but that caused CI errors due to the type
mismatch ...

> Then this loop will never run (which is fine), but *after* the loop, our
> condition for "not found" will not hold, because StackIdx will be zero,
> but sk_SSL_CIPHER_num() will return (-1).

Good point, missed that.

> but it's probably better to just skip the whole outer loop if
> "OpensslCipherStack" is NULL (as no lookup will succeed).

Agree, will do it that way.

> (4) Why AsciiStrnLenS(), and not AsciiStrLen()?

No good reason.  I just looked up the edk2 name of strlen using
'git grep strlen CryptoPkg/Library/Include', and this is the
result I got ;)

> > -Mapping = MappedCipher[Index];
> > +OpensslCipher = MappedCipher[Index];
> > +OpensslCipherName = SSL_CIPHER_get_name (OpensslCipher);
> > +OpensslCipherNameSize = AsciiStrnLenS (OpensslCipherName, 
> > MAX_STRING_SIZE);
> 
> (5) Better call this "OpensslCipherNameLength" ("Size" suggests
> including the terminating NUL).

OK.

> (8) Can you
> 
> - assign  to yourself,
> 
> - link this patch into a comment on that BZ,
> 
> - and reference the BZ URL in the commit message?

Will do.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib

2023-10-04 Thread Gerd Hoffmann

On Fri, Sep 29, 2023 at 12:52:35PM -0700, Taylor Beebe wrote:
> Sorry for the slow reply :)
> 
> 
> Additional profiles which fit general use cases can be added to
> SetMemoryProtectionsLib, but because this is a profile for grub
> compatibility I'd say it's better suited for platform code making
> MemoryProtectionConfigLib in OvmfPkg the best spot.
> I'll add an additional static profile array to MemoryProtectionConfigLib
> and have logic loop through both to see if a profile matches. I'll
> add the GrubCompat profile you outlined to this new profile array.

Sounds good to me.

> I can also update ArmVirtPkg to disable execution protection
> for EfiLoaderData by default until fw_cfg parsing
> support is added to ArmVirtPkg. Let me know if you think
> this is necessary.

With MemoryProtectionConfigLib adding fw_cfg parsing support to
ArmVirtPkg should be easy, so maybe just do that?

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v2] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

Re: [edk2-devel] reg: Two IAID assignment for single MAC Address

[edk2-devel] [PATCH 3/3] PlatformHookLib: Set PcdSerialClockRate using HOB data

[edk2-devel] [PATCH 2/3] UefiPayloadEntry: Set serial ClockRate from parsed SerialInfo

[edk2-devel] [PATCH 1/3] MdeModulePkg: Add ClockRate field to SerialPortInfo

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [PATCH v1 2/2] MdeModulePkg/Bus/Usb/UsbMouseDxe: Fix MISSING_BREAK Coverity issues

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

[edk2-devel] [PATCH v2] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib

Re: [edk2-devel] [PATCH 1/1] MdePkg/DxeRngLib: Add missing GUID declaration in inf

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

Re: [edk2-devel] [PATCH 1/1] MdePkg/DxeRngLib: Add missing GUID declaration in inf

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [PATCH 1/1] MdePkg/DxeRngLib: Add missing GUID declaration in inf

Re: [edk2-devel] [PATCH] MdeModulePkg/DxeCore: Allow relocation of images with large address

Re: [edk2-devel] [PATCH] ArmPkg/ArmPsciMpServices Add EFI_NOT_READY return

Re: [edk2-devel] [PATCH v2 0/2] dp command without ACPI

[edk2-devel] Event: TianoCore edk2-test Bug Triage Meeting - Thursday, October 5, 2023 #cal-reminder

Re: [edk2-devel] [PATCH v2 1/1] CryptoPkg/TlsLib: fix tls cipher configuration

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

Re: [edk2-devel] [PATCH] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

Re: [edk2-devel] [PATCH] BaseStackCheckLib: Fix STACK FAULT message

[edk2-devel] [PATCH v2 1/1] CryptoPkg/TlsLib: fix tls cipher configuration

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/TlsLib: fix tls cipher configuration

Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib

29 matches

Site Navigation

Mail list logo

Footer information