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?