[PATCH 1/1] hw/arm/sbsa-ref: switch to 1GHz timer frequency

[Marcin Juszkiewicz]

Updated firmware for QEMU CI is already in merge queue so we can move
platform to be future proof.

All supported cpus work fine with 1GHz timer frequency when firmware is
fresh enough.

Signed-off-by: Marcin Juszkiewicz 
---
 hw/arm/sbsa-ref.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 57c337fd92..7bd6898edf 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -62,16 +62,12 @@
 
 /*
  * Generic timer frequency in Hz (which drives both the CPU generic timers
- * and the SBSA watchdog-timer). Older versions of the TF-A firmware
- * typically used with sbsa-ref (including the binaries in our Avocado test
- * Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef
- * assume it is this value.
+ * and the SBSA watchdog-timer). Older (<2.11) versions of the TF-A firmware
+ * assumed 62.5MHz here.
  *
- * TODO: this value is not architecturally correct for an Armv8.6 or
- * better CPU, so we should move to 1GHz once the TF-A fix above has
- * made it into a release and into our Avocado test.
+ * Starting with Armv8.6 CPU 1GHz timer frequency is mandated.
  */
-#define SBSA_GTIMER_HZ 6250
+#define SBSA_GTIMER_HZ 10
 
 enum {
 SBSA_FLASH,
-- 
2.45.1

[PATCH 0/1] hw/arm/sbsa-ref: switch to 1GHz timer frequency

[Marcin Juszkiewicz]

Trusted Firmware 2.11 got released, EDK2 202405 got released as well.
Both were built for QEMU CI and proper patch is now in arm.next queue.

So all requirements to move from legacy 62.5MHz to armv8.6-ready 1GHz
frequency are fulfiled.

Marcin Juszkiewicz (1):
  hw/arm/sbsa-ref: switch to 1GHz timer frequency

 hw/arm/sbsa-ref.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

-- 
2.45.1

Re: [PATCH 1/1] tests/avocado: update sbsa-ref firmware

[Marcin Juszkiewicz]

W dniu 29.05.2024 o 15:12, Leif Lindholm pisze:

On 2024-05-28 19:29, Marcin Juszkiewicz wrote:

Partial support for NUMA setup:
- cpu nodes
- memory nodes

Used versions:

- Trusted Firmware v2.11.0
- Tianocore EDK2 stable202405
- Tianocore EDK2 Platforms code commit 4bbd0ed

Firmware is built using Debian 'bookworm' cross toolchain (gcc 12.2.0).


Missing signoff?


Ooops.

Signed-off-by: Marcin Juszkiewicz 


Apart from that:
Reviewed-by: Leif Lindholm 


---
  tests/avocado/machine_aarch64_sbsaref.py | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py

index 98c76c1ff7..6bb82f2a03 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -37,18 +37,18 @@ def fetch_firmware(self):
  Used components:
-    - Trusted Firmware 2.10.2
-    - Tianocore EDK2 stable202402
-    - Tianocore EDK2-platforms commit 085c2fb
+    - Trusted Firmware 2.11.0
+    - Tianocore EDK2 stable202405
+    - Tianocore EDK2-platforms commit 4bbd0ed
  """
  # Secure BootRom (TF-A code)
  fs0_xz_url = (
  
"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;

-    "20240313-116475/edk2/SBSA_FLASH0.fd.xz"
+    "20240528-140808/edk2/SBSA_FLASH0.fd.xz"
  )
-    fs0_xz_hash = 
"637593749cc307dea7dc13265c32e5d020267552f22b18a31850b8429fc5e159"
+    fs0_xz_hash = 
"fa6004900b67172914c908b78557fec4d36a5f784f4c3dd08f49adb75e1892a9"
  tar_xz_path = self.fetch_asset(fs0_xz_url, 
asset_hash=fs0_xz_hash,

    algorithm='sha256')
  archive.extract(tar_xz_path, self.workdir)
@@ -57,9 +57,9 @@ def fetch_firmware(self):
  # Non-secure rom (UEFI and EFI variables)
  fs1_xz_url = (
  
"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;

-    "20240313-116475/edk2/SBSA_FLASH1.fd.xz"
+    "20240528-140808/edk2/SBSA_FLASH1.fd.xz"
  )
-    fs1_xz_hash = 
"cb0a5e8cf5e303c5d3dc106cfd5943ffe9714b86afddee7164c69ee1dd41991c"
+    fs1_xz_hash = 
"5f3747d4000bc416d9641e33ff4ac60c3cc8cb74ca51b6e932e58531c62eb6f7"
  tar_xz_path = self.fetch_asset(fs1_xz_url, 
asset_hash=fs1_xz_hash,

    algorithm='sha256')
  archive.extract(tar_xz_path, self.workdir)
@@ -98,15 +98,15 @@ def test_sbsaref_edk2_firmware(self):
  # AP Trusted ROM
  wait_for_console_pattern(self, "Booting Trusted Firmware")
-    wait_for_console_pattern(self, "BL1: v2.10.2(release):")
+    wait_for_console_pattern(self, "BL1: v2.11.0(release):")
  wait_for_console_pattern(self, "BL1: Booting BL2")
  # Trusted Boot Firmware
-    wait_for_console_pattern(self, "BL2: v2.10.2(release)")
+    wait_for_console_pattern(self, "BL2: v2.11.0(release)")
  wait_for_console_pattern(self, "Booting BL31")
  # EL3 Runtime Software
-    wait_for_console_pattern(self, "BL31: v2.10.2(release)")
+    wait_for_console_pattern(self, "BL31: v2.11.0(release)")
  # Non-trusted Firmware
  wait_for_console_pattern(self, "UEFI firmware (version 1.0")

[PATCH 1/1] tests/avocado: update sbsa-ref firmware

[Marcin Juszkiewicz]

Partial support for NUMA setup:
- cpu nodes
- memory nodes

Used versions:

- Trusted Firmware v2.11.0
- Tianocore EDK2 stable202405
- Tianocore EDK2 Platforms code commit 4bbd0ed

Firmware is built using Debian 'bookworm' cross toolchain (gcc 12.2.0).
---
 tests/avocado/machine_aarch64_sbsaref.py | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 98c76c1ff7..6bb82f2a03 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -37,18 +37,18 @@ def fetch_firmware(self):
 
 Used components:
 
-- Trusted Firmware 2.10.2
-- Tianocore EDK2 stable202402
-- Tianocore EDK2-platforms commit 085c2fb
+- Trusted Firmware 2.11.0
+- Tianocore EDK2 stable202405
+- Tianocore EDK2-platforms commit 4bbd0ed
 
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
 "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
-"20240313-116475/edk2/SBSA_FLASH0.fd.xz"
+"20240528-140808/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = 
"637593749cc307dea7dc13265c32e5d020267552f22b18a31850b8429fc5e159"
+fs0_xz_hash = 
"fa6004900b67172914c908b78557fec4d36a5f784f4c3dd08f49adb75e1892a9"
 tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash,
   algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
@@ -57,9 +57,9 @@ def fetch_firmware(self):
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
 "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
-"20240313-116475/edk2/SBSA_FLASH1.fd.xz"
+"20240528-140808/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = 
"cb0a5e8cf5e303c5d3dc106cfd5943ffe9714b86afddee7164c69ee1dd41991c"
+fs1_xz_hash = 
"5f3747d4000bc416d9641e33ff4ac60c3cc8cb74ca51b6e932e58531c62eb6f7"
 tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
   algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
@@ -98,15 +98,15 @@ def test_sbsaref_edk2_firmware(self):
 
 # AP Trusted ROM
 wait_for_console_pattern(self, "Booting Trusted Firmware")
-wait_for_console_pattern(self, "BL1: v2.10.2(release):")
+wait_for_console_pattern(self, "BL1: v2.11.0(release):")
 wait_for_console_pattern(self, "BL1: Booting BL2")
 
 # Trusted Boot Firmware
-wait_for_console_pattern(self, "BL2: v2.10.2(release)")
+wait_for_console_pattern(self, "BL2: v2.11.0(release)")
 wait_for_console_pattern(self, "Booting BL31")
 
 # EL3 Runtime Software
-wait_for_console_pattern(self, "BL31: v2.10.2(release)")
+wait_for_console_pattern(self, "BL31: v2.11.0(release)")
 
 # Non-trusted Firmware
 wait_for_console_pattern(self, "UEFI firmware (version 1.0")
-- 
2.45.1

Re: [PATCH] target/arm: Disable SVE extensions when SVE is disabled

[Marcin Juszkiewicz]

W dniu 26.05.2024 o 22:45, Richard Henderson pisze:

From: Marcin Juszkiewicz 

Cc: qemu-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2304
Reported-by: Marcin Juszkiewicz 
Signed-off-by: Richard Henderson 


Signed-off-by: Marcin Juszkiewicz 


---

Marcin added the correct patch to the issue 3 weeks ago, so I'm giving
him authorship here.  I only updated the comment a bit.


I am not fully sure is it everything needed to be honest.

Value 0x in [3:0] means "The SVE instructions are implemented".

The way why it works is probably because QEMU keeps "there is no SVE" 
information separately and do not emulate them.



Marcin, if you'd reply to this with your s-o-b, that would be helpful.


done



r~

---
  target/arm/cpu64.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index c15d086049..862d2b92fa 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -109,7 +109,11 @@ void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
   * No explicit bits enabled, and no implicit bits from sve-max-vq.
   */
  if (!cpu_isar_feature(aa64_sve, cpu)) {
-/* SVE is disabled and so are all vector lengths.  Good. */
+/*
+ * SVE is disabled and so are all vector lengths.  Good.
+ * Disable all SVE extensions as well.
+ */
+cpu->isar.id_aa64zfr0 = 0;
  return;
  }
  

Re: [PATCH v4 1/1] hw/arm/sbsa-ref: Enable CPU cluster on ARM sbsa machine

[Marcin Juszkiewicz]

W dniu 26.04.2024 o 09:35, Xiong Yining pisze:

From: xiongyining1480

Enable CPU cluster support on SbsaQemu platform, so that users can
specify a 4-level CPU hierarchy sockets/clusters/cores/threads. And
this topology can be passed to the firmware through DT cpu-map.

Signed-off-by: Xiong Yining
tested-by: Marcin Juszkiewicz


I had some thinking about it recently. This patch exported whole 
/cpus/cpu-map/ tree which we then parse in TF-A to get amount of 
sockets/clusters/cores/threads.


Why not export them directly? Kind of:

cpus {
topology {
threads = <0x01>;
cores = <0x04>;
clusters = <0x01>;
sockets = <0x01>;
};

It gives everything we need.

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.

[PATCH 1/1] tests/avocado: sbsa-ref: switch from OpenBSD to FreeBSD

[Marcin Juszkiewicz]

FreeBSD has longer support cycle for stable release (14.x EoL in 2028)
than OpenBSD (7.3 we used is already EoL). Also bugfixes are backported
so we can stay on 14.x for longer.

Planned to upgrade to newer OpenBSD but we would have to wait for 7.6
release to get Neoverse-V1/N2 support.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 65 
 1 file changed, 43 insertions(+), 22 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 98c76c1ff7..c3c7c0e639 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -1,4 +1,4 @@
-# Functional test that boots a Linux kernel and checks the console
+# Functional test that boots a kernel and checks the console
 #
 # SPDX-FileCopyrightText: 2023-2024 Linaro Ltd.
 # SPDX-FileContributor: Philippe Mathieu-Daud?? 
@@ -177,14 +177,14 @@ def test_sbsaref_alpine_linux_max(self):
 # This tests the whole boot chain from EFI to Userspace
 # We only boot a whole OS for the current top level CPU and GIC
 # Other test profiles should use more minimal boots
-def boot_openbsd73(self, cpu):
+def boot_freebsd14(self, cpu):
 self.fetch_firmware()
 
 img_url = (
-"https://cdn.openbsd.org/pub/OpenBSD/7.3/arm64/miniroot73.img;
+
"https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-RELEASE-arm64-aarch64-bootonly.iso;
 )
 
-img_hash = 
"7fc2c75401d6f01fbfa25f4953f72ad7d7c18650056d30755c44b9c129b707e5"
+img_hash = 
"2f3ceb0ef6b1de53553abb9979a6d65f51b006dbfa985798b282812ecb758c1b"
 img_path = self.fetch_asset(img_url, algorithm="sha256", 
asset_hash=img_hash)
 
 self.vm.set_console()
@@ -196,43 +196,64 @@ def boot_openbsd73(self, cpu):
 )
 
 self.vm.launch()
-wait_for_console_pattern(self,
- "Welcome to the OpenBSD/arm64"
- " 7.3 installation program.")
+wait_for_console_pattern(self, "Welcome to FreeBSD!")
 
-def test_sbsaref_openbsd73_cortex_a57(self):
+def test_sbsaref_freebsd14_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("cortex-a57")
+self.boot_freebsd14("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(self):
+def test_sbsaref_freebsd14_neoverse_n1(self):
 """
 :avocado: tags=cpu:neoverse-n1
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("neoverse-n1")
+self.boot_freebsd14("neoverse-n1")
 
-def test_sbsaref_openbsd73_max_pauth_off(self):
+def test_sbsaref_freebsd14_neoverse_n2_pauth_off(self):
+"""
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd14("neoverse-n2,pauth=off")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+def test_sbsaref_freebsd14_neoverse_n2_pauth_impdef(self):
+"""
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd14("neoverse-n2,pauth-impdef=on")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+def test_sbsaref_freebsd14_neoverse_n2(self):
+"""
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd14("neoverse-n2")
+
+def test_sbsaref_freebsd14_max_pauth_off(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max,pauth=off")
+self.boot_freebsd14("max,pauth=off")
 
 @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max_pauth_impdef(self):
+def test_sbsaref_freebsd14_max_pauth_impdef(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max,pauth-impdef=on")
+self.boot_freebsd14("max,pauth-impdef=on")
 
 @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max(self):
+def test_sbsaref_freebsd14_max(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max")
+self.boot_freebsd14("max")
-- 
2.45.1

[PATCH 1/1] arm/sbsa-ref: move to Neoverse-N2 as default

[Marcin Juszkiewicz]

Moving to Neoverse-N2 gives us several cpu features to use for expanding
our platform:

- branch target identification
- pointer authentication
- RME for confidential computing
- RNG for EFI_PROTOCOL_RNG
- SVE being enabled by default

We do not go for "max" as default to have stable set of features enabled
by default. It is still supported and can be selected with "--cpu"
argument.

Signed-off-by: Marcin Juszkiewicz 
---
 hw/arm/sbsa-ref.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 57c337fd92..e884692f07 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -891,7 +891,7 @@ static void sbsa_ref_class_init(ObjectClass *oc, void *data)
 
 mc->init = sbsa_ref_init;
 mc->desc = "QEMU 'SBSA Reference' ARM Virtual Machine";
-mc->default_cpu_type = ARM_CPU_TYPE_NAME("neoverse-n1");
+mc->default_cpu_type = ARM_CPU_TYPE_NAME("neoverse-n2");
 mc->valid_cpu_types = valid_cpu_types;
 mc->max_cpus = 512;
 mc->pci_allow_0_address = true;
-- 
2.45.1

Re: [PATCH] hvf: arm: Fix encodings for ID_AA64PFR1_EL1 and debug System registers

[Marcin Juszkiewicz]

W dniu 3.05.2024 o 17:34, Zenghui Yu pisze:

We wrongly encoded ID_AA64PFR1_EL1 using {3,0,0,4,2} in hvf_sreg_match[] so
we fail to get the expected ARMCPRegInfo from cp_regs hash table with the
wrong key.

Fix it with the correct encoding {3,0,0,4,1}. With that fixed, the Linux
guest can properly detect FEAT_SSBS2 on my M1 HW.

All DBG{B,W}{V,C}R_EL1 registers are also wrongly encoded with op0 == 14.
It happens to work because HVF_SYSREG(CRn, CRm, 14, op1, op2) equals to
HVF_SYSREG(CRn, CRm, 2, op1, op2), by definition. But we shouldn't rely on
it.

Fixes: a1477da3ddeb ("hvf: Add Apple Silicon support")
Signed-off-by: Zenghui Yu


If your boot environment allows to run EFI binaries then my ArmCpuInfo 
app [1] can be used to check values of system registers and flags 
present in them.


https://github.com/hrw/edk2-armcpuinfo/releases/tag/v1.2.0

Example header:

ArmCpuInfo v1.2.0

ID_AA64MMFR0_EL1 = 0x0100032310201126
ID_AA64MMFR1_EL1 = 0x0010011010312122
ID_AA64MMFR2_EL1 = 0x122102011011
ID_AA64PFR0_EL1  = 0x120100112111
ID_AA64PFR1_EL1  = 0x01000121
ID_AA64ISAR0_EL1 = 0x122110212120
ID_AA64ISAR1_EL1 = 0x001101211052
ID_AA64ISAR2_EL1 = 0x0011
ID_AA64DFR0_EL1  = 0x100010305609
ID_AA64SMFR0_EL1 = 0x80F100FD
ID_AA64ZFR0_EL1  = 0x0110110100110021

Have to finish work on next release - it will show also values of 
MMFR3/4, ISAR3, AFR0/1 and FPFR0 registers.

Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Marcin Juszkiewicz]

W dniu 2.05.2024 o 15:13, Peter Maydell pisze:

On Thu, 2 May 2024 at 14:11, Marcin Juszkiewicz
 wrote:


W dniu 2.05.2024 o 15:04, Dorjoy Chowdhury pisze:

Should "return" also have "(1 << 24) |" to have MT=1 set?

Otherwise MPIDR_EL1 = 0x000100 can mean core0 in cluster1 or core1 in
cluster0.

Value 0x1000100 shows MT=1 so thread0 in core1 in cluster0.



I don't know all the details but from what I understand the
"arm_build_mp_afiinity" is used to set the "mp_affinity" member
variable which I assume is about affinity, not the whole MPIDR
register value. That is what I assumed because the Uniprocessor
indication bit(30) is being set only in the "mpidr_read_val" function.
In the patch, the MT bit is also being set in the "mpidr_read_val"
function based on the SMT status (has_smt) of the CPU.


mpidr_read_val() is used only to set VMPIDR and VMPIDR_EL2 registers.

So setting MT bit for MPIDR_EL1 needs to be added somewhere.


The readfn for MPIDR_EL1 is mpidr_read(), which calls
mpidr_read_val().


My mistake.

Both hw/arm/sbsa-ref.c and hw/arm/virt.c build cpu information in 
DeviceTree using "arm_build_mp_afinnity()" function. So if firmware 
parses it then it gets wrong values.


Firmware should probably read MPIDR_EL1 directly instead but what with 
those who read DT and rely on this value already?

Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Marcin Juszkiewicz]

W dniu 2.05.2024 o 15:04, Dorjoy Chowdhury pisze:

Should "return" also have "(1 << 24) |" to have MT=1 set?

Otherwise MPIDR_EL1 = 0x000100 can mean core0 in cluster1 or core1 in
cluster0.

Value 0x1000100 shows MT=1 so thread0 in core1 in cluster0.



I don't know all the details but from what I understand the
"arm_build_mp_afiinity" is used to set the "mp_affinity" member
variable which I assume is about affinity, not the whole MPIDR
register value. That is what I assumed because the Uniprocessor
indication bit(30) is being set only in the "mpidr_read_val" function.
In the patch, the MT bit is also being set in the "mpidr_read_val"
function based on the SMT status (has_smt) of the CPU.


mpidr_read_val() is used only to set VMPIDR and VMPIDR_EL2 registers.

So setting MT bit for MPIDR_EL1 needs to be added somewhere.

Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Marcin Juszkiewicz]

W dniu 19.04.2024 o 20:31, Dorjoy Chowdhury pisze:

-uint64_t arm_build_mp_affinity(int idx, uint8_t clustersz)
+uint64_t arm_build_mp_affinity(ARMCPU *cpu, int idx, uint8_t clustersz)
  {
+if (cpu->has_smt) {
+/*
+ * Right now, the ARM CPUs with SMT supported by QEMU only have
+ * one thread per core. So Aff0 is always 0.
+ */
+uint32_t Aff2 = idx / clustersz;
+uint32_t Aff1 = idx % clustersz;
+uint32_t Aff0 = 0;
+return (Aff2 << ARM_AFF2_SHIFT) | (Aff1 << ARM_AFF1_SHIFT) | Aff0;
+}


Should "return" also have "(1 << 24) |" to have MT=1 set?

Otherwise MPIDR_EL1 = 0x000100 can mean core0 in cluster1 or core1 in 
cluster0.


Value 0x1000100 shows MT=1 so thread0 in core1 in cluster0.

Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Marcin Juszkiewicz]

W dniu 2.05.2024 o 12:37, Peter Maydell pisze:

  * what are the constraints on the Aff* fields (eg that kernel
commit suggests Aff0 shouldn't be > 15)?



This one is apparently related to GICv3 -- if the GIC doesn't
implement RangeSelector support in ICC_SGI0R_EL1 and other
places (advertised via GICD_TYPER.RSS and ICC_CTLR_EL1.SS) then
there's no way to send an SGI to a CPU whose Aff0 is outside
[0..15], and so you shouldn't build a system with Aff0 > 15.
QEMU's GICv3 doesn't implement the RSS functionality (though it
wouldn't be hard to add if we really cared), so we should also
keep Aff0 in [0..15].


Arm/virt uses 8 cores/cluster on GICv2 and 16 cores/cluster on GICv3 as 
this is amount of SGI target-list bits available.


Arm/sbsa-ref goes with 8 cores per cluster by use of 
ARM_DEFAULT_CPUS_PER_CLUSTER.



We have ARM_DEFAULT_CPUS_PER_CLUSTER = 8, which does keep us
in that range. I don't think there's really a good reason for
it to be 8 rather than 16: this might be legacy from GICv2?


GICv2 supported only 8 cores.

Re: [PATCH] target/arm: fix MPIDR value for ARM CPUs with SMT

[Marcin Juszkiewicz]

W dniu 22.04.2024 o 17:21, Richard Henderson pisze:

For Arm's CPUs they fall into two categories:
  * older ones don't set MT in their MPIDR, and the Aff0
    field is effectively the CPU number
  * newer ones do set MT in their MPIDR, but don't have
    SMT, so their Aff0 is always 0 and their Aff1
    is the CPU number

Of all the CPUs we model, none of them are the
architecturally-permitted "MT is set, CPU implements
actual SMT, Aff0 indicates the thread in the CPU" type.


Looking at the TRM, Neoverse-E1 is "MT is set, actual SMT,
Aff0 is the thread" (Aff0 can be 0 or 1). We just don't
model that CPU type yet. But we should probably make
sure we don't block ourselves into a corner where that
would be awkward -- I'll have a think about this and
look at what x86 does with the topology info.


I'm suggesting that we set things up per -smp, and if the user chooses a 
-cpu value for which that topology doesn't make sense, we do it anyway 
and let them keep both pieces.


Aff[0-3] are 8 bit each. On those cpus where they exist.

So "-smp 512" (maximum allowed for sbsa-ref) would need to be split to 2 
clusters by 256 cores or 64 clusters of 8 cores each like it is today so 
it is backward compatible with whatever assumption firmware/OS does.


But if we go for 'newer, better MPIDR_EL1' then maybe it is time to set 
U bit [30] if "-smp X,sockets=Y" where Y > 1? Or when NUMA config with 
multiple cpu nodes are setup.


Also a way to know which AffX fields to check on firmware/OS side would 
be nice. A57/72 use Aff[1-2], N1+ use Aff[0-3]. Sure, it can be checked 
by going through cores, reading then MPIDR_EL1 and if 7:0 has same value 
on all of them then check Aff[1-3], otherwise Aff[1-2].

Re: [PATCH v2 2/4] hw/arm/sbsa-ref: Force CPU generic timer to 62.5MHz

[Marcin Juszkiewicz]

W dniu 26.04.2024 o 14:29, Peter Maydell pisze:

The default frequency used by the 'max' CPU is about to change, so
make the sbsa-ref board force the CPU frequency to the value which
the firmware expects.

Newer versions of TF-A will read the frequency from the CPU's
CNTFRQ_EL0 register:
  
https://github.com/ARM-software/arm-trusted-firmware/commit/4c77fac98dac0bebc63798aae9101ac865b87148
so in the longer term we could make this board use the 1GHz
frequency. We will need to make sure we update the binaries used
by our avocado test
  Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef
before we can do that.

Signed-off-by: Peter Maydell
---
I leave it up to the sbsa-ref maintainers exactly when they
want to shift to 1GHz (probably after a TF-A release with the fix?)


Reviewed-by: Marcin Juszkiewicz 

TF-A 2.11 will be released in June. It will have several other 
improvements so I prefer to wait for it.


We will have EDK2 202405 stable release then too which allow us to 
collect all changes we did during last half year (and maybe even those 
in progress).


In meantime we go with 62.5 MHz frequency as it was before so no one 
will get "too fast wall clock" issue. Then, in a middle of June, new 
firmware will be built for QEMU CI and we will be able to move to 1 GHz 
by default and maybe add some other changes on top.

Re: [PATCH v4 1/1] hw/arm/sbsa-ref: Enable CPU cluster on ARM sbsa machine

[Marcin Juszkiewicz]

W dniu 26.04.2024 o 18:06, Richard Henderson pisze:


Isn't this basically what MPIDR_EL1 is supposed to indicate?
We do not yet implement all of that in QEMU, but should.


QEMU has socket/cluster/core/thread model which could map to
aff3/aff2/aff1/aff0 (or aff0/1/2/3) of MPIDR_EL1 register, right? But it 
does not.


Nevermind which combination of socket/cluster/core/thread I use all I 
have is this:


cpu 0x000 mpidr  
cpu 0x001 mpidr  0001
cpu 0x002 mpidr  0010
cpu 0x003 mpidr  0011
cpu 0x004 mpidr  0100
cpu 0x005 mpidr  0101
cpu 0x006 mpidr  0110
cpu 0x007 mpidr  0111

cpu 0x008 mpidr 0001 
cpu 0x009 mpidr 0001 0001
cpu 0x00a mpidr 0001 0010
cpu 0x00b mpidr 0001 0011
cpu 0x00c mpidr 0001 0100
cpu 0x00d mpidr 0001 0101
cpu 0x00e mpidr 0001 0110
cpu 0x00f mpidr 0001 0111

Eight cpu cores per unit. Probably leftover from GICv2 times where there 
was 8 cores per GIC limit.


So looks like adding mapping of topology to MPIDR_EL1 into QEMU would be 
a better option. May require checking for more than 256 of one kind then.



Why does the same info need to be replicated in devicetree?


One of things we had on todolist: export cpu topology in PPTT table. 
With MPIDR being 2 level while topology can be 4 level.

Re: [PATCH v4 1/1] hw/arm/sbsa-ref: Enable CPU cluster on ARM sbsa machine

[Marcin Juszkiewicz]

W dniu 26.04.2024 o 09:35, Xiong Yining pisze:

From: xiongyining1480

Enable CPU cluster support on SbsaQemu platform, so that users can
specify a 4-level CPU hierarchy sockets/clusters/cores/threads. And
this topology can be passed to the firmware through DT cpu-map.

Signed-off-by: Xiong Yining
tested-by: Marcin Juszkiewicz


Thanks. Checked with TF-A and EDK2 patches applied. PPTT table will be 
more detailed now.


Reviewed-by: Marcin Juszkiewicz 

Re: [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines

[Marcin Juszkiewicz]

W dniu 22.04.2024 o 17:37, Marcin Juszkiewicz pisze:

It also seems to be hardcoded in TF-A's support for the virt
board too, annoyingly.


I looked at it and it seems that TF-A can just read what is in 
CNTFRQ_EL0 instead of hardcoding the value.


Submitted patch:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/28313
refactor(qemu): do not hardcode counter frequency [NEW]


Change is now merged.

Re: [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines

[Marcin Juszkiewicz]

W dniu 22.04.2024 o 16:18, Peter Maydell pisze:

On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz



  From what I see in EDK2 code we read CNTFREQ_EL0:

GetPlatformTimerFreq() checks for PcdArmArchTimerFreqInHz variable which
sbsa-ref has set to 0. So it calls ArmGenericTimerGetTimerFreq() ->
ArmReadCntFrq() -> "mrs x0, cntfrq_el0"


Yeah, it looks like it's TF-A that hardcodes the frequency:
https://github.com/ARM-software/arm-trusted-firmware/blob/c8be7c08c3b3a2330d54b58651faa9438ff34f6e/plat/qemu/qemu_sbsa/include/platform_def.h#L269

I imagine that value gets written into CNTFRQ by TF-A somewhere
along the line (and then read by EDK2 later), though I haven't
quite found where. Plus I notice that the TF-A sbsa-watchdog-timer
assumes that the generic-timer frequency and the watchdog
timer frequency are the same, which is a bit dubious IMHO.

It also seems to be hardcoded in TF-A's support for the virt
board too, annoyingly.


I looked at it and it seems that TF-A can just read what is in 
CNTFRQ_EL0 instead of hardcoding the value.


Submitted patch:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/28313
refactor(qemu): do not hardcode counter frequency [NEW]

Re: [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines

[Marcin Juszkiewicz]

W dniu 22.04.2024 o 14:56, Peter Maydell pisze:

On Fri, 19 Apr 2024 at 19:46, Peter Maydell  wrote:



The upshot is that the only CPU type that changes is 'max'; but any
new type we add in future (whether v8.6 or not) will also get the new
1GHz default (assuming we spot in code review any attempts to set
the ARM_FEATURE_BACKCOMPAT_CNTFRQ flag on new CPU types as a result
of cut-n-paste from an older CPU initfn ;-)).

It remains the case that the machine model can override the default
value via the 'cntfrq' QOM property (regardless of the CPU type).


This patchset turns out to break the sbsa-ref board: the
Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef
avocado test both (a) takes rather longer to boot and (b) when
running thinks that time is advancing very fast.

I suspect this may be because the firmware hard-codes the
generic timer clock frequency it is expecting. I've cc'd the
sbsa-ref maintainers: is that correct?

If so, we can deal with it by making the sbsa-ref board set the
cntfrq QOM property on its CPUs to force them to the old
frequency. However this will produce a technically-out-of-spec
CPU when used with a v8.6-compliant CPU type, so probably we
should do something to be able to tell the firmware the clock
frequency (if it doesn't want to just read CNTFRQ_EL0 itself).


From what I see in EDK2 code we read CNTFREQ_EL0:

GetPlatformTimerFreq() checks for PcdArmArchTimerFreqInHz variable which
sbsa-ref has set to 0. So it calls ArmGenericTimerGetTimerFreq() ->
ArmReadCntFrq() -> "mrs x0, cntfrq_el0"

I added debug output to firmware and it shows me:

HRW: GetPlatformTimerFreq TimerFreq = 6250

Local tree:
ed0604e99c (HEAD -> test-counter) target/arm: Default to 1GHz cntfrq for 'max' 
and new CPUs
c0a8c341f5 target/arm: Refactor default generic timer frequency handling
592c01312b hw: Add compat machines for 9.1
62dbe54c24 (tag: v9.0.0-rc4, origin/master, origin/HEAD) Update version for 
v9.0.0-rc4 release
a12214d1c4 (origin/staging) usb-storage: Fix BlockConf defaults

sbsa-ref with "-cpu max" used. All cpu cores give me same value.

How to use pxb-pcie in correct way?

[Marcin Juszkiewicz]

For quite a while I am experimenting with PCI Express setup on SBSA-Ref 
system. And finally decided to write.


We want to play with NUMA setup and "pxb-pcie" can be assigned to NUMA 
node other than cpu0 one. But adding it makes other cards dissapear...


When I boot sbsa-ref I have plain PCIe setup:

(qemu) info pci
  Bus  0, device   0, function 0:
Host bridge: PCI device 1b36:0008
  PCI subsystem 1af4:1100
  id ""
  Bus  0, device   1, function 0:
Ethernet controller: PCI device 8086:10d3
  PCI subsystem 8086:
  IRQ 255, pin A
  BAR0: 32 bit memory at 0x [0x0001fffe].
  BAR1: 32 bit memory at 0x [0x0001fffe].
  BAR2: I/O at 0x [0x001e].
  BAR3: 32 bit memory at 0x [0x3ffe].
  BAR6: 32 bit memory at 0x [0x0003fffe].
  id ""
  Bus  0, device   2, function 0:
Display controller: PCI device 1234:
  PCI subsystem 1af4:1100
  BAR0: 32 bit prefetchable memory at 0x8000 [0x80ff].
  BAR2: 32 bit memory at 0x81084000 [0x81084fff].
  BAR6: 32 bit memory at 0x [0x7ffe].
  id ""

Adding extra PCIe card works fine - both just "igb" and "igb" with 
"pcie-root-port".


But adding "pcie-root-port" + "igb" and then "pxb-pcie" makes "igb" 
dissapear:


../code/qemu/build/qemu-system-aarch64
-monitor telnet::45454,server,nowait
-serial stdio
-device pcie-root-port,id=ULyWl,slot=0,chassis=0
-device igb,bus=ULyWl
-device pxb-pcie,bus_nr=1

(qemu) info pci
  Bus  0, device   0, function 0:
Host bridge: PCI device 1b36:0008
  PCI subsystem 1af4:1100
  id ""
  Bus  0, device   1, function 0:
Ethernet controller: PCI device 8086:10d3
  PCI subsystem 8086:
  IRQ 255, pin A
  BAR0: 32 bit memory at 0x [0x0001fffe].
  BAR1: 32 bit memory at 0x [0x0001fffe].
  BAR2: I/O at 0x [0x001e].
  BAR3: 32 bit memory at 0x [0x3ffe].
  BAR6: 32 bit memory at 0x [0x0003fffe].
  id ""
  Bus  0, device   2, function 0:
Display controller: PCI device 1234:
  PCI subsystem 1af4:1100
  BAR0: 32 bit prefetchable memory at 0x8000 [0x80ff].
  BAR2: 32 bit memory at 0x81085000 [0x81085fff].
  BAR6: 32 bit memory at 0x [0x7ffe].
  id ""
  Bus  0, device   3, function 0:
PCI bridge: PCI device 1b36:000c
  IRQ 255, pin A
  BUS 0.
  secondary bus 1.
  subordinate bus 1.
  IO range [0xf000, 0x0fff]
  memory range [0xfff0, 0x000f]
  prefetchable memory range [0xfff0, 0x000f]
  BAR0: 32 bit memory at 0x81084000 [0x81084fff].
  id "ULyWl"
  Bus  0, device   4, function 0:
Host bridge: PCI device 1b36:000b
  PCI subsystem 1af4:1100
  id ""


If I add "igb" directly (without root port) then it appears correctly:

(qemu) info pci
  Bus  0, device   0, function 0:
Host bridge: PCI device 1b36:0008
  PCI subsystem 1af4:1100
  id ""
  Bus  0, device   1, function 0:
Ethernet controller: PCI device 8086:10d3
  PCI subsystem 8086:
  IRQ 255, pin A
  BAR0: 32 bit memory at 0x [0x0001fffe].
  BAR1: 32 bit memory at 0x [0x0001fffe].
  BAR2: I/O at 0x [0x001e].
  BAR3: 32 bit memory at 0x [0x3ffe].
  BAR6: 32 bit memory at 0x [0x0003fffe].
  id ""
  Bus  0, device   2, function 0:
Display controller: PCI device 1234:
  PCI subsystem 1af4:1100
  BAR0: 32 bit prefetchable memory at 0x8000 [0x80ff].
  BAR2: 32 bit memory at 0x810c4000 [0x810c4fff].
  BAR6: 32 bit memory at 0x [0x7ffe].
  id ""
  Bus  0, device   3, function 0:
Ethernet controller: PCI device 8086:10c9
  PCI subsystem 1af4:1100
  IRQ 255, pin A
  BAR0: 32 bit memory at 0x [0x0001fffe].
  BAR1: 32 bit memory at 0x [0x0001fffe].
  BAR2: I/O at 0x [0x001e].
  BAR3: 64 bit memory at 0x [0x3ffe].
  id ""
  Bus  0, device   4, function 0:
Host bridge: PCI device 1b36:000b
  PCI subsystem 1af4:1100
  id ""


When I add "pcie-root-port" with "igb" followed by "pcie-root-port" and 
"pxb-pcie" then no IGB again:



-device pcie-root-port,id=RjKXs,slot=0,chassis=0
-device igb,bus=RjKXs
-device pcie-root-port,chassis=7
-device pxb-pcie,bus_nr=1


(qemu) info pci
  Bus  0, device   0, function 0:
Host bridge: PCI device 1b36:0008
  PCI subsystem 1af4:1100
  id ""
  Bus  0, device   1, function 0:
Ethernet controller: PCI device 8086:10d3
  PCI subsystem 8086:
  IRQ 255, pin A
  BAR0: 32 bit memory at 0x [0x0001fffe].
  BAR1: 32 bit memory at 0x [0x0001fffe].
  BAR2: I/O at 0x 

Re: /util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

[Marcin Juszkiewicz]

W dniu 1.04.2024 o 21:55, Liviu Ionescu pisze:

On 1 Apr 2024, at 21:48, Richard
Henderson  wrote:

You were told back in September that Ubuntu 18.04 is no longer
supported.

Sorry, I missed that.

BTW, according to ubuntu.com: "With Ubuntu Pro, the 18.04 LTS will be
fully supported until 2028.".


So ask Ubuntu Pro team for support?

QEMU team does not support Ubuntu 18.04. And several other distributions.

Re: [PATCH 1/1] docs: sbsa: update specs, add dt note

[Marcin Juszkiewicz]

W dniu 28.03.2024 o 16:43, Peter Maydell pisze:

On Tue, 26 Mar 2024 at 09:58, Marcin Juszkiewicz
 wrote:


Hardware of sbsa-ref board is nowadays defined by both BSA and SBSA
specifications. Then BBR defines firmware interface.

Added note about DeviceTree data passed from QEMU to firmware. It is
very minimal and provides only data we use in firmware.

Added NUMA information to list of things reported by DeviceTree.

Signed-off-by: Marcin Juszkiewicz 
---
  docs/system/arm/sbsa.rst | 37 -
  1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index bca61608ff..d4d1f2efe3 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst



+Note
+
+
+QEMU provides us with minimal information about hardware platform using


s/us/the guest EL3 firmware/  (or whatever other term you want to
use to describe the guest software that reads the dt).


Thanks, fixed.


+minimalistic devicetree. This is not a Linux devicetree. It is not even a
+firmware devicetree.
+
+It is information passed from QEMU to describe the information a hardware
+platform would have other mechanisms to discover at runtime, that are affected
+by the QEMU command line.



Might want to say also
  Guest EL3 firmware does not pass this devicetree on to later
  components of the software stack.
?


This is a matter of what firmware stack QEMU user will run. TF-A (our 
current "guest EL3 firmware") passed devicetree to later components of 
the software stack. We just stopped using it in EDK2. But if someone 
would like to run U-Boot or other firmware then both SMC and DT will 
wait for them.



+
+Ultimately this devicetree will be replaced by IPC calls to an emulated SCP.
+And when we do that, we won't then have to rewrite Normal world firmware to
+cope.


I would drop the last sentence here, and use "may" instead of "will".


Done.


+
  DeviceTree information
  ''

-The devicetree provided by the board model to the firmware is not intended
-to be a complete compliant DT. It currently reports:
+The devicetree reports:

 - CPUs
 - memory
 - platform version
 - GIC addresses
+   - NUMA node id for CPUs and memory


Otherwise looks good to me, and the updates to the spec URLs
are particularly helpful. As a docs change I'd be happy
to take it into 9.0 (at least before rc2) if some other
sbsa-ref-knowledgeable person wants to either review or ack it.
(But it's also OK if it misses 9.0 and goes into 9.1.)


OK.

[PATCH v2 1/1] docs: sbsa: update specs, add dt note

[Marcin Juszkiewicz]

Hardware of sbsa-ref board is nowadays defined by both BSA and SBSA
specifications. Then BBR defines firmware interface.

Added note about DeviceTree data passed from QEMU to firmware. It is
very minimal and provides only data we use in firmware.

Added NUMA information to list of things reported by DeviceTree.

Signed-off-by: Marcin Juszkiewicz 
---
 docs/system/arm/sbsa.rst | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index bca61608ff..2bf22a1d0b 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -1,12 +1,16 @@
 Arm Server Base System Architecture Reference board (``sbsa-ref``)
 ==
 
-While the ``virt`` board is a generic board platform that doesn't match
-any real hardware the ``sbsa-ref`` board intends to look like real
-hardware. The `Server Base System Architecture
-<https://developer.arm.com/documentation/den0029/latest>`_ defines a
-minimum base line of hardware support and importantly how the firmware
-reports that to any operating system.
+The ``sbsa-ref`` board intends to look like real hardware (while the ``virt``
+board is a generic board platform that doesn't match any real hardware).
+
+The hardware part is defined by two specifications:
+
+  - `Base System Architecture 
<https://developer.arm.com/documentation/den0094/>`__ (BSA)
+  - `Server Base System Architecture 
<https://developer.arm.com/documentation/den0029/>`__ (SBSA)
+
+The `Arm Base Boot Requirements 
<https://developer.arm.com/documentation/den0044/>`__ (BBR)
+specification defines how the firmware reports that to any operating system.
 
 It is intended to be a machine for developing firmware and testing
 standards compliance with operating systems.
@@ -35,16 +39,29 @@ includes both internal hardware and parts affected by the 
qemu command line
 (i.e. CPUs and memory). As a result it must have a firmware specifically built
 to expect a certain hardware layout (as you would in a real machine).
 
+Note
+
+
+QEMU provides the guest EL3 firmware with minimal information about hardware
+platform using minimalistic devicetree. This is not a Linux devicetree. It is
+not even a firmware devicetree.
+
+It is information passed from QEMU to describe the information a hardware
+platform would have other mechanisms to discover at runtime, that are affected
+by the QEMU command line.
+
+Ultimately this devicetree may be replaced by IPC calls to an emulated SCP.
+
 DeviceTree information
 ''
 
-The devicetree provided by the board model to the firmware is not intended
-to be a complete compliant DT. It currently reports:
+The devicetree reports:
 
- CPUs
- memory
- platform version
- GIC addresses
+   - NUMA node id for CPUs and memory
 
 Platform version
 
@@ -70,4 +87,4 @@ Platform version changes:
   GIC ITS information is present in devicetree.
 
 0.3
-  The USB controller is an XHCI device, not EHCI
+  The USB controller is an XHCI device, not EHCI.
-- 
2.44.0

Re: [PATCH-for-9.0 v2] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine

[Marcin Juszkiewicz]

W dniu 27.03.2024 o 17:54, Philippe Mathieu-Daudé pisze:

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..345c35507f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -208,6 +208,13 @@ is no longer packaged in any distro making it harder to 
run the
  ``check-tcg`` tests. Unless we can improve the testing situation there
  is a chance the code will bitrot without anyone noticing.
  
+64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0)

+'
+
+The ``isapc`` machine aims to emulate old PC machine without PCI was
+generalized, so hardware available around 1995, before 64-bit intel
+CPUs were produced.


Can you s/Intel/x86-64/ here? Intel was not first with x86-64 (AMD 
invented it). Also "64-bit Intel" smells of Itanium too much.

How to add pcie-root-port and device behind it in C?

[Marcin Juszkiewicz]

I was going through Arm (S)BSA tests run against sbsa-ref. Many of them 
check for presence of other cards than "Root Complex Integrated 
Endpoint" ones.


The "-device root-pcie-port" etc arguments can be used to add such ones 
but I was wondering how to add them directly in C code. Tried to find is 
there any example but looks like all systems use flat structure.


So the question is: How to add pcie-root-port and device behind it in C?

Something like those two arguments but in C:

-device pcie-root-port,id=JBHBE,slot=0,chassis=0
-device igb,bus=JBHBE

# lspci -tv
-[:00]-+-00.0  Red Hat, Inc. QEMU PCIe Host bridge
   +-01.0  Intel Corporation 82574L Gigabit Network Connection
   +-02.0  Device 1234:
   \-03.0-[01]00.0  Intel Corporation 82576 Gigabit Network

[PATCH 1/1] docs: sbsa: update specs, add dt note

[Marcin Juszkiewicz]

Hardware of sbsa-ref board is nowadays defined by both BSA and SBSA
specifications. Then BBR defines firmware interface.

Added note about DeviceTree data passed from QEMU to firmware. It is
very minimal and provides only data we use in firmware.

Added NUMA information to list of things reported by DeviceTree.

Signed-off-by: Marcin Juszkiewicz 
---
 docs/system/arm/sbsa.rst | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index bca61608ff..d4d1f2efe3 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -1,12 +1,16 @@
 Arm Server Base System Architecture Reference board (``sbsa-ref``)
 ==
 
-While the ``virt`` board is a generic board platform that doesn't match
-any real hardware the ``sbsa-ref`` board intends to look like real
-hardware. The `Server Base System Architecture
-<https://developer.arm.com/documentation/den0029/latest>`_ defines a
-minimum base line of hardware support and importantly how the firmware
-reports that to any operating system.
+The ``sbsa-ref`` board intends to look like real hardware (while the ``virt``
+board is a generic board platform that doesn't match any real hardware).
+
+The hardware part is defined by two specifications:
+
+  - `Base System Architecture 
<https://developer.arm.com/documentation/den0094/>`__ (BSA)
+  - `Server Base System Architecture 
<https://developer.arm.com/documentation/den0029/>`__ (SBSA)
+
+The `Arm Base Boot Requirements 
<https://developer.arm.com/documentation/den0044/>`__ (BBR)
+specification defines how the firmware reports that to any operating system.
 
 It is intended to be a machine for developing firmware and testing
 standards compliance with operating systems.
@@ -35,16 +39,31 @@ includes both internal hardware and parts affected by the 
qemu command line
 (i.e. CPUs and memory). As a result it must have a firmware specifically built
 to expect a certain hardware layout (as you would in a real machine).
 
+Note
+
+
+QEMU provides us with minimal information about hardware platform using
+minimalistic devicetree. This is not a Linux devicetree. It is not even a
+firmware devicetree.
+
+It is information passed from QEMU to describe the information a hardware
+platform would have other mechanisms to discover at runtime, that are affected
+by the QEMU command line.
+
+Ultimately this devicetree will be replaced by IPC calls to an emulated SCP.
+And when we do that, we won't then have to rewrite Normal world firmware to
+cope.
+
 DeviceTree information
 ''
 
-The devicetree provided by the board model to the firmware is not intended
-to be a complete compliant DT. It currently reports:
+The devicetree reports:
 
- CPUs
- memory
- platform version
- GIC addresses
+   - NUMA node id for CPUs and memory
 
 Platform version
 
@@ -70,4 +89,4 @@ Platform version changes:
   GIC ITS information is present in devicetree.
 
 0.3
-  The USB controller is an XHCI device, not EHCI
+  The USB controller is an XHCI device, not EHCI.
-- 
2.44.0

Re: [RFC PATCH 00/12] SMMUv3 nested translation support

[Marcin Juszkiewicz]

W dniu 25.03.2024 o 11:13, Mostafa Saleh pisze:

Currently, QEMU supports emulating either stage-1 or stage-2 SMMUs
but not nested instances.
This patch series adds support for nested translation in SMMUv3,
this is controlled by property “arm-smmuv3.stage=nested”, and
advertised to guests as (IDR0.S1P == 1 && IDR0.S2P == 2)


From pure curiosity I applied the series, enabled 'nested' one in
sbsa-ref and ran (S)BSA ACS tests.

Two more tests passed. Ones which check does SMMU supports both stage1 
and stage2 at same time.


The fun part? Those tests only check SMMU registers.

Re: [PATCH v2 0/2] ARM Sbsa-ref: Enable CPU cluster topology

[Marcin Juszkiewicz]

W dniu 22.03.2024 o 19:51, Peter Maydell pisze:

On Tue, 12 Mar 2024 at 08:32, Xiong Yining



xiongyining1480 (2):
   hw/arm/sbsa-ref:Enable CPU cluster on ARM sbsa machine
   hw/arm/sbsa-ref: Add cpu-map to device tree


Thanks for these patches. I think we should squash the two
patches together into one, because the first patch is only
a single line, and also because we shouldn't say that the
machine supports cluster topology until it actually does
by putting the information into the device tree.

There's no rush, because we're  now in softfreeze for 9.0, so these
will have to wait until 9.0 is released (in about a month's time).



I'm also a bit confused by the Reviewed-by: tag from Marcin on patch 2,
because I can't see that in my mail archives of the discussion on version
1 of this patchset, only a Tested-by.
Marcin, are you OK with these patches?


I only tested them. They are fine, will check on Monday.


Also, is this change to the DTB something that would require an
increase in the sbsa-ref platform version number, or not?


TF-A will check for "/cpus/cpu-map" node and if it is missing then will 
not provide it to EDK2. So far I did not saw patches for firmware side.


I would add bump of platform version to 0.4 one. It is cheap operation 
and so far (from firmware side) we check for >= 0.3 only.


> Should we adjust the documentation in docs/system/arm/sbsa.rst to
> mention that the DTB might have cluster topology information?

Yes. I will send an update to mention that NUMA configuration can be 
there too (we already export it from TF-A to EDK2 via SMC calls).

Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine

[Marcin Juszkiewicz]

W dniu 22.03.2024 o 09:50, Heinrich Schuchardt pisze:
>>> I see no mention of device trees in the spec, but I do see ACPI. Do we
>>> really expect a server platform to use DTs?
>>
>> This platform "kind of" follows sbsa-ref where we have very
>> minimalistic device tree sharing information qemu->firmware.
>>
>> libfdt is small, format is known and describes hardware. Firmware is
>> free to make use of it in any way it wants.
>>
>> On sbsa-ref we parse DT in TF-A (base firmware) and provide hardware
>> information to higher level (edk2) via SMC mechanism. Then EDK2
>> creates ACPI tables and provide them to the Operating System.

> We should ensure that only either an ACPI table or a device-tree
> description is passed to the OS and not both, e.g. when using
>
>  qemu-system-riscv64 -kernel vmlinux -M sbsa-ref
>
> But that requirement is not machine specific.

I would not call "qemu-system-* -M machinename -k kernel_image" a proper 
way to boot for several systems emulated by QEMU.


DeviceTree is in rvsp-ref and sbsa-ref because it is easy to process in 
limited space 1st stage of firmware has.


And if we knew how people will mention 'sbsa-ref uses DT' we would use 
something else instead. But that would require adding more code into 
existing firmware projects (libfdt is usually already there).


I did not looked at DT generated for rvsp-ref. I know that sbsa-ref one 
is too minimalistic for kernel use as we added only those fields/nodes 
we need to provide data for firmware.

Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine

[Marcin Juszkiewicz]

W dniu 22.03.2024 o 05:55, Alistair Francis pisze:

I see no mention of device trees in the spec, but I do see ACPI. Do we
really expect a server platform to use DTs?


This platform "kind of" follows sbsa-ref where we have very minimalistic 
device tree sharing information qemu->firmware.


libfdt is small, format is known and describes hardware. Firmware is 
free to make use of it in any way it wants.


On sbsa-ref we parse DT in TF-A (base firmware) and provide hardware 
information to higher level (edk2) via SMC mechanism. Then EDK2 creates 
ACPI tables and provide them to the Operating System.


In physical system some parts of information provided in DT would be 
read by firmware from onboard Embedded Controller chip.



These functions should be shared with the virt machine if we really do
want DTs, but I'm not convinced we do

[PATCH v3 0/4] tests/avocado: update sbsa-ref firmware to latest

[Marcin Juszkiewicz]

Updating sbsa-ref firmware for QEMU CI was manual task. Now it is
replaced by CI job run on CodeLinaro Gitlab instance.

This patchset updates to current state:

- Trusted Firmware v2.10.2 (latest LTS)
- Tianocore EDK2 stable202402 (latest release)

And Tianocore EDK2-platforms commit 085c2fb (edk2-platforms does not
have releases).

Firmware images were built using Debian 'bookworm' cross gcc 12.2.0
compiler.

And while I am in that file I dropped use of 'virtio-rng-pci' device as
sbsa-ref is supposed to emulate physical hardware.

Added 'max' tests with 'pauth=off' and 'pauth-impdef=on' variants.

(01/11) test_sbsaref_edk2_firmware: PASS (2.51 s)
(02/11) test_sbsaref_alpine_linux_cortex_a57: PASS (23.72 s)
(03/11) test_sbsaref_alpine_linux_neoverse_n1: PASS (23.70 s)
(04/11) test_sbsaref_alpine_linux_max_pauth_off: PASS (23.00 s)
(05/11) test_sbsaref_alpine_linux_max_pauth_impdef: PASS (29.03 s)
(06/11) test_sbsaref_alpine_linux_max: PASS (80.69 s)
(07/11) test_sbsaref_openbsd73_cortex_a57: PASS (16.05 s)
(08/11) test_sbsaref_openbsd73_neoverse_n1: PASS (15.97 s)
(09/11) test_sbsaref_openbsd73_max_pauth_off: PASS (16.22 s)
(10/11) test_sbsaref_openbsd73_max_pauth_impdef: PASS (16.11 s)
(11/11) test_sbsaref_openbsd73_max: PASS (16.08 s)

Signed-off-by: Marcin Juszkiewicz 
---
Changes in v3:
- left OpenBSD at 7.3 (7.4+ is known to not boot)
  https://gitlab.com/qemu-project/qemu/-/issues/2224
  https://marc.info/?l=openbsd-arm=171050428327850=2
- added pauth variants of 'max' to OpenBSD tests
- Link to v2: 
https://lore.kernel.org/r/20240314-sbsa-ref-firmware-update-v2-0-b557c5655...@linaro.org

Changes in v2:
- disabled 'max' tests on OpenBSD
- moved tags to 'one tag per line'
- added 'os:linux' tags to Alpine ones
- Link to v1: 
https://lore.kernel.org/r/20240313-sbsa-ref-firmware-update-v1-0-e166703c5...@linaro.org

---
Marcin Juszkiewicz (4):
  tests/avocado: update sbsa-ref firmware
  tests/avocado: drop virtio-rng from sbsa-ref tests
  tests/avocado: sbsa-ref: add Alpine tests for misc 'max' setup
  tests/avocado: sbsa-ref: add OpenBSD tests for misc 'max' setup

 tests/avocado/machine_aarch64_sbsaref.py | 86 +---
 1 file changed, 58 insertions(+), 28 deletions(-)
---
base-commit: ba49d760eb04630e7b15f423ebecf6c871b8f77b
change-id: 20240313-sbsa-ref-firmware-update-7579d9f6d59b

Best regards,
-- 
Marcin Juszkiewicz 

[PATCH v3 1/4] tests/avocado: update sbsa-ref firmware

[Marcin Juszkiewicz]

We now have CI job to build those and publish in space with
readable urls.

Firmware is built using Debian 'bookworm' cross toolchain (gcc 12.2.0).

Used versions:

- Trusted Firmware v2.10.2
- Tianocore EDK2 stable202402
- Tianocore EDK2 Platforms code commit 085c2fb

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 528c7d2934..cbab793455 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -1,6 +1,6 @@
 # Functional test that boots a Linux kernel and checks the console
 #
-# SPDX-FileCopyrightText: 2023 Linaro Ltd.
+# SPDX-FileCopyrightText: 2023-2024 Linaro Ltd.
 # SPDX-FileContributor: Philippe Mathieu-Daudé 
 # SPDX-FileContributor: Marcin Juszkiewicz 
 #
@@ -32,34 +32,36 @@ def fetch_firmware(self):
 """
 Flash volumes generated using:
 
-- Fedora GNU Toolchain version 13.2.1 20230728 (Red Hat 13.2.1-1)
+Toolchain from Debian:
+aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
 
-- Trusted Firmware-A
-  https://github.com/ARM-software/arm-trusted-firmware/tree/7c3ff62d
+Used components:
+
+- Trusted Firmware 2.10.2
+- Tianocore EDK2 stable202402
+- Tianocore EDK2-platforms commit 085c2fb
 
-- Tianocore EDK II
-  https://github.com/tianocore/edk2/tree/0f9283429dd4
-  https://github.com/tianocore/edk2/tree/ad1c0394b177
-  https://github.com/tianocore/edk2-platforms/tree/d03a60523a60
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
-"https://fileserver.linaro.org/s/rE43RJyTfxPtBkc/;
-"download/SBSA_FLASH0.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = "cdb8e4ffdaaa79292b7b465693f9e5fae6b7062d"
-tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash)
+fs0_xz_hash = 
"637593749cc307dea7dc13265c32e5d020267552f22b18a31850b8429fc5e159"
+tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs0_path = os.path.join(self.workdir, "SBSA_FLASH0.fd")
 
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
-"https://fileserver.linaro.org/s/AGWPDXbcqJTKS4R/;
-"download/SBSA_FLASH1.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = "411155ae6984334714dff08d5d628178e790c875"
-tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash)
+fs1_xz_hash = 
"cb0a5e8cf5e303c5d3dc106cfd5943ffe9714b86afddee7164c69ee1dd41991c"
+tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs1_path = os.path.join(self.workdir, "SBSA_FLASH1.fd")
 
