Date   

Re: [PATCH v1 0/2] SignedCapsulePkg: Enable CI

Michael D Kinney
 

Series Reviewed-by: Michael D Kinney <michael.d.kinney@...>

-----Original Message-----
From: mikuback@... <mikuback@...>
Sent: Tuesday, September 6, 2022 10:05 PM
To: devel@edk2.groups.io
Cc: Sean Brogan <sean.brogan@...>; Barkelew, Bret <bret.barkelew@...>; Kinney, Michael D
<michael.d.kinney@...>; Gao, Liming <gaoliming@...>; Wang, Jian J <jian.j.wang@...>
Subject: [PATCH v1 0/2] SignedCapsulePkg: Enable CI

From: Michael Kubacki <michael.kubacki@...>

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

Adds SignedCapsulePkg to edk2 CI.

In the edk2 PR for this change, you can see that the package only
runs on GCC and CI passes with this configuration.

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

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Jian J Wang <jian.j.wang@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>

Michael Kubacki (2):
SignedCapsulePkg: Add package CI YAML file
.azurepipelines: Add SignedCapsulePkg to CI

.azurepipelines/templates/pr-gate-build-job.yml | 2 +-
.pytool/CISettings.py | 1 +
SignedCapsulePkg/SignedCapsulePkg.ci.yaml | 90 ++++++++++++++++++++
3 files changed, 92 insertions(+), 1 deletion(-)
create mode 100644 SignedCapsulePkg/SignedCapsulePkg.ci.yaml

--
2.28.0.windows.1


Re: [PATCH v1 0/3] SourceLevelDebugPkg: Enable CI

Michael D Kinney
 

Series Reviewed-by: Michael D Kinney <michael.d.kinney@...>

Mike

-----Original Message-----
From: mikuback@... <mikuback@...>
Sent: Tuesday, October 4, 2022 8:19 AM
To: devel@edk2.groups.io
Cc: Wu, Hao A <hao.a.wu@...>; Gao, Liming <gaoliming@...>; Kinney, Michael D <michael.d.kinney@...>; Sean
Brogan <sean.brogan@...>
Subject: [PATCH v1 0/3] SourceLevelDebugPkg: Enable CI

From: Michael Kubacki <michael.kubacki@...>

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

1. Fixes pre-existing spelling errors in the package.
2. Adds SourceLevelDebugPkg to edk2 CI.

CI results are available in the PR:
https://github.com/tianocore/edk2/pull/3439

Cc: Hao A Wu <hao.a.wu@...>
Cc: Liming Gao <gaoliming@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Sean Brogan <sean.brogan@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>

Michael Kubacki (3):
SourceLevelDebugPkg: Fix spelling errors
SourceLevelDebugPkg: Add package CI YAML file
.azurepipelines: Add SourceLevelDebugPkg to CI

SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c | 8 +-
SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c | 22 ++--
SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.c | 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandlerFuncs.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandlerFuncs.c | 2 +-
.azurepipelines/templates/pr-gate-build-job.yml | 2 +-
.pytool/CISettings.py | 1 +
SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h | 2 +-
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.h | 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Internal.h | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.h | 2 +-
SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml | 117 ++++++++++++++++++++
13 files changed, 142 insertions(+), 24 deletions(-)
create mode 100644 SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml

--
2.28.0.windows.1


[PATCH v1 3/3] .azurepipelines: Add SourceLevelDebugPkg to CI

Michael Kubacki
 

From: Michael Kubacki <michael.kubacki@...>

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

Adds SourceLevelDebugPkg to the "OTHER" CI matrix job so it is built
in edk2 CI.

Cc: Sean Brogan <sean.brogan@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Hao A Wu <hao.a.wu@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
.azurepipelines/templates/pr-gate-build-job.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml b/.azurepipe=
lines/templates/pr-gate-build-job.yml
index 54a74a1a9873..d1628f1aa55d 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -41,7 +41,7 @@ jobs:
Build.Pkgs: 'NetworkPkg,RedfishPkg'
Build.Targets: 'DEBUG,RELEASE,NO-TARGET,NOOPT'
TARGET_OTHER:
- Build.Pkgs: 'PcAtChipsetPkg,PrmPkg,ShellPkg,StandaloneMmPkg'
+ Build.Pkgs: 'PcAtChipsetPkg,PrmPkg,ShellPkg,SourceLevelDebugPkg,=
StandaloneMmPkg'
Build.Targets: 'DEBUG,RELEASE,NO-TARGET,NOOPT'
TARGET_FMP_FAT_TEST:
Build.Pkgs: 'FmpDevicePkg,FatPkg,UnitTestFrameworkPkg,DynamicTab=
lesPkg'
--=20
2.28.0.windows.1


[PATCH v1 2/3] SourceLevelDebugPkg: Add package CI YAML file

Michael Kubacki
 

From: Michael Kubacki <michael.kubacki@...>

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

Adds the package as a supported package to .pytool/CISettings.py
and adds a CI YAML for the package so it can be run in CI.

Cc: Hao A Wu <hao.a.wu@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
.pytool/CISettings.py | 1 +
SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml | 117 ++++++++++++++++++=
++
2 files changed, 118 insertions(+)

diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index aef850a54549..f2c6303b2a08 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -70,6 +70,7 @@ class Settings(CiBuildSettingsManager, UpdateSettingsMa=
nager, SetupSettingsManag
"UnitTestFrameworkPkg",
"OvmfPkg",
"RedfishPkg",
+ "SourceLevelDebugPkg",
"UefiPayloadPkg"
)
=20
diff --git a/SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml b/SourceLeve=
lDebugPkg/SourceLevelDebugPkg.ci.yaml
new file mode 100644
index 000000000000..8887a6d10bc5
--- /dev/null
+++ b/SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml
@@ -0,0 +1,117 @@
+## @file
+# Core CI configuration for SourceLevelDebugPkg
+#
+# Copyright (c) Microsoft Corporation
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+{
+ ## options defined .pytool/Plugin/LicenseCheck
+ "LicenseCheck": {
+ "IgnoreFiles": []
+ },
+
+ "EccCheck": {
+ ## Exception sample looks like below:
+ ## "ExceptionList": [
+ ## "<ErrorID>", "<KeyWord>"
+ ## ]
+ "ExceptionList": [
+ ],
+ ## Both file path and directory path are accepted.
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/CompilerPlugin
+ "CompilerPlugin": {
+ "DscPath": "SourceLevelDebugPkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestCompilerPlugin
+ "HostUnitTestCompilerPlugin": {
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/CharEncodingCheck
+ "CharEncodingCheck": {
+ "IgnoreFiles": []
+ },
+
+ ## options defined .pytool/Plugin/DependencyCheck
+ "DependencyCheck": {
+ "AcceptableDependencies": [
+ "MdeModulePkg/MdeModulePkg.dec",
+ "MdePkg/MdePkg.dec",
+ "SecurityPkg/SecurityPkg.dec",
+ "SourceLevelDebugPkg/SourceLevelDebugPkg.dec",
+ "UefiCpuPkg/UefiCpuPkg.dec"
+ ],
+ # For host based unit tests
+ "AcceptableDependencies-HOST_APPLICATION":[
+ "UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec"
+ ],
+ # For UEFI shell based apps
+ "AcceptableDependencies-UEFI_APPLICATION":[],
+ "IgnoreInf": []
+ },
+
+ ## options defined .pytool/Plugin/DscCompleteCheck
+ "DscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "SourceLevelDebugPkg.dsc"
+ },
+
+ ## options defined .pytool/Plugin/HostUnitTestDscCompleteCheck
+ "HostUnitTestDscCompleteCheck": {
+ "IgnoreInf": [""],
+ "DscPath": "" # Don't support this test
+ },
+
+ ## options defined .pytool/Plugin/GuidCheck
+ "GuidCheck": {
+ "IgnoreGuidName": [],
+ "IgnoreGuidValue": [],
+ "IgnoreFoldersAndFiles": [],
+ "IgnoreDuplicates": [],
+ },
+
+ ## options defined .pytool/Plugin/LibraryClassCheck
+ "LibraryClassCheck": {
+ "IgnoreHeaderFile": []
+ },
+
+ ## options defined .pytool/Plugin/SpellCheck
+ "SpellCheck": {
+ "AuditOnly": False, # All failures were addressed when =
SpellCheck was enabled in this package
+ "IgnoreFiles": [], # use gitignore syntax to ignore er=
rors in matching files
+ "ExtendWords": [ # words to extend to the dictionary=
for this package
+ "bidir",
+ "bsp's",
+ "capbility", # comes from external package
+ "dcddi",
+ "dcerstba",
+ "dcportsc",
+ "dcerstsz",
+ "epring",
+ "evalu",
+ "fxrestor",
+ "hccparams",
+ "hcsparams",
+ "iretd",
+ "iretq",
+ "isoch",
+ "mfindex",
+ "ompressed",
+ "portsc",
+ "sequenceno",
+ "smmentrybreak",
+ "stosd",
+ "stosq",
+ "ttach",
+ "urb's",
+ "xhc's"
+ ],
+ "IgnoreStandardPaths": [], # Standard Plugin defined paths tha=
t should be ignore
+ "AdditionalIncludePaths": [] # Additional paths to spell check (=
wildcards supported)
+ }
+}
--=20
2.28.0.windows.1


[PATCH v1 1/3] SourceLevelDebugPkg: Fix spelling errors

Michael Kubacki
 

From: Michael Kubacki <michael.kubacki@...>

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

Fixes spelling errors in the package so the SpellCheck CI plugin can
be enabled.

Cc: Hao A Wu <hao.a.wu@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c =
| 8 +++----
SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c =
| 22 ++++++++++----------
SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommuni=
cationLibSerialPort.c | 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationL=
ibUsb.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandlerFun=
cs.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandlerFunc=
s.c | 2 +-
SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h =
| 2 +-
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.h =
| 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunication=
LibUsb3Internal.h | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionL=
ib.h | 2 +-
10 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Debu=
gAgent.c b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA=
gent.c
index a1e61a6ef90e..b553a2a9aa0c 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.=
c
+++ b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.=
c
@@ -1,5 +1,5 @@
/** @file
- Commond Debug Agent library implementation. It mainly includes
+ Common Debug Agent library implementation. It mainly includes
the first C function called by exception/interrupt handlers,
read/write debug packet to communication with HOST based on transfer
protocol.
@@ -608,7 +608,7 @@ DebugAgentDataMsgPrint (
}
=20
/**
- Read remaing debug packet except for the start symbol
+ Read remaining debug packet except for the start symbol
=20
@param[in] Handle Pointer to Debug Port handle.
@param[in, out] DebugHeader Debug header buffer including start symb=
ol.
@@ -616,7 +616,7 @@ DebugAgentDataMsgPrint (
@retval EFI_SUCCESS Read the symbol in BreakSymbol.
@retval EFI_CRC_ERROR CRC check fail.
@retval EFI_TIMEOUT Timeout occurs when reading debug packet.
- @retval EFI_DEVICE_ERROR Receive the old or responsed packet.
+ @retval EFI_DEVICE_ERROR Receive the old or response packet.
=20
**/
EFI_STATUS
@@ -651,7 +651,7 @@ ReadRemainingBreakPacket (
if (IS_REQUEST (DebugHeader)) {
if (DebugHeader->SequenceNo =3D=3D (UINT8)(Mailbox->HostSequenceNo +=
1)) {
//
- // Only updagte HostSequenceNo for new command packet
+ // Only update HostSequenceNo for new command packet
//
UpdateMailboxContent (Mailbox, DEBUG_MAILBOX_HOST_SEQUENCE_NO_INDE=
X, DebugHeader->SequenceNo);
return EFI_SUCCESS;
diff --git a/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialI=
o.c b/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c
index 6661275cc343..97d30c802df4 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c
+++ b/SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c
@@ -213,10 +213,10 @@ SERIAL_IO_DEVICE_PATH mSerialIoDevicePath =3D {
}
};
=20
-#define DEBGU_SERIAL_IO_FIFO_DEPTH 10
+#define DEBUG_SERIAL_IO_FIFO_DEPTH 10
//
// Data buffer for Terminal input character and Debug Symbols.
-// The depth is DEBGU_SERIAL_IO_FIFO_DEPTH.
+// The depth is DEBUG_SERIAL_IO_FIFO_DEPTH.
// Fields:
// First UINT8: The index of the first data in array Data[].
// Last UINT8: The index, which you can put a new data into arra=
y Data[].
@@ -227,7 +227,7 @@ typedef struct {
UINT8 First;
UINT8 Last;
UINT8 Surplus;
- UINT8 Data[DEBGU_SERIAL_IO_FIFO_DEPTH];
+ UINT8 Data[DEBUG_SERIAL_IO_FIFO_DEPTH];
} DEBUG_SERIAL_FIFO;
=20
//
@@ -236,10 +236,10 @@ typedef struct {
EFI_HANDLE mSerialIoHandle =3D NULL;
UINTN mLoopbackBuffer =3D 0;
DEBUG_SERIAL_FIFO mSerialFifoForTerminal =3D {
- 0, 0, DEBGU_SERIAL_IO_FIFO_DEPTH, { 0 }
+ 0, 0, DEBUG_SERIAL_IO_FIFO_DEPTH, { 0 }
};
DEBUG_SERIAL_FIFO mSerialFifoForDebug =3D {
- 0, 0, DEBGU_SERIAL_IO_FIFO_DEPTH, { 0 }
+ 0, 0, DEBUG_SERIAL_IO_FIFO_DEPTH, { 0 }
};
=20
/**
@@ -251,11 +251,11 @@ DEBUG_SERIAL_FIFO mSerialFifoForDebug =3D {
=20
**/
BOOLEAN
-IsDebugTermianlFifoEmpty (
+IsDebugTerminalFifoEmpty (
IN DEBUG_SERIAL_FIFO *Fifo
)
{
- if (Fifo->Surplus =3D=3D DEBGU_SERIAL_IO_FIFO_DEPTH) {
+ if (Fifo->Surplus =3D=3D DEBUG_SERIAL_IO_FIFO_DEPTH) {
return TRUE;
}
=20
@@ -313,7 +313,7 @@ DebugTerminalFifoAdd (
Fifo->Data[Fifo->Last] =3D Data;
Fifo->Surplus--;
Fifo->Last++;
- if (Fifo->Last =3D=3D DEBGU_SERIAL_IO_FIFO_DEPTH) {
+ if (Fifo->Last =3D=3D DEBUG_SERIAL_IO_FIFO_DEPTH) {
Fifo->Last =3D 0;
}
=20
@@ -339,7 +339,7 @@ DebugTerminalFifoRemove (
//
// if FIFO is empty, no data can remove
//
- if (IsDebugTermianlFifoEmpty (Fifo)) {
+ if (IsDebugTerminalFifoEmpty (Fifo)) {
return EFI_OUT_OF_RESOURCES;
}
=20
@@ -349,7 +349,7 @@ DebugTerminalFifoRemove (
*Data =3D Fifo->Data[Fifo->First];
Fifo->Surplus++;
Fifo->First++;
- if (Fifo->First =3D=3D DEBGU_SERIAL_IO_FIFO_DEPTH) {
+ if (Fifo->First =3D=3D DEBUG_SERIAL_IO_FIFO_DEPTH) {
Fifo->First =3D 0;
}
=20
@@ -532,7 +532,7 @@ SerialGetControl (
// Check to see if the Terminal FIFO is empty and
// check to see if the input buffer in the Debug Communication Library=
is empty
//
- if (!IsDebugTermianlFifoEmpty (&mSerialFifoForTerminal) || DebugPortPo=
llBuffer (Handle)) {
+ if (!IsDebugTerminalFifoEmpty (&mSerialFifoForTerminal) || DebugPortPo=
llBuffer (Handle)) {
*Control &=3D ~EFI_SERIAL_INPUT_BUFFER_EMPTY;
}
=20
diff --git a/SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/=
DebugCommunicationLibSerialPort.c b/SourceLevelDebugPkg/Library/DebugComm=
unicationLibSerialPort/DebugCommunicationLibSerialPort.c
index 34c269e6b527..9953904725ac 100644
--- a/SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCo=
mmunicationLibSerialPort.c
+++ b/SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCo=
mmunicationLibSerialPort.c
@@ -70,7 +70,7 @@ DebugPortInitialize (
}
=20
/**
- Read data from debug device and save the datas in buffer.
+ Read data from debug device and save the data in a buffer.
=20
Reads NumberOfBytes data bytes from a debug device into the buffer
specified by Buffer. The number of bytes actually read is returned.
diff --git a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCo=
mmunicationLibUsb.c b/SourceLevelDebugPkg/Library/DebugCommunicationLibUs=
b/DebugCommunicationLibUsb.c
index 479757f5bae2..da55f3e69ef0 100644
--- a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunica=
tionLibUsb.c
+++ b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunica=
tionLibUsb.c
@@ -768,7 +768,7 @@ InitializeUsbDebugHardware (
}
=20
/**
- Read data from debug device and save the datas in buffer.
+ Read data from debug device and save the data in a buffer.
=20
Reads NumberOfBytes data bytes from a debug device into the buffer
specified by Buffer. The number of bytes actually read is returned.
diff --git a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/I=
ntHandlerFuncs.c b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/=
Ia32/IntHandlerFuncs.c
index 600bde10d656..3e6db0db8679 100644
--- a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandl=
erFuncs.c
+++ b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandl=
erFuncs.c
@@ -15,7 +15,7 @@
@param[in] InterruptType Interrupt type.
=20
@retval TRUE IDT entries were setup by Debug Agent.
- @retval FALSE IDT entries were not setuo by Debug Agent.
+ @retval FALSE IDT entries were not setup by Debug Agent.
=20
**/
BOOLEAN
diff --git a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/In=
tHandlerFuncs.c b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X=
64/IntHandlerFuncs.c
index 952285a8eac0..1baa88206b06 100644
--- a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandle=
rFuncs.c
+++ b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandle=
rFuncs.c
@@ -15,7 +15,7 @@
@param[in] InterruptType Interrupt type.
=20
@retval TRUE IDT entries were setup by Debug Agent.
- @retval FALSE IDT entries were not setuo by Debug Agent.
+ @retval FALSE IDT entries were not setup by Debug Agent.
=20
**/
BOOLEAN
diff --git a/SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h =
b/SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h
index ad7bccda285c..ebb2168632da 100644
--- a/SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h
+++ b/SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h
@@ -71,7 +71,7 @@ DebugPortInitialize (
);
=20
/**
- Read data from debug device and save the datas in buffer.
+ Read data from debug device and save the data in a buffer.
=20
Reads NumberOfBytes data bytes from a debug device into the buffer
specified by Buffer. The number of bytes actually read is returned.
diff --git a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Debu=
gAgent.h b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugA=
gent.h
index a0ede308efee..4c72f8f3a90c 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.=
h
+++ b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.=
h
@@ -452,7 +452,7 @@ DebugAgentDataMsgPrint (
);
=20
/**
- Read remaing debug packet except for the start symbol
+ Read remaining debug packet except for the start symbol
=20
@param[in] Handle Pointer to Debug Port handle.
@param[in, out] DebugHeader Debug header buffer including start symb=
ol.
diff --git a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugC=
ommunicationLibUsb3Internal.h b/SourceLevelDebugPkg/Library/DebugCommunic=
ationLibUsb3/DebugCommunicationLibUsb3Internal.h
index c73233ea49b0..cc5f294f334d 100644
--- a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunic=
ationLibUsb3Internal.h
+++ b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunic=
ationLibUsb3Internal.h
@@ -586,7 +586,7 @@ XhcWriteDebugReg (
/**
Verifies if the bit positions specified by a mask are set in a registe=
r.
=20
- @param[in, out] Register UNITN register
+ @param[in, out] Register UINTN register
@param[in] BitMask 32-bit mask
=20
@return BOOLEAN - TRUE if all bits specified by the mask are enable=
d.
diff --git a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoff=
ExtraActionLib.h b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/=
PeCoffExtraActionLib.h
index 149186b226f4..f428af963231 100644
--- a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAc=
tionLib.h
+++ b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAc=
tionLib.h
@@ -34,7 +34,7 @@ extern UINTN AsmInterruptHandle;
@param[in] InterruptType Interrupt type.
=20
@retval TRUE IDT entries were setup by Debug Agent.
- @retval FALSE IDT entries were not setuo by Debug Agent.
+ @retval FALSE IDT entries were not setup by Debug Agent.
=20
**/
BOOLEAN
--=20
2.28.0.windows.1


[PATCH v1 0/3] SourceLevelDebugPkg: Enable CI

Michael Kubacki
 

From: Michael Kubacki <michael.kubacki@...>

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

1. Fixes pre-existing spelling errors in the package.
2. Adds SourceLevelDebugPkg to edk2 CI.

CI results are available in the PR:
https://github.com/tianocore/edk2/pull/3439

Cc: Hao A Wu <hao.a.wu@...>
Cc: Liming Gao <gaoliming@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Sean Brogan <sean.brogan@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>

Michael Kubacki (3):
SourceLevelDebugPkg: Fix spelling errors
SourceLevelDebugPkg: Add package CI YAML file
.azurepipelines: Add SourceLevelDebugPkg to CI

SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c =
| 8 +-
SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgent/SerialIo.c =
| 22 ++--
SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommuni=
cationLibSerialPort.c | 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationL=
ibUsb.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandlerFun=
cs.c | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandlerFunc=
s.c | 2 +-
.azurepipelines/templates/pr-gate-build-job.yml =
| 2 +-
.pytool/CISettings.py =
| 1 +
SourceLevelDebugPkg/Include/Library/DebugCommunicationLib.h =
| 2 +-
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.h =
| 2 +-
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunication=
LibUsb3Internal.h | 2 +-
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionL=
ib.h | 2 +-
SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml =
| 117 ++++++++++++++++++++
13 files changed, 142 insertions(+), 24 deletions(-)
create mode 100644 SourceLevelDebugPkg/SourceLevelDebugPkg.ci.yaml

--
2.28.0.windows.1


Community Meeting

Demeter, Miki
 

The TianoCore Community meeting has been moved out 1 week to October 13th, 2022

-- 

Miki Demeter (she/her/Miki)

Security Researcher / FW Developer

FST

Intel Corporation

 

Co-Chair, Network of Intel African-Ancestry(NIA) - Oregon

NIA-Oregon

 

Portland Women in Tech Best Speaker

miki.demeter@...

 


Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library

Girish Mahadevan
 

Hi Sami

Response inline.[GM]

Best Regards
Girish

On 10/4/2022 2:16 AM, Sami Mujawar wrote:
External email: Use caution opening links or attachments
Hi Girish,
There are 2 cases that need handling. Please see my response inline
marked [SAMI].
Regards,
Sami Mujawar
On 04/10/2022 04:01 am, Girish Mahadevan wrote:
Hello Sami,

My apologies for the late response. I had one question/comment.

Comment marked with [GM] inline.

Best Regards
Girish

On 9/12/2022 8:18 AM, Sami Mujawar wrote:
External email: Use caution opening links or attachments


The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.

Test strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.

Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.

SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the
string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.

Example:
EFI_STATUS
BuildSmbiosType17Table () {
   STRING_TABLE         StrTable;
   UINT8                DevLocatorRef;
   UINT8                BankLocatorRef;
   SMBIOS_TABLE_TYPE17  *SmbiosRecord;
   CHAR8                *StringSet;
   ...

   // Initialize string table for 7 strings
   StringTableInitialize (&StrTable, 7);

   StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
   StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
   ...

   SmbiosRecord = AllocateZeroPool (
                    sizeof (SMBIOS_TABLE_TYPE17) +
                      StringTableGetStringSetSize (&StrTable)
                    );
   ...
   SmbiosRecord->DeviceLocator = DevLocatorRef;
   SmbiosRecord->BankLocator = BankLocatorRef;
   ...
   // get the string set area
   StringSet = (CHAR8*)(SmbiosRecord + 1);

   // publish the string set
   StringTablePublishStringSet (
     &StrTable,
     StringSet,
     StringTableGetStringSetSize (&StrTable)
     );

   // free string table
   StringTableFree (&StrTable);

   return EFI_SUCCESS;
}

Signed-off-by: Sami Mujawar <sami.mujawar@...>
Cc: Alexei Fedorov <Alexei.Fedorov@...>
Cc: Pierre Gondois <pierre.gondois@...>
Cc: Girish Mahadevan <gmahadevan@...>
Cc: Jeff Brasen <jbrasen@...>
Cc: Ashish Singhal <ashishsingha@...>
Cc: Nick Ramirez <nramirez@...>
Cc: William Watson <wwatson@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
---
The changes can be seen at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsamimujawar%2Fedk2%2Ftree%2F2370_smbios_stringlib_v1&;data=05%7C01%7Cgmahadevan%40nvidia.com%7Cc983eff139e143b459ea08daa5e0c308%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638004682041794981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=S5QKosbQutvQs17jTnZUHrxrTcxJmClwuUpdMRVoJKU%3D&amp;reserved=0

DynamicTablesPkg/DynamicTables.dsc.inc |   3 +-
DynamicTablesPkg/DynamicTablesPkg.dec |   5 +-
DynamicTablesPkg/DynamicTablesPkg.dsc |   3 +-
DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h | 119 ++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
| 227 ++++++++++++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
|  25 +++
  6 files changed, 379 insertions(+), 3 deletions(-)

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc
b/DynamicTablesPkg/DynamicTables.dsc.inc
index
3d4fa0c4c4b67d6770aee8705c80cc18d20c823a..d35acc1788f2ddc5e2b5fc3e4bedfd48251f7ec8
100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
  ## @file
  #  Dsc include file for Dynamic Tables Framework.
  #
-#  Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+#  Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -18,6 +18,7 @@ [LibraryClasses.common]
SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
+
SmbiosStringTableLib|DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

  [Components.common]
    #
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec
b/DynamicTablesPkg/DynamicTablesPkg.dec
index
cc34c2bdd6ff9b5ca508961b3d0fe85ffbb73c12..2a79cfd4edebbdff05bee66fa01a17d68252e8a7
100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -1,7 +1,7 @@
  ## @file
  # dec file for Dynamic Tables Framework.
  #
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
  #
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -39,6 +39,9 @@ [LibraryClasses]
    ##  @libraryclass  Defines a set of helper methods.
    TableHelperLib|Include/Library/TableHelperLib.h

+  ##  @libraryclass  Defines a set of SMBIOS string helper methods.
+  SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
+
  [Protocols]
    # Configuration Manager Protocol GUID
    gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82,
0x4894, { 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc
b/DynamicTablesPkg/DynamicTablesPkg.dsc
index
07cc837552f587fe5bf9031e0061b0234e8698d4..bd5084a9008f040acdd16200ae8cdb23455ac101
100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dsc
+++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
@@ -2,7 +2,7 @@
  #  Dsc file for Dynamic Tables Framework.
  #
  #  Copyright (c) 2019, Linaro Limited. All rights reserved.<BR>
-#  Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.<BR>
+#  Copyright (c) 2019 - 2022, Arm Limited. All rights reserved.<BR>
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -46,6 +46,7 @@ [Components.common]
DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf
+
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

  [BuildOptions]
    *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git a/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
new file mode 100644
index
0000000000000000000000000000000000000000..246d4d30ddf901640ea720c108e2971552ec6c96
--- /dev/null
+++ b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
@@ -0,0 +1,119 @@
+/** @file
+  SMBIOS String Table Helper library.
+
+  Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SMBIOS_STRING_TABLE_H_
+#define SMBIOS_STRING_TABLE_H_
+
+/** A structure representing a string in the string table.
+*/
+typedef struct StringElement {
+  /// Length of the string (does not include the NULL termination)
+  UINTN          StringLen;
+
+  /// Reference to the string
+  CONST CHAR8    *String;
+} STRING_ELEMENT;
+
+/** A structure representing a string table.
+*/
+typedef struct StringTable {
+  /// Count of strings in the table
+  UINT8             StrCount;
+
+  /// Total length of all strings in the table (does not include
+  // the NULL termination for each string)
+  UINTN             TotalStrLen;
+
+  /// Maximum string count
+  UINT8             MaxStringElements;
+
+  /// Pointer to the string table elements
+  STRING_ELEMENT    *Elements;
+} STRING_TABLE;
+
+/** Add a string to the string table
+
+  @param [IN]   StrTable  Pointer to the string table
+  @param [IN]   Str       Pointer to the string
+  @param [OUT]  StrRef    Optional pointer to retrieve the string field
+                          reference of the string in the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+  IN        STRING_TABLE *CONST  StrTable,
+  IN  CONST CHAR8                *Str,
+  OUT       UINT8                *StrRef      OPTIONAL
+  );
+
+/** Returns the total size required to publish the strings to the
SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+
+  @return Total size required to publish the strings in the SMBIOS
string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+  IN  STRING_TABLE *CONST  StrTable
+  );
+
+/** Iterate through the string table and publish the strings in the
SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+  @param [IN] SmbiosStringAreaStart Start address of the SMBIOS
string area.
+  @param [IN] SmbiosStringAreaSize  Size of the SMBIOS string area.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+  IN        STRING_TABLE  *CONST  StrTable,
+  IN        CHAR8         *CONST  SmbiosStringAreaStart,
+  IN  CONST UINTN                 SmbiosStringAreaSize
+  );
+
+/** Initialise the string table and allocate memory for the string
elements.
+
+  @param [IN] StrTable           Pointer to the string table
+  @param [IN] MaxStringElements  Maximum number of strings that the
string
+                                 table can hold.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_OUT_OF_RESOURCES   Failed to allocate memory for
string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+  IN STRING_TABLE *CONST  StrTable,
+  IN UINTN                MaxStringElements
+  );
+
+/** Free memory allocated for the string elements in the string table.
+
+  @param [IN] StrTable           Pointer to the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer or
string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+  IN STRING_TABLE *CONST  StrTable
+  );
+
+#endif // SMBIOS_STRING_TABLE_H_
diff --git
a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c

new file mode 100644
index
0000000000000000000000000000000000000000..bd186f27fe1613cf819b6600e62960c003a796d6
--- /dev/null
+++
b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
@@ -0,0 +1,227 @@
+/** @file
+  SMBIOS String Table Helper
+
+  Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - DSP0134 - SMBIOS Specification Version 3.6.0, 2022-06-17
+**/
+
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/SmbiosStringTableLib.h>
+
+/** Add a string to the string table
+
+  @param [IN]   StrTable  Pointer to the string table
+  @param [IN]   Str       Pointer to the string
+  @param [OUT]  StrRef    Optional pointer to retrieve the string field
+                          reference of the string in the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+  IN        STRING_TABLE *CONST  StrTable,
+  IN  CONST CHAR8                *Str,
+  OUT       UINT8                *StrRef      OPTIONAL
+  )
+{
+  UINTN           StrLength;
+  STRING_ELEMENT  *StrElement;
+
+  if ((StrTable == NULL) || (Str == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  if (StrTable->StrCount >= StrTable->MaxStringElements) {
+    return EFI_BUFFER_TOO_SMALL;
+  }
+
+  StrLength = AsciiStrLen (Str);
+  if (StrLength == 0) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  // Update the string element
+  StrElement            = &StrTable->Elements[StrTable->StrCount];
+  StrElement->StringLen = StrLength;
+  StrElement->String    = Str;
+
+  // Update String table information
+  StrTable->TotalStrLen += StrLength;
+  StrTable->StrCount++;
+
+  // Return the index of the string in the string table if requested
+  if (StrRef != NULL) {
+    // Note: SMBIOS string field references start at 1. So, return the
+    // StrCount as the string refrence after it is updated.
+    *StrRef = StrTable->StrCount;
+  }
+
+  return EFI_SUCCESS;
+}
+
+/** Returns the total size required to publish the strings to the
SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+
+  @return Total size required to publish the strings in the SMBIOS
string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+  IN  STRING_TABLE *CONST  StrTable
+  )
+{
+  if (StrTable == NULL) {
+    ASSERT (0);
+    return 0;
+  }
+
+  // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+  // - If the formatted portion of the structure contains
string-reference
+  //   fields and all the string fields are set to 0 (no string
references),
+  //   the formatted section of the structure is followed by two
null (00h)
+  //   BYTES.
+  // - Each string is terminated with a null (00h) BYTE
+  // - and the set of strings is terminated with an additional null
(00h) BYTE.
+
+  // Therefore, if string count = 0, return 2
+  // if string count > 0, the string set size =
+  // StrTable->TotalStrLen (total length of the strings in the
string table)
+  // + StrTable->StrCount (add string count to include '\0' for each
string)
+  // +1 (an additional '\0' is required at the end of the string set).
+  return (StrTable->StrCount == 0) ? 2 :
+         (StrTable->TotalStrLen + StrTable->StrCount + 1);
+}
+
+/** Iterate through the string table and publish the strings in the
SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+  @param [IN] SmbiosStringAreaStart Start address of the SMBIOS
string area.
+  @param [IN] SmbiosStringAreaSize  Size of the SMBIOS string area.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+  IN        STRING_TABLE  *CONST  StrTable,
+  IN        CHAR8         *CONST  SmbiosStringAreaStart,
+  IN  CONST UINTN                 SmbiosStringAreaSize
+  )
+{
+  UINT8           Index;
+  STRING_ELEMENT  *StrElement;
+  CHAR8           *SmbiosString;
+  UINTN           BytesRemaining;
+  UINTN           BytesCopied;
+
+  if ((StrTable == NULL) || (SmbiosStringAreaStart == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  if (SmbiosStringAreaSize < StringTableGetStringSetSize (StrTable)) {
+    return EFI_BUFFER_TOO_SMALL;
+  }
+
+  SmbiosString   = SmbiosStringAreaStart;
+  BytesRemaining = SmbiosStringAreaSize;
[SAMI] SmbiosString points to the startof the sting storage area.
+
+  if (StrTable->StrCount == 0) {
+    // See Section 6.1.3 Text strings, SMBIOS Specification Version
3.6.0
+    // If the formatted portion of the structure contains
string-reference
+    // fields and all the string fields are set to 0 (no string
references),
+    // the formatted section of the structure is followed by two
null (00h)
+    // BYTES.
+    *SmbiosString++ = '\0';
[SAMI] Case 1: SmbiosString[0] is set to '\0' and the pointer is
incremented. So now it points to SmbiosString[1] which will be updated
with the String table null terminator before the function returns.
+  } else {
+    for (Index = 0; Index < StrTable->StrCount; Index++) {
+      StrElement = &StrTable->Elements[Index];
+      AsciiStrCpyS (SmbiosString, BytesRemaining, StrElement->String);
+
+      // See Section 6.1.3 Text strings, SMBIOS Specification
Version 3.6.0
+      // - Each string is terminated with a null (00h) BYTE
+      // Bytes Copied = String length + 1 for the string NULL
terminator.
+      BytesCopied     = StrElement->StringLen + 1;
+      BytesRemaining -= BytesCopied;
+      SmbiosString   += BytesCopied;
[SAMI] Case 2: AsciiStrCpyS() copies the string including the
terrminating null character and BytesCopied is incremented accordingly.
SmbiosString is then incremented by BytesCopied. So, SmbiosString should
point to the byte where the next string starts or will be updated with
the String table null terminator before the function returns.
+    }
+  }
+
+  // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+  // - the set of strings is terminated with an additional null
(00h) BYTE.
+  *SmbiosString = '\0';
[GM] Shouldn't you advance the SmbiosString pointer by one more ?
After the loop isn't SmbiosString going to be at the NULL char of the
last string ? And we're trying to add one more NULL character ?
Should it be:
SmbiosString++;
[SAMI] I don't think this increment is required for the reasons
explained above in Case 1 & Case 2. However, please let me know if I
have missed something.
*SmbiosString = '\0';
[GM]
Got it. Thanks for detail.
Patch looks good to me, I've tested it as well. Thanks a lot.



+  return EFI_SUCCESS;
+}
+
+/** Initialise the string table and allocate memory for the string
elements.
+
+  @param [IN] StrTable           Pointer to the string table
+  @param [IN] MaxStringElements  Maximum number of strings that the
string
+                                 table can hold.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_OUT_OF_RESOURCES   Failed to allocate memory for
string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+  IN STRING_TABLE *CONST  StrTable,
+  IN UINTN                MaxStringElements
+  )
+{
+  STRING_ELEMENT  *Elements;
+
+  if ((StrTable == NULL) || (MaxStringElements > MAX_UINT8)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  ZeroMem (StrTable, sizeof (STRING_TABLE));
+
+  Elements = (STRING_ELEMENT *)AllocateZeroPool (
+                                 sizeof (STRING_ELEMENT) *
MaxStringElements
+                                 );
+  if (Elements == NULL) {
+    return EFI_OUT_OF_RESOURCES;
+  }
+
+  StrTable->Elements          = Elements;
+  StrTable->MaxStringElements = (UINT8)MaxStringElements;
+  return EFI_SUCCESS;
+}
+
+/** Free memory allocated for the string elements in the string table.
+
+  @param [IN] StrTable           Pointer to the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer or
string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+  IN STRING_TABLE *CONST  StrTable
+  )
+{
+  if ((StrTable == NULL) || (StrTable->Elements == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  FreePool (StrTable->Elements);
+  ZeroMem (StrTable, sizeof (STRING_TABLE));
+  return EFI_SUCCESS;
+}
diff --git
a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

new file mode 100644
index
0000000000000000000000000000000000000000..88624c50e3f3e930074222b6d686f75485538b26
--- /dev/null
+++
b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
@@ -0,0 +1,25 @@
+## @file
+#  SMBIOS String Table Helper library.
+#
+#  Copyright (c) 2022, Arm Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION    = 0x0001001B
+  BASE_NAME      = SmbiosStringTableLib
+  FILE_GUID      = 8C570DD8-531E-473F-85C6-9252746DBAC1
+  VERSION_STRING = 1.0
+  MODULE_TYPE    = DXE_DRIVER
+  LIBRARY_CLASS  = SmbiosStringTableLib
+
+[Sources]
+  SmbiosStringTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  DynamicTablesPkg/DynamicTablesPkg.dec
+
+[LibraryClasses]
+  BaseLib
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


[RESEND PATCH 1/1] MdeModulePkg: Fix PiSmmCore integer over- and underflows.

Gerd Hoffmann
 

Prevents potential math over and underflows when comparing buffers
for SMM validity.

Original patch uploaded to bugzilla by Bret Barkelew <bret@...>.
I've adapted the patch to latest master, uncristified, dropped MU
comments.

Ref: CVE-2021-38578
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3387
Signed-off-by: Gerd Hoffmann <kraxel@...>
---
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf | 1 +
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 1 +
MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 32 ++++++++++++++++-------
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 10 +++++--
5 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index c8bfae3860fc..3df44b38f13c 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -60,6 +60,7 @@ [LibraryClasses]
PerformanceLib
HobLib
SmmMemLib
+ SafeIntLib

[Protocols]
gEfiDxeSmmReadyToLockProtocolGuid ## UNDEFINED # SmiHandlerRegister
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
index 6109d6b5449c..ddeb39cee266 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
@@ -46,6 +46,7 @@ [LibraryClasses]
DxeServicesLib
PcdLib
ReportStatusCodeLib
+ SafeIntLib

[Protocols]
gEfiSmmBase2ProtocolGuid ## PRODUCES
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 71422b9dfcdf..b8a490a8c3b5 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -54,6 +54,7 @@
#include <Library/PerformanceLib.h>
#include <Library/HobLib.h>
#include <Library/SmmMemLib.h>
+#include <Library/SafeIntLib.h>

#include "PiSmmCorePrivateData.h"
#include "HeapGuard.h"
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 9e5c6cbe33dd..5ef8b31ee361 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -610,6 +610,7 @@ SmmEndOfS3ResumeHandler (
@param[in] Size2 Size of Buff2

@retval TRUE Buffers overlap in memory.
+ @retval TRUE Math error.
@retval FALSE Buffer doesn't overlap.

**/
@@ -621,11 +622,21 @@ InternalIsBufferOverlapped (
IN UINTN Size2
)
{
+ UINTN End1;
+ UINTN End2;
+
+ // Prevents potential math over and underflows.
+ if (EFI_ERROR (SafeUintnAdd ((UINTN)Buff1, Size1, &End1)) ||
+ EFI_ERROR (SafeUintnAdd ((UINTN)Buff2, Size2, &End2)))
+ {
+ return TRUE;
+ }
+
//
// If buff1's end is less than the start of buff2, then it's ok.
// Also, if buff1's start is beyond buff2's end, then it's ok.
//
- if (((Buff1 + Size1) <= Buff2) || (Buff1 >= (Buff2 + Size2))) {
+ if ((End1 <= (UINTN)Buff2) || ((UINTN)Buff1 >= End2)) {
return FALSE;
}

@@ -699,7 +710,10 @@ SmmEntryPoint (
(UINT8 *)gSmmCorePrivate,
sizeof (*gSmmCorePrivate)
);
- if (!SmmIsBufferOutsideSmmValid ((UINTN)CommunicationBuffer, BufferSize) || IsOverlapped) {
+ if (!SmmIsBufferOutsideSmmValid ((UINTN)CommunicationBuffer, BufferSize) ||
+ IsOverlapped ||
+ EFI_ERROR (SafeUintnSub (BufferSize, OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, Data), &BufferSize)))
+ {
//
// If CommunicationBuffer is not in valid address scope,
// or there is overlap between gSmmCorePrivate and CommunicationBuffer,
@@ -709,13 +723,13 @@ SmmEntryPoint (
gSmmCorePrivate->ReturnStatus = EFI_ACCESS_DENIED;
} else {
CommunicateHeader = (EFI_SMM_COMMUNICATE_HEADER *)CommunicationBuffer;
- BufferSize -= OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, Data);
- Status = SmiManage (
- &CommunicateHeader->HeaderGuid,
- NULL,
- CommunicateHeader->Data,
- &BufferSize
- );
+ // BufferSize was updated by the SafeUintnSub() call above.
+ Status = SmiManage (
+ &CommunicateHeader->HeaderGuid,
+ NULL,
+ CommunicateHeader->Data,
+ &BufferSize
+ );
//
// Update CommunicationBuffer, BufferSize and ReturnStatus
// Communicate service finished, reset the pointer to CommBuffer to NULL
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index 4f00cebaf5ed..f08ca55e26b7 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -34,6 +34,7 @@
#include <Library/UefiRuntimeLib.h>
#include <Library/PcdLib.h>
#include <Library/ReportStatusCodeLib.h>
+#include <Library/SafeIntLib.h>

#include "PiSmmCorePrivateData.h"

@@ -1354,6 +1355,7 @@ SmmSplitSmramEntry (
@param[in] ReservedRangeToCompare Pointer to EFI_SMM_RESERVED_SMRAM_REGION to compare.

@retval TRUE There is overlap.
+ @retval TRUE Math error.
@retval FALSE There is no overlap.

**/
@@ -1366,8 +1368,12 @@ SmmIsSmramOverlap (
UINT64 RangeToCompareEnd;
UINT64 ReservedRangeToCompareEnd;

- RangeToCompareEnd = RangeToCompare->CpuStart + RangeToCompare->PhysicalSize;
- ReservedRangeToCompareEnd = ReservedRangeToCompare->SmramReservedStart + ReservedRangeToCompare->SmramReservedSize;
+ // Prevents potential math over and underflows.
+ if (EFI_ERROR (SafeUint64Add ((UINT64)RangeToCompare->CpuStart, RangeToCompare->PhysicalSize, &RangeToCompareEnd)) ||
+ EFI_ERROR (SafeUint64Add ((UINT64)ReservedRangeToCompare->SmramReservedStart, ReservedRangeToCompare->SmramReservedSize, &ReservedRangeToCompareEnd)))
+ {
+ return TRUE;
+ }

if ((RangeToCompare->CpuStart >= ReservedRangeToCompare->SmramReservedStart) &&
(RangeToCompare->CpuStart < ReservedRangeToCompareEnd))
--
2.37.3


Re: The principles of EDK2 module reconstruction for archs

Michael D Kinney
 

I would not add link to Wiki from EDK II C Coding Standard Specification.

We want documents published from tianocore-docs to support standalone
formats such as PDF and if there is a link in one of those documents,
we want to know that it is a permanent link. I am concerned we may
reorganize Wiki pages and links in PDF would become stale.

Links from Wiki to specs makes sense.

Mike

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Tuesday, October 4, 2022 7:05 AM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; quic_llindhol@...; Ni, Ray <ray.ni@...>;
Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

[AMD Official Use Only - General]



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 4, 2022 12:54 AM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
(Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
archs

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


Hi Abner,

responses below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang,
Abner via groups.io
Sent: Sunday, October 2, 2022 10:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction
for archs

[AMD Official Use Only - General]

Mike,
Agree. This can be mentioned on the Wiki page. Also, this would
require the discussion between maintainer and contributor. I would say
maintainer has the responsibility to make sure an arch folder is only created
when necessary.

Agreed
Ok, I will update Directory and file names section.


Do you agree with the arch concatenate solution for arch folder? That
means IA32_X64 instead of X86 (I am fine with this)?

Yes

However, there is one scenario. Assume there were two arch folders
IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64, we may
rename IA32_X64 to IA32_X64_ARM.
Although the directory naming is not real a problem to the build, a
separate ARM folder seems easier? Or we can just allow this kind of folder
naming structure, however we let maintainer to make the decision?

I would let the maintainer make the decision. For your example, another
approach may be to move the IA32_X64 content up a level so it is common
and is used by IA32, X64, ARM. And leave RISCV64 folder for an arch that has
special requirements. I think having some flexibility in the guidelines is very
beneficial. The main goal is for consistency when a specific guideline is
followed.
I think we can have the naming rules in the edk2 C coding standard spec and put these guidelines on the Wiki page.
Is that ok to have a link to Wiki page in the edk2 C coding standard spec?

Abner



Abner


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Monday, October 3, 2022 1:18 PM
To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Abner,

I think another guideline is to minimize the number of subdirectories.

Only create them if it helps with the organization and long term
maintenance of the component.

Mike


-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Sunday, October 2, 2022 8:13 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Hi Mike and Leif,
First of all, we don't use arch folder if the module is mainly for
a specific arch in obviously. So we will have both common and
arch-specific
files constructed under module/library root.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed
k
2
.groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7CA
bner.Chan
g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
e608e11a
82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
sb3d8eyJWI
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7
C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
M%3D&amp;r
eserved=0
SmmCpuFeatureLib\Ia32
SmmCpuFeatureLib\X64
SmmCpuFeatureLib\SmmCpuFeatureLib.c
SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib


Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
Looks like below?

CpuDxe\IA32_X64\IA32\abc.nasm
CpuDxe\IA32_X64\X64\abc.nasm
CpuDxe\IA32_X64\CpuDxe.c
CpuDxe\IA32_X64\AmdCpuDxe.c
CpuDxe\IA32_X64\IntelCpuDxe.c
CpuDxe\RiscV64\CpuDxe.c
CpuDxe\ARM\CpuDxe.c
CpuDxe\
CpuDxeCommon.c // If required.
CpuDxe.inf // Use INF section arch modifier for X86,
RISC-V
and ARM.
CpuDxeAmd.inf // Separate INF for AMD.

Seems ok, but is AARCH64_RISCV64 a real case? Or it means we can
create a folder "AARCH64_RISCV64" when there are some common
files
shared by AARCH64 and RISCV64?

For the 32/64 bit support, it can still stay under module root and
don't need to assign a folder for them unless the arch has the
different
implementation.
Regards,
Abner



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Saturday, October 1, 2022 2:52 AM
To: devel@edk2.groups.io; quic_llindhol@...; Chang,
Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V
L <sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>;
Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Hi Leif,

Concatenation is a good idea. Makes it more obvious and can be
easily adopted for new CPU archs.

There is an additional case where an implementation does not
have differences based on CPU Arch or Vendor, but it does have
differences based on the bit- width of the CPU. Take
BaseSafeIntLib as
an example.
It has source files for 32-bit CPUs, 64-bit CPUs, and CPU arch
specific file for Ebc because Ebc adapts to 32-bit or 64-bit
depending on the CPU type the EBC Interpreter is running.

MdePkg/Library/BaseSafeIntLib/
BaseSafeIntLib.inf
SafeIntLib.c
SafeIntLib32.c
SafeIntLib64.c
SafeIntLibEbc.c

Should we add "32" and "64" as supported suffices in file names?

If we wanted to put type content into a subdirectory, what would
be the suggested directory name for "32" and "64". Or do we
want to require this type of difference to always be files in
top level directory of
the modules/library?

Best regards,

Mike


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Leif Lindholm
Sent: Friday, September 30, 2022 9:09 AM
To: devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>; Chang, Abner
<Abner.Chang@...>;
Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

I agree similar things will certainly happen for ARM/AARCH64,
which will probably be noticeable when I start eradicating
ArmPkg and putting the arch-standard bits into (mostly) MdePkg.

But I like the ability to see already at the filesystem level
which files belong to the architecture I'm currently working
on and
which don't.

Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?

/
Leif

On 2022-09-30 08:28, Michael D Kinney wrote:
Hi Abner,

One comment is on adding a new CPU type dir name of 'X86'
for content that is common for IA32/X64.

I can imagine a similar case for ARM/AARCH64 and for the
RISCV (32, 64, 128) cases.

I think I would prefer to drop X86 and if there are files
that are common to multiple CPU architectures then they are
considered common and are in top directory of module and the
file header and INF file can clearly document which CPU
archs the file
applies.

Mike

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Friday, September 30, 2022 12:11 AM
To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif
Lindholm <quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Thanks Ray, here are my responses.
https://nam11.safelinks.protection.outlook.com/?url=https%3
A%2F
%2Fg
ithub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification
%2Fp
ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
f4
86f
920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
3800
1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQ
IjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=
HAq
ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0

@Kinney, Michael D we may also need your clarification on
the
comments.


-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Thursday, September 29, 2022 3:42 PM
To: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Chang, Abner
<Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>; lichao
<lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif Lindholm <quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Abner,
Comments in
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification%2Fpull%2F2%23pullrequestrevi
ew-
1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
8jo8%3D&amp;reserved=0

We can discuss more in tomorrow's meeting.


-----Original Message-----
From: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>
Sent: Thursday, September 29, 2022 3:11 PM
To: Chang, Abner <Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io; Ni, Ray
<ray.ni@...>
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

Hi Abner,
Looks good to me.
Reviewed-by: Abdul Lateef Attar <abdattar@...>

Thanks
AbduL

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: 28 September 2022 20:31
To: Sunil V L <sunilvl@...>;
devel@edk2.groups.io; ray.ni@...
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

I just had created PR to update edkII C coding standard
spec for the file and directory naming. We can review and
confirm this update first and then go back to the
principles of EDK2 module
reconstruction for archs.
Here is the PR:
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
&amp;data=05%7C01%7CAbner.Chang%40amd.c
om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
d994e18
3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
7C%7C&a
mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
mp;reserv
ed=0
CCodingStandardsSpecification/pull/2

The naming rule is mainly for the new module or new file IMO.
Some existing module may not meet the guidelines
mentioned in this
spec.
Thus we need the principles of EDK2 module reconstruction
on the existing module to support other processor archs
and not impacting the
existing platforms (e.g.
rename the INF file or directory to meet the guidelines).

Sunil, seems RISC-V CpuDxe meet the guideline. Please check
it.
Just feel that having CpuDxe.c to Riscv64 folder is not
quite a best solution. I think at least we can abstract
the protocol structure and protocol installation under
CpuDxe\ and have the arch implementation under arch
folder. We can discuss this later after we confirming the
guideline and principles.

Thanks
Abner

-----Original Message-----
From: Sunil V L <sunilvl@...>
Sent: Wednesday, September 28, 2022 3:34 PM
To: devel@edk2.groups.io; ray.ni@...
Cc: Chang, Abner <Abner.Chang@...>; Kinney,
Michael
D <michael.d.kinney@...>; lichao
<lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray wrote:
Hi Ray,

1. When a new arch's implementation is introduced
to the existing
module which was developed for the specific arch:

1. The folder reconstruction:

* Create arch folder for the existing arch implementation
[Ray] Do you move existing arch implementation to that
arch
folder?
It will
break existing platforms a lot.

* Create the arch folder for the new introduced arch
[Ray] I agree. But if we don't create arch folder for
existing arch
implementation, the pkg layout will be a mess.

[Ray] Hard for me to understand all the principles here.
Maybe we review
existing code including to-be-upstreamed code and decide
how
to go.
Could you please take a look below changes which is
trying to add RISC-V support for CpuDxe?
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
ed=0

What do you suggest with above example?

1) Common INF for all architectures - but modify INF
alone, no
X86 folder creation.

This is what I have done in the commit above. May be of
least impact to existing code since it is only INF change.
But like you mentioned this is bit weird that X86 files
will remain in root folder directly along with some common
files.

2) Common INF (CpuDxe.inf) + create arch folders X86,
X64, IA32,
RiscV64 etc

IMO, this is probably the best approach. What would be
the challenges with this?

3) Separate INF for arch like CpuDxe.inf for x86,
CpuDxeRiscV64.inf for
RISC-V.

This again probably is not a good idea.

4) If the module/library is specific to one arch (ex:
SMM(X86), SBI(RISC-V)), then create separate INF.

Thanks!
Sunil









Re: The principles of EDK2 module reconstruction for archs

Chang, Abner
 

[AMD Official Use Only - General]

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 4, 2022 12:54 AM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
(Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
archs

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


Hi Abner,

responses below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chang,
Abner via groups.io
Sent: Sunday, October 2, 2022 10:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction
for archs

[AMD Official Use Only - General]

Mike,
Agree. This can be mentioned on the Wiki page. Also, this would
require the discussion between maintainer and contributor. I would say
maintainer has the responsibility to make sure an arch folder is only created
when necessary.

Agreed
Ok, I will update Directory and file names section.


Do you agree with the arch concatenate solution for arch folder? That
means IA32_X64 instead of X86 (I am fine with this)?

Yes

However, there is one scenario. Assume there were two arch folders
IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64, we may
rename IA32_X64 to IA32_X64_ARM.
Although the directory naming is not real a problem to the build, a
separate ARM folder seems easier? Or we can just allow this kind of folder
naming structure, however we let maintainer to make the decision?

I would let the maintainer make the decision. For your example, another
approach may be to move the IA32_X64 content up a level so it is common
and is used by IA32, X64, ARM. And leave RISCV64 folder for an arch that has
special requirements. I think having some flexibility in the guidelines is very
beneficial. The main goal is for consistency when a specific guideline is
followed.
I think we can have the naming rules in the edk2 C coding standard spec and put these guidelines on the Wiki page.
Is that ok to have a link to Wiki page in the edk2 C coding standard spec?

Abner



Abner


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Monday, October 3, 2022 1:18 PM
To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Abner,

I think another guideline is to minimize the number of subdirectories.

Only create them if it helps with the organization and long term
maintenance of the component.

Mike


-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Sunday, October 2, 2022 8:13 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Hi Mike and Leif,
First of all, we don't use arch folder if the module is mainly for
a specific arch in obviously. So we will have both common and
arch-specific
files constructed under module/library root.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed
k
2
.groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7CA
bner.Chan
g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
e608e11a
82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
sb3d8eyJWI
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7
C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
M%3D&amp;r
eserved=0
SmmCpuFeatureLib\Ia32
SmmCpuFeatureLib\X64
SmmCpuFeatureLib\SmmCpuFeatureLib.c
SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib


Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
Looks like below?

CpuDxe\IA32_X64\IA32\abc.nasm
CpuDxe\IA32_X64\X64\abc.nasm
CpuDxe\IA32_X64\CpuDxe.c
CpuDxe\IA32_X64\AmdCpuDxe.c
CpuDxe\IA32_X64\IntelCpuDxe.c
CpuDxe\RiscV64\CpuDxe.c
CpuDxe\ARM\CpuDxe.c
CpuDxe\
CpuDxeCommon.c // If required.
CpuDxe.inf // Use INF section arch modifier for X86,
RISC-V
and ARM.
CpuDxeAmd.inf // Separate INF for AMD.

Seems ok, but is AARCH64_RISCV64 a real case? Or it means we can
create a folder "AARCH64_RISCV64" when there are some common
files
shared by AARCH64 and RISCV64?

For the 32/64 bit support, it can still stay under module root and
don't need to assign a folder for them unless the arch has the
different
implementation.
Regards,
Abner



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Saturday, October 1, 2022 2:52 AM
To: devel@edk2.groups.io; quic_llindhol@...; Chang,
Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V
L <sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>;
Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Hi Leif,

Concatenation is a good idea. Makes it more obvious and can be
easily adopted for new CPU archs.

There is an additional case where an implementation does not
have differences based on CPU Arch or Vendor, but it does have
differences based on the bit- width of the CPU. Take
BaseSafeIntLib as
an example.
It has source files for 32-bit CPUs, 64-bit CPUs, and CPU arch
specific file for Ebc because Ebc adapts to 32-bit or 64-bit
depending on the CPU type the EBC Interpreter is running.

MdePkg/Library/BaseSafeIntLib/
BaseSafeIntLib.inf
SafeIntLib.c
SafeIntLib32.c
SafeIntLib64.c
SafeIntLibEbc.c

Should we add "32" and "64" as supported suffices in file names?

If we wanted to put type content into a subdirectory, what would
be the suggested directory name for "32" and "64". Or do we
want to require this type of difference to always be files in
top level directory of
the modules/library?

Best regards,

Mike


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Leif Lindholm
Sent: Friday, September 30, 2022 9:09 AM
To: devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>; Chang, Abner
<Abner.Chang@...>;
Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

I agree similar things will certainly happen for ARM/AARCH64,
which will probably be noticeable when I start eradicating
ArmPkg and putting the arch-standard bits into (mostly) MdePkg.

But I like the ability to see already at the filesystem level
which files belong to the architecture I'm currently working
on and
which don't.

Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?

/
Leif

On 2022-09-30 08:28, Michael D Kinney wrote:
Hi Abner,

One comment is on adding a new CPU type dir name of 'X86'
for content that is common for IA32/X64.

I can imagine a similar case for ARM/AARCH64 and for the
RISCV (32, 64, 128) cases.

I think I would prefer to drop X86 and if there are files
that are common to multiple CPU architectures then they are
considered common and are in top directory of module and the
file header and INF file can clearly document which CPU
archs the file
applies.

Mike

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Friday, September 30, 2022 12:11 AM
To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif
Lindholm <quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Thanks Ray, here are my responses.
https://nam11.safelinks.protection.outlook.com/?url=https%3
A%2F
%2Fg
ithub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification
%2Fp
ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
f4
86f
920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
3800
1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQ
IjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=
HAq
ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0

@Kinney, Michael D we may also need your clarification on
the
comments.


-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Thursday, September 29, 2022 3:42 PM
To: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Chang, Abner
<Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>; lichao
<lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif Lindholm <quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


Abner,
Comments in
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification%2Fpull%2F2%23pullrequestrevi
ew-
1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
8jo8%3D&amp;reserved=0

We can discuss more in tomorrow's meeting.


-----Original Message-----
From: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>
Sent: Thursday, September 29, 2022 3:11 PM
To: Chang, Abner <Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io; Ni, Ray
<ray.ni@...>
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

Hi Abner,
Looks good to me.
Reviewed-by: Abdul Lateef Attar <abdattar@...>

Thanks
AbduL

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: 28 September 2022 20:31
To: Sunil V L <sunilvl@...>;
devel@edk2.groups.io; ray.ni@...
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

I just had created PR to update edkII C coding standard
spec for the file and directory naming. We can review and
confirm this update first and then go back to the
principles of EDK2 module
reconstruction for archs.
Here is the PR:
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
&amp;data=05%7C01%7CAbner.Chang%40amd.c
om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
d994e18
3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
7C%7C&a
mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
mp;reserv
ed=0
CCodingStandardsSpecification/pull/2

The naming rule is mainly for the new module or new file IMO.
Some existing module may not meet the guidelines
mentioned in this
spec.
Thus we need the principles of EDK2 module reconstruction
on the existing module to support other processor archs
and not impacting the
existing platforms (e.g.
rename the INF file or directory to meet the guidelines).

Sunil, seems RISC-V CpuDxe meet the guideline. Please check
it.
Just feel that having CpuDxe.c to Riscv64 folder is not
quite a best solution. I think at least we can abstract
the protocol structure and protocol installation under
CpuDxe\ and have the arch implementation under arch
folder. We can discuss this later after we confirming the
guideline and principles.

Thanks
Abner

-----Original Message-----
From: Sunil V L <sunilvl@...>
Sent: Wednesday, September 28, 2022 3:34 PM
To: devel@edk2.groups.io; ray.ni@...
Cc: Chang, Abner <Abner.Chang@...>; Kinney,
Michael
D <michael.d.kinney@...>; lichao
<lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

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


On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray wrote:
Hi Ray,

1. When a new arch's implementation is introduced
to the existing
module which was developed for the specific arch:

1. The folder reconstruction:

* Create arch folder for the existing arch implementation
[Ray] Do you move existing arch implementation to that
arch
folder?
It will
break existing platforms a lot.

* Create the arch folder for the new introduced arch
[Ray] I agree. But if we don't create arch folder for
existing arch
implementation, the pkg layout will be a mess.

[Ray] Hard for me to understand all the principles here.
Maybe we review
existing code including to-be-upstreamed code and decide
how
to go.
Could you please take a look below changes which is
trying to add RISC-V support for CpuDxe?
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
ed=0

What do you suggest with above example?

1) Common INF for all architectures - but modify INF
alone, no
X86 folder creation.

This is what I have done in the commit above. May be of
least impact to existing code since it is only INF change.
But like you mentioned this is bit weird that X86 files
will remain in root folder directly along with some common
files.

2) Common INF (CpuDxe.inf) + create arch folders X86,
X64, IA32,
RiscV64 etc

IMO, this is probably the best approach. What would be
the challenges with this?

3) Separate INF for arch like CpuDxe.inf for x86,
CpuDxeRiscV64.inf for
RISC-V.

This again probably is not a good idea.

4) If the module/library is specific to one arch (ex:
SMM(X86), SBI(RISC-V)), then create separate INF.

Thanks!
Sunil









[PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space

Gerd Hoffmann
 

Try detect physical address space, when successful use it.
Otherwise go continue using the current guesswork code path.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 143a01ceb01e..16ecbfadc30c 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -761,6 +761,19 @@ PlatformAddressWidthInitialization (
FirstNonAddress = PlatformGetFirstNonAddress (PlatformInfoHob);
}

+ PlatformAddressWidthFromCpuid (PlatformInfoHob, TRUE);
+ if (PlatformInfoHob->PhysMemAddressWidth != 0) {
+ // physical address width is known
+ PlatformInfoHob->FirstNonAddress = FirstNonAddress;
+ return;
+ }
+
+ //
+ // physical address width is NOT known
+ // -> do some guess work, mostly based on installed memory
+ // -> try be conservstibe to stay below the guaranteed minimum of
+ // 36 phys bits (aka 64 GB).
+ //
PhysMemAddressWidth = (UINT8)HighBitSet64 (FirstNonAddress);

//
--
2.37.3


[PATCH v2 4/4] OvmfPkg/PciHotPlugInitDxe: reserve more mmio space

Gerd Hoffmann
 

In case the 64-bit pci mmio window is larger than the default size
of 32G be generous and hand out larger chunks of address space for
prefetchable mmio bridge windows.

Cc: Laszlo Ersek <lersek@...>
Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf | 1 +
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c | 21 ++++++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
index 78b95faa7a7a..f56b1de6fd92 100644
--- a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
+++ b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
@@ -40,6 +40,7 @@ [Protocols]

[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId ## CONSUMES
+ gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size ## CONSUMES

[Depex]
TRUE
diff --git a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
index c122855b735d..3f9c84cf2b54 100644
--- a/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
+++ b/OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c
@@ -556,6 +556,7 @@ GetResourcePadding (
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_PCI_ADDRESS *Address;
BOOLEAN DefaultIo;
BOOLEAN DefaultMmio;
+ BOOLEAN DefaultPrefMmio;
RESOURCE_PADDING ReservationRequest;
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *FirstResource;
EFI_STATUS ReservationHintStatus;
@@ -588,8 +589,9 @@ GetResourcePadding (
return EFI_INVALID_PARAMETER;
}

- DefaultIo = TRUE;
- DefaultMmio = TRUE;
+ DefaultIo = TRUE;
+ DefaultMmio = TRUE;
+ DefaultPrefMmio = TRUE;

//
// Init ReservationRequest, and point FirstResource one past the last
@@ -722,6 +724,7 @@ GetResourcePadding (
HighBit = HighBitSetRoundUp32 (ReservationHint.Prefetchable32BitMmio);
if (HighBit != -1) {
SetMmioPadding (--FirstResource, TRUE, TRUE, (UINTN)HighBit);
+ DefaultPrefMmio = FALSE;
}
} else if ((ReservationHint.Prefetchable64BitMmio > 0) &&
(ReservationHint.Prefetchable64BitMmio < MAX_UINT64))
@@ -729,6 +732,7 @@ GetResourcePadding (
HighBit = HighBitSetRoundUp64 (ReservationHint.Prefetchable64BitMmio);
if (HighBit != -1) {
SetMmioPadding (--FirstResource, TRUE, FALSE, (UINTN)HighBit);
+ DefaultPrefMmio = FALSE;
}
}
}
@@ -752,6 +756,19 @@ GetResourcePadding (
);
}

+ if (DefaultPrefMmio) {
+ UINT64 Pci64Size = PcdGet64 (PcdPciMmio64Size);
+
+ if (Pci64Size > SIZE_32GB) {
+ SetMmioPadding (
+ --FirstResource,
+ TRUE,
+ FALSE,
+ (UINTN)HighBitSetRoundUp64 (RShiftU64 (Pci64Size, 8))
+ );
+ }
+ }
+
//
// Output a copy of ReservationRequest from the lowest-address populated
// entry until the end of the structure (including
--
2.37.3


[PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size

Gerd Hoffmann
 

In case we have a reliable PhysMemAddressWidth use that to dynamically
size the 64bit address window. Allocate 1/8 of the physical address
space and place the window at the upper end of the address space.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 28 +++++++++++++++++++++
1 file changed, 28 insertions(+)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 16ecbfadc30c..ae217d0242ed 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -604,6 +604,33 @@ PlatformAddressWidthFromCpuid (
}
}

+VOID
+EFIAPI
+PlatformDynamicMmioWindow (
+ IN OUT EFI_HOB_PLATFORM_INFO *PlatformInfoHob
+ )
+{
+ UINT64 AddrSpace, MmioSpace;
+
+ AddrSpace = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth);
+ MmioSpace = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth - 3);
+
+ if ((PlatformInfoHob->PcdPciMmio64Size < MmioSpace) &&
+ (PlatformInfoHob->PcdPciMmio64Base + MmioSpace < AddrSpace))
+ {
+ DEBUG ((DEBUG_INFO, "%a: using dynamic mmio window\n", __func__));
+ DEBUG ((DEBUG_INFO, "%a: Addr Space 0x%Lx (%Ld GB)\n", __func__, AddrSpace, RShiftU64 (AddrSpace, 30)));
+ DEBUG ((DEBUG_INFO, "%a: MMIO Space 0x%Lx (%Ld GB)\n", __func__, MmioSpace, RShiftU64 (MmioSpace, 30)));
+ PlatformInfoHob->PcdPciMmio64Size = MmioSpace;
+ PlatformInfoHob->PcdPciMmio64Base = AddrSpace - MmioSpace;
+ } else {
+ DEBUG ((DEBUG_INFO, "%a: using classic mmio window\n", __func__));
+ }
+
+ DEBUG ((DEBUG_INFO, "%a: Pci64 Base 0x%Lx\n", __func__, PlatformInfoHob->PcdPciMmio64Base));
+ DEBUG ((DEBUG_INFO, "%a: Pci64 Size 0x%Lx\n", __func__, PlatformInfoHob->PcdPciMmio64Size));
+}
+
/**
Iterate over the PCI host bridges resources information optionally provided
in fw-cfg and find the highest address contained in the PCI MMIO windows. If
@@ -765,6 +792,7 @@ PlatformAddressWidthInitialization (
if (PlatformInfoHob->PhysMemAddressWidth != 0) {
// physical address width is known
PlatformInfoHob->FirstNonAddress = FirstNonAddress;
+ PlatformDynamicMmioWindow (PlatformInfoHob);
return;
}

--
2.37.3


[PATCH v2 1/4] OvmfPkg/PlatformInitLib: qemu cpuid physbits detection

Gerd Hoffmann
 

Add some qemu specific quirks to PlatformAddressWidthFromCpuid()
to figure whenever the PhysBits value returned by CPUID is
something real we can work with or not.

See the source code comment for details on the logic.

Also apply some limits to the address space we are going to use:
* Place a hard cap at 47 PhysBits (128 TB) to avoid using addresses
which require 5-level paging support.
* Cap at 40 PhysBits (1 TB) in case the CPU has no support for
gigabyte pages, to avoid excessive amounts of pages being
used for page tables.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 102 ++++++++++++++++----
1 file changed, 84 insertions(+), 18 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index d1a4f4b20791..143a01ceb01e 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -503,39 +503,105 @@ PlatformGetFirstNonAddress (
}

/*
- * Use CPUID to figure physical address width. Does *not* work
- * reliable on qemu. For historical reasons qemu returns phys-bits=40
- * even in case the host machine supports less than that.
- *
- * qemu has a cpu property (host-phys-bits={on,off}) to change that
- * and make sure guest phys-bits are not larger than host phys-bits.,
- * but it is off by default. Exception: microvm machine type
- * hard-wires that property to on.
+ * Use CPUID to figure physical address width.
+ *
+ * Does *not* work reliable on qemu. For historical reasons qemu
+ * returns phys-bits=40 by default even in case the host machine
+ * supports less than that.
+ *
+ * So we apply the following rules (which can be enabled/disabled
+ * using the QemuQuirk parameter) to figure whenever we can work with
+ * the returned physical address width or not:
+ *
+ * (1) If it is 41 or higher consider it valid.
+ * (2) If it is 40 or lower consider it valid in case it matches a
+ * known-good value for the CPU vendor, which is:
+ * -> 36 or 39 for Intel
+ * -> 40 for AMD
+ * (3) Otherwise consider it invalid.
+ *
+ * Recommendation: Run qemu with host-phys-bits=on. That will make
+ * sure guest phys-bits is not larger than host phys-bits. Some
+ * distro builds do that by default.
*/
VOID
EFIAPI
PlatformAddressWidthFromCpuid (
- IN OUT EFI_HOB_PLATFORM_INFO *PlatformInfoHob
+ IN OUT EFI_HOB_PLATFORM_INFO *PlatformInfoHob,
+ IN BOOLEAN QemuQuirk
)
{
- UINT32 RegEax;
+ UINT32 RegEax, RegEbx, RegEcx, RegEdx, Max;
+ UINT8 PhysBits;
+ CHAR8 Signature[13] = { 0 };
+ BOOLEAN Valid = FALSE;
+ BOOLEAN Page1GSupport = FALSE;

- AsmCpuid (0x80000000, &RegEax, NULL, NULL, NULL);
- if (RegEax >= 0x80000008) {
+ AsmCpuid (0x80000000, &RegEax, &RegEbx, &RegEcx, &RegEdx);
+ *(UINT32 *)(Signature + 0) = RegEbx;
+ *(UINT32 *)(Signature + 4) = RegEdx;
+ *(UINT32 *)(Signature + 8) = RegEcx;
+ Max = RegEax;
+
+ if (Max >= 0x80000001) {
+ AsmCpuid (0x80000001, NULL, NULL, NULL, &RegEdx);
+ if ((RegEdx & BIT26) != 0) {
+ Page1GSupport = TRUE;
+ }
+ }
+
+ if (Max >= 0x80000008) {
AsmCpuid (0x80000008, &RegEax, NULL, NULL, NULL);
- PlatformInfoHob->PhysMemAddressWidth = (UINT8)RegEax;
+ PhysBits = (UINT8)RegEax;
} else {
- PlatformInfoHob->PhysMemAddressWidth = 36;
+ PhysBits = 36;
}

- PlatformInfoHob->FirstNonAddress = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth);
+ if (!QemuQuirk) {
+ Valid = TRUE;
+ } else if (PhysBits >= 41) {
+ Valid = TRUE;
+ } else if (AsciiStrCmp (Signature, "GenuineIntel") == 0) {
+ if ((PhysBits == 36) || (PhysBits == 39)) {
+ Valid = TRUE;
+ }
+ } else if (AsciiStrCmp (Signature, "AuthenticAMD") == 0) {
+ if (PhysBits == 40) {
+ Valid = TRUE;
+ }
+ }

DEBUG ((
DEBUG_INFO,
- "%a: cpuid: phys-bits is %d\n",
+ "%a: Signature: '%a', PhysBits: %d, QemuQuirk: %a, Valid: %a\n",
__FUNCTION__,
- PlatformInfoHob->PhysMemAddressWidth
+ Signature,
+ PhysBits,
+ QemuQuirk ? "On" : "Off",
+ Valid ? "Yes" : "No"
));
+
+ if (Valid) {
+ if (PhysBits > 47) {
+ /*
+ * Avoid 5-level paging altogether for now, which limits
+ * PhysBits to 48. Also avoid using address bit 48, due to sign
+ * extension we can't identity-map these addresses (and lots of
+ * places in edk2 assume we have everything identity-mapped).
+ * So the actual limit is 47.
+ */
+ DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 47 (avoid 5-level paging)\n", __func__));
+ PhysBits = 47;
+ }
+
+ if (!Page1GSupport && (PhysBits > 40)) {
+ DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 40 (no 1G pages available)\n", __func__));
+ PhysBits = 40;
+ }
+
+ PlatformInfoHob->PhysMemAddressWidth = PhysBits;
+ PlatformInfoHob->FirstNonAddress = LShiftU64 (1, PlatformInfoHob->PhysMemAddressWidth);
+ }
}

/**
@@ -672,7 +738,7 @@ PlatformAddressWidthInitialization (
EFI_STATUS Status;

if (PlatformInfoHob->HostBridgeDevId == 0xffff /* microvm */) {
- PlatformAddressWidthFromCpuid (PlatformInfoHob);
+ PlatformAddressWidthFromCpuid (PlatformInfoHob, FALSE);
return;
}

--
2.37.3


[PATCH v2 0/4] OvmfPkg: make better use of physical address space.

Gerd Hoffmann
 

For historical reasons ovmf is quite conservative on address space
usage, to play safe and avoid using more than 36 physical address bits
(the guaranteed minimum) if possible. With devices (specifically GPUs)
becoming larger and larger pci memory bars this becomes increasingly
problematic.

This patch series address that by trying to figure what the physical
address space size is (which is a bit tricky, see patch #1 for details).
If that worked scale up the 64-bit mmio window and also pcie bridge
windows dynamically with the available address space.

v2:
- fix pcie bridge window logic, track prefetchable and non-prefetchable
default state separately (Laszlo).

Gerd Hoffmann (4):
OvmfPkg/PlatformInitLib: qemu cpuid physbits detection
OvmfPkg/PlatformInitLib: detect physical address space
OvmfPkg/PlatformInitLib: dynamic mmio window size
OvmfPkg/PciHotPlugInitDxe: reserve more mmio space

OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf | 1 +
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 143 ++++++++++++++++---
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c | 21 ++-
3 files changed, 145 insertions(+), 20 deletions(-)

--
2.37.3


[PATCH 1/1] OvmfPkg: rename QemuBootOrderNNNN to VMMBootOrderNNNN

Gerd Hoffmann
 

While the actual implementation (using qemu fw_cfg) is qemu-specific,
the idea to store the boot order as configured by the VMM in EFI
variables is not. So lets give the variables a more neutral name while
we still can (i.e. no stable tag yet with the new feature).

While being at it also fix the NNNN format (use %x instead of %d for
consistency with BootNNNN).

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/OvmfPkg.dec | 2 +-
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf | 2 +-
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6d689ecc5d55..f13dd4a61f01 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -146,7 +146,7 @@ [Guids]
gConfidentialComputingSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
gConfidentialComputingSevSnpBlobGuid = {0x067b1f5f, 0xcf26, 0x44c5, {0x85, 0x54, 0x93, 0xd7, 0x77, 0x91, 0x2d, 0x42}}
gUefiOvmfPkgPlatformInfoGuid = {0xdec9b486, 0x1f16, 0x47c7, {0x8f, 0x68, 0xdf, 0x1a, 0x41, 0x88, 0x8b, 0xa5}}
- gQemuBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6, 0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}}
+ gVMMBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6, 0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}}

[Ppis]
# PPI whose presence in the PPI database signals that the TPM base address
diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
index 211344fb0b89..6e320e3e8514 100644
--- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
+++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
@@ -49,7 +49,7 @@ [LibraryClasses]
[Guids]
gEfiGlobalVariableGuid
gVirtioMmioTransportGuid
- gQemuBootOrderGuid
+ gVMMBootOrderGuid

[FeaturePcd]
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation
diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
index 18646daa67e3..cea4b7a099e3 100644
--- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
+++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
@@ -1709,7 +1709,7 @@ ConnectDevicesFromQemu (
Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate
the OpenFirmware device paths therein to UEFI device path fragments.

- On Success store the device path in QemuBootOrderNNNN variables.
+ On Success store the device path in VMMBootOrderNNNN variables.
**/
VOID
EFIAPI
@@ -1794,13 +1794,13 @@ StoreQemuBootOrder (
UnicodeSPrint (
VariableName,
sizeof (VariableName),
- L"QemuBootOrder%04d",
+ L"VMMBootOrder%04x",
VariableIndex++
);
DEBUG ((DEBUG_INFO, "%a: %s = %s\n", __FUNCTION__, VariableName, Translated));
gRT->SetVariable (
VariableName,
- &gQemuBootOrderGuid,
+ &gVMMBootOrderGuid,
EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
GetDevicePathSize (DevicePath),
DevicePath
--
2.37.3


Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library

PierreGondois
 

Hello Girish,

On 10/4/22 05:01, Girish Mahadevan wrote:
Hello Sami,
My apologies for the late response. I had one question/comment.
Comment marked with [GM] inline.
Best Regards
Girish
On 9/12/2022 8:18 AM, Sami Mujawar wrote:
External email: Use caution opening links or attachments


The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.

Test strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.

Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.

SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.

Example:
EFI_STATUS
BuildSmbiosType17Table () {
STRING_TABLE StrTable;
UINT8 DevLocatorRef;
UINT8 BankLocatorRef;
SMBIOS_TABLE_TYPE17 *SmbiosRecord;
CHAR8 *StringSet;
...

// Initialize string table for 7 strings
StringTableInitialize (&StrTable, 7);

StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
...

SmbiosRecord = AllocateZeroPool (
sizeof (SMBIOS_TABLE_TYPE17) +
StringTableGetStringSetSize (&StrTable)
);
...
SmbiosRecord->DeviceLocator = DevLocatorRef;
SmbiosRecord->BankLocator = BankLocatorRef;
...
// get the string set area
StringSet = (CHAR8*)(SmbiosRecord + 1);

// publish the string set
StringTablePublishStringSet (
&StrTable,
StringSet,
StringTableGetStringSetSize (&StrTable)
);

// free string table
StringTableFree (&StrTable);

return EFI_SUCCESS;
}

Signed-off-by: Sami Mujawar <sami.mujawar@...>
Cc: Alexei Fedorov <Alexei.Fedorov@...>
Cc: Pierre Gondois <pierre.gondois@...>
Cc: Girish Mahadevan <gmahadevan@...>
Cc: Jeff Brasen <jbrasen@...>
Cc: Ashish Singhal <ashishsingha@...>
Cc: Nick Ramirez <nramirez@...>
Cc: William Watson <wwatson@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
---
The changes can be seen at:
https://github.com/samimujawar/edk2/tree/2370_smbios_stringlib_v1

DynamicTablesPkg/DynamicTables.dsc.inc | 3 +-
DynamicTablesPkg/DynamicTablesPkg.dec | 5 +-
DynamicTablesPkg/DynamicTablesPkg.dsc | 3 +-
DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h | 119 ++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c | 227 ++++++++++++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf | 25 +++
6 files changed, 379 insertions(+), 3 deletions(-)

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc b/DynamicTablesPkg/DynamicTables.dsc.inc
index 3d4fa0c4c4b67d6770aee8705c80cc18d20c823a..d35acc1788f2ddc5e2b5fc3e4bedfd48251f7ec8 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
## @file
# Dsc include file for Dynamic Tables Framework.
#
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -18,6 +18,7 @@ [LibraryClasses.common]
SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
+ SmbiosStringTableLib|DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

[Components.common]
#
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec b/DynamicTablesPkg/DynamicTablesPkg.dec
index cc34c2bdd6ff9b5ca508961b3d0fe85ffbb73c12..2a79cfd4edebbdff05bee66fa01a17d68252e8a7 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -1,7 +1,7 @@
## @file
# dec file for Dynamic Tables Framework.
#
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -39,6 +39,9 @@ [LibraryClasses]
## @libraryclass Defines a set of helper methods.
TableHelperLib|Include/Library/TableHelperLib.h

+ ## @libraryclass Defines a set of SMBIOS string helper methods.
+ SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
+
[Protocols]
# Configuration Manager Protocol GUID
gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82, 0x4894, { 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc b/DynamicTablesPkg/DynamicTablesPkg.dsc
index 07cc837552f587fe5bf9031e0061b0234e8698d4..bd5084a9008f040acdd16200ae8cdb23455ac101 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dsc
+++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
@@ -2,7 +2,7 @@
# Dsc file for Dynamic Tables Framework.
#
# Copyright (c) 2019, Linaro Limited. All rights reserved.<BR>
-# Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.<BR>
+# Copyright (c) 2019 - 2022, Arm Limited. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -46,6 +46,7 @@ [Components.common]
DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf
+ DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git a/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
new file mode 100644
index 0000000000000000000000000000000000000000..246d4d30ddf901640ea720c108e2971552ec6c96
--- /dev/null
+++ b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
@@ -0,0 +1,119 @@
+/** @file
+ SMBIOS String Table Helper library.
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SMBIOS_STRING_TABLE_H_
+#define SMBIOS_STRING_TABLE_H_
+
+/** A structure representing a string in the string table.
+*/
+typedef struct StringElement {
+ /// Length of the string (does not include the NULL termination)
+ UINTN StringLen;
+
+ /// Reference to the string
+ CONST CHAR8 *String;
+} STRING_ELEMENT;
+
+/** A structure representing a string table.
+*/
+typedef struct StringTable {
+ /// Count of strings in the table
+ UINT8 StrCount;
+
+ /// Total length of all strings in the table (does not include
+ // the NULL termination for each string)
+ UINTN TotalStrLen;
+
+ /// Maximum string count
+ UINT8 MaxStringElements;
+
+ /// Pointer to the string table elements
+ STRING_ELEMENT *Elements;
+} STRING_TABLE;
+
+/** Add a string to the string table
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] Str Pointer to the string
+ @param [OUT] StrRef Optional pointer to retrieve the string field
+ reference of the string in the string table
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_BUFFER_TOO_SMALL Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+ IN STRING_TABLE *CONST StrTable,
+ IN CONST CHAR8 *Str,
+ OUT UINT8 *StrRef OPTIONAL
+ );
+
+/** Returns the total size required to publish the strings to the SMBIOS
+ string area.
+
+ @param [IN] StrTable Pointer to the string table
+
+ @return Total size required to publish the strings in the SMBIOS string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+ IN STRING_TABLE *CONST StrTable
+ );
+
+/** Iterate through the string table and publish the strings in the SMBIOS
+ string area.
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] SmbiosStringAreaStart Start address of the SMBIOS string area.
+ @param [IN] SmbiosStringAreaSize Size of the SMBIOS string area.
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_BUFFER_TOO_SMALL Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+ IN STRING_TABLE *CONST StrTable,
+ IN CHAR8 *CONST SmbiosStringAreaStart,
+ IN CONST UINTN SmbiosStringAreaSize
+ );
+
+/** Initialise the string table and allocate memory for the string elements.
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] MaxStringElements Maximum number of strings that the string
+ table can hold.
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_OUT_OF_RESOURCES Failed to allocate memory for string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+ IN STRING_TABLE *CONST StrTable,
+ IN UINTN MaxStringElements
+ );
+
+/** Free memory allocated for the string elements in the string table.
+
+ @param [IN] StrTable Pointer to the string table
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer or string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+ IN STRING_TABLE *CONST StrTable
+ );
+
+#endif // SMBIOS_STRING_TABLE_H_
diff --git a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
new file mode 100644
index 0000000000000000000000000000000000000000..bd186f27fe1613cf819b6600e62960c003a796d6
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
@@ -0,0 +1,227 @@
+/** @file
+ SMBIOS String Table Helper
+
+ Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Reference(s):
+ - DSP0134 - SMBIOS Specification Version 3.6.0, 2022-06-17
+**/
+
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/SmbiosStringTableLib.h>
+
+/** Add a string to the string table
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] Str Pointer to the string
+ @param [OUT] StrRef Optional pointer to retrieve the string field
+ reference of the string in the string table
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_BUFFER_TOO_SMALL Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+ IN STRING_TABLE *CONST StrTable,
+ IN CONST CHAR8 *Str,
+ OUT UINT8 *StrRef OPTIONAL
+ )
+{
+ UINTN StrLength;
+ STRING_ELEMENT *StrElement;
+
+ if ((StrTable == NULL) || (Str == NULL)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ if (StrTable->StrCount >= StrTable->MaxStringElements) {
+ return EFI_BUFFER_TOO_SMALL;
+ }
+
+ StrLength = AsciiStrLen (Str);
+ if (StrLength == 0) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ // Update the string element
+ StrElement = &StrTable->Elements[StrTable->StrCount];
+ StrElement->StringLen = StrLength;
+ StrElement->String = Str;
+
+ // Update String table information
+ StrTable->TotalStrLen += StrLength;
+ StrTable->StrCount++;
+
+ // Return the index of the string in the string table if requested
+ if (StrRef != NULL) {
+ // Note: SMBIOS string field references start at 1. So, return the
+ // StrCount as the string refrence after it is updated.
+ *StrRef = StrTable->StrCount;
+ }
+
+ return EFI_SUCCESS;
+}
+
+/** Returns the total size required to publish the strings to the SMBIOS
+ string area.
+
+ @param [IN] StrTable Pointer to the string table
+
+ @return Total size required to publish the strings in the SMBIOS string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+ IN STRING_TABLE *CONST StrTable
+ )
+{
+ if (StrTable == NULL) {
+ ASSERT (0);
+ return 0;
+ }
+
+ // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+ // - If the formatted portion of the structure contains string-reference
+ // fields and all the string fields are set to 0 (no string references),
+ // the formatted section of the structure is followed by two null (00h)
+ // BYTES.
+ // - Each string is terminated with a null (00h) BYTE
+ // - and the set of strings is terminated with an additional null (00h) BYTE.
+
+ // Therefore, if string count = 0, return 2
+ // if string count > 0, the string set size =
+ // StrTable->TotalStrLen (total length of the strings in the string table)
+ // + StrTable->StrCount (add string count to include '\0' for each string)
+ // +1 (an additional '\0' is required at the end of the string set).
+ return (StrTable->StrCount == 0) ? 2 :
+ (StrTable->TotalStrLen + StrTable->StrCount + 1);
+}
+
+/** Iterate through the string table and publish the strings in the SMBIOS
+ string area.
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] SmbiosStringAreaStart Start address of the SMBIOS string area.
+ @param [IN] SmbiosStringAreaSize Size of the SMBIOS string area.
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_BUFFER_TOO_SMALL Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+ IN STRING_TABLE *CONST StrTable,
+ IN CHAR8 *CONST SmbiosStringAreaStart,
+ IN CONST UINTN SmbiosStringAreaSize
+ )
+{
+ UINT8 Index;
+ STRING_ELEMENT *StrElement;
+ CHAR8 *SmbiosString;
+ UINTN BytesRemaining;
+ UINTN BytesCopied;
+
+ if ((StrTable == NULL) || (SmbiosStringAreaStart == NULL)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ if (SmbiosStringAreaSize < StringTableGetStringSetSize (StrTable)) {
+ return EFI_BUFFER_TOO_SMALL;
+ }
+
+ SmbiosString = SmbiosStringAreaStart;
+ BytesRemaining = SmbiosStringAreaSize;
+
+ if (StrTable->StrCount == 0) {
+ // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+ // If the formatted portion of the structure contains string-reference
+ // fields and all the string fields are set to 0 (no string references),
+ // the formatted section of the structure is followed by two null (00h)
+ // BYTES.
+ *SmbiosString++ = '\0';
+ } else {
+ for (Index = 0; Index < StrTable->StrCount; Index++) {
+ StrElement = &StrTable->Elements[Index];
+ AsciiStrCpyS (SmbiosString, BytesRemaining, StrElement->String);
+
+ // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+ // - Each string is terminated with a null (00h) BYTE
+ // Bytes Copied = String length + 1 for the string NULL terminator.
+ BytesCopied = StrElement->StringLen + 1;
+ BytesRemaining -= BytesCopied;
+ SmbiosString += BytesCopied;
+ }
+ }
+
+ // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+ // - the set of strings is terminated with an additional null (00h) BYTE.
+ *SmbiosString = '\0';
[GM] Shouldn't you advance the SmbiosString pointer by one more ? After
the loop isn't SmbiosString going to be at the NULL char of the last
string ? And we're trying to add one more NULL character ?
Should it be:
SmbiosString++;
*SmbiosString = '\0';
I didn't try to run the code, but it seems ok to me. Assuming the string has 9 chars:
"""
// Copy 9 chars + 1 NULL char
AsciiStrCpyS (SmbiosString, BytesRemaining, StrElement->String);

// We have copied 10 chars
BytesCopied = StrElement->StringLen + 1;
BytesRemaining -= BytesCopied;
// Increment SmbiosString of 10 chars, so SmbiosString is pointing
// to an un-initialized char now and we can continue.
SmbiosString += BytesCopied;
"""

However, maybe we need to add an extra check/ASSERT for BytesRemaining before
writing the last NULL char.



+ return EFI_SUCCESS;
+}
+
+/** Initialise the string table and allocate memory for the string elements.
+
+ @param [IN] StrTable Pointer to the string table
+ @param [IN] MaxStringElements Maximum number of strings that the string
+ table can hold.
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer
+ @return EFI_OUT_OF_RESOURCES Failed to allocate memory for string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+ IN STRING_TABLE *CONST StrTable,
+ IN UINTN MaxStringElements
+ )
+{
+ STRING_ELEMENT *Elements;
+
+ if ((StrTable == NULL) || (MaxStringElements > MAX_UINT8)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ ZeroMem (StrTable, sizeof (STRING_TABLE));
+
+ Elements = (STRING_ELEMENT *)AllocateZeroPool (
+ sizeof (STRING_ELEMENT) * MaxStringElements
+ );
+ if (Elements == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+ }
+
+ StrTable->Elements = Elements;
+ StrTable->MaxStringElements = (UINT8)MaxStringElements;
+ return EFI_SUCCESS;
+}
+
+/** Free memory allocated for the string elements in the string table.
+
+ @param [IN] StrTable Pointer to the string table
+
+ @return EFI_SUCCESS Success
+ @return EFI_INVALID_PARAMETER Invalid string table pointer or string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+ IN STRING_TABLE *CONST StrTable
+ )
+{
+ if ((StrTable == NULL) || (StrTable->Elements == NULL)) {
+ return EFI_INVALID_PARAMETER;
+ }
+
+ FreePool (StrTable->Elements);
+ ZeroMem (StrTable, sizeof (STRING_TABLE));
+ return EFI_SUCCESS;
+}
diff --git a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
new file mode 100644
index 0000000000000000000000000000000000000000..88624c50e3f3e930074222b6d686f75485538b26
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
@@ -0,0 +1,25 @@
+## @file
+# SMBIOS String Table Helper library.
+#
+# Copyright (c) 2022, Arm Limited. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ INF_VERSION = 0x0001001B
+ BASE_NAME = SmbiosStringTableLib
+ FILE_GUID = 8C570DD8-531E-473F-85C6-9252746DBAC1
+ VERSION_STRING = 1.0
+ MODULE_TYPE = DXE_DRIVER
+ LIBRARY_CLASS = SmbiosStringTableLib
+
+[Sources]
+ SmbiosStringTableLib.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ DynamicTablesPkg/DynamicTablesPkg.dec
+
+[LibraryClasses]
+ BaseLib
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


Re: [PATCH v1 1/1] DynamicTablesPkg: Add SMBIOS String table helper library

Sami Mujawar
 

Hi Girish,

There are 2 cases that need handling. Please see my response inline marked [SAMI].

Regards,

Sami Mujawar

On 04/10/2022 04:01 am, Girish Mahadevan wrote:
Hello Sami,

My apologies for the late response. I had one question/comment.

Comment marked with [GM] inline.

Best Regards
Girish

On 9/12/2022 8:18 AM, Sami Mujawar wrote:
External email: Use caution opening links or attachments


The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.

Test strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.

Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.

SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.

Example:
EFI_STATUS
BuildSmbiosType17Table () {
   STRING_TABLE         StrTable;
   UINT8                DevLocatorRef;
   UINT8                BankLocatorRef;
   SMBIOS_TABLE_TYPE17  *SmbiosRecord;
   CHAR8                *StringSet;
   ...

   // Initialize string table for 7 strings
   StringTableInitialize (&StrTable, 7);

   StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
   StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
   ...

   SmbiosRecord = AllocateZeroPool (
                    sizeof (SMBIOS_TABLE_TYPE17) +
                      StringTableGetStringSetSize (&StrTable)
                    );
   ...
   SmbiosRecord->DeviceLocator = DevLocatorRef;
   SmbiosRecord->BankLocator = BankLocatorRef;
   ...
   // get the string set area
   StringSet = (CHAR8*)(SmbiosRecord + 1);

   // publish the string set
   StringTablePublishStringSet (
     &StrTable,
     StringSet,
     StringTableGetStringSetSize (&StrTable)
     );

   // free string table
   StringTableFree (&StrTable);

   return EFI_SUCCESS;
}

Signed-off-by: Sami Mujawar <sami.mujawar@...>
Cc: Alexei Fedorov <Alexei.Fedorov@...>
Cc: Pierre Gondois <pierre.gondois@...>
Cc: Girish Mahadevan <gmahadevan@...>
Cc: Jeff Brasen <jbrasen@...>
Cc: Ashish Singhal <ashishsingha@...>
Cc: Nick Ramirez <nramirez@...>
Cc: William Watson <wwatson@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
---
The changes can be seen at:
https://github.com/samimujawar/edk2/tree/2370_smbios_stringlib_v1

DynamicTablesPkg/DynamicTables.dsc.inc |   3 +-
DynamicTablesPkg/DynamicTablesPkg.dec |   5 +-
DynamicTablesPkg/DynamicTablesPkg.dsc |   3 +-
DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h | 119 ++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c | 227 ++++++++++++++++++++
DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf |  25 +++
  6 files changed, 379 insertions(+), 3 deletions(-)

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc b/DynamicTablesPkg/DynamicTables.dsc.inc
index 3d4fa0c4c4b67d6770aee8705c80cc18d20c823a..d35acc1788f2ddc5e2b5fc3e4bedfd48251f7ec8 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
  ## @file
  #  Dsc include file for Dynamic Tables Framework.
  #
-#  Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+#  Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -18,6 +18,7 @@ [LibraryClasses.common]
SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
+ SmbiosStringTableLib|DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

  [Components.common]
    #
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec b/DynamicTablesPkg/DynamicTablesPkg.dec
index cc34c2bdd6ff9b5ca508961b3d0fe85ffbb73c12..2a79cfd4edebbdff05bee66fa01a17d68252e8a7 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -1,7 +1,7 @@
  ## @file
  # dec file for Dynamic Tables Framework.
  #
-# Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+# Copyright (c) 2017 - 2022, Arm Limited. All rights reserved.<BR>
  #
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -39,6 +39,9 @@ [LibraryClasses]
    ##  @libraryclass  Defines a set of helper methods.
    TableHelperLib|Include/Library/TableHelperLib.h

+  ##  @libraryclass  Defines a set of SMBIOS string helper methods.
+  SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
+
  [Protocols]
    # Configuration Manager Protocol GUID
    gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82, 0x4894, { 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc b/DynamicTablesPkg/DynamicTablesPkg.dsc
index 07cc837552f587fe5bf9031e0061b0234e8698d4..bd5084a9008f040acdd16200ae8cdb23455ac101 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dsc
+++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
@@ -2,7 +2,7 @@
  #  Dsc file for Dynamic Tables Framework.
  #
  #  Copyright (c) 2019, Linaro Limited. All rights reserved.<BR>
-#  Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.<BR>
+#  Copyright (c) 2019 - 2022, Arm Limited. All rights reserved.<BR>
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -46,6 +46,7 @@ [Components.common]
DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf
+ DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf

  [BuildOptions]
    *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git a/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
new file mode 100644
index 0000000000000000000000000000000000000000..246d4d30ddf901640ea720c108e2971552ec6c96
--- /dev/null
+++ b/DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h
@@ -0,0 +1,119 @@
+/** @file
+  SMBIOS String Table Helper library.
+
+  Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SMBIOS_STRING_TABLE_H_
+#define SMBIOS_STRING_TABLE_H_
+
+/** A structure representing a string in the string table.
+*/
+typedef struct StringElement {
+  /// Length of the string (does not include the NULL termination)
+  UINTN          StringLen;
+
+  /// Reference to the string
+  CONST CHAR8    *String;
+} STRING_ELEMENT;
+
+/** A structure representing a string table.
+*/
+typedef struct StringTable {
+  /// Count of strings in the table
+  UINT8             StrCount;
+
+  /// Total length of all strings in the table (does not include
+  // the NULL termination for each string)
+  UINTN             TotalStrLen;
+
+  /// Maximum string count
+  UINT8             MaxStringElements;
+
+  /// Pointer to the string table elements
+  STRING_ELEMENT    *Elements;
+} STRING_TABLE;
+
+/** Add a string to the string table
+
+  @param [IN]   StrTable  Pointer to the string table
+  @param [IN]   Str       Pointer to the string
+  @param [OUT]  StrRef    Optional pointer to retrieve the string field
+                          reference of the string in the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+  IN        STRING_TABLE *CONST  StrTable,
+  IN  CONST CHAR8                *Str,
+  OUT       UINT8                *StrRef      OPTIONAL
+  );
+
+/** Returns the total size required to publish the strings to the SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+
+  @return Total size required to publish the strings in the SMBIOS string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+  IN  STRING_TABLE *CONST  StrTable
+  );
+
+/** Iterate through the string table and publish the strings in the SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+  @param [IN] SmbiosStringAreaStart Start address of the SMBIOS string area.
+  @param [IN] SmbiosStringAreaSize  Size of the SMBIOS string area.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+  IN        STRING_TABLE  *CONST  StrTable,
+  IN        CHAR8         *CONST  SmbiosStringAreaStart,
+  IN  CONST UINTN                 SmbiosStringAreaSize
+  );
+
+/** Initialise the string table and allocate memory for the string elements.
+
+  @param [IN] StrTable           Pointer to the string table
+  @param [IN] MaxStringElements  Maximum number of strings that the string
+                                 table can hold.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_OUT_OF_RESOURCES   Failed to allocate memory for string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+  IN STRING_TABLE *CONST  StrTable,
+  IN UINTN                MaxStringElements
+  );
+
+/** Free memory allocated for the string elements in the string table.
+
+  @param [IN] StrTable           Pointer to the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer or string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+  IN STRING_TABLE *CONST  StrTable
+  );
+
+#endif // SMBIOS_STRING_TABLE_H_
diff --git a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
new file mode 100644
index 0000000000000000000000000000000000000000..bd186f27fe1613cf819b6600e62960c003a796d6
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.c
@@ -0,0 +1,227 @@
+/** @file
+  SMBIOS String Table Helper
+
+  Copyright (c) 2022, Arm Limited. All rights reserved.<BR>
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - DSP0134 - SMBIOS Specification Version 3.6.0, 2022-06-17
+**/
+
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/SmbiosStringTableLib.h>
+
+/** Add a string to the string table
+
+  @param [IN]   StrTable  Pointer to the string table
+  @param [IN]   Str       Pointer to the string
+  @param [OUT]  StrRef    Optional pointer to retrieve the string field
+                          reference of the string in the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to add string
+**/
+EFI_STATUS
+EFIAPI
+StringTableAddString (
+  IN        STRING_TABLE *CONST  StrTable,
+  IN  CONST CHAR8                *Str,
+  OUT       UINT8                *StrRef      OPTIONAL
+  )
+{
+  UINTN           StrLength;
+  STRING_ELEMENT  *StrElement;
+
+  if ((StrTable == NULL) || (Str == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  if (StrTable->StrCount >= StrTable->MaxStringElements) {
+    return EFI_BUFFER_TOO_SMALL;
+  }
+
+  StrLength = AsciiStrLen (Str);
+  if (StrLength == 0) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  // Update the string element
+  StrElement            = &StrTable->Elements[StrTable->StrCount];
+  StrElement->StringLen = StrLength;
+  StrElement->String    = Str;
+
+  // Update String table information
+  StrTable->TotalStrLen += StrLength;
+  StrTable->StrCount++;
+
+  // Return the index of the string in the string table if requested
+  if (StrRef != NULL) {
+    // Note: SMBIOS string field references start at 1. So, return the
+    // StrCount as the string refrence after it is updated.
+    *StrRef = StrTable->StrCount;
+  }
+
+  return EFI_SUCCESS;
+}
+
+/** Returns the total size required to publish the strings to the SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+
+  @return Total size required to publish the strings in the SMBIOS string area.
+**/
+UINTN
+EFIAPI
+StringTableGetStringSetSize (
+  IN  STRING_TABLE *CONST  StrTable
+  )
+{
+  if (StrTable == NULL) {
+    ASSERT (0);
+    return 0;
+  }
+
+  // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+  // - If the formatted portion of the structure contains string-reference
+  //   fields and all the string fields are set to 0 (no string references),
+  //   the formatted section of the structure is followed by two null (00h)
+  //   BYTES.
+  // - Each string is terminated with a null (00h) BYTE
+  // - and the set of strings is terminated with an additional null (00h) BYTE.
+
+  // Therefore, if string count = 0, return 2
+  // if string count > 0, the string set size =
+  // StrTable->TotalStrLen (total length of the strings in the string table)
+  // + StrTable->StrCount (add string count to include '\0' for each string)
+  // +1 (an additional '\0' is required at the end of the string set).
+  return (StrTable->StrCount == 0) ? 2 :
+         (StrTable->TotalStrLen + StrTable->StrCount + 1);
+}
+
+/** Iterate through the string table and publish the strings in the SMBIOS
+    string area.
+
+  @param [IN] StrTable              Pointer to the string table
+  @param [IN] SmbiosStringAreaStart Start address of the SMBIOS string area.
+  @param [IN] SmbiosStringAreaSize  Size of the SMBIOS string area.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_BUFFER_TOO_SMALL   Insufficient space to publish strings
+**/
+EFI_STATUS
+EFIAPI
+StringTablePublishStringSet (
+  IN        STRING_TABLE  *CONST  StrTable,
+  IN        CHAR8         *CONST  SmbiosStringAreaStart,
+  IN  CONST UINTN                 SmbiosStringAreaSize
+  )
+{
+  UINT8           Index;
+  STRING_ELEMENT  *StrElement;
+  CHAR8           *SmbiosString;
+  UINTN           BytesRemaining;
+  UINTN           BytesCopied;
+
+  if ((StrTable == NULL) || (SmbiosStringAreaStart == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  if (SmbiosStringAreaSize < StringTableGetStringSetSize (StrTable)) {
+    return EFI_BUFFER_TOO_SMALL;
+  }
+
+  SmbiosString   = SmbiosStringAreaStart;
+  BytesRemaining = SmbiosStringAreaSize;
[SAMI] SmbiosString points to the startof the sting storage area.
+
+  if (StrTable->StrCount == 0) {
+    // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+    // If the formatted portion of the structure contains string-reference
+    // fields and all the string fields are set to 0 (no string references),
+    // the formatted section of the structure is followed by two null (00h)
+    // BYTES.
+    *SmbiosString++ = '\0';
[SAMI] Case 1: SmbiosString[0] is set to '\0' and the pointer is incremented. So now it points to SmbiosString[1] which will be updated with the String table null terminator before the function returns.
+  } else {
+    for (Index = 0; Index < StrTable->StrCount; Index++) {
+      StrElement = &StrTable->Elements[Index];
+      AsciiStrCpyS (SmbiosString, BytesRemaining, StrElement->String);
+
+      // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+      // - Each string is terminated with a null (00h) BYTE
+      // Bytes Copied = String length + 1 for the string NULL terminator.
+      BytesCopied     = StrElement->StringLen + 1;
+      BytesRemaining -= BytesCopied;
+      SmbiosString   += BytesCopied;
[SAMI] Case 2: AsciiStrCpyS() copies the string including the terrminating null character and BytesCopied is incremented accordingly. SmbiosString is then incremented by BytesCopied. So, SmbiosString should point to the byte where the next string starts or will be updated with the String table null terminator before the function returns.
+    }
+  }
+
+  // See Section 6.1.3 Text strings, SMBIOS Specification Version 3.6.0
+  // - the set of strings is terminated with an additional null (00h) BYTE.
+  *SmbiosString = '\0';
[GM] Shouldn't you advance the SmbiosString pointer by one more ? After the loop isn't SmbiosString going to be at the NULL char of the last string ? And we're trying to add one more NULL character ?
Should it be:
SmbiosString++;
[SAMI] I don't think this increment is required for the reasons explained above in Case 1 & Case 2. However, please let me know if I have missed something.
*SmbiosString = '\0';


+  return EFI_SUCCESS;
+}
+
+/** Initialise the string table and allocate memory for the string elements.
+
+  @param [IN] StrTable           Pointer to the string table
+  @param [IN] MaxStringElements  Maximum number of strings that the string
+                                 table can hold.
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer
+  @return EFI_OUT_OF_RESOURCES   Failed to allocate memory for string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableInitialize (
+  IN STRING_TABLE *CONST  StrTable,
+  IN UINTN                MaxStringElements
+  )
+{
+  STRING_ELEMENT  *Elements;
+
+  if ((StrTable == NULL) || (MaxStringElements > MAX_UINT8)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  ZeroMem (StrTable, sizeof (STRING_TABLE));
+
+  Elements = (STRING_ELEMENT *)AllocateZeroPool (
+                                 sizeof (STRING_ELEMENT) * MaxStringElements
+                                 );
+  if (Elements == NULL) {
+    return EFI_OUT_OF_RESOURCES;
+  }
+
+  StrTable->Elements          = Elements;
+  StrTable->MaxStringElements = (UINT8)MaxStringElements;
+  return EFI_SUCCESS;
+}
+
+/** Free memory allocated for the string elements in the string table.
+
+  @param [IN] StrTable           Pointer to the string table
+
+  @return EFI_SUCCESS            Success
+  @return EFI_INVALID_PARAMETER  Invalid string table pointer or string elements
+**/
+EFI_STATUS
+EFIAPI
+StringTableFree (
+  IN STRING_TABLE *CONST  StrTable
+  )
+{
+  if ((StrTable == NULL) || (StrTable->Elements == NULL)) {
+    return EFI_INVALID_PARAMETER;
+  }
+
+  FreePool (StrTable->Elements);
+  ZeroMem (StrTable, sizeof (STRING_TABLE));
+  return EFI_SUCCESS;
+}
diff --git a/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
new file mode 100644
index 0000000000000000000000000000000000000000..88624c50e3f3e930074222b6d686f75485538b26
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/SmbiosStringTableLib/SmbiosStringTableLib.inf
@@ -0,0 +1,25 @@
+## @file
+#  SMBIOS String Table Helper library.
+#
+#  Copyright (c) 2022, Arm Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION    = 0x0001001B
+  BASE_NAME      = SmbiosStringTableLib
+  FILE_GUID      = 8C570DD8-531E-473F-85C6-9252746DBAC1
+  VERSION_STRING = 1.0
+  MODULE_TYPE    = DXE_DRIVER
+  LIBRARY_CLASS  = SmbiosStringTableLib
+
+[Sources]
+  SmbiosStringTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  DynamicTablesPkg/DynamicTablesPkg.dec
+
+[LibraryClasses]
+  BaseLib
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


[PATCH v1 1/1] uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL

Sam Kaynor
 

Changed 4 incorrect instances of "RANDOM_NAME_PROTOCOL" in
RandomNumberBBTestConformance and RandomNumberBBTestFunction
to "RANDOM_NUMBER_PROTOCOL".

Cc: G Edhaya Chandran <Edhaya.Chandran@...>
Cc: Barton Gao <gaojie@...>
Cc: Carolyn Gjertsen <Carolyn.Gjertsen@...>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Cc: Eric Jin <eric.jin@...>
Cc: Arvin Chen <arvinx.chen@...>
Cc: Supreeth Venkatesh <Supreeth.Venkatesh@...>

Signed-off-by: Sam Kaynor <sam.kaynor@...>
---
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran=
domNumberBBTestConformance.c | 4 ++--
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/Ran=
domNumberBBTestFunction.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/Blac=
kBoxTest/RandomNumberBBTestConformance.c b/uefi-sct/SctPkg/TestCase/UEFI/=
EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
index 2738a4899457..364aaca925e0 100644
--- a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes=
t/RandomNumberBBTestConformance.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes=
t/RandomNumberBBTestConformance.c
@@ -160,7 +160,7 @@ BBTestGetInfoConformanceTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_WARNING,
gConformanceTestAssertionGuid001,
- L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not sup=
ported or EFI_DEVICE_ERROR",
+ L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not s=
upported or EFI_DEVICE_ERROR",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
@@ -180,7 +180,7 @@ BBTestGetInfoConformanceTestCheckpoint1 (
StandardLib,
AssertionType,
gConformanceTestAssertionGuid001,
- L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() returns EFI_=
BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size",
+ L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() returns EF=
I_BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size=
",
L"%a:%d: Status - %r, RNGAlgorithmListSize - %d",
__FILE__,
(UINTN)__LINE__,
diff --git a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/Blac=
kBoxTest/RandomNumberBBTestFunction.c b/uefi-sct/SctPkg/TestCase/UEFI/EFI=
/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
index 3d41085d2243..0ba003449dc6 100644
--- a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes=
t/RandomNumberBBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTes=
t/RandomNumberBBTestFunction.c
@@ -188,7 +188,7 @@ BBTestGetInfoFunctionTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_FAILED,
gTestGenericFailureGuid,
- L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not sup=
ported or EFI_DEVICE_ERROR",
+ L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not s=
upported or EFI_DEVICE_ERROR",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
@@ -201,7 +201,7 @@ BBTestGetInfoFunctionTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_FAILED,
gTestGenericFailureGuid,
- L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() could not =
return the correct RNGAlgorithmListSize",
+ L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() could no=
t return the correct RNGAlgorithmListSize",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
--=20
2.34.1