Linaro Connect MAD24 brought several meetings and discussions. We had
session where I presented what was done on SBSA Reference Platform
during last year and what are plans.
https://resources.linaro.org/en/resource/fnNt6vFpdT73EDhLZCxK6w has
video (with AI generated subtitles) and slides.
Current patch queue:
QEMU:
- move sbsa-ref to Neoverse-N2 by default
- switch from OpenBSD to FreeBSD in QEMU CI (for non-Linux coverage)
- update firmware used in QEMU CI to TF-A 2.11.0 + EDK2 stable202405
EDK2:
- multiple PCIe buses in NUMA setup
- update TF-A in edk2-non-osi to 2.11.0 like above
Some of my notes and ideas from Connect below.
1. Simple topology stuff.
Maybe instead of exporting whole /cpus/cpu-map/ we should export simple
topology:
cpus {
topology {
threads = <0x01>;
cores = <0x04>;
clusters = <0x01>;
sockets = <0x01>;
};
It gives everything we need. And much easier parsing in TF-A.
Had some thinking about exporting amount of cores per cluster (8 now,
virt uses 16 which is architecture maximum now) in case we would use it
in generation of PPTT in EDK2.
2. L1/L2 cache info per core in PPTT.
I was asked can we put L1/L2 cache information for each core in PPTT. We
would need to change that code while handling topology stuff so why not
do that at same time. It would be used once we get MPAM support.
3. Move to Neoverse-N2 by default.
N2 is v9.0 cpu which gives us several features like RME, RNG, SVE etc
enabled by default. There is a work related with CCA (Confidential
Computing) which requires RME. Presence of RNG allows us to provide
EFI_PROTOCOL_RNG to kernel.
4. EDK2 needs changes for SMCCC 1.5
ArmCallSmc*() functions make use of x0-x7 registers (x0-x7 as arguments,
x0-x3 as results) like it was designed in 2016 in "SMC Calling
Conventions" specification. But those calls can use x0-x17 (both as
arguments and results) since 2020 and our topology stuff needs that.
https://developer.arm.com/documentation/den0028/latest/
As part of it should also use ArmCallSmc() instead of ArmCallSmc[0-3]()
functions - this way we can use more arguments/results without a need
for creation of all ArmCallSmc[0-17]() calls.
5. Firmware Handoff protocol
FH protocol is very simple protocol to share data between firmware
layers. We could use it instead of Devicetree so people would stop
suggesting 'add this or that to DT'.
https://github.com/FirmwareHandoff/firmware_handoff
We should do it sooner than later - 'adapt spec now, or adapt to spec
later' kind.
6. CPU hotplug
So far the only data is 'check with cpu hotplug, -smp and maxcpus stuff'
but it may be interesting to know do we (can) have it or not.
Any opinions? Something to add, comments?
There is a patch for changing MPIDR_EL1 handling on qemu-devel ML [1]
which (if merged) will force us to do changes to SBSA-ref in QEMU, TF-A
and probably EDK2 too.
1.
https://lore.kernel.org/qemu-devel/20240419183135.12276-1-dorjoychy111@gmai…
Details:
MPIDR_EL1 register keeps cpu topology information. There are 2 or 4 8bit
fields called Aff0-Aff3.
For now Aff0 and Aff1 are used in QEMU:
Aff0 - keeps core number (8 cores per cluster)
Aff1 - keeps cluster number
The plan is to use 0/1 for cores below Neoverse-N1 and 0-3 on higher
ones with Aff0 being 0 as it is used for threads which are forbidden in
designed emulated by QEMU.
So whole topology can be stored:
Aff0 - thread
Aff1 - core
Aff2 - cluster
Aff3 - socket
What it means for us?
First of all: platform version MAJOR bump. So we would have
platform_version = 1.0 as virtual hardware changes force firmware changes.
Second: TF-A freeze is coming. Would be good to not have to wait for
November and 2.12 release.
We need to drop sbsa_topology.c from TF-A as it assumes Aff0/1 way and
errors out on Aff0-3 way.
Generation of PPTT in EDK2 needs to be changed too. Good side is that we
may drop DT/SMC way and read socket/cluster/core/thread from MPIDR_EL1
directly.
To make things easier I would like to drop support for Cortex-A57/A72
from sbsa-ref. They have Aff0/1 only and would require special handling
in firmware. We would need it anyway as people tend to use misc versions
of QEMU but this way code will get less and less used. And v8.2 will be
minimal version.
Opinions?