@@ -96,15 +98,15 @@ def test_sbsaref_edk2_firmware(self):
 
 # AP Trusted ROM
 wait_for_console_pattern(self, "Booting Trusted Firmware")
-wait_for_console_pattern(self, "BL1: v2.9(release):v2.9")
+wait_for_console_pattern(self, "BL1: v2.10.2(release):")
 wait_for_console_pattern(self, "BL1: Booting BL2")
 
 # Trusted Boot Firmware
-wait_for_console_pattern(self, "BL2: v2.9(release)")
+wait_for_console_pattern(self, "BL2: v2.10.2(release)")
 wait_for_console_pattern(self, "Booting BL31")
 
 # EL3 Runtime Software
-wait_for_console_pattern(self, "BL31: v2.9(release)")
+wait_for_console_pattern(self, "BL31: v2.10.2(release)")
 
 # Non-trusted Firmware
 wait_for_console_pattern(self, "UEFI firmware (version 1.0")

-- 
2.44.0

[PATCH v3 2/4] tests/avocado: drop virtio-rng from sbsa-ref tests

[Marcin Juszkiewicz]

sbsa-ref is supposed to emulate real hardware so virtio-rng-pci
does not fit here

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 8 
 1 file changed, 8 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index cbab793455..259225f15f 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -132,10 +132,6 @@ def boot_alpine_linux(self, cpu):
 cpu,
 "-drive",
 f"file={iso_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()
@@ -179,10 +175,6 @@ def boot_openbsd73(self, cpu):
 cpu,
 "-drive",
 f"file={img_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()

-- 
2.44.0

[PATCH v3 4/4] tests/avocado: sbsa-ref: add OpenBSD tests for misc 'max' setup

[Marcin Juszkiewicz]

PAuth makes run timeout on CI so add tests using 'max' without
it and with impdef one.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index cf8954d02e..98c76c1ff7 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -203,18 +203,36 @@ def boot_openbsd73(self, cpu):
 def test_sbsaref_openbsd73_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
+:avocado: tags=os:openbsd
 """
 self.boot_openbsd73("cortex-a57")
 
 def test_sbsaref_openbsd73_neoverse_n1(self):
 """
 :avocado: tags=cpu:neoverse-n1
+:avocado: tags=os:openbsd
 """
 self.boot_openbsd73("neoverse-n1")
 
+def test_sbsaref_openbsd73_max_pauth_off(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:openbsd
+"""
+self.boot_openbsd73("max,pauth=off")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+def test_sbsaref_openbsd73_max_pauth_impdef(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:openbsd
+"""
+self.boot_openbsd73("max,pauth-impdef=on")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_sbsaref_openbsd73_max(self):
 """
 :avocado: tags=cpu:max
+:avocado: tags=os:openbsd
 """
 self.boot_openbsd73("max")
-

-- 
2.44.0

[PATCH v3 3/4] tests/avocado: sbsa-ref: add Alpine tests for misc 'max' setup

[Marcin Juszkiewicz]

PAuth makes run timeout on CI so add tests using 'max' without it
and with impdef one.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 259225f15f..cf8954d02e 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -140,18 +140,36 @@ def boot_alpine_linux(self, cpu):
 def test_sbsaref_alpine_linux_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("cortex-a57")
 
 def test_sbsaref_alpine_linux_neoverse_n1(self):
 """
 :avocado: tags=cpu:neoverse-n1
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("neoverse-n1")
 
+def test_sbsaref_alpine_linux_max_pauth_off(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:linux
+"""
+self.boot_alpine_linux("max,pauth=off")
+
+def test_sbsaref_alpine_linux_max_pauth_impdef(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:linux
+"""
+self.boot_alpine_linux("max,pauth-impdef=on")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("max")
 

-- 
2.44.0

Re: [PATCH v2 3/4] tests/avocado: use OpenBSD 7.4 for sbsa-ref

[Marcin Juszkiewicz]

W dniu 14.03.2024 o 15:56, Alex Bennée pisze:

If we are not going to delete the entries then at least use a @skip
instead of commenting. Maybe:
@skip("Potential un-diagnosed upstream bug?")

Daniel or Peter suggested to open a GitLab issue and use

 @skip("https://gitlab.com/qemu-project/qemu/-/issues/xyz;)

to track progress.

That's a good idea. Are you going to respin?


Opened https://gitlab.com/qemu-project/qemu/-/issues/2224 to track 
problem. Subscribed to arm@openbsd mailing list.


Will walk the dog and then mail them with problem.

And respin patch series tomorrow.

Re: [PATCH v2 3/4] tests/avocado: use OpenBSD 7.4 for sbsa-ref

[Marcin Juszkiewicz]

W dniu 14.03.2024 o 13:14, Alex Bennée pisze:

+# OpenBSD 7.4 does not boot on current max cpu.
+#
+#   def test_sbsaref_openbsd_max_pauth_off(self):
+#   """
+#   :avocado: tags=cpu:max
+#   :avocado: tags=os:openbsd
+#   """
+#   self.boot_openbsd("max,pauth=off")

If we are not going to delete the entries then at least use a @skip
instead of commenting. Maybe:

   @skip("Potential un-diagnosed upstream bug?")

but it would be nice to figure out exactly where is breaks.


I am going to subscribe to openbsd mailing list and ask there.

OpenBSD 7.3 works, 7.4/7.5-current does not.
And it is on Neoverse-V1/N2 and max cpu types.

[PATCH v2 4/4] tests/avocado: sbsa-ref: add Alpine tests for misc 'max' setup

[Marcin Juszkiewicz]

PAuth makes run timeout on CI so add tests using 'max' without it
and with impdef one.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 0e52dc5854..0dd2eff0de 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -140,18 +140,36 @@ def boot_alpine_linux(self, cpu):
 def test_sbsaref_alpine_linux_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("cortex-a57")
 
 def test_sbsaref_alpine_linux_neoverse_n1(self):
 """
 :avocado: tags=cpu:neoverse-n1
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("neoverse-n1")
 
+def test_sbsaref_alpine_linux_max_pauth_off(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:linux
+"""
+self.boot_alpine_linux("max,pauth=off")
+
+def test_sbsaref_alpine_linux_max_pauth_impdef(self):
+"""
+:avocado: tags=cpu:max
+:avocado: tags=os:linux
+"""
+self.boot_alpine_linux("max,pauth-impdef=on")
+
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
+:avocado: tags=os:linux
 """
 self.boot_alpine_linux("max")
 

-- 
2.44.0

[PATCH v2 0/4] tests/avocado: update sbsa-ref firmware to latest

[Marcin Juszkiewicz]

Updating sbsa-ref firmware for QEMU CI was manual task. Now it is
replaced by CI job run on CodeLinaro Gitlab instance.

This patchset updates to current state:

- Trusted Firmware v2.10.2 (latest LTS)
- Tianocore EDK2 stable202402 (latest release)

And Tianocore EDK2-platforms commit 085c2fb (edk2-platforms does not
have releases).

Firmware images were built using Debian 'bookworm' cross gcc 12.2.0
compiler.

And while I am in that file I dropped use of 'virtio-rng-pci' device as
sbsa-ref is supposed to emulate physical hardware.

OpenBSD updated to 7.4 version.

(1/8) test_sbsaref_edk2_firmware: PASS (2.49 s)
(2/8) test_sbsaref_alpine_linux_cortex_a57: PASS (23.78 s)
(3/8) test_sbsaref_alpine_linux_neoverse_n1: PASS (23.38 s)
(4/8) test_sbsaref_alpine_linux_max_pauth_off: PASS (23.31 s)
(5/8) test_sbsaref_alpine_linux_max_pauth_impdef: PASS (29.27 s)
(6/8) test_sbsaref_alpine_linux_max: PASS (80.13 s)
(7/8) test_sbsaref_openbsd_cortex_a57: PASS (16.01 s)
(8/8) test_sbsaref_openbsd_neoverse_n1: PASS (16.05 s)

Signed-off-by: Marcin Juszkiewicz 
---
Changes in v2:
- disabled 'max' tests on OpenBSD
- moved tags to 'one tag per line'
- added 'os:linux' tags to Alpine ones
- Link to v1: 
https://lore.kernel.org/r/20240313-sbsa-ref-firmware-update-v1-0-e166703c5...@linaro.org

---
Marcin Juszkiewicz (4):
  tests/avocado: update sbsa-ref firmware
  tests/avocado: drop virtio-rng from sbsa-ref tests
  tests/avocado: use OpenBSD 7.4 for sbsa-ref
  tests/avocado: sbsa-ref: add Alpine tests for misc 'max' setup

 tests/avocado/machine_aarch64_sbsaref.py | 113 ---
 1 file changed, 73 insertions(+), 40 deletions(-)
---
base-commit: 0748129684be2773117b0b8fc3c60161abdb7bb8
change-id: 20240313-sbsa-ref-firmware-update-7579d9f6d59b

Best regards,
-- 
Marcin Juszkiewicz 

[PATCH v2 1/4] tests/avocado: update sbsa-ref firmware

[Marcin Juszkiewicz]

We now have CI job to build those and publish in space with
readable urls.

Firmware is built using Debian 'bookworm' cross toolchain (gcc 12.2.0).

Used versions:

- Trusted Firmware v2.10.2
- Tianocore EDK2 stable202402
- Tianocore EDK2 Platforms code commit 085c2fb

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 528c7d2934..cbab793455 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -1,6 +1,6 @@
 # Functional test that boots a Linux kernel and checks the console
 #
-# SPDX-FileCopyrightText: 2023 Linaro Ltd.
+# SPDX-FileCopyrightText: 2023-2024 Linaro Ltd.
 # SPDX-FileContributor: Philippe Mathieu-Daudé 
 # SPDX-FileContributor: Marcin Juszkiewicz 
 #
@@ -32,34 +32,36 @@ def fetch_firmware(self):
 """
 Flash volumes generated using:
 
-- Fedora GNU Toolchain version 13.2.1 20230728 (Red Hat 13.2.1-1)
+Toolchain from Debian:
+aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
 
-- Trusted Firmware-A
-  https://github.com/ARM-software/arm-trusted-firmware/tree/7c3ff62d
+Used components:
+
+- Trusted Firmware 2.10.2
+- Tianocore EDK2 stable202402
+- Tianocore EDK2-platforms commit 085c2fb
 
-- Tianocore EDK II
-  https://github.com/tianocore/edk2/tree/0f9283429dd4
-  https://github.com/tianocore/edk2/tree/ad1c0394b177
-  https://github.com/tianocore/edk2-platforms/tree/d03a60523a60
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
-"https://fileserver.linaro.org/s/rE43RJyTfxPtBkc/;
-"download/SBSA_FLASH0.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = "cdb8e4ffdaaa79292b7b465693f9e5fae6b7062d"
-tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash)
+fs0_xz_hash = 
"637593749cc307dea7dc13265c32e5d020267552f22b18a31850b8429fc5e159"
+tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs0_path = os.path.join(self.workdir, "SBSA_FLASH0.fd")
 
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
-"https://fileserver.linaro.org/s/AGWPDXbcqJTKS4R/;
-"download/SBSA_FLASH1.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = "411155ae6984334714dff08d5d628178e790c875"
-tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash)
+fs1_xz_hash = 
"cb0a5e8cf5e303c5d3dc106cfd5943ffe9714b86afddee7164c69ee1dd41991c"
+tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs1_path = os.path.join(self.workdir, "SBSA_FLASH1.fd")
 
@@ -96,15 +98,15 @@ def test_sbsaref_edk2_firmware(self):
 
 # AP Trusted ROM
 wait_for_console_pattern(self, "Booting Trusted Firmware")
-wait_for_console_pattern(self, "BL1: v2.9(release):v2.9")
+wait_for_console_pattern(self, "BL1: v2.10.2(release):")
 wait_for_console_pattern(self, "BL1: Booting BL2")
 
 # Trusted Boot Firmware
-wait_for_console_pattern(self, "BL2: v2.9(release)")
+wait_for_console_pattern(self, "BL2: v2.10.2(release)")
 wait_for_console_pattern(self, "Booting BL31")
 
 # EL3 Runtime Software
-wait_for_console_pattern(self, "BL31: v2.9(release)")
+wait_for_console_pattern(self, "BL31: v2.10.2(release)")
 
 # Non-trusted Firmware
 wait_for_console_pattern(self, "UEFI firmware (version 1.0")

-- 
2.44.0

[PATCH v2 2/4] tests/avocado: drop virtio-rng from sbsa-ref tests

[Marcin Juszkiewicz]

sbsa-ref is supposed to emulate real hardware so virtio-rng-pci
does not fit here

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 8 
 1 file changed, 8 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index cbab793455..259225f15f 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -132,10 +132,6 @@ def boot_alpine_linux(self, cpu):
 cpu,
 "-drive",
 f"file={iso_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()
@@ -179,10 +175,6 @@ def boot_openbsd73(self, cpu):
 cpu,
 "-drive",
 f"file={img_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()

-- 
2.44.0

[PATCH v2 3/4] tests/avocado: use OpenBSD 7.4 for sbsa-ref

[Marcin Juszkiewicz]

7.4 was released in October 2023, time to update before 7.3 gets dropped.

Disabled tests for 'max' cpu as OpenBSD fails there.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 47 +++-
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 259225f15f..0e52dc5854 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -159,14 +159,14 @@ def test_sbsaref_alpine_linux_max(self):
 # This tests the whole boot chain from EFI to Userspace
 # We only boot a whole OS for the current top level CPU and GIC
 # Other test profiles should use more minimal boots
-def boot_openbsd73(self, cpu):
+def boot_openbsd(self, cpu):
 self.fetch_firmware()
 
 img_url = (
-"https://cdn.openbsd.org/pub/OpenBSD/7.3/arm64/miniroot73.img;
+"https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img;
 )
 
-img_hash = 
"7fc2c75401d6f01fbfa25f4953f72ad7d7c18650056d30755c44b9c129b707e5"
+img_hash = 
"7b08b2ce081cff6408d183f7152ddcfd2779912104866e4fdf6ae2d864b51142"
 img_path = self.fetch_asset(img_url, algorithm="sha256", 
asset_hash=img_hash)
 
 self.vm.set_console()
@@ -180,23 +180,44 @@ def boot_openbsd73(self, cpu):
 self.vm.launch()
 wait_for_console_pattern(self,
  "Welcome to the OpenBSD/arm64"
- " 7.3 installation program.")
+ " 7.4 installation program.")
 
-def test_sbsaref_openbsd73_cortex_a57(self):
+def test_sbsaref_openbsd_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
+:avocado: tags=os:openbsd
 """
-self.boot_openbsd73("cortex-a57")
+self.boot_openbsd("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(self):
+def test_sbsaref_openbsd_neoverse_n1(self):
 """
 :avocado: tags=cpu:neoverse-n1
+:avocado: tags=os:openbsd
 """
-self.boot_openbsd73("neoverse-n1")
+self.boot_openbsd("neoverse-n1")
 
-def test_sbsaref_openbsd73_max(self):
-"""
-:avocado: tags=cpu:max
-"""
-self.boot_openbsd73("max")
+# OpenBSD 7.4 does not boot on current max cpu.
+#
+#   def test_sbsaref_openbsd_max_pauth_off(self):
+#   """
+#   :avocado: tags=cpu:max
+#   :avocado: tags=os:openbsd
+#   """
+#   self.boot_openbsd("max,pauth=off")
+
+#   @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+#   def test_sbsaref_openbsd_max_pauth_impdef(self):
+#   """
+#   :avocado: tags=cpu:max
+#   :avocado: tags=os:openbsd
+#   """
+#   self.boot_openbsd("max,pauth-impdef=on")
+
+#   @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+#   def test_sbsaref_openbsd_max(self):
+#   """
+#   :avocado: tags=cpu:max
+#   :avocado: tags=os:openbsd
+#   """
+#   self.boot_openbsd("max")
 

-- 
2.44.0

Re: [PATCH 3/3] tests/avocado: use OpenBSD 7.4 for sbsa-ref

[Marcin Juszkiewicz]

W dniu 13.03.2024 o 12:44, Philippe Mathieu-Daudé pisze:

-    :avocado: tags=cpu:cortex-a57
+    :avocado: tags=cpu:cortex-a57,os:openbsd


IIRC for some reason we must use one tag per line... Even if
named 'tags', this is handled as a single tag, so we couldn't
filter on "os:openbsd". We need:

   :avocado: tags=cpu:cortex-a57
   :avocado: tags=os:openbsd


OK. It worked when I tested this way:

$ make check-avocado AVOCADO_TAGS='machine:sbsa-ref,os:openbsd'
[..]
 (1/3) 
tests/avocado/machine_aarch64_sbsaref.py:Aarch64SbsarefMachine.test_sbsaref_openbsd_cortex_a57:
 PASS (16.18 s)
 (2/3) 
tests/avocado/machine_aarch64_sbsaref.py:Aarch64SbsarefMachine.test_sbsaref_openbsd_neoverse_n1:
 PASS (16.06 s)

$ make check-avocado AVOCADO_TAGS='os:openbsd'
[..]
 (1/3) 
tests/avocado/machine_aarch64_sbsaref.py:Aarch64SbsarefMachine.test_sbsaref_openbsd_cortex_a57:
 PASS (16.18 s)
 (2/3) 
tests/avocado/machine_aarch64_sbsaref.py:Aarch64SbsarefMachine.test_sbsaref_openbsd_neoverse_n1:
 PASS (16.06 s)

[PATCH 2/3] tests/avocado: drop virtio-rng from sbsa-ref tests

[Marcin Juszkiewicz]

sbsa-ref is supposed to emulate real hardware so virtio-rng-pci
does not fit here

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 8 
 1 file changed, 8 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index cbab793455..259225f15f 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -132,10 +132,6 @@ def boot_alpine_linux(self, cpu):
 cpu,
 "-drive",
 f"file={iso_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()
@@ -179,10 +175,6 @@ def boot_openbsd73(self, cpu):
 cpu,
 "-drive",
 f"file={img_path},format=raw",
-"-device",
-"virtio-rng-pci,rng=rng0",
-"-object",
-"rng-random,id=rng0,filename=/dev/urandom",
 )
 
 self.vm.launch()

-- 
2.44.0

[PATCH 1/3] tests/avocado: update sbsa-ref firmware

[Marcin Juszkiewicz]

We now have CI job to build those and publish in space with
readable urls.

Firmware is built using Debian 'bookworm' cross toolchain (gcc 12.2.0).

Used versions:

- Trusted Firmware v2.10.2
- Tianocore EDK2 stable202402
- Tianocore EDK2 Platforms code commit 085c2fb

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 528c7d2934..cbab793455 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -1,6 +1,6 @@
 # Functional test that boots a Linux kernel and checks the console
 #
-# SPDX-FileCopyrightText: 2023 Linaro Ltd.
+# SPDX-FileCopyrightText: 2023-2024 Linaro Ltd.
 # SPDX-FileContributor: Philippe Mathieu-Daudé 
 # SPDX-FileContributor: Marcin Juszkiewicz 
 #
@@ -32,34 +32,36 @@ def fetch_firmware(self):
 """
 Flash volumes generated using:
 
-- Fedora GNU Toolchain version 13.2.1 20230728 (Red Hat 13.2.1-1)
+Toolchain from Debian:
+aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
 
-- Trusted Firmware-A
-  https://github.com/ARM-software/arm-trusted-firmware/tree/7c3ff62d
+Used components:
+
+- Trusted Firmware 2.10.2
+- Tianocore EDK2 stable202402
+- Tianocore EDK2-platforms commit 085c2fb
 
-- Tianocore EDK II
-  https://github.com/tianocore/edk2/tree/0f9283429dd4
-  https://github.com/tianocore/edk2/tree/ad1c0394b177
-  https://github.com/tianocore/edk2-platforms/tree/d03a60523a60
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
-"https://fileserver.linaro.org/s/rE43RJyTfxPtBkc/;
-"download/SBSA_FLASH0.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = "cdb8e4ffdaaa79292b7b465693f9e5fae6b7062d"
-tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash)
+fs0_xz_hash = 
"637593749cc307dea7dc13265c32e5d020267552f22b18a31850b8429fc5e159"
+tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs0_path = os.path.join(self.workdir, "SBSA_FLASH0.fd")
 
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
-"https://fileserver.linaro.org/s/AGWPDXbcqJTKS4R/;
-"download/SBSA_FLASH1.fd.xz"
+"https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
+"20240313-116475/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = "411155ae6984334714dff08d5d628178e790c875"
-tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash)
+fs1_xz_hash = 
"cb0a5e8cf5e303c5d3dc106cfd5943ffe9714b86afddee7164c69ee1dd41991c"
+tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
+  algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
 fs1_path = os.path.join(self.workdir, "SBSA_FLASH1.fd")
 
@@ -96,15 +98,15 @@ def test_sbsaref_edk2_firmware(self):
 
 # AP Trusted ROM
 wait_for_console_pattern(self, "Booting Trusted Firmware")
-wait_for_console_pattern(self, "BL1: v2.9(release):v2.9")
+wait_for_console_pattern(self, "BL1: v2.10.2(release):")
 wait_for_console_pattern(self, "BL1: Booting BL2")
 
 # Trusted Boot Firmware
-wait_for_console_pattern(self, "BL2: v2.9(release)")
+wait_for_console_pattern(self, "BL2: v2.10.2(release)")
 wait_for_console_pattern(self, "Booting BL31")
 
 # EL3 Runtime Software
-wait_for_console_pattern(self, "BL31: v2.9(release)")
+wait_for_console_pattern(self, "BL31: v2.10.2(release)")
 
 # Non-trusted Firmware
 wait_for_console_pattern(self, "UEFI firmware (version 1.0")

-- 
2.44.0

[PATCH 3/3] tests/avocado: use OpenBSD 7.4 for sbsa-ref

[Marcin Juszkiewicz]

7.4 was released in October 2023, time to update before 7.3 gets dropped.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 259225f15f..94c9f81d72 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -159,14 +159,14 @@ def test_sbsaref_alpine_linux_max(self):
 # This tests the whole boot chain from EFI to Userspace
 # We only boot a whole OS for the current top level CPU and GIC
 # Other test profiles should use more minimal boots
-def boot_openbsd73(self, cpu):
+def boot_openbsd(self, cpu):
 self.fetch_firmware()
 
 img_url = (
-"https://cdn.openbsd.org/pub/OpenBSD/7.3/arm64/miniroot73.img;
+"https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img;
 )
 
-img_hash = 
"7fc2c75401d6f01fbfa25f4953f72ad7d7c18650056d30755c44b9c129b707e5"
+img_hash = 
"7b08b2ce081cff6408d183f7152ddcfd2779912104866e4fdf6ae2d864b51142"
 img_path = self.fetch_asset(img_url, algorithm="sha256", 
asset_hash=img_hash)
 
 self.vm.set_console()
@@ -180,23 +180,23 @@ def boot_openbsd73(self, cpu):
 self.vm.launch()
 wait_for_console_pattern(self,
  "Welcome to the OpenBSD/arm64"
- " 7.3 installation program.")
+ " 7.4 installation program.")
 
-def test_sbsaref_openbsd73_cortex_a57(self):
+def test_sbsaref_openbsd_cortex_a57(self):
 """
-:avocado: tags=cpu:cortex-a57
+:avocado: tags=cpu:cortex-a57,os:openbsd
 """
-self.boot_openbsd73("cortex-a57")
+self.boot_openbsd("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(self):
+def test_sbsaref_openbsd_neoverse_n1(self):
 """
-:avocado: tags=cpu:neoverse-n1
+:avocado: tags=cpu:neoverse-n1,os:openbsd
 """
-self.boot_openbsd73("neoverse-n1")
+self.boot_openbsd("neoverse-n1")
 
-def test_sbsaref_openbsd73_max(self):
+def test_sbsaref_openbsd_max(self):
 """
-:avocado: tags=cpu:max
+:avocado: tags=cpu:max,os:openbsd
 """
-self.boot_openbsd73("max")
+self.boot_openbsd("max")
 

-- 
2.44.0

[PATCH 0/3] tests/avocado: update sbsa-ref firmware to latest

[Marcin Juszkiewicz]

Updating sbsa-ref firmware for QEMU CI was manual task. Now it is
replaced by CI job run on CodeLinaro Gitlab instance.

This patchset updates to current state:

- Trusted Firmware v2.10.2 (latest LTS)
- Tianocore EDK2 stable202402 (latest release)

And Tianocore EDK2-platforms commit 085c2fb (edk2-platforms does not
have releases).

Firmware images were built using Debian 'bookworm' cross gcc 12.2.0
compiler.

And while I am in that file I dropped use of 'virtio-rng-pci' device as
sbsa-ref is supposed to emulate physical hardware.

OpenBSD updated to 7.4 version.

Signed-off-by: Marcin Juszkiewicz 
---
Marcin Juszkiewicz (3):
  tests/avocado: update sbsa-ref firmware
  tests/avocado: drop virtio-rng from sbsa-ref tests
  tests/avocado: use OpenBSD 7.4 for sbsa-ref

 tests/avocado/machine_aarch64_sbsaref.py | 74 +++-
 1 file changed, 34 insertions(+), 40 deletions(-)
---
base-commit: 0748129684be2773117b0b8fc3c60161abdb7bb8
change-id: 20240313-sbsa-ref-firmware-update-7579d9f6d59b

Best regards,
-- 
Marcin Juszkiewicz 

Re: [RFC 0/2] Add RISC-V Server Platform Reference Board

[Marcin Juszkiewicz]

W dniu 4.03.2024 o 11:25, Fei Wu pisze:


The RISC-V Server Platform specification[1] defines a standardized
set of hardware and software capabilities, that portable system
software, such as OS and hypervisors can rely on being present in a
RISC-V server platform. This patchset provides a RISC-V Server
Platform (RVSP) reference implementation on qemu which is in
compliance with the spec as faithful as possible.


I am working on sbsa-ref which is AArch64 Standard Server Platform 
implementation. Will not go through details of rvsp-ref but give some 
potential hints from my work with our platform.



1. Consider versioning the platform.

We have 'platform_version'.'major/minor' exported in 
DeviceTree-formatted data. This allows for firmware to know which of 
non-discoverable hardware features exists and which not. We use it to 
disable XHCI controller on older platform version.



2. If specification allows to have non-discoverable devices then add some.

This will require you to handle them in firmware in some way. Sooner or 
later some physical hardware will be in same situation so they can use 
your firmware code as reference. We have AHCI and XHCI on system bus 
(hardcoded in firmware).



3. You are going to use EDK2 with ACPI. Hide DT from code there with 
some hardware information library.


For sbsa-ref we created SbsaHardwareInfoLib in 
https://openfw.io/edk2-devel/20240306-no-dt-for-cpu-v6-0-acd8727a1...@linaro.org/ 
patchset.

[PATCH 1/1] hw/arm/sbsa-ref: Simplify init since PCIe is always enabled

[Marcin Juszkiewicz]

There is no point in checking do we have PCIe if first thing after check
is adding PCIe card without checking.

Signed-off-by: Marcin Juszkiewicz 
---
 hw/arm/sbsa-ref.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index f2adf30337..b7d6ba2351 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -672,9 +672,8 @@ static void create_pcie(SBSAMachineState *sms)
 }
 
 pci = PCI_HOST_BRIDGE(dev);
-if (pci->bus) {
-pci_init_nic_devices(pci->bus, mc->default_nic);
-}
+
+pci_init_nic_devices(pci->bus, mc->default_nic);
 
 pci_create_simple(pci->bus, -1, "bochs-display");
 
-- 
2.43.0

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 15.02.2024 o 9:52 AM, Dmitry Baryshkov pisze:

If we want to actually go there, I think the best option for PCMCIA
support is likely to replace the entire "soc_common" pcmcia driver
with a simple drivers/pata/ storage driver and no support for
other cards.



hmm, main usage for PCMCIA/CF in those devices was often something else,
not storage,



Do we still support any non-storage CF devices that someone might
actually use? Do you have a specific example in mind? These are
the currently supported devices that I see:



The Bluetooth over the PCMCIA UART worked last time I checked it and
according to your grep it is still a valid user.


If we want to keep those pda devices in Linux kernel then dropping 
whatever PCMCIA which is not a storage sounds like sane way.


No one is going to use such old PDA as daily tool nowadays. And if they 
want then 6.6 LTS kernel would work better due to WiFi drivers being 
still present.


Bluetooth CF cards are old, v1.x tech. WiFi is 802.11b unless you manage 
to get one of those libertas_cs cards but they were rare even when new 
(I was involved in starting 2.6 driver for it). Camera cards had own 
out-of-tree drivers at that time.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 14.02.2024 o 1:26 PM, Dmitry Baryshkov pisze:

The thriving world of PostmarketOS only exist because Google was
clever to realize devices should have a developer mode.



There were two projects that worked on reenabling phones and PDAs from
that era, hack'n'dev and handhelds.org. I think both of them were dead
when the Zaurus was still alive and kicking.


I left handhelds.org developer community in 2007 due to trademark wars 
when admins wanted to take control of several projects hosted there.


LinuxToGo was created in 2006 and some projects moved there from hh.org 
server.


Most of OpenZaurus/Ångström developers abandoned Zaurus devices in 2008. 
Usually in favour of Nokia 770/n800/n810 tablets.


Both OpenZaurus and Ångström used own hosting in handhelds.org era.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 12.02.2024 o 15:36, Guenter Roeck pisze:


The machines I have in mind are:

PXA2xx machines:

akita    Sharp SL-C1000 (Akita) PDA (PXA270)
borzoi   Sharp SL-C3100 (Borzoi) PDA (PXA270)
connex   Gumstix Connex (PXA255)
mainstone    Mainstone II (PXA27x)
spitz    Sharp SL-C3000 (Spitz) PDA (PXA270)
terrier  Sharp SL-C3200 (Terrier) PDA (PXA270)
tosa Sharp SL-6000 (Tosa) PDA (PXA255)
verdex   Gumstix Verdex Pro XL6P COMs (PXA270)
z2   Zipit Z2 (PXA27x)


I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
I am no longer testing those.


I do wonder are those Zaurus models also boot kernels which QEMU boots. 
Would love to see someone still using those old palmtops. I put my 
Zauruses (collie, poodle, c7x0) into drawer long time ago.



OMAP2 machines:

n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
n810 Nokia N810 tablet aka. RX-44 (OMAP2420)


I never managed to get those to boot the Linux kernel.


They were working in 2008. I was running Maemo and Poky Linux then. 
Never tried later.



The one SA1110 machine:

collie   Sharp SL-5500 (Collie) PDA (SA-1110)


I do test collie.


Can you share kernel/initrd/config? I wanted to boot something at 20th 
anniversary of buying one but was unable to build anything bootable on 
either QEMU/collie or physical one.

Re: [PATCH 0/2] ARM Sbsa-ref: Enable CPU cluster topology

[Marcin Juszkiewicz]

W dniu 27.12.2023 o 13:07, Xiong Yining pisze:

Enable CPU cluster support on SbsaQemu platform, so that users can
specify a 4-level CPU hierarchy sockets/clusters/cores/threads. And this
topology can be passed to the firmware through DT cpu-map.

xiongyining1480 (2):
   hw/arm/sbsa-ref:Enable CPU cluster on ARM sbsa machine
   hw/arm/sbsa-ref: Add cpu-map to device tree

  hw/arm/sbsa-ref.c | 36 
  1 file changed, 36 insertions(+)



Tested-by: Marcin Juszkiewicz 

Booted system with "-smp 8,sockets=2,clusters=2,cores=1,threads=2" and 
got what I wanted:


cpus {
#size-cells = <0x00>;
#address-cells = <0x02>;

cpu-map {
socket0 {
cluster0 {
core0 {
thread0 {
cpu = <0x8007>;
};
thread1 {
cpu = <0x8006>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <0x8005>;
};
thread1 {
cpu = <0x8004>;
};
};
};
};
socket1 {
cluster0 {
core0 {
thread0 {
cpu = <0x8003>;
};
thread1 {
cpu = <0x8002>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <0x8001>;
};
thread1 {
cpu = <0x8000>;
};
};
};
};
};

cpu@0 {
phandle = <0x8007>;
reg = <0x00 0x00>;
};

cpu@1 {
phandle = <0x8006>;
reg = <0x00 0x01>;
};

cpu@2 {
phandle = <0x8005>;
reg = <0x00 0x02>;
};

cpu@3 {
phandle = <0x8004>;
reg = <0x00 0x03>;
};

cpu@4 {
phandle = <0x8003>;
reg = <0x00 0x04>;
};

cpu@5 {
phandle = <0x8002>;
reg = <0x00 0x05>;
};

cpu@6 {
phandle = <0x8001>;
reg = <0x00 0x06>;
};

cpu@7 {
phandle = <0x8000>;
reg = <0x00 0x07>;
};
};

Re: [PATCH 2/2] hw/arm/sbsa-ref: Add cpu-map to device tree

[Marcin Juszkiewicz]

W dniu 27.12.2023 o 13:07, Xiong Yining pisze:

From: xiongyining1480 

Support CPU topology description through device tree.

Signed-off-by: Xiong Yining 
Signed-off-by: Chen Baozi 
---
  hw/arm/sbsa-ref.c | 35 +++
  1 file changed, 35 insertions(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index e6cd612bc5..a3c851148a 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -283,10 +283,45 @@ static void create_fdt(SBSAMachineState *sms)
  ms->possible_cpus->cpus[cs->cpu_index].props.node_id);
  }
  
+qemu_fdt_setprop_cell(sms->fdt, nodename, "phandle",

+qemu_fdt_alloc_phandle(sms->fdt));
+
  g_free(nodename);
  }
  
+

  sbsa_fdt_add_gic_node(sms);


Can you add vCPU topology code before ^^ line? So code would add /cpus/ 
node and then go for /intc/ node.



+
+/*
+ * Add vCPU topology description through fdt node cpu-map.


Maybe worth adding pointer to hw/arm/virt.c code for longer description?


+ */
+qemu_fdt_add_subnode(sms->fdt, "/cpus/cpu-map");
+
+for (cpu = sms->smp_cpus - 1; cpu >= 0; cpu--) {
+char *cpu_path = g_strdup_printf("/cpus/cpu@%d", cpu);
+char *map_path;
+
+if (ms->smp.threads > 1) {
+map_path = g_strdup_printf(
+"/cpus/cpu-map/socket%d/cluster%d/core%d/thread%d",
+cpu / (ms->smp.clusters * ms->smp.cores * ms->smp.threads),
+(cpu / (ms->smp.cores * ms->smp.threads)) % ms->smp.clusters,
+(cpu / ms->smp.threads) % ms->smp.cores,
+cpu % ms->smp.threads);
+} else {
+map_path = g_strdup_printf(
+"/cpus/cpu-map/socket%d/cluster%d/core%d",
+cpu / (ms->smp.clusters * ms->smp.cores),
+(cpu / ms->smp.cores) % ms->smp.clusters,
+cpu % ms->smp.cores);
+}
+qemu_fdt_add_path(sms->fdt, map_path);
+qemu_fdt_setprop_phandle(sms->fdt, map_path, "cpu", cpu_path);
+
+g_free(map_path);
+g_free(cpu_path);
+}
+
  }
  
  #define SBSA_FLASH_SECTOR_SIZE (256 * KiB)

Re: [PATCH 21/35] target/arm: Add FEAT_NV to max, neoverse-n2, neoverse-v1 CPUs

[Marcin Juszkiewicz]

W dniu 18.12.2023 o 12:32, Peter Maydell pisze:

Enable FEAT_NV on the 'max' CPU, and stop filtering it out for the 
Neoverse N2 and Neoverse V1 CPUs.  We continue to downgrade FEAT_NV2 
support to FEAT_NV for the latter two CPU types.


According to Neoverse-V1 TRM r1p2 it has FEAT_NV2. Similar with Neoverse-N2.

You wrote already:

in practice hypervisors such as KVM are going to require FEAT_NV2 
and not bother to support the FEAT_NV-only case, so I have

implemented them one after the other in this single patchset.
So maybe they both should be FEAT_NV2 and FEAT_NV will be left unused. 
Or enable FEAT_NV for V1 (as being older) and FEAT_NV2 on N2.


This way if someone wants to test nested virtualization then both 
versions will be available without use of 'max' cpu.

Re: [PATCH 04/10] tests/avocado: machine aarch64: standardize location and RO/RW access

[Marcin Juszkiewicz]

W dniu 8.12.2023 o 20:09, Cleber Rosa pisze:

The tests under machine_aarch64_virt.py do not need read-write access
to the ISOs.  The ones under machine_aarch64_sbsaref.py, on the other
hand, will need read-write access, so let's give each test an unique
file.

And while at it, let's use a single code style and hash for the ISO
url.

Signed-off-by: Cleber Rosa


It is ISO file, so sbsa-ref tests should be fine with readonly as well.

Nothing gets installed so nothing is written. We only test does boot works.

Re: [PATCH v7 5/8] hw/arm/virt: Check CPU type in machine_run_board_init()

[Marcin Juszkiewicz]

W dniu 27.11.2023 o 00:12, Gavin Shan pisze:

@@ -2939,6 +2900,28 @@ static void virt_machine_class_init(ObjectClass *oc, 
void *data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);
  HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
+static const char * const valid_cpu_types[] = {
+#ifdef CONFIG_TCG
+ARM_CPU_TYPE_NAME("cortex-a7"),
+ARM_CPU_TYPE_NAME("cortex-a15"),
+ARM_CPU_TYPE_NAME("cortex-a35"),
+ARM_CPU_TYPE_NAME("cortex-a55"),
+ARM_CPU_TYPE_NAME("cortex-a72"),
+ARM_CPU_TYPE_NAME("cortex-a76"),
+ARM_CPU_TYPE_NAME("cortex-a710"),
+ARM_CPU_TYPE_NAME("a64fx"),
+ARM_CPU_TYPE_NAME("neoverse-n1"),
+ARM_CPU_TYPE_NAME("neoverse-v1"),
+ARM_CPU_TYPE_NAME("neoverse-n2"),
+#endif
+ARM_CPU_TYPE_NAME("cortex-a53"),
+ARM_CPU_TYPE_NAME("cortex-a57"),
+#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
+ARM_CPU_TYPE_NAME("host"),
+#endif
+ARM_CPU_TYPE_NAME("max"),
+NULL
+};


I understand that you just move list from one place to the other but 
also wonder why a53/a57 were/are outside of 'ifdef CONFIG_TCG' check.

Re: [PATCH v7 0/8] Unified CPU type check

[Marcin Juszkiewicz]

W dniu 27.11.2023 o 00:12, Gavin Shan pisze:

After the series is applied:

   [gshan@gshan q]$ ./build/qemu-system-aarch64 -M virt -cpu cortex-a8
   qemu-system-aarch64: Invalid CPU type: cortex-a8
   The valid types are: cortex-a7, cortex-a15, cortex-a35, cortex-a55, \
cortex-a72, cortex-a76, cortex-a710, a64fx,\
neoverse-n1, neoverse-v1, neoverse-n2, cortex-a53, \
cortex-a57, max


Can this list have some better order? A35, A53, A55, A57, A72 feels 
better than current one.

Re: [PATCH v6 0/8] Unified CPU type check

[Marcin Juszkiewicz]

W dniu 20.11.2023 o 01:27, Gavin Shan pisze:

Testing
===

With the following command lines, the output messages are varied before
and after the series is applied.

   ./build/qemu-system-aarch64\
   -accel tcg -machine virt,gic-version=3 \
   -cpu cortex-a8 -smp maxcpus=2,cpus=1

Before the series is applied:

   qemu-system-aarch64: mach-virt: CPU type cortex-a8-arm-cpu not supported

After the series is applied:

   qemu-system-aarch64: Invalid CPU type: cortex-a8-arm-cpu
   The valid models are: cortex-a7, cortex-a15, cortex-a35, cortex-a55,
 cortex-a72, cortex-a76, a64fx, neoverse-n1,
 neoverse-v1, cortex-a53, cortex-a57, max



$ ./build/qemu-system-aarch64 -M sbsa-ref -cpu cortex-a53
qemu-system-aarch64: Invalid CPU type: cortex-a53
The valid types are: cortex-a57, cortex-a72, neoverse-n1, neoverse-v1, 
neoverse-n2, max


$ ./build/qemu-system-aarch64 -M sbsa-ref -cpu sa1100
Unexpected error in object_property_find_err() at ../qom/object.c:1329:
qemu-system-aarch64: Property 'sa1100-arm-cpu.secure-memory' not found
Aborted (core dumped)


Similar with 'host' or 'pxa250' while QEMU/master does:

$ qemu-system-aarch64 -M sbsa-ref -cpu sa1100
qemu-system-aarch64: sbsa-ref: CPU type sa1100-arm-cpu not supported

[PATCH 1/1] target/arm: enable FEAT_RNG on Neoverse-N2

[Marcin Juszkiewicz]

I noticed that Neoverse-V1 has FEAT_RNG enabled so let enable it also on
Neoverse-N2.

Signed-off-by: Marcin Juszkiewicz 
---
 target/arm/tcg/cpu64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 08db1dbcc7..fcda99e158 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -1018,7 +1018,7 @@ static void aarch64_neoverse_n2_initfn(Object *obj)
 cpu->isar.id_aa64dfr1  = 0;
 cpu->id_aa64afr0   = 0;
 cpu->id_aa64afr1   = 0;
-cpu->isar.id_aa64isar0 = 0x022110212120ull; /* with Crypto */
+cpu->isar.id_aa64isar0 = 0x122110212120ull; /* with Crypto and 
FEAT_RNG */
 cpu->isar.id_aa64isar1 = 0x001101211052ull;
 cpu->isar.id_aa64mmfr0 = 0x022200101125ull;
 cpu->isar.id_aa64mmfr1 = 0x10212122ull;
-- 
2.41.0

Re: [PATCH v3] hw/ide/ahci: fix legacy software reset

[Marcin Juszkiewicz]

W dniu 8.11.2023 o 23:26, Niklas Cassel pisze:

From: Niklas Cassel 



This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.

Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz 
Signed-off-by: Niklas Cassel 


Tested-by: Marcin Juszkiewicz 

FreeBSD 14-rc3 boots fine on AArch64 with this patch:

Trying to mount root from cd9660:/dev/iso9660/14_0_RC3_AARCH64_BO [ro]...
cd0 at ahcich0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: Serial Number QM1
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: 347MB (177954 2048 byte sectors)
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ATA-7 SATA device
ada0: Serial Number QM3
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 504MB (1032192 512 byte sectors)
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1:  ATA-7 SATA device
ada1: Serial Number QM5
ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 8192MB (16777216 512 byte sectors)

Re: [PATCH] hw/ide/ahci: fix legacy software reset

[Marcin Juszkiewicz]

W dniu 5.10.2023 o 11:53, Niklas Cassel pisze:

From: Niklas Cassel

Legacy software contains a standard mechanism for generating a reset to a
Serial ATA device - setting the SRST (software reset) bit in the Device
Control register.

Serial ATA has a more robust mechanism called COMRESET, also referred to
as port reset. A port reset is the preferred mechanism for error
recovery and should be used in place of software reset.

Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
improved the handling of PxCI, such that PxCI gets cleared after handling
a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after
receiving an arbitrary FIS).

However, simply clearing PxCI after a non-NCQ, or NCQ command, is not
enough, we also need to clear PxCI when receiving a SRST in the Device
Control register.

This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.

Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz
Signed-off-by: Niklas Cassel


Sorry, I missed that patch earlier.

FreeBSD 14-rc3 boots fine on aarch64. Thanks!

Trying to mount root from cd9660:/dev/iso9660/14_0_RC3_AARCH64_BO [ro]...
cd0 at ahcich0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: Serial Number QM1
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: 347MB (177954 2048 byte sectors)
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ATA-7 SATA device
ada0: Serial Number QM3
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 504MB (1032192 512 byte sectors)
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1:  ATA-7 SATA device
ada1: Serial Number QM5
ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 8192MB (16777216 512 byte sectors)

Tested-by: Marcin Juszkiewicz

Re: FreeBSD 13.2 installer does not see AHCI devices on aarch64/sbsa-ref and x86-64/q35

[Marcin Juszkiewicz]

W dniu 3.10.2023 o 22:41, Niklas Cassel pisze:

On Tue, Oct 03, 2023 at 08:11:39PM +0300, Michael Tokarev wrote:



Were you able to take a look at what's going on here?  I wish I were
able to help here but I know right to nothing about ahci emulation..


I was away on a conference all last week, so I didn't have much time to
look at this yet. I will debug the problem this week.


Did you had a chance of finding out what the problem is?

FreeBSD 14-rc3 came out recently and problem exists still. If they have 
to change code then it may be last hope before final release.

Re: [PATCH] pci: SLT must be RO

[Marcin Juszkiewicz]

W dniu 8.09.2023 o 15:29, Marcin Juszkiewicz pisze:

W dniu 31.08.2023 o 12:05, Marcin Juszkiewicz pisze:

W dniu 30.08.2023 o 23:48, Michael S. Tsirkin pisze:

current code sets PCI_SEC_LATENCY_TIMER to WO, but for
pcie to pcie bridges it must be RO 0 according to
pci express spec which says:
 This register does not apply to PCI Express. It must be read-only
 and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, 
refer to the

 [PCIe-to-PCI-PCI-X-Bridge] for requirements for this register.

also, fix typo in comment where it's make writeable - this typo
is likely what prevented us noticing we violate this requirement
in the 1st place.

Reported-by: Marcin Juszkiewicz 
Signed-off-by: Michael S. Tsirkin 
---



Marcin, could you pls test this patch with virt-8.1 and latest?
Thanks a lot!


Tested-by: Marcin Juszkiewicz 

sbsa-ref: PASS
virt: PASS
virt-8.1: FAIL (as expected)
virt-8.0: FAIL (as expected)


Can we get this patch refreshed and merged?


ping?

[PATCH v2 1/1] tests/avocado: update firmware to enable OpenBSD test on sbsa-ref

[Marcin Juszkiewicz]

Update prebuilt firmware images:
- Neoverse V1/N2 cpu support
- non-secure EL2 virtual timer
- XHCI controller in DSDT

With those changes we can now run OpenBSD as part of sbsa-ref tests.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 68 
 1 file changed, 58 insertions(+), 10 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index a794245e7e..2d683d4f6a 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -28,33 +28,33 @@ def fetch_firmware(self):
 """
 Flash volumes generated using:
 
-- Fedora GNU Toolchain version 13.1.1 20230511 (Red Hat 13.1.1-2)
+- Fedora GNU Toolchain version 13.2.1 20230728 (Red Hat 13.2.1-1)
 
 - Trusted Firmware-A
-  https://github.com/ARM-software/arm-trusted-firmware/tree/c0d8ee38
+  https://github.com/ARM-software/arm-trusted-firmware/tree/7c3ff62d
 
 - Tianocore EDK II
   https://github.com/tianocore/edk2/tree/0f9283429dd4
-  https://github.com/tianocore/edk2-non-osi/tree/f0bb00937ad6
-  https://github.com/tianocore/edk2-platforms/tree/7880b92e2a04
+  https://github.com/tianocore/edk2/tree/ad1c0394b177
+  https://github.com/tianocore/edk2-platforms/tree/d03a60523a60
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
-"https://fileserver.linaro.org/s/HrYMCjP7MEccjRP/;
+"https://fileserver.linaro.org/s/rE43RJyTfxPtBkc/;
 "download/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = "447eff64a90b84ce47703c6ec41fbfc25befaaea"
+fs0_xz_hash = "cdb8e4ffdaaa79292b7b465693f9e5fae6b7062d"
 tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash)
 archive.extract(tar_xz_path, self.workdir)
 fs0_path = os.path.join(self.workdir, "SBSA_FLASH0.fd")
 
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
-"https://fileserver.linaro.org/s/t8foNnMPz74DZZy/;
+"https://fileserver.linaro.org/s/AGWPDXbcqJTKS4R/;
 "download/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = "13a9a262953787c7fc5a9155dfaa26e703631e02"
+fs1_xz_hash = "411155ae6984334714dff08d5d628178e790c875"
 tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash)
 archive.extract(tar_xz_path, self.workdir)
 fs1_path = os.path.join(self.workdir, "SBSA_FLASH1.fd")
