RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Bring plenty of PCDs values and modifying the original PCIE values
- Less experience and not particularly confident in ACPI area so this might be
stupidly broken in a way I've not considered.
This series leverages Jonathan's patches[1] to add acpi0016 & acpi0017 objects into the
previous DSDT table of sbsa-ref. Since the acpi0016 implementation model on qemu side is
the pxb-cxl, this cxl Bus would share the MMIO space and ECAM sapce of PCIE Bus. Thus I
divide some space from PciMmio32、PciMmio64、PciExpressBar to support cxl-related values.
Based on the new CEDT definitions patch on edk2[2], this series adds a static Cedt.aslc to
support the [SBSA_CXL_HOST] & [SBSA_CXL_FIXED_WINDOW] space on sbsa-ref.
Since I was first developing this platform design for cxl, at the initial stage I only reserved
one cxl host bridge (Bus: 0000:fe) and a cxl root port underneath (fe:00.0), therefore, only one
cxl device(ff:00.0)could be added by user on this cxl Bus.
Link:
[1]: https://lore.kernel.org/linux-cxl/20220616141950.23374-2-Jonathan.Cameron@h…
[2]: https://edk2.groups.io/g/devel/topic/rfc_patch_0_1/108173029
Yuquan Wang (2):
SbsaQemu: Add acpi0016 & acpi0017 objects into DSDT
SbsaQemu: AcpiTables: Add CEDT Table
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 30 +-
.../Qemu/SbsaQemu/AcpiTables/AcpiTables.inf | 20 +-
Silicon/Qemu/SbsaQemu/AcpiTables/Cedt.aslc | 70 +++
Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 410 +++++++++++++++++-
Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc | 2 +-
.../SbsaQemuPciHostBridgeLib.c | 4 +-
.../SbsaQemuPciHostBridgeLib.inf | 3 +
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 34 +-
8 files changed, 555 insertions(+), 18 deletions(-)
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Cedt.aslc
--
2.34.1
信息安全声明:本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
信息安全声明:本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Bring plenty of PCDs values and modifying the original PCIE values
- Less experience and not particularly confident in ACPI area so this might be
stupidly broken in a way I've not considered.
This series leverages Jonathan's patches[1] to add acpi0016 & acpi0017 objects into the
previous DSDT table of sbsa-ref. Since the acpi0016 implementation model on qemu side is
the pxb-cxl, this cxl Bus would share the MMIO space and ECAM sapce of PCIE Bus. Thus I
divide some space from PciMmio32、PciMmio64、PciExpressBar to support cxl-related values.
Based on the new CEDT definitions patch on edk2[2], this series adds a static Cedt.aslc to
support the [SBSA_CXL_HOST] & [SBSA_CXL_FIXED_WINDOW] space on sbsa-ref.
Since I was first developing this platform design for cxl, at the initial stage I only reserved
one cxl host bridge (Bus: 0000:fe) and a cxl root port underneath (fe:00.0), therefore, only one
cxl device(ff:00.0)could be added by user on this cxl Bus.
Link:
[1]: https://lore.kernel.org/linux-cxl/20220616141950.23374-2-Jonathan.Cameron@h…
[2]: https://edk2.groups.io/g/devel/topic/rfc_patch_0_1/108173029
Yuquan Wang (2):
SbsaQemu: Add acpi0016 & acpi0017 objects into DSDT
SbsaQemu: AcpiTables: Add CEDT Table
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 30 +-
.../Qemu/SbsaQemu/AcpiTables/AcpiTables.inf | 20 +-
Silicon/Qemu/SbsaQemu/AcpiTables/Cedt.aslc | 70 +++
Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 410 +++++++++++++++++-
Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc | 2 +-
.../SbsaQemuPciHostBridgeLib.c | 4 +-
.../SbsaQemuPciHostBridgeLib.inf | 3 +
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 34 +-
8 files changed, 555 insertions(+), 18 deletions(-)
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Cedt.aslc
--
2.34.1
信息安全声明:本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。
Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
Hello Marcin
I’m sorry to disturb you in your busy schedule.
Hafnium is the Secure Partition Manager (SPM) reference implementation. The documents describe that qemu above 2.9 version support to run hafnium,
and I am thinking about how to run Hafnium under SbsaQemu, is there any demo or any reference?
Yours sincerely
yining
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?
BSA ACS run on SBSA Reference platform gives 8 skipped tests:
303 : Check SMMU Large Physical Addr Support
403 : Memory mapped timer check
404 : Generate Mem Mapped SYS Timer Intr
405 : Restore PE timer on PE wake up
505 : Wake from System Timer Int
606 : 16550 compatible UART
806 : Legacy int must be SPI & lvl-sensitive
817 : Check Direct Transl P2P Support
303 wants SMMU with LPA support but skips when cpu lacks it.
606 checks for 16550 UART, we have PL011 one (you need one of them)
403, 404, 405, 505 require memory mapped system timers which we do not
have. But we have PE timer always on (test 402) so can ignore them.
806 is platform specific and needs to be populated by partners with
system legacy irq map.
817 wants RP type device with P2P and ATS support. Skips if not present.