I have to skip tomorrow's (19th Dec) meeting. Zoom should allow to join
without me being present but I plan to have an alarm to be able to start
it in case of need.
SbsaQemu can configure with numa-related arguments, but OS cannot
identify the numa architecture without SRAT tables. We add supporting
for generating SRAT tables at runtime to solve this issue.
Changes in v2:
- get the information of numa via SMC calls rather than parse DT.
Changes in v3
- Considering the combination of CPU and memory nodes when counting
numa nodes.
Xiong Yining (1):
SbsaQemu: AcpiDxe: Create SRAT table at runtime
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 91 +++++++++++++++++++
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 28 ++++++
.../SbsaQemu/Include/Library/QemuSbsaSmc.h | 10 ++
.../Library/SbsaQemuSmc/SbsaQemuSmc.c | 31 +++++++
.../Library/SbsaQemuSmc/SbsaQemuSmc.inf | 1 +
5 files changed, 161 insertions(+)
--
2.34.1
We submit a patch in TF-A which is armed at reporting the information
of through SMC. Cooperating with that patch, we can get thecinformation
of memory in EDK2 via SMC calls.
Changes in v2:
- Align with the latest version.
- modify language and formatting errors.
Changes in v3:
- read the information of memory in SbsaQemuSmc.c.
Changes in v4:
- add DT fallback when SMC failed.
Xiong Yining (1):
SbsaQemu: get the information of memory form TF-A
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 +
.../Include/IndustryStandard/SbsaQemuSmc.h | 2 +
.../SbsaQemu/Include/Library/QemuSbsaSmc.h | 49 +++++++
.../Library/SbsaQemuLib/SbsaQemuLib.inf | 2 +-
.../Library/SbsaQemuLib/SbsaQemuMem.c | 52 ++-----
.../Library/SbsaQemuSmc/SbsaQemuSmc.c | 137 ++++++++++++++++++
.../Library/SbsaQemuSmc/SbsaQemuSmc.inf | 10 ++
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 3 +
8 files changed, 216 insertions(+), 41 deletions(-)
--
2.34.1
SbsaQemu can configure with numa-related arguments, but OS cannot
identify the numa architecture without SRAT tables. We add supporting
for generating SRAT tables at runtime to solve this issue.
Changes in v2:
- get the information of numa via SMC calls rather than parse DT.
Xiong Yining (1):
SbsaQemu: AcpiDxe: Create SRAT table at runtime
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 91 +++++++++++++++++++
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 28 ++++++
.../SbsaQemu/Include/Library/QemuSbsaSmc.h | 10 ++
.../Library/SbsaQemuSmc/SbsaQemuSmc.c | 22 +++++
.../Library/SbsaQemuSmc/SbsaQemuSmc.inf | 3 +
5 files changed, 154 insertions(+)
--
2.34.1
We submit a patch in TF-A which is armed at reporting the information
of through SMC. Cooperating with that patch, we can get thecinformation
of memory in EDK2 via SMC calls.
Changes in v2:
- Align with the latest version.
- modify language and formatting errors.
Changes in v3:
- read the information of memory in SbsaQemuSmc.c.
Xiong Yining (1):
SbsaQemu: get the information of memory form TF-A
.../SbsaQemuPlatformVersion.h | 1 +
.../Include/IndustryStandard/SbsaQemuSmc.h | 2 +
.../SbsaQemu/Include/Library/QemuSbsaSmc.h | 28 ++++++++++
.../Library/SbsaQemuLib/SbsaQemuLib.inf | 2 +-
.../Library/SbsaQemuLib/SbsaQemuMem.c | 52 +++++--------------
.../Library/SbsaQemuSmc/SbsaQemuSmc.c | 45 ++++++++++++++++
6 files changed, 89 insertions(+), 41 deletions(-)
--
2.34.1
As a part of removing DeviceTree from EDK2 I wrote code for CPU
information.
TF-A reads data for upto 512 cpus and keep it in local memory.
Two SMC calls are provided for EDK2:
- GET_CPU_COUNT reports amount of cpus
- GET_CPU_NODE returns MPIDR and NUMA node id values for selected cpu
I took some ideas from Xiong Yining's memory patches.
For EDK2 I removed FdtHelperLib as we no longer need it. Dropped FdtLib
from all places where it is no longer needed - the only place is getting
memory nodes but that is handled by Xiong Yining's patches.
There is SbsaQemuSmc helper library with functions to get MPIDR and NUMA
node id for selected cpu.
Amount of cpus is read in SbsaQemuPlatformDxe and stored in PcdCoreCount
variable. It is the first place where this data is used so I replaced
all FdtHelperLib calls with PcdGet32 calls.
Generation of SRAT table needs to be rewritten.
Marcin Juszkiewicz (2):
feat(qemu_sbsa): handle CPU information
SbsaQemu: get cpu information from TF-A
--
2.43.0
We submit a patch(d56b488) in TF-A which is armed at reporting the information of
memory through SMC. Cooperating with that patch, we can get the
information of memory in EDK2 via SMC calls.
Xiong Yining (1):
SbsaQemu: get the information of memory form TF-A
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 5 +++-
.../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c | 29 +++++++++++++++++++
.../SbsaQemuPlatformDxe.inf | 1 +
.../SbsaQemuPlatformVersion.h | 14 +++++++++
.../Include/IndustryStandard/SbsaQemuSmc.h | 2 ++
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 2 ++
6 files changed, 52 insertions(+), 1 deletion(-)
--
2.34.1
Back in May 2023, when we were handling versioning changes, I added set
of SMC calls between TF-A and EDK2 to share hardware details (instead of
parsing DeviceTree in EDK2).
I think that it is time to move forward and drop DeviceTree support from
EDK2 completely.
# what for we use DT now?
There are few things we read from DT in EDK2 now:
- cpu count
- cpu mpidr value
- cpu numa node id
- memory nodes (with numa node ids)
# initial code
I took a look at it, created some tickets [1] in Linaro Jira and wrote
some initial code for checking cpu count (will send to ML).
1. https://linaro.atlassian.net/browse/SRCPC-156
# ideas for next steps
For mpidr/numa I have some ideas. I was thinking of adding function in
sbsa_sip_svc.c which would count cpus (using code I already have) and
then malloc() memory for cpu struct { id, mpidr, node_id } for each cpu.
And similar for memory nodes: read DT, alloc structures, fill them.
When EDK2 does SMC call to get cpu data like mpidr/node_id code will go
through allocated structures and return single data. Again, similar for
memory nodes.
The funny part: DT is somewhere in memory during BL3*, we provide it for
EDK2 at start of memory but I probably do something wrong when trying to
access it during BL3*.
Current data gathering reads DT from BL2 memory before MMU kicks in.
# things for the future
Adding SPM would require additional calls. So far I only created ticket
[2] for it without looking into details.
2. https://linaro.atlassian.net/browse/SRCPC-165
# call for opinions
What are your opinions about it? Ideas? Someone maybe already considered it?
When SaSbQemu platform is configured with multi memory nodes,like numa architecture, os will ignore any memory node in the device tree except the first one.The kernel reads UEFI memory map for memory information when booting via UEFI.However UEFI only allocates the first memory node memory space for SbsaQemu platform, in this scenario we can full use of HighMemDxe to add memory spaces for other memory nodes.
Changes in V2:
- Modify the the execution order of PlatformPeiLib moodule after memory initialization
xiongyining1480 (3):
SbsaQemu: Use HighMemDxe provided by OvmfPkg
SbsaQemu: Use FdtClientDxe provided by EmbeddedPkg
SbsaQemu: Add PlatformPeiLib library
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 8 ++-
Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 2 +
.../Library/PlatformPeiLib/PlatformPeiLib.c | 63 +++++++++++++++++++
.../Library/PlatformPeiLib/PlatformPeiLib.inf | 41 ++++++++++++
4 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 Silicon/Qemu/SbsaQemu/Library/PlatformPeiLib/PlatformPeiLib.c
create mode 100644 Silicon/Qemu/SbsaQemu/Library/PlatformPeiLib/PlatformPeiLib.inf
--
2.34.1