@@ -144,7 +144,7 @@ def test_sbsaref_alpine_linux_cortex_a57(self):
 
 def test_sbsaref_alpine_linux_neoverse_n1(self):
 """
-:avocado: tags=cpu:max
+:avocado: tags=cpu:neoverse-n1
 """
 self.boot_alpine_linux("neoverse-n1")
 
@@ -152,4 +152,52 @@ def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
 """
-self.boot_alpine_linux("max,pauth-impdef=on")
+self.boot_alpine_linux("max")
+
+
+# This tests the whole boot chain from EFI to Userspace
+# We only boot a whole OS for the current top level CPU and GIC
+# Other test profiles should use more minimal boots
+def boot_openbsd73(self, cpu):
+self.fetch_firmware()
+
+img_url = (
+"https://cdn.openbsd.org/pub/OpenBSD/7.3/arm64/miniroot73.img;
+)
+
+img_hash = 
"7fc2c75401d6f01fbfa25f4953f72ad7d7c18650056d30755c44b9c129b707e5"
+img_path = self.fetch_asset(img_url, algorithm="sha256", 
asset_hash=img_hash)
+
+self.vm.set_console()
+self.vm.add_args(
+"-cpu",
+cpu,
+"-drive",
+f"file={img_path},format=raw",
+"-device",
+"virtio-rng-pci,rng=rng0",
+"-object",
+"rng-random,id=rng0,filename=/dev/urandom",
+)
+
+self.vm.launch()
+wait_for_console_pattern(self, "Welcome to the OpenBSD/arm64 7.3 
installation program.")
+
+def test_sbsaref_openbsd73_cortex_a57(self):
+"""
+:avocado: tags=cpu:cortex-a57
+"""
+self.boot_openbsd73("cortex-a57")
+
+def test_sbsaref_openbsd73_neoverse_n1(self):
+"""
+:avocado: tags=cpu:neoverse-n1
+"""
+self.boot_openbsd73("neoverse-n1")
+
+def test_sbsaref_openbsd73_max(self):
+"""
+:avocado: tags=cpu:max
+"""
+self.boot_openbsd73("max")
+
-- 
2.41.0

[PATCH v2 0/1] tests/avocado: update firmware to enable OpenBSD test on sbsa-ref

[Marcin Juszkiewicz]

I noticed that neither OpenBSD nor FreeBSD ran properly so this change
adds OpenBSD into testing. Instead of adding tests on all cpu cores I
decided to go with small set:

- Cortex-A57  as it is the oldest
- Neoverse-N1 as it is the default one
- max as this one was broken in past

There was a lot of going on in firmware space for SBSA Reference
Platform recently. Updates prebuilt firmware images got new stuff:
- Neoverse V1/N2 cpu support
- non-secure EL2 virtual timer
- XHCI controller in DSDT

With those changes we can now run OpenBSD as part of sbsa-ref tests.

Changes since v1:
- added OpenBSD test
- decided to not run Neoverse-V1 tests

Marcin Juszkiewicz (1):
  tests/avocado: update firmware to enable OpenBSD test on sbsa-ref

 tests/avocado/machine_aarch64_sbsaref.py | 68 
 1 file changed, 58 insertions(+), 10 deletions(-)

-- 
2.41.0

FreeBSD 13.2 installer does not see AHCI devices on aarch64/sbsa-ref and x86-64/q35

[Marcin Juszkiewicz]

I work on SBSA Reference Platform (sbsa-ref) at Linaro. And yesterday I
wanted to check how non-Linux operating systems work on sbsa-ref machine.

One of them was FreeBSD 13.2 - the latest one. Fetched bootonly ISO
image [1] and booted system.

1. 
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-bootonly.iso

QEMU command line arguments:

-drive 
if=ide,file=disks/FreeBSD-13.2-RELEASE-arm64-aarch64-bootonly.iso,media=cdrom
-machine sbsa-ref
-m 4096
-smp 2
-cpu neoverse-n1
-drive 
file=fat:rw:/home/marcin/devel/linaro/sbsa-qemu/sbsa-ref-status/disks/virtual/,format=raw
-drive 
format=raw,file=/home/marcin/devel/linaro/sbsa-qemu/sbsa-ref-status/disks/full-debian.hddimg
-watchdog-action none
-no-reboot
-monitor telnet::45454,server,nowait
-serial stdio
-device igb
-nographic
-drive if=pflash,file=SBSA_FLASH0.fd,format=raw
-drive if=pflash,file=SBSA_FLASH1.fd,format=raw


Firmware loaded FreeBSD loader, kernel booted but it does not see
any AHCI devices:

ahci0:  iomem 0x6010-0x6010 irq 1 on acpi0
ahci0: AHCI v1.00 with 6 1.5Gbps ports, Port Multiplier not supported
ahci0: Caps: 64bit NCQ 1.5Gbps 32cmd 6ports
ahcich0:  at channel 0 on ahci0
ahcich0: Caps:
[..]
ahcich0: AHCI reset...
ahcich0: SATA connect time=0us status=0113
ahcich0: AHCI reset: device found
ahcich0: AHCI reset: device ready after 0ms
ahcich1: AHCI reset...
ahcich1: SATA connect time=0us status=0113
ahcich1: AHCI reset: device found
ahcich1: AHCI reset: device ready after 0ms
ahcich2: AHCI reset...
ahcich2: SATA connect time=0us status=0113
ahcich2: AHCI reset: device found
ahcich2: AHCI reset: device ready after 0ms
[..]
Trying to mount root from cd9660:/dev/iso9660/13_2_RELEASE_AARCH64_BO [ro]...
Root mount waiting for: CAM
[..]
Root mount waiting for: CAM
ahcich0: Poll timeout on slot 1 port 0
ahcich0: is  cs 0002 ss  rs 0002 tfd 170 serr  
cmd c017

And finally it gives up.


v8.1.1 was bad, v8.0.5 was bad so I did git bisecting.
Which gave me this commit:

commit 7bcd32128b227cee1fb39ff242d486ed9fff7648
Author: Niklas Cassel 
Date:   Fri Jun 9 16:08:40 2023 +0200

hw/ide/ahci: simplify and document PxCI handling

The AHCI spec states that:
For NCQ, PxCI is cleared on command queued successfully.



I built x86_64-softmmu target and checked both "pc" and "q35"
machines.

./build/x86_64-softmmu/qemu-system-x86_64
-cdrom FreeBSD-13.2-RELEASE-amd64-bootonly.iso
-m 2048 -serial stdio  -monitor telnet::45454,server,nowait

PC target ("-M pc") booted fine. But Q35 ("-M q35") failed
similar way as aarch64/sbsa-ref did:

ahci0:  port 0xc060-0xc07f mem 
0xfebd5000-0xfebd5fff irq 16 at device 31.2 on pci0
ahci0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 26 to local APIC 0 vector 52
ahci0: using IRQ 26 for MSI
ahci0: AHCI v1.00 with 6 1.5Gbps ports, Port Multiplier not supported
ahci0: Caps: 64bit NCQ 1.5Gbps 32cmd 6ports
ahcich0:  at channel 0 on ahci0
ahcich0: Caps:
ahcich1:  at channel 1 on ahci0
ahcich1: Caps:
ahcich2:  at channel 2 on ahci0
ahcich2: Caps:
[..]
ahcich2: AHCI reset...
ahcich2: SATA connect time=0us status=0113
ahcich2: AHCI reset: device found
ahcich2: AHCI reset: device ready after 0ms
[..]
Trying to mount root from cd9660:/dev/iso9660/13_2_RELEASE_AMD64_BO [ro]...
ahcich2: Poll timeout on slot 1 port 0
ahcich2: is  cs 0002 ss  rs 0002 tfd 170 serr  
cmd c017
(aprobe2:ahcich2:0:0:0): SOFT_RESET. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe2:ahcich2:0:0:0): CAM status: Command timeout
(aprobe2:ahcich2:0:0:0): Error 5, Retries exhausted
ahcich2: Poll timeout on slot 2 port 0
ahcich2: is  cs 0006 ss  rs 0004 tfd 170 serr  
cmd c017
(aprobe2:ahcich2:0:0:0): SOFT_RESET. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe2:ahcich2:0:0:0): CAM status: Command timeout
(aprobe2:ahcich2:0:0:0): Error 5, Retries exhausted
mountroot: waiting for device /dev/iso9660/13_2_RELEASE_AMD64_BO...
Mounting from cd9660:/dev/iso9660/13_2_RELEASE_AMD64_BO failed with error 19.

Same thing happens with current qemu HEAD:

commit 494a6a2cf7f775d2c20fd6df9601e30606cc2014
Merge: 29578f5757 b821109583
Author: Stefan Hajnoczi 
Date:   Mon Sep 25 10:10:30 2023 -0400

Merge tag 'pull-request-2023-09-25' of https://gitlab.com/thuth/qemu into 
staging


Any ideas?

Re: [PATCH 0/2] target/arm: Implement Neoverse-N2

[Marcin Juszkiewicz]

W dniu 15.09.2023 o 20:54, Peter Maydell pisze:

This patchset implements a model of the Neoverse-N2 CPU.
Because it's very similar to the Cortex-A710 we don't
need to implement any new features for it; but because it
supports 48 bit physical addresses we can use it in the
sbsa-ref board.

Patch 1 fixes a few minor errors in the A710 definition
that I spotted while I was cross-checking it against the
N2 TRM to see what had changed.

Patch 2 is the new CPU model.


Tested-by: Marcin Juszkiewicz 

root@sbsa-ref:~# lscpu
Architecture:   aarch64
  CPU op-mode(s):   32-bit, 64-bit
  Byte Order:   Little Endian
CPU(s): 2
  On-line CPU(s) list:  0,1
Vendor ID:  ARM
  BIOS Vendor ID:   QEMU
  Model name:   Neoverse-N2

Re: [PATCH v1 0/3] Refactor PPI logic/definitions for virt/sbsa-ref

[Marcin Juszkiewicz]

W dniu 15.09.2023 o 13:55, Leif Lindholm pisze:

This set reworks the handling of private peripheral interrupts in virt
to use INTIDs instead of PPI IDs, to make it easier to cross reference
against Arm's Base System Architecture specification.

It then breaks those definitions out into a separate header and switches
sbsa-ref to use the same header instead of defining its own values
locally.

Changes since RFC:
- Compilation tested
- Reordered patches 1-2 as suggested by Philippe.

Leif Lindholm (3):
   {include/}hw/arm: refactor virt PPI logic
   include/hw/arm: move BSA definitions to bsa.h
   hw/arm/sbsa-ref: use bsa.h for PPI definitions

  hw/arm/sbsa-ref.c| 23 +++
  hw/arm/virt-acpi-build.c |  4 ++--
  hw/arm/virt.c|  9 +
  include/hw/arm/bsa.h | 35 +++
  include/hw/arm/virt.h| 12 +---
  5 files changed, 54 insertions(+), 29 deletions(-)
  create mode 100644 include/hw/arm/bsa.h



Tested-by: Marcin Juszkiewicz 
Reviewed-by: Marcin Juszkiewicz 

[PATCH 1/1] tests/avocado: update firmware to enable sbsa-ref/neoverse-v1

[Marcin Juszkiewicz]

Update prebuilt firmware images to have TF-A with Neoverse V1 support enabled.
This allowed us to enable test for this cpu in sbsa-ref machine.

Signed-off-by: Marcin Juszkiewicz 
---
 tests/avocado/machine_aarch64_sbsaref.py | 25 ++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index a794245e7e..b39f5566d7 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -28,33 +28,32 @@ def fetch_firmware(self):
 """
 Flash volumes generated using:
 
-- Fedora GNU Toolchain version 13.1.1 20230511 (Red Hat 13.1.1-2)
+- Fedora GNU Toolchain version 13.2.1 20230728 (Red Hat 13.2.1-1)
 
 - Trusted Firmware-A
-  https://github.com/ARM-software/arm-trusted-firmware/tree/c0d8ee38
+  https://github.com/ARM-software/arm-trusted-firmware/tree/cc933e1d
 
 - Tianocore EDK II
-  https://github.com/tianocore/edk2/tree/0f9283429dd4
-  https://github.com/tianocore/edk2-non-osi/tree/f0bb00937ad6
-  https://github.com/tianocore/edk2-platforms/tree/7880b92e2a04
+  https://github.com/tianocore/edk2/tree/29cce3356aec
+  https://github.com/tianocore/edk2-platforms/tree/fc22c0e69709
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
-"https://fileserver.linaro.org/s/HrYMCjP7MEccjRP/;
+"https://fileserver.linaro.org/s/g4C3WzJzNBES2p2/;
 "download/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = "447eff64a90b84ce47703c6ec41fbfc25befaaea"
+fs0_xz_hash = "374738599f7ba38c22924b2075ec5355c2b24a47"
 tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash)
 archive.extract(tar_xz_path, self.workdir)
 fs0_path = os.path.join(self.workdir, "SBSA_FLASH0.fd")
 
 # Non-secure rom (UEFI and EFI variables)
 fs1_xz_url = (
-"https://fileserver.linaro.org/s/t8foNnMPz74DZZy/;
+"https://fileserver.linaro.org/s/scJRninsAFTwEct/;
 "download/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = "13a9a262953787c7fc5a9155dfaa26e703631e02"
+fs1_xz_hash = "5d3f156ebd6c6374da2121e15c7c8f4ed0351dcc"
 tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash)
 archive.extract(tar_xz_path, self.workdir)
 fs1_path = os.path.join(self.workdir, "SBSA_FLASH1.fd")
@@ -144,10 +143,16 @@ def test_sbsaref_alpine_linux_cortex_a57(self):
 
 def test_sbsaref_alpine_linux_neoverse_n1(self):
 """
-:avocado: tags=cpu:max
+:avocado: tags=cpu:neoverse-n1
 """
 self.boot_alpine_linux("neoverse-n1")
 
+def test_sbsaref_alpine_linux_neoverse_v1(self):
+"""
+:avocado: tags=cpu:neoverse-v1
+"""
+self.boot_alpine_linux("neoverse-v1,pauth-impdef=on")
+
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
-- 
2.41.0

Re: [RFC PATCH 0/3] Refactor PPI logic/definitions for virt/sbsa-ref

[Marcin Juszkiewicz]

W dniu 14.09.2023 o 14:01, Leif Lindholm pisze:

While reviewing Marcin's patch this morning, cross referencing different
specifications and looking at various places around the source code in
order to convinced myself he really hadn't missed something out (the
existing plumbing made it *so* clean to add), my brain broke slightly
at keeping track of PPIs/INTIDs between the various sources.

Moreover, I found the PPI() macro in virt.h to be doing the exact
opposite of what I would have expected it to (it converts a PPI to an
INTID rather than the other way around).

So I refactored stuff so that:
- PPIs defined by BSA are moved to a (new) common header.
- The _IRQ definitions for those PPIs refer to the INTIDs.
- sbsa-ref and virt both use these definitions.

This change does objectively add a bit more noise to the code, since it
means more locations need to use the PPI macro than before, but it felt
like a readability improvement to me.


I like how code looks after those changes. No more adding 16 to irq
numbers to fit them into BSA spec numbers is nice to have.

Will rebase my "non-secure EL2 virtual timer" patch on top of it.


Not even compilation tested, just the least confusing way of asking
whether the change could be accepted at all.


There are build warnings and final binary segfaults on start.


[1799/2931] Compiling C object libqemu-aarch64-softmmu.fa.p/hw_arm_sbsa-ref.c.o
../hw/arm/sbsa-ref.c: In function ‘create_gic’:
../hw/arm/sbsa-ref.c:496:13: warning: assignment to ‘int’ from ‘qemu_irq’ {aka 
‘struct IRQState *’} makes integer from pointer without a cast 
[-Wint-conversion]
  496 | irq = qdev_get_gpio_in(sms->gic,
  | ^
../hw/arm/sbsa-ref.c:499:37: warning: passing argument 4 of 
‘qdev_connect_gpio_out_named’ makes pointer from integer without a cast 
[-Wint-conversion]
  499 | irq);
  | ^~~
  | |
  | int
In file included from 
/home/marcin/devel/linaro/sbsa-qemu/code/qemu/include/hw/core/cpu.h:23,
 from ../target/arm/cpu-qom.h:23,
 from ../target/arm/cpu.h:26,
 from 
/home/marcin/devel/linaro/sbsa-qemu/code/qemu/include/sysemu/kvm.h:244,
 from ../hw/arm/sbsa-ref.c:27:
/home/marcin/devel/linaro/sbsa-qemu/code/qemu/include/hw/qdev-core.h:699:43: 
note: expected ‘qemu_irq’ {aka ‘struct IRQState *’} but argument is of type 
‘int’
  699 |  qemu_irq input_pin);
  |  ~^
../hw/arm/sbsa-ref.c:501:13: warning: assignment to ‘int’ from ‘qemu_irq’ {aka 
‘struct IRQState *’} makes integer from pointer without a cast 
[-Wint-conversion]
  501 | irq = qdev_get_gpio_in(sms->gic,
  | ^
../hw/arm/sbsa-ref.c:503:65: warning: passing argument 4 of 
‘qdev_connect_gpio_out_named’ makes pointer from integer without a cast 
[-Wint-conversion]
  503 | qdev_connect_gpio_out_named(cpudev, "pmu-interrupt", 0, irq);
  | ^~~
  | |
  | int
/home/marcin/devel/linaro/sbsa-qemu/code/qemu/include/hw/qdev-core.h:699:43: 
note: expected ‘qemu_irq’ {aka ‘struct IRQState *’} but argument is of type 
‘int’
  699 |  qemu_irq input_pin);
  |  ~^

[PATCH 0/1] sbsa-ref: add non-secure EL2 virtual timer

[Marcin Juszkiewicz]

Armv8.1+ cpus have Virtual Host Extension (VHE) which added non-secure
EL2 virtual timer.

This change adds it to fullfil Arm BSA (Base System Architecture)
requirements.

>From firmware side information about timer needs to be present in GTDT
acpi table. If it is there with suggested interrupt 28 then BSA ACS test
266 passes:

--
 226 : Check NS EL2-Virt timer PPI Assignment START

   Received vir el2 interrupt
   B_PPI_02
   : Result:  PASS
 END
--

On Armv8.0 cpus this timer should not exist as there is no VHE.

I hope this code is correct. Tried to compare with other emulation
targets but only "virt" and "sbsa-ref" use cpu cores newer than v8.0
ones.

Marcin Juszkiewicz (1):
  sbsa-ref: add non-secure EL2 virtual timer

 hw/arm/sbsa-ref.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.41.0

[PATCH 1/1] sbsa-ref: add non-secure EL2 virtual timer

[Marcin Juszkiewicz]

Armv8.1+ cpus have Virtual Host Extension (VHE) which added non-secure
EL2 virtual timer.

This change adds it to fullfil Arm BSA (Base System Architecture)
requirements.

Signed-off-by: Marcin Juszkiewicz 

---
 hw/arm/sbsa-ref.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index bc89eb4806..3c7dfcd6dc 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -61,6 +61,7 @@
 #define ARCH_TIMER_S_EL1_IRQ   13
 #define ARCH_TIMER_NS_EL1_IRQ  14
 #define ARCH_TIMER_NS_EL2_IRQ  10
+#define ARCH_TIMER_NS_EL2_VIRT_IRQ  12
 
 enum {
 SBSA_FLASH,
@@ -489,6 +490,7 @@ static void create_gic(SBSAMachineState *sms, MemoryRegion 
*mem)
 [GTIMER_VIRT] = ARCH_TIMER_VIRT_IRQ,
 [GTIMER_HYP]  = ARCH_TIMER_NS_EL2_IRQ,
 [GTIMER_SEC]  = ARCH_TIMER_S_EL1_IRQ,
+[GTIMER_HYPVIRT] = ARCH_TIMER_NS_EL2_VIRT_IRQ,
 };
 
 for (irq = 0; irq < ARRAY_SIZE(timer_irq); irq++) {
-- 
2.41.0

Should pcie-pci-bridge use 32-bit non-prefetchable memory?

[Marcin Juszkiewicz]

I am working on aarch64/sbsa-ref machine so people can have virtual
machine to test their OS against something reminding standards compliant
system.

One of tools I use is BSA ACS (Base System Architecture - Architecture
Compliance Suite) [1] written by Arm. It runs set of tests to check does
system conforms to BSA specification.

1. https://github.com/ARM-software/bsa-acs

To run tests I use my "boot-sbsa-ref.sh" script [2] which allows me to
run exactly same setup each time.

2. https://github.com/hrw/sbsa-ref-status/blob/main/boot-sbsa-ref.sh

Since we have ITS support in whole stack (qemu, tf-a, edk2) I use
overcomplicated PCIe setup:

-device igb
-device pcie-root-port,id=root_port_for_switch1,chassis=0,slot=0
 -device x3130-upstream,id=upstream_port1,bus=root_port_for_switch1
  -device 
xio3130-downstream,id=downstream_port1,bus=upstream_port1,chassis=1,slot=0
   -device ac97,bus=downstream_port1
-device pcie-root-port,id=root_port_for_nvme1,chassis=2,slot=0
 -device nvme,serial=deadbeef,bus=root_port_for_nvme1
-device pcie-root-port,id=root_port_for_igb,chassis=3,slot=0
 -device igb,bus=root_port_for_igb
-device pcie-root-port,id=root_port_for_xhci,chassis=4,slot=0
 -device qemu-xhci,bus=root_port_for_xhci
-device pcie-root-port,id=root_port_for_rng,chassis=5,slot=0
 -device virtio-rng-pci,bus=root_port_for_rng
-device pcie-root-port,id=root_port_for_pci,chassis=6,slot=0
 -device pcie-pci-bridge,id=pci,bus=root_port_for_pci
  -device es1370,bus=pci,addr=9
  -device e1000,bus=pci,addr=10
-device pxb-pcie,id=pxb1,bus_nr=1
 -device pcie-root-port,id=root_port_for_ahci,bus=pxb1,chassis=10,slot=0
  -device ahci,bus=root_port_for_ahci

BSA ACS test 841 checks do Type-1 PCIe devices have 32-bit
non-prefetchable memory. And fails on pcie-pci-bridge:

Operating System View:
 841 : NP type-1 PCIe supp 32-bit onlySTART

   BDF - 0x400
   BDF - 0x500
   BDF - 0x600
   BDF - 0x700
   BDF - 0x800
   BDF - 0x900
   BDF - 0x1
   BDF - 0x3
   Skipping Non Type-1 headers
   BDF - 0x4
   Skipping Non Type-1 headers
   BDF - 0x5
   Skipping Non Type-1 headers
   BDF - 0x6
   Skipping Non Type-1 headers
   BDF - 0x7
   NP type-1 pcie is not 32-bit mem type
   Failed on PE -0
   PCI_MM_04
   Checkpoint --  1   : Result:  FAIL

0x7 is pcie-pci-bridge card.

I opened issue for BSA ACS [3] and asked where the problem is.

3. https://github.com/ARM-software/bsa-acs/issues/197

Got quote from BSA (Arm Base System Architecture) [4]
chapter E.2 PCI Express Memory Space:


When PCI Express memory space is mapped as normal memory, the system
must support unaligned accesses to that region.
PCI Type 1 headers, used in PCI-to-PCI bridges, and therefore in root
ports and switches, have to be programmed with the address space
resources claimed by the given bridge.
For non-prefetchable (NP) memory, Type 1 headers only support 32-bit
addresses. This implies that endpoints on the other end of a
PCI-to-PCI bridge only support 32-bit NP BARs


4. https://developer.arm.com/documentation/den0094/latest/


I looked at code and tried to switch pcie-pci-bridge to 32-bit:


diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
index 2301b2ca0b..45199d2fa0 100644
--- a/hw/pci-bridge/pcie_pci_bridge.c
+++ b/hw/pci-bridge/pcie_pci_bridge.c
@@ -82,7 +82,7 @@ static void pcie_pci_bridge_realize(PCIDevice *d, Error 
**errp)
 }
 }
 pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY |
- PCI_BASE_ADDRESS_MEM_TYPE_64, _br->shpc_bar);
+ PCI_BASE_ADDRESS_MEM_TYPE_32, _br->shpc_bar);
 return;

 msi_error:



With it, test 841 passes.

The difference in "lspci -" output suggests that this region address
was 32-bit in both cases:

-   Region 0: Memory at 81c0 (64-bit, non-prefetchable) [size=256]
+   Region 0: Memory at 81c0 (32-bit, non-prefetchable) [size=256]

Any ideas how to continue from here?

Re: [PATCH] pci: SLT must be RO

[Marcin Juszkiewicz]

W dniu 31.08.2023 o 12:05, Marcin Juszkiewicz pisze:

W dniu 30.08.2023 o 23:48, Michael S. Tsirkin pisze:

current code sets PCI_SEC_LATENCY_TIMER to WO, but for
pcie to pcie bridges it must be RO 0 according to
pci express spec which says:
 This register does not apply to PCI Express. It must be read-only
 and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer 
to the

 [PCIe-to-PCI-PCI-X-Bridge] for requirements for this register.

also, fix typo in comment where it's make writeable - this typo
is likely what prevented us noticing we violate this requirement
in the 1st place.

Reported-by: Marcin Juszkiewicz 
Signed-off-by: Michael S. Tsirkin 
---



Marcin, could you pls test this patch with virt-8.1 and latest?
Thanks a lot!


Tested-by: Marcin Juszkiewicz 

sbsa-ref: PASS
virt: PASS
virt-8.1: FAIL (as expected)
virt-8.0: FAIL (as expected)


Can we get this patch refreshed and merged?

Re: /util/cpuinfo-aarch64.c:58:22: error: 'HWCAP_USCAT' undeclared

[Marcin Juszkiewicz]

W dniu 2.09.2023 o 20:11, Liviu Ionescu pisze:

When trying to build 8.1.0 on an Ubuntu 18.04 aarch64, I get the
above error.


Ubuntu 18.04 is not supported anymore by Canonical. End-Of-Life was in
May 2023.


The offending code in `/util/cpuinfo-aarch64.c` is:


> ```c
> #ifdef CONFIG_LINUX
>  unsigned long hwcap = qemu_getauxval(AT_HWCAP);
>  info |= (hwcap & HWCAP_ATOMICS ? CPUINFO_LSE : 0);
>  info |= (hwcap & HWCAP_USCAT ? CPUINFO_LSE2 : 0);
>  info |= (hwcap & HWCAP_AES ? CPUINFO_AES: 0);
> #endif
> ```


The reason is that on this distribution the  header
file does not define HWCAP_USCAT:


I would recommend either upgrading your distro or staying at QEMU 8.1
release.

HWCAP_USCAT was added to glibc in June 2018. As your distribution is not 
supported anymore you can also patch glibc in your system.



I don't know if other distributions are also affected, my build
platform for all xPack standalone binaries is Ubuntu 18.04 LTS.


I do not know any supported distribution release without it.


I know that 18.04 is an old version, but I use the xPack QEMU mainly
to run unit tests, and in some enterprise environments the machines
used for testing are sometimes pretty outdated, thus 18.04 will
remain the base build platform for a while.

It would be very nice if QEMU would still compile on Ubuntu 18.04, as
it did before 8.1.0.

Re: [PATCH] pci: SLT must be RO

[Marcin Juszkiewicz]

W dniu 30.08.2023 o 23:48, Michael S. Tsirkin pisze:

current code sets PCI_SEC_LATENCY_TIMER to WO, but for
pcie to pcie bridges it must be RO 0 according to
pci express spec which says:
 This register does not apply to PCI Express. It must be read-only
 and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer to the
 [PCIe-to-PCI-PCI-X-Bridge] for requirements for this register.

also, fix typo in comment where it's make writeable - this typo
is likely what prevented us noticing we violate this requirement
in the 1st place.

Reported-by: Marcin Juszkiewicz 
Signed-off-by: Michael S. Tsirkin 
---



Marcin, could you pls test this patch with virt-8.1 and latest?
Thanks a lot!


Tested-by: Marcin Juszkiewicz 

sbsa-ref: PASS
virt: PASS
virt-8.1: FAIL (as expected)
virt-8.0: FAIL (as expected)

./code/qemu/build/aarch64-softmmu/qemu-system-aarch64 \
 -machine virt \
 -m 4096  \
 -cpu neoverse-n1 \
 -smp 2 \
 -drive if=pflash,format=raw,file=QEMU_EFI.fd \
 -drive if=pflash,format=raw,file=QEMU_EFI-vars.fd \
-drive file=fat:rw:$PWD/disks/virtual/,format=raw \
-device pcie-root-port,id=root30,chassis=30,slot=0 \
-device igb,bus=root30 \
 -device qemu-xhci,id=usb \
 -device bochs-display \
 -device e1000e \
-nographic \
 -usb \
 -device usb-kbd \
 -device usb-tablet \
 -monitor telnet::45454,server,nowait \
 -serial stdio



  include/hw/pci/pci_bridge.h |  3 +++
  hw/core/machine.c   |  5 -
  hw/pci/pci.c|  2 +-
  hw/pci/pci_bridge.c | 14 ++
  4 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ea54a81a15..5cd452115a 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -77,6 +77,9 @@ struct PCIBridge {
  
  pci_map_irq_fn map_irq;

  const char *bus_name;
+
+/* SLT is RO for PCIE to PCIE bridges, but old QEMU versions had it RW */
+bool pcie_writeable_slt_bug;
  };
  
  #define PCI_BRIDGE_DEV_PROP_CHASSIS_NR "chassis_nr"

diff --git a/hw/core/machine.c b/hw/core/machine.c
index da699cf4e1..76743e3b31 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -32,6 +32,7 @@
  #include "qemu/error-report.h"
  #include "sysemu/qtest.h"
  #include "hw/pci/pci.h"
+#include "hw/pci/pci_bridge.h"
  #include "hw/mem/nvdimm.h"
  #include "migration/global_state.h"
  #include "migration/vmstate.h"
@@ -39,7 +40,9 @@
  #include "hw/virtio/virtio.h"
  #include "hw/virtio/virtio-pci.h"
  
-GlobalProperty hw_compat_8_1[] = {};

+GlobalProperty hw_compat_8_1[] = {
+{ TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },
+};
  const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);
  
  GlobalProperty hw_compat_8_0[] = {

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 881d774fb6..b0d21bf43a 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -893,7 +893,7 @@ static void pci_init_w1cmask(PCIDevice *dev)
  static void pci_init_mask_bridge(PCIDevice *d)
  {
  /* PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, PCI_SUBORDINATE_BUS and
-   PCI_SEC_LETENCY_TIMER */
+   PCI_SEC_LATENCY_TIMER */
  memset(d->wmask + PCI_PRIMARY_BUS, 0xff, 4);
  
  /* base and limit */

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index e7b9345615..6a4e38856d 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -38,6 +38,7 @@
  #include "qapi/error.h"
  #include "hw/acpi/acpi_aml_interface.h"
  #include "hw/acpi/pci.h"
+#include "hw/qdev-properties.h"
  
  /* PCI bridge subsystem vendor ID helper functions */

  #define PCI_SSVID_SIZEOF8
@@ -385,6 +386,11 @@ void pci_bridge_initfn(PCIDevice *dev, const char 
*typename)
  pci_bridge_region_init(br);
  QLIST_INIT(_bus->child);
  QLIST_INSERT_HEAD(>child, sec_bus, sibling);
+
+/* For express secondary buses, secondary latency timer is RO 0 */
+if (pci_bus_is_express(sec_bus) && !br->pcie_writeable_slt_bug) {
+dev->wmask[PCI_SEC_LATENCY_TIMER] = 0;
+}
  }
  
  /* default qdev clean up function for PCI-to-PCI bridge */

@@ -466,10 +472,18 @@ int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int 
cap_offset,
  return 0;
  }
  
+static Property pci_bridge_properties[] = {

+DEFINE_PROP_BOOL("x-pci-express-writeable-slt-bug", PCIBridge,
+ pcie_writeable_slt_bug, false),
+DEFINE_PROP_END_OF_LIST(),
+};
+
  static void pci_bridge_class_init(ObjectClass *klass, void *data)
  {
  AcpiDevAmlIfClass *adevc = ACPI_DEV_AML_IF_CLASS(klass);
+DeviceClass *k = DEVICE_CLASS(klass);
  
+device_class_set_props(k, pci_bridge_properties);

  adevc->build_dev_aml = build_pci_bridge_aml;
  }
  

Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 22:46, Michael S. Tsirkin pisze:

On Tue, Aug 29, 2023 at 10:44:08PM +0200, Marcin Juszkiewicz wrote:

W dniu 29.08.2023 o 22:40, Michael S. Tsirkin pisze:

It passes with sbsa-ref (which is not using QEMU versioning).

Fails (as expected) when used new property for each pcie-root-port
(ignore line breaks):

"-device pcie-root-port,
x-pci-express-writeable-slt-bug=true,
id=root30,chassis=30,slot=0"


could you also check with -machine pc-q35-8.1 instead of this
property?


BSA ACS is AArch64 only.


virt-8.1 then


Passes for virt, virt-8.1 and virt-8.0 machines.

./code/qemu/build/aarch64-softmmu/qemu-system-aarch64 \
 -machine virt-8.0 \
 -m 4096  \
 -cpu neoverse-n1 \
 -smp 2 \
 -drive if=pflash,format=raw,file=QEMU_EFI.fd \
 -drive if=pflash,format=raw,file=QEMU_EFI-vars.fd \
-drive file=fat:rw:$PWD/disks/virtual/,format=raw \
-device pcie-root-port,id=root30,chassis=30,slot=0 \
-device igb,bus=root30 \
 -device qemu-xhci,id=usb \
 -device bochs-display \
 -device e1000e \
-nographic \
 -usb \
 -device usb-kbd \
 -device usb-tablet \
 -monitor telnet::45454,server,nowait \
 -serial stdio

Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 19:07, Michael S. Tsirkin pisze:


No - it depends on secondart bus type and only applies to bridges.
Also we need compat machinery.
Marcin could you pls test the following?


Works fine:

 822 : Check Type 1 config header rules   : Result:  PASS



diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ea54a81a15..5cd452115a 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -77,6 +77,9 @@ struct PCIBridge {
  
  pci_map_irq_fn map_irq;

  const char *bus_name;
+
+/* SLT is RO for PCIE to PCIE bridges, but old QEMU versions had it RW */
+bool pcie_writeable_slt_bug;
  };
  
  #define PCI_BRIDGE_DEV_PROP_CHASSIS_NR "chassis_nr"

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index e7b9345615..6a4e38856d 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -38,6 +38,7 @@
  #include "qapi/error.h"
  #include "hw/acpi/acpi_aml_interface.h"
  #include "hw/acpi/pci.h"
+#include "hw/qdev-properties.h"
  
  /* PCI bridge subsystem vendor ID helper functions */

  #define PCI_SSVID_SIZEOF8
@@ -385,6 +386,11 @@ void pci_bridge_initfn(PCIDevice *dev, const char 
*typename)
  pci_bridge_region_init(br);
  QLIST_INIT(_bus->child);
  QLIST_INSERT_HEAD(>child, sec_bus, sibling);
+
+/* For express secondary buses, secondary latency timer is RO 0 */
+if (pci_bus_is_express(sec_bus) && !br->pcie_writeable_slt_bug) {
+dev->wmask[PCI_SEC_LATENCY_TIMER] = 0;
+}
  }
  
  /* default qdev clean up function for PCI-to-PCI bridge */

@@ -466,10 +472,18 @@ int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int 
cap_offset,
  return 0;
  }
  
+static Property pci_bridge_properties[] = {

+DEFINE_PROP_BOOL("x-pci-express-writeable-slt-bug", PCIBridge,
+ pcie_writeable_slt_bug, false),
+DEFINE_PROP_END_OF_LIST(),
+};
+
  static void pci_bridge_class_init(ObjectClass *klass, void *data)
  {
  AcpiDevAmlIfClass *adevc = ACPI_DEV_AML_IF_CLASS(klass);
+DeviceClass *k = DEVICE_CLASS(klass);
  
+device_class_set_props(k, pci_bridge_properties);

  adevc->build_dev_aml = build_pci_bridge_aml;
  }
  

Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 22:40, Michael S. Tsirkin pisze:

It passes with sbsa-ref (which is not using QEMU versioning).

Fails (as expected) when used new property for each pcie-root-port
(ignore line breaks):

"-device pcie-root-port,
   x-pci-express-writeable-slt-bug=true,
   id=root30,chassis=30,slot=0"


could you also check with -machine pc-q35-8.1 instead of this
property?


BSA ACS is AArch64 only.

Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 22:18, Michael S. Tsirkin pisze:

On Tue, Aug 29, 2023 at 10:05:47PM +0200, Marcin Juszkiewicz wrote:

W dniu 29.08.2023 o 19:07, Michael S. Tsirkin pisze:


No - it depends on secondart bus type and only applies to bridges.
Also we need compat machinery.
Marcin could you pls test the following?


Works fine:

  822 : Check Type 1 config header rules   : Result:  PASS


Thanks! Now if possible I'd like to ask you to run the following test
with both default machine and 8.1 machine types.
With default should pass with 8.1 should fail as before.


It passes with sbsa-ref (which is not using QEMU versioning).

Fails (as expected) when used new property for each pcie-root-port
(ignore line breaks):

"-device pcie-root-port,
  x-pci-express-writeable-slt-bug=true,
  id=root30,chassis=30,slot=0"


Thanks!


Thanks for sorting it out. I may have some more PCIe related
questions in future.
 

diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ea54a81a15..5cd452115a 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -77,6 +77,9 @@ struct PCIBridge {
  
  pci_map_irq_fn map_irq;

  const char *bus_name;
+
+/* SLT is RO for PCIE to PCIE bridges, but old QEMU versions had it RW */
+bool pcie_writeable_slt_bug;
  };
  
  #define PCI_BRIDGE_DEV_PROP_CHASSIS_NR "chassis_nr"

diff --git a/hw/core/machine.c b/hw/core/machine.c
index da699cf4e1..d665c79de3 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,7 +39,9 @@
  #include "hw/virtio/virtio.h"
  #include "hw/virtio/virtio-pci.h"
  
-GlobalProperty hw_compat_8_1[] = {};

+GlobalProperty hw_compat_8_1[] = {
+{ TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },


../hw/core/machine.c:43:7: error: ‘TYPE_PCI_BRIDGE’ undeclared here (not in a 
function); did you mean ‘TYPE_PCI_BUS’?
   43 | { TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },
  |   ^~~
  |   TYPE_PCI_BUS

Works with TYPE_PCI_BUS.


+};
  const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);
  
  GlobalProperty hw_compat_8_0[] = {

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index e7b9345615..6a4e38856d 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -38,6 +38,7 @@
  #include "qapi/error.h"
  #include "hw/acpi/acpi_aml_interface.h"
  #include "hw/acpi/pci.h"
+#include "hw/qdev-properties.h"
  
  /* PCI bridge subsystem vendor ID helper functions */

  #define PCI_SSVID_SIZEOF8
@@ -385,6 +386,11 @@ void pci_bridge_initfn(PCIDevice *dev, const char 
*typename)
  pci_bridge_region_init(br);
  QLIST_INIT(_bus->child);
  QLIST_INSERT_HEAD(>child, sec_bus, sibling);
+
+/* For express secondary buses, secondary latency timer is RO 0 */
+if (pci_bus_is_express(sec_bus) && !br->pcie_writeable_slt_bug) {
+dev->wmask[PCI_SEC_LATENCY_TIMER] = 0;
+}
  }
  
  /* default qdev clean up function for PCI-to-PCI bridge */

@@ -466,10 +472,18 @@ int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int 
cap_offset,
  return 0;
  }
  
+static Property pci_bridge_properties[] = {

+DEFINE_PROP_BOOL("x-pci-express-writeable-slt-bug", PCIBridge,
+ pcie_writeable_slt_bug, false),
+DEFINE_PROP_END_OF_LIST(),
+};
+
  static void pci_bridge_class_init(ObjectClass *klass, void *data)
  {
  AcpiDevAmlIfClass *adevc = ACPI_DEV_AML_IF_CLASS(klass);
+DeviceClass *k = DEVICE_CLASS(klass);
  
+device_class_set_props(k, pci_bridge_properties);

  adevc->build_dev_aml = build_pci_bridge_aml;
  }
  

Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

W dniu 29.08.2023 o 15:57, Philippe Mathieu-Daudé pisze:

On 29/8/23 13:39, Marcin Juszkiewicz wrote:



Does someone know where the problem may be? And how to fix it?


Commit fb23162885 ("pci: initialize pci config headers depending it pci
header type.") sets PCI_SEC_LATENCY_TIMER writable; it seems to be a
mistake (and bsa-acs is doing the correct testing).

Can you try this quick fix?

-- >8 --
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 881d774fb6..e43aa0fb36 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -894,5 +895,4 @@ static void pci_init_mask_bridge(PCIDevice *d)
  {
-    /* PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, PCI_SUBORDINATE_BUS and
-   PCI_SEC_LETENCY_TIMER */
-    memset(d->wmask + PCI_PRIMARY_BUS, 0xff, 4);
+    /* PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, PCI_SUBORDINATE_BUS */
+    memset(d->wmask + PCI_PRIMARY_BUS, 0xff, 3);


It made test pass:

 822 : Check Type 1 config header rules   : Result:  PASS

PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Marcin Juszkiewicz]

I am working on aarch64/sbsa-ref machine so people can have virtual
machine to test their OS against something reminding standards compliant
system.

One of tools I use is BSA ACS (Base System Architecture - Architecture
Compliance Suite) [1] written by Arm. It runs set of tests to check does
system conforms to BSA specification.

1. https://github.com/ARM-software/bsa-acs


SBSA-ref goes better and better, yet still we have some issues. One of
them is test 822 ("Check Type 1 config header rules") which fails on
each PCIe root port device:

BDF 0x400 : SLT attribute mismatch: 0xFF020100 instead of 0x20100
BDF 0x500 : SLT attribute mismatch: 0xFF030300 instead of 0x30300
BDF 0x600 : SLT attribute mismatch: 0xFF040400 instead of 0x40400

I reported it as an issue [2] and got response that it may be QEMU
fault. My pcie knowledge is not good enough to know where the problem is.

2. https://github.com/ARM-software/bsa-acs/issues/193


In the comment Gowtham Siddarth wrote:

Regarding the SLT (Secondary Latency Timer) register, the expected 
values align with the ACS specifications, registering as 0. However, 
a discrepancy arises in the register's attribute, intended to be set 
as Read-Only. Contrary to this intent, the bit field seems to 
function as> Read-Write. Ordinarily, when attempting to write to the 
register by configuring all bits to 1, the anticipated behaviour 
should involve rejecting the write operation, maintaining the value 
at 0 to uphold the register's designated Read-Only nature. However, 
in this scenario, the write action takes effect, leading to a 
transformation of the register's value to FFs. This anomaly could 
potentially stem from an issue within the emulator.


Does someone know where the problem may be? And how to fix it?

Re: [PATCH 5/5] target/arm: Implement cortex-a710

[Marcin Juszkiewicz]

W dniu 10.08.2023 o 19:12, Peter Maydell pisze:

On Thu, 10 Aug 2023 at 18:05, Richard Henderson

On 8/10/23 08:49, Peter Maydell wrote:

On Thu, 10 Aug 2023 at 03:36, Richard Henderson



Will sbsa-ref want this core ?



It only has 40 PA bits, and I think sbsa-ref requires 48.



Yes, it does want 48 (we ran into that with some other core).


sbsa-ref needs PA > 40 bit as memory starts at 2^40.

Cortex A57/A72 have only 44 bits for PA space and are fine.

From v9 cores I look forward for Neoverse-N2/V2 cores.

My "AArch64 cpu cores info table" [1] lists all/most of Arm designed 
cores with some basic information (arch level, 32bit, PA/VA, granules, SVE).


1. https://marcin.juszkiewicz.com.pl/download/tables/arm-cpu-cores.html

Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation

[Marcin Juszkiewicz]

W dniu 13.07.2023 o 14:34, Gavin Shan pisze:

On 7/13/23 21:52, Marcin Juszkiewicz wrote:

W dniu 13.07.2023 o 13:44, Peter Maydell pisze:

I see this isn't a change in this patch, but given that what the 
user specifies is not "cortex-a8-arm-cpu" but "cortex-a8", why

do we include the "-arm-cpu" suffix in the error messages? It's
not valid syntax to say "-cpu cortex-a8-arm-cpu", so it's a bit 
misleading...



I like the change but it (IMHO) needs to cut "-{TYPE_*_CPU}"
string from names:


Peter and Marcin, how about to split the CPU types to two fields, as 
below? In this way, the complete CPU type will be used for validation

and the 'internal' names will be used for the error messages.


Note that it should probably propagate to all architectures handled in 
QEMU, not only Arm ones. I do not know which machines have list of 
supported cpu types like arm/virt or arm/sbsa-ref ones.
I can change sbsa-ref to follow that change but let it be 
userfriendly.



Yes, sbsa-ref needs an extra patch to use the generic invalidation.
I can add one patch on the top for that in next revision if you
agree, Marcin.


I am fine with it.

Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation

[Marcin Juszkiewicz]

W dniu 13.07.2023 o 13:44, Peter Maydell pisze:


I see this isn't a change in this patch, but given that
what the user specifies is not "cortex-a8-arm-cpu" but
"cortex-a8", why do we include the "-arm-cpu" suffix in
the error messages? It's not valid syntax to say
"-cpu cortex-a8-arm-cpu", so it's a bit misleading...


Internally those cpu names are "max-{TYPE_ARM_CPU}" and similar for 
other architectures.


I like the change but it (IMHO) needs to cut "-{TYPE_*_CPU}" string from 
names:


13:37 marcin@applejack:qemu$ ./build/aarch64-softmmu/qemu-system-aarch64 
-M virt -cpu cortex-r5

qemu-system-aarch64: Invalid CPU type: cortex-r5-arm-cpu
The valid types are: cortex-a7-arm-cpu, cortex-a15-arm-cpu, 
cortex-a35-arm-cpu, cortex-a55-arm-cpu, cortex-a72-arm-cpu, 
cortex-a76-arm-cpu, a64fx-arm-cpu, neoverse-n1-arm-cpu, 
neoverse-v1-arm-cpu, cortex-a53-arm-cpu, cortex-a57-arm-cpu, 
host-arm-cpu, max-arm-cpu


13:37 marcin@applejack:qemu$ ./build/aarch64-softmmu/qemu-system-aarch64 
-M virt -cpu cortex-a57-arm-cpu

qemu-system-aarch64: unable to find CPU model 'cortex-a57-arm-cpu'


I can change sbsa-ref to follow that change but let it be userfriendly.

Re: [PATCH 1/1] hw/arm/sbsa-ref: set 'slots' property of xhci

[Marcin Juszkiewicz]

W dniu 10.07.2023 o 08:37, Yuquan Wang pisze:

This extends the slots of xhci to 64, since the default xhci_sysbus
just supports one slot.

Signed-off-by: Wang Yuquan 
Signed-off-by: Chen Baozi 
---
  hw/arm/sbsa-ref.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 64e1cbce17..bc89eb4806 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -611,6 +611,7 @@ static void create_xhci(const SBSAMachineState *sms)
  hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base;
  int irq = sbsa_ref_irqmap[SBSA_XHCI];
  DeviceState *dev = qdev_new(TYPE_XHCI_SYSBUS);
+qdev_prop_set_uint32(dev, "slots", XHCI_MAXSLOTS);


Looks like tab instead of spaces.

  
  sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);

  sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);


Tested-by: Marcin Juszkiewicz 
Reviewed-by: Marcin Juszkiewicz 


Before:

xhci-hcd PNP0D10:00: Error while assigning device slot ID: No Slots Available 
Error
xhci-hcd PNP0D10:00: Max number of devices this xHCI host supports is 1.
usb usb1-port2: couldn't allocate usb_device


After:

input: QEMU QEMU USB Keyboard as 
/devices/platform/PNP0D10:00/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input0
hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 Keyboard [QEMU 
QEMU USB Keyboard] on usb-PNP0D10:00-1/input0
input: QEMU QEMU USB Tablet as 
/devices/platform/PNP0D10:00/usb1/1-2/1-2:1.0/0003:0627:0001.0002/input/input1
hid-generic 0003:0627:0001.0002: input,hidraw1: USB HID v0.01 Mouse [QEMU QEMU 
USB Tablet] on usb-PNP0D10:00-2/input0

Re: [PATCH 1/1] hw/arm/sbsa-ref: set 'slots' property of xhci

[Marcin Juszkiewicz]

W dniu 10.07.2023 o 09:28, Richard Henderson pisze:


hw/usb/hcd-xhci-nec.c:    DEFINE_PROP_UINT32("slots", XHCINecState, 
slots, XHCI_MAXSLOTS),
hw/usb/hcd-xhci-sysbus.c:    DEFINE_PROP_UINT32("slots", 
XHCISysbusState, xhci.numslots, XHCI_MAXSLOTS),


The default is XCHI_MAXSLOTS, not 1.  So I can't see why you'd need this.


There are two systems using XHCI: i386/microvm and arm/sbsa. First
one sets amount of slots already.

Without this patch Linux complains that there is only one port and
refuses to connect second usb device:

xhci-hcd PNP0D10:00: Error while assigning device slot ID: No Slots Available 
Error
xhci-hcd PNP0D10:00: Max number of devices this xHCI host supports is 1.
usb usb1-port2: couldn't allocate usb_device

So it looks like default being XHCI_MAXSLOTS is not applied somewhere.

Re: [PATCH] target/arm: Fix ptw parameters in S1_ptw_translate() for debug contexts

[Marcin Juszkiewicz]

W dniu 6.07.2023 o 17:25, Jean-Philippe Brucker pisze:


(Note that there is an issue with TF-A missing ENABLE_FEAT_FGT for qemu at
the moment, which prevents booting Linux with -cpu max. I'll send the fix
to TF-A after this, but this reproducer should at least boot edk2.)


Which reminds me that qemu/qemu_sbsa targets are still out of sync in 
TF-A when it comes to enabled features ;(

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Marcin Juszkiewicz]

W dniu 4.07.2023 o 16:54, Philippe Mathieu-Daudé pisze:

On 4/7/23 15:35, Marcin Juszkiewicz wrote:

W dniu 4.07.2023 o 15:06, Peter Maydell pisze:


This patchset implements the Cortex Neoverse-V1 CPU type, as a
representative Armv8.3 (+ some extras from 8.4) CPU matching real
hardware.  The main thing we were waiting for to be able to define
this was FEAT_LSE2, and that is now supported.


Now I can add "reach SBSA level 4" to todo list as it requires v8.3 
cpu (I do not count 'max' cpu type).


Do we need to introduce machine variants, such sbsa-lvl3-ref and
sbsa-lvl4-ref? Or simply sbsa-level3/sbsa-level4?


No such combinations. The plan for sbsa-ref is to have only one platform.

Version of platform is exported in DeviceTree already. TF-A reads it and 
exports via SMC call to EDK2. What changes between versions is present 
in documentation.

Re: [PATCH 1/1] hw/arm/sbsa-ref: add PCIe node into DT

[Marcin Juszkiewicz]

W dniu 4.07.2023 o 15:21, Peter Maydell pisze:


Just to be clear about the status of this patch, I don't
have a problem with the code changes, but it does definitely
need a much clearer commit message to explain why we're changing
the way we handle the PCI controller. So I'm dropping this from
my to-review list on the assumption there will be a v2.


Sorry for delay. There will be v2 version of it. I am busy with sorting 
out EDK2 side of GIC ITS enablement.



We could also do with expanding the commentary in the source
file to clarify the design approach we're using w.r.t. what
we do and don't want to put into the "dt" blob, but that would
probably be best in a different patch.


Already on todo list.

Re: [PATCH 0/2] target/arm: Implement Cortex Neoverse-V1

[Marcin Juszkiewicz]

W dniu 4.07.2023 o 15:06, Peter Maydell pisze:


This patchset implements the Cortex Neoverse-V1 CPU type, as a
representative Armv8.3 (+ some extras from 8.4) CPU matching real
hardware.  The main thing we were waiting for to be able to define
this was FEAT_LSE2, and that is now supported.


Now I can add "reach SBSA level 4" to todo list as it requires v8.3 cpu 
(I do not count 'max' cpu type).


Tested-by: Marcin Juszkiewicz 

[PATCH 1/1] hw/arm/sbsa-ref: add PCIe node into DT

[Marcin Juszkiewicz]

Add PCI Express information into DeviceTree as part of SBSA-REF
versioning.

Trusted Firmware will read it and provide to next firmware level.

Signed-off-by: Marcin Juszkiewicz 
---
 hw/arm/sbsa-ref.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 0639f97dd5..b87d2ee3b2 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -171,6 +171,25 @@ static uint64_t sbsa_ref_cpu_mp_affinity(SBSAMachineState 
*sms, int idx)
 return arm_cpu_mp_affinity(idx, clustersz);
 }
 
+static void sbsa_fdt_add_pcie_node(SBSAMachineState *sms)
+{
+char *nodename;
+
+nodename = g_strdup_printf("/pcie");
+qemu_fdt_add_subnode(sms->fdt, nodename);
+qemu_fdt_setprop_sized_cells(sms->fdt, nodename, "reg",
+ 2, sbsa_ref_memmap[SBSA_PCIE_ECAM].base,
+ 2, sbsa_ref_memmap[SBSA_PCIE_ECAM].size,
+ 2, sbsa_ref_memmap[SBSA_PCIE_PIO].base,
+ 2, sbsa_ref_memmap[SBSA_PCIE_PIO].size,
+ 2, sbsa_ref_memmap[SBSA_PCIE_MMIO].base,
+ 2, sbsa_ref_memmap[SBSA_PCIE_MMIO].size,
+ 2, sbsa_ref_memmap[SBSA_PCIE_MMIO_HIGH].base,
+ 2, sbsa_ref_memmap[SBSA_PCIE_MMIO_HIGH].size);
+
+g_free(nodename);
+}
+
 static void sbsa_fdt_add_gic_node(SBSAMachineState *sms)
 {
 char *nodename;
@@ -286,6 +305,7 @@ static void create_fdt(SBSAMachineState *sms)
 }
 
 sbsa_fdt_add_gic_node(sms);
+sbsa_fdt_add_pcie_node(sms);
 }
 
 #define SBSA_FLASH_SECTOR_SIZE (256 * KiB)
-- 
2.41.0

Re: [PATCH v4 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI

[Marcin Juszkiewicz]

W dniu 21.06.2023 o 05:46, Yuquan Wang pisze:

On 2023-06-21 01:24, Leif wrote:



> > Leif, do you think we should bump the minor version here?
> I think that makes sense, yes.



There is a new confusion: Which minor version should I bump to (2 or 3) ?
As I found that Marcin’s latest patch (add ITS support in SBSA GIC
 )
increased the minor version to 2.


Please bump platform version to 0.3 one. ITS being 0.2 is already in our 
plans. Not that numbers matter for those components which are provided 
via DeviceTree.

[PATCH v2 1/1] hw/arm/sbsa-ref: add ITS support in SBSA GIC

[Marcin Juszkiewicz]

From: Shashi Mallela 

Create ITS as part of SBSA platform GIC initialization.

GIC ITS information is in DeviceTree so TF-A can pass it to EDK2.

Bumping platform version to 0.2 as this is important hardware change.

Signed-off-by: Shashi Mallela 
Co-authored-by: Marcin Juszkiewicz 
Signed-off-by: Marcin Juszkiewicz 
---
 docs/system/arm/sbsa.rst | 14 ++
 hw/arm/sbsa-ref.c| 33 ++---
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index f571fe645e..a8e0b530a2 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -46,6 +46,9 @@ to be a complete compliant DT. It currently reports:
- platform version
- GIC addresses
 
+Platform version
+
+
 The platform version is only for informing platform firmware about
 what kind of ``sbsa-ref`` board it is running on. It is neither
 a QEMU versioned machine type nor a reflection of the level of the
@@ -54,3 +57,14 @@ SBSA/SystemReady SR support provided.
 The ``machine-version-major`` value is updated when changes breaking
 fw compatibility are introduced. The ``machine-version-minor`` value
 is updated when features are added that don't break fw compatibility.
+
+Platform version changes:
+
+0.0
+  Devicetree holds information about CPUs, memory and platform version.
+
+0.1
+  GIC information is present in devicetree.
+
+0.2
+  GIC ITS information is present in devicetree.
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index de21200ff9..0639f97dd5 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -65,6 +65,7 @@ enum {
 SBSA_CPUPERIPHS,
 SBSA_GIC_DIST,
 SBSA_GIC_REDIST,
+SBSA_GIC_ITS,
 SBSA_SECURE_EC,
 SBSA_GWDT_WS0,
 SBSA_GWDT_REFRESH,
@@ -108,6 +109,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
 [SBSA_CPUPERIPHS] = { 0x4000, 0x0004 },
 [SBSA_GIC_DIST] =   { 0x4006, 0x0001 },
 [SBSA_GIC_REDIST] = { 0x4008, 0x0400 },
+[SBSA_GIC_ITS] ={ 0x44081000, 0x0002 },
 [SBSA_SECURE_EC] =  { 0x5000, 0x1000 },
 [SBSA_GWDT_REFRESH] =   { 0x5001, 0x1000 },
 [SBSA_GWDT_CONTROL] =   { 0x50011000, 0x1000 },
@@ -181,8 +183,15 @@ static void sbsa_fdt_add_gic_node(SBSAMachineState *sms)
  2, sbsa_ref_memmap[SBSA_GIC_REDIST].base,
  2, sbsa_ref_memmap[SBSA_GIC_REDIST].size);
 
+nodename = g_strdup_printf("/intc/its");
+qemu_fdt_add_subnode(sms->fdt, nodename);
+qemu_fdt_setprop_sized_cells(sms->fdt, nodename, "reg",
+ 2, sbsa_ref_memmap[SBSA_GIC_ITS].base,
+ 2, sbsa_ref_memmap[SBSA_GIC_ITS].size);
+
 g_free(nodename);
 }
+
 /*
  * Firmware on this machine only uses ACPI table to load OS, these limited
  * device tree nodes are just to let firmware know the info which varies from
@@ -219,7 +228,7 @@ static void create_fdt(SBSAMachineState *sms)
  *fw compatibility.
  */
 qemu_fdt_setprop_cell(fdt, "/", "machine-version-major", 0);
-qemu_fdt_setprop_cell(fdt, "/", "machine-version-minor", 1);
+qemu_fdt_setprop_cell(fdt, "/", "machine-version-minor", 2);
 
 if (ms->numa_state->have_numa_distance) {
 int size = nb_numa_nodes * nb_numa_nodes * 3 * sizeof(uint32_t);
@@ -409,7 +418,20 @@ static void create_secure_ram(SBSAMachineState *sms,
 memory_region_add_subregion(secure_sysmem, base, secram);
 }
 
-static void create_gic(SBSAMachineState *sms)
+static void create_its(SBSAMachineState *sms)
+{
+const char *itsclass = its_class_name();
+DeviceState *dev;
+
+dev = qdev_new(itsclass);
+
+object_property_set_link(OBJECT(dev), "parent-gicv3", OBJECT(sms->gic),
+ _abort);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, 
sbsa_ref_memmap[SBSA_GIC_ITS].base);
+}
+
+static void create_gic(SBSAMachineState *sms, MemoryRegion *mem)
 {
 unsigned int smp_cpus = MACHINE(sms)->smp.cpus;
 SysBusDevice *gicbusdev;
@@ -436,6 +458,10 @@ static void create_gic(SBSAMachineState *sms)
 qdev_prop_set_uint32(sms->gic, "len-redist-region-count", 1);
 qdev_prop_set_uint32(sms->gic, "redist-region-count[0]", redist0_count);
 
+object_property_set_link(OBJECT(sms->gic), "sysmem",
+ OBJECT(mem), _fatal);
+qdev_prop_set_bit(sms->gic, "has-lpi", true);
+
 gicbusdev = SYS_BUS_DEVICE(sms->gic);
 sysbus_realize_and_unref(gicbusdev, _fatal);
 sysbus_mmio_map(gicbusdev, 0, sbsa_ref_memmap[SBSA_GIC_DIST].base);
@@ -482,6 +508,7 @@ static void create_gic(SBSAMachineState *sms)

[PATCH v2 0/1] hw/arm/sbsa-ref: add ITS support in GIC

[Marcin Juszkiewicz]

In 2021 Shashi Mallela sent v8 of GIC ITS patchset [1]. At that time it
was decided to do platform versioning first.

1. 
https://lore.kernel.org/qemu-devel/20210812165341.40784-8-shashi.mall...@linaro.org/

Now we are going through our list of changes for SBSA Reference Platform
and GIC ITS is one of early ones. There was decision that there will be
no option to disable it and platform version will get a minor bump.

This is refreshed version of v8 one from 2021. GIC ITS is placed behind
GIC Redistributor in memory space to allow use of older EDK2 firmware.

New address is placed in DeviceTree for firmware to use. Due to it we
also bump platform version to 0.2 version.

Trusted Firmware will read GIC ITS address and provide to EDK2 via
Secure Monitor Call (SMC). Same way as it is done with GIC addresses
already.

Changes since v1:
- everything in one patch
- removed bogus check for kvm_irqchip_in_kernel()
- documentation about platform version changes added


Shashi Mallela (1):
  hw/arm/sbsa-ref: add ITS support in SBSA GIC

 docs/system/arm/sbsa.rst | 14 ++
 hw/arm/sbsa-ref.c| 33 ++---
 2 files changed, 44 insertions(+), 3 deletions(-)

-- 
2.40.1

Re: [PATCH 2/2] hw/arm/sbsa-ref: add GIC ITS to DeviceTree

[Marcin Juszkiewicz]

W dniu 19.06.2023 o 14:55, Peter Maydell pisze:

On Tue, 6 Jun 2023 at 19:24, Marcin Juszkiewicz
 wrote:


We need GIC ITS information in DeviceTree so TF-A can pass it to EDK2.

Bumping platform version to 0.2 as this is important hardware change.




We should fold this patch into the previous one.


Will do. With "Co-authored-by:" tag as ITS stuff was done by Shashi 
Mallela while I did DT part. And S-o-b too.



If we are bumping the version-minor, we should add something
to the documentation that says what the difference between
0.1 and 0.2 is. (And if we can remember what 0.0 was that
would be worth noting.)


Will rebase on top of target-arm.next once you push it with 
documentation updates.

Re: [PATCH 1/1] docs: sbsa: document board to firmware interface

[Marcin Juszkiewicz]

W dniu 19.06.2023 o 14:41, Peter Maydell pisze:

I'm going to apply this to target-arm.next with this squashed in
to fix a few grammar/format nits and add some text from the comment
in the source file about the platform version part.


Thanks.

My English grammar sucks so I am glad that you looked and improved that 
text.

Re: [PATCH v4 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI

[Marcin Juszkiewicz]

W dniu 7.06.2023 o 04:33, Yuquan Wang pisze:

The current sbsa-ref cannot use EHCI controller which is only
able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB.
Hence, this uses system bus XHCI to provide a usb controller with
64-bit DMA capablity instead of EHCI.

Signed-off-by: Yuquan Wang


Reviewed-by: Marcin Juszkiewicz