Re: [PATCH 1/1] target/arm: calculate cache sizes properly

[Marcin Juszkiewicz]

On 11.07.2024 12:19, Peter Maydell wrote:

On Wed, 10 Jul 2024 at 18:35, Marcin Juszkiewicz
 wrote:


Neoverse-V1 TRM says that NumSets are [27:13] not :32 like in code.


NumSets in fields [27:13] is the 32-bit CCSIDR_EL1 format
(i.e. what you have when FEAT_CCIDX is not implemented).
The make_ccsidr64() function provides the 64-bit CCSIDR_EL1
format (i.e. the one when FEAT_CCIDX is implemented).

I would suspect this is an accidental error in the Neoverse-V1
TRM -- if you have access to the real hardware and can dump
the CCSIDR_EL1 value I would expect you'll see it matches
what QEMU is implementing here (and that ID_AA64MMFR2_EL1.CCIDX
also says that FEAT_CCIDX is implemented). See also the comment
"The Neoverse-V1 r1p2 TRM lists 32-bit format CCSIDR_EL1 values"
in aarch64_neoverse_v1_initfn() where we document that we
don't trust what the TRM is saying here.

How did you run into this? Is there some guest software
which is assuming the old 32-bit format and not checking
ID_AA64MMFR2_EL1.CCIDX to see if it needs to use the new one?


I started adding cpu cache info into PPTT and so far the only code I 
used was old 32-bit format one:


https://openfw.io/edk2-devel/20240710-acpi65-v4-6-bc32224e4...@linaro.org/


Will check for CCIDX and adapt proper way. But that has to wait for 
August due to vacation plans.

[PATCH 1/1] target/arm: calculate cache sizes properly

[Marcin Juszkiewicz]

Neoverse-V1 TRM says that NumSets are [27:13] not :32 like in code.

With this fix all cores which use make_ccsidr64() function have proper
size of cpu caches.

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 fe232eb306..98144e1d20 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -50,7 +50,7 @@ static uint64_t make_ccsidr64(unsigned assoc, unsigned 
linesize,
 sets = cachesize / (assoc * linesize);
 assert(cachesize % (assoc * linesize) == 0);
 
-return ((uint64_t)(sets - 1) << 32)
+return ((uint64_t)(sets - 1) << 13)
  | ((assoc - 1) << 3)
  | (lg_linesize - 4);
 }
-- 
2.45.2

[PATCH v4 1/2] tests/avocado: sbsa-ref: add FreeBSD tests

[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. Tests done on OpenBSD will now be
done using FreeBSD.

OpenBSD 7.3 stays with Cortex-A57 test for local runs only.

Moved from Neoverse-N1 to Neoverse-N2 as sbsa-ref defaults were changed.

Timeout messages expanded to mention being affected by PAuth emulation.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index e920bbf08c..2e27d37cb8 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é 
@@ -163,7 +163,8 @@ def test_sbsaref_alpine_linux_max_pauth_impdef(self):
 """
 self.boot_alpine_linux("max,pauth-impdef=on")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
+'Test might timeout due to PAuth emulation')
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
@@ -171,7 +172,6 @@ def test_sbsaref_alpine_linux_max(self):
 """
 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
@@ -198,6 +198,9 @@ def boot_openbsd73(self, cpu):
  "Welcome to the OpenBSD/arm64"
  " 7.3 installation program.")
 
+
+# we keep OpenBSD 7.3 on Cortex-A57 by request
+@skipUnless(os.getenv('AVOCADO_TEST_LEGACY_OS'), 'OpenBSD 7.3 is EOL')
 def test_sbsaref_openbsd73_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
@@ -205,32 +208,66 @@ def test_sbsaref_openbsd73_cortex_a57(self):
 """
 self.boot_openbsd73("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(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_freebsd(self, cpu):
+self.fetch_firmware()
+
+img_url = (
+"https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/;
+"14.1/FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso"
+)
+
+img_hash = 
"44cdbae275ef1bb6dab1d5fbb59473d4f741e1c8ea8a80fd9e906b531d6ad461"
+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",
+)
+
+self.vm.launch()
+wait_for_console_pattern(self, "Welcome to FreeBSD!")
+
+def test_sbsaref_freebsd_cortex_a57(self):
 """
-:avocado: tags=cpu:neoverse-n1
-:avocado: tags=os:openbsd
+:avocado: tags=cpu:cortex-a57
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd("cortex-a57")
+
+# We use Neoverse-N2 as default cpu
+def test_sbsaref_freebsd_neoverse_n2(self):
 """
-self.boot_openbsd73("neoverse-n1")
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd("neoverse-n2")
 
-def test_sbsaref_openbsd73_max_pauth_off(self):
+def test_sbsaref_freebsd_max_pauth_off(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max,pauth=off")
+self.boot_freebsd("max,pauth=off")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max_pauth_impdef(self):
+def test_sbsaref_freebsd_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_freebsd("max,pauth-impdef=on")
 
-   

[PATCH v4 2/2] tests/avocado: add test for default sbsa-ref cpu

[Marcin Juszkiewicz]

We changed sbsa-ref cpu several times already and may do it again in a
future. To newer core or to enable/disable some properties.

This change switches Neoverse-N2 tests to 'let test default cpu' ones.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 2e27d37cb8..46a1d982f3 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -113,7 +113,7 @@ def test_sbsaref_edk2_firmware(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_alpine_linux(self, cpu):
+def boot_alpine_linux(self, cpu=False):
 self.fetch_firmware()
 
 iso_url = (
@@ -126,12 +126,14 @@ def boot_alpine_linux(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={iso_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to Alpine Linux 3.17")
 
@@ -142,12 +144,12 @@ def test_sbsaref_alpine_linux_cortex_a57(self):
 """
 self.boot_alpine_linux("cortex-a57")
 
-def test_sbsaref_alpine_linux_neoverse_n1(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_alpine_linux_default(self):
 """
-:avocado: tags=cpu:neoverse-n1
 :avocado: tags=os:linux
 """
-self.boot_alpine_linux("neoverse-n1")
+self.boot_alpine_linux()
 
 def test_sbsaref_alpine_linux_max_pauth_off(self):
 """
@@ -212,7 +214,7 @@ def test_sbsaref_openbsd73_cortex_a57(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_freebsd(self, cpu):
+def boot_freebsd(self, cpu=False):
 self.fetch_firmware()
 
 img_url = (
@@ -225,12 +227,14 @@ def boot_freebsd(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={img_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to FreeBSD!")
 
@@ -241,13 +245,12 @@ def test_sbsaref_freebsd_cortex_a57(self):
 """
 self.boot_freebsd("cortex-a57")
 
-# We use Neoverse-N2 as default cpu
-def test_sbsaref_freebsd_neoverse_n2(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_freebsd_default(self):
 """
-:avocado: tags=cpu:neoverse-n2
 :avocado: tags=os:freebsd
 """
-self.boot_freebsd("neoverse-n2")
+self.boot_freebsd()
 
 def test_sbsaref_freebsd_max_pauth_off(self):
 """

-- 
2.45.2

[PATCH v4 0/2] tests/avocado: updates for sbsa-ref testing

[Marcin Juszkiewicz]

We want to have some non-Linux OS in testing in case one of changes keep
Linux booting but crash elsewhere. So far OpenBSD was used for it but we
move to FreeBSD 14.x due to longer support cycles.

One OpenBSD stays - will be run on Cortex-A57 only. And only on local
runs hidden behind AVOCADO_TEST_LEGACY_OS variable.

At same time we add test to run on default cpu settings. For now it is
plain Neoverse-N2 but we are considering either disabling PAuth or going
with 'impdef' way.

Signed-off-by: Marcin Juszkiewicz 

---
Changes in v4:
- hide OpenBSD test behind AVOCADO_TEST_LEGACY_OS switch
- Link to v3: 
https://lore.kernel.org/r/20240624-b4-move-to-freebsd-v3-0-71496bf11...@linaro.org

Changes in v3:
- kept OpenBSD/Cortex-A57 test for local runs (by request of Philippe)
- Link to v2: 
https://lore.kernel.org/r/20240624-b4-move-to-freebsd-v2-0-64ea7b049...@linaro.org

---
Marcin Juszkiewicz (2):
  tests/avocado: sbsa-ref: add FreeBSD tests
  tests/avocado: add test for default sbsa-ref cpu

 tests/avocado/machine_aarch64_sbsaref.py | 88 +++-
 1 file changed, 64 insertions(+), 24 deletions(-)
---
base-commit: 1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768
change-id: 20240624-b4-move-to-freebsd-aafdeb75ef38

Best regards,
-- 
Marcin Juszkiewicz 

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

[Marcin Juszkiewicz]

W dniu 30.06.2024 o 16:37, Ard Biesheuvel pisze:

On Thu, 20 Jun 2024 at 12:20, Marcin Juszkiewicz
 wrote:


Update firmware to have graphics card memory fix from EDK2 commit
c1d1910be6e04a8b1a73090cf2881fb698947a6e:

 OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C

 Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
 tolerate misaligned accesses to normal memory, and raise alignment
 faults on such accesses to device memory, which is the default for PCIe
 MMIO BARs.

 When emulating a PCIe graphics controller, the framebuffer is typically
 exposed via a MMIO BAR, while the disposition of the region is closer to
 memory (no side effects on reads or writes, except for the changing
 picture on the screen; direct random access to any pixel in the image).

 In order to permit the use of such controllers on platforms that only
 tolerate these types of accesses for normal memory, it is necessary to
 remap the memory. Use the DXE services to set the desired capabilities
 and attributes.

 Hide this behavior under a feature PCD so only platforms that really
 need it can enable it. (OVMF on x86 has no need for this)

With this fix enabled we can boot sbsa-ref with more than one cpu core.



This requires an explanation: what does the number of CPU cores have
to do with the memory attributes used for the framebuffer?


I have no idea. Older firmware was hanging on several systems but was 
passing in QEMU tests. After closer looking I noticed that Avocado tests 
run with "-smp 1" and pass.


Checked failing system with "-smp 1" and it worked. In meantime you have 
fixed problem in EDK2.


So yes, updating firmware may look like hiding a bug. Which I do not 
know how to track (I can build and test QEMU, but going into its 
internals is something I never done).

[PATCH v3 0/2] tests/avocado: updates for sbsa-ref testing

[Marcin Juszkiewicz]

We want to have some non-Linux OS in testing in case one of changes keep
Linux booting but crash elsewhere. So far OpenBSD was used for it but we
move to FreeBSD 14.x due to longer support cycles.

One OpenBSD stays - will be run on Cortex-A57 only. And only on local
runs.

At same time we add test to run on default cpu settings. For now it is
plain Neoverse-N2 but we are considering either disabling PAuth or going
with 'impdef' way.

Signed-off-by: Marcin Juszkiewicz 

---
Changes in v3:
- kept OpenBSD/Cortex-A57 test for local runs (by request of Philippe)
- Link to v2: 
https://lore.kernel.org/r/20240624-b4-move-to-freebsd-v2-0-64ea7b049...@linaro.org

---
Marcin Juszkiewicz (2):
  tests/avocado: sbsa-ref: add FreeBSD tests
  tests/avocado: add test for default sbsa-ref cpu

 tests/avocado/machine_aarch64_sbsaref.py | 90 +++-
 1 file changed, 65 insertions(+), 25 deletions(-)
---
base-commit: c9ba79baca7c673098361e3a687f72d458e0d18a
change-id: 20240624-b4-move-to-freebsd-aafdeb75ef38

Best regards,
-- 
Marcin Juszkiewicz 

[PATCH v3 2/2] tests/avocado: add test for default sbsa-ref cpu

[Marcin Juszkiewicz]

We changed sbsa-ref cpu several times already and may do it again in a
future. To newer core or to enable/disable some properties.

This change switches Neoverse-N2 tests to 'let test default cpu' ones.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index bb2c098aac..43bb1860e0 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -115,7 +115,7 @@ def test_sbsaref_edk2_firmware(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_alpine_linux(self, cpu):
+def boot_alpine_linux(self, cpu=False):
 self.fetch_firmware()
 
 iso_url = (
@@ -128,12 +128,14 @@ def boot_alpine_linux(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={iso_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to Alpine Linux 3.17")
 
@@ -144,12 +146,12 @@ def test_sbsaref_alpine_linux_cortex_a57(self):
 """
 self.boot_alpine_linux("cortex-a57")
 
-def test_sbsaref_alpine_linux_neoverse_n1(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_alpine_linux_default(self):
 """
-:avocado: tags=cpu:neoverse-n1
 :avocado: tags=os:linux
 """
-self.boot_alpine_linux("neoverse-n1")
+self.boot_alpine_linux()
 
 def test_sbsaref_alpine_linux_max_pauth_off(self):
 """
@@ -214,7 +216,7 @@ def test_sbsaref_openbsd73_cortex_a57(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_freebsd(self, cpu):
+def boot_freebsd(self, cpu=False):
 self.fetch_firmware()
 
 img_url = (
@@ -227,12 +229,14 @@ def boot_freebsd(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={img_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to FreeBSD!")
 
@@ -243,13 +247,12 @@ def test_sbsaref_freebsd_cortex_a57(self):
 """
 self.boot_freebsd("cortex-a57")
 
-# We use Neoverse-N2 as default cpu
-def test_sbsaref_freebsd_neoverse_n2(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_freebsd_default(self):
 """
-:avocado: tags=cpu:neoverse-n2
 :avocado: tags=os:freebsd
 """
-self.boot_freebsd("neoverse-n2")
+self.boot_freebsd()
 
 def test_sbsaref_freebsd_max_pauth_off(self):
 """

-- 
2.45.2

[PATCH v3 1/2] tests/avocado: sbsa-ref: add FreeBSD tests

[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. Tests done on OpenBSD will now be
done using FreeBSD.

OpenBSD 7.3 stays with Cortex-A57 test for local runs only.

Moved from Neoverse-N1 to Neoverse-N2 as sbsa-ref defaults were changed.

Timeout messages expanded to mention being affected by PAuth emulation.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 6bb82f2a03..bb2c098aac 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é 
@@ -8,7 +8,7 @@
 
 import os
 
-from avocado import skipUnless
+from avocado import skipIf, skipUnless
 from avocado.utils import archive
 
 from avocado_qemu import QemuSystemTest
@@ -165,7 +165,8 @@ def test_sbsaref_alpine_linux_max_pauth_impdef(self):
 """
 self.boot_alpine_linux("max,pauth-impdef=on")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
+'Test might timeout due to PAuth emulation')
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
@@ -173,7 +174,6 @@ def test_sbsaref_alpine_linux_max(self):
 """
 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
@@ -200,6 +200,9 @@ def boot_openbsd73(self, cpu):
  "Welcome to the OpenBSD/arm64"
  " 7.3 installation program.")
 
+
+# we keep OpenBSD 7.3 on Cortex-A57 by request
+@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
 def test_sbsaref_openbsd73_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
@@ -207,32 +210,66 @@ def test_sbsaref_openbsd73_cortex_a57(self):
 """
 self.boot_openbsd73("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(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_freebsd(self, cpu):
+self.fetch_firmware()
+
+img_url = (
+"https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/;
+"14.1/FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso"
+)
+
+img_hash = 
"44cdbae275ef1bb6dab1d5fbb59473d4f741e1c8ea8a80fd9e906b531d6ad461"
+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",
+)
+
+self.vm.launch()
+wait_for_console_pattern(self, "Welcome to FreeBSD!")
+
+def test_sbsaref_freebsd_cortex_a57(self):
 """
-:avocado: tags=cpu:neoverse-n1
-:avocado: tags=os:openbsd
+:avocado: tags=cpu:cortex-a57
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd("cortex-a57")
+
+# We use Neoverse-N2 as default cpu
+def test_sbsaref_freebsd_neoverse_n2(self):
 """
-self.boot_openbsd73("neoverse-n1")
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
+"""
+self.boot_freebsd("neoverse-n2")
 
-def test_sbsaref_openbsd73_max_pauth_off(self):
+def test_sbsaref_freebsd_max_pauth_off(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max,pauth=off")
+self.boot_freebsd("max,pauth=off")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max_pauth_impdef(self):
+def test_sbsaref_freebsd_max_pauth_impdef(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 

[PATCH v2 0/2] tests/avocado: updates for sbsa-ref testing

[Marcin Juszkiewicz]

We want to have some non-Linux OS in testing in case one of changes keep
Linux booting but crash elsewhere. So far OpenBSD was used for it but we
move to FreeBSD 14.x due to longer support cycles.

At same time we add test to run on default cpu settings. For now it is
plain Neoverse-N2 but we are considering either disabling PAuth or going
with 'impdef' way.

Signed-off-by: Marcin Juszkiewicz 

---
Marcin Juszkiewicz (2):
  tests/avocado: sbsa-ref: switch from OpenBSD to FreeBSD
  tests/avocado: add test for default sbsa-ref cpu

 tests/avocado/machine_aarch64_sbsaref.py | 72 +---
 1 file changed, 38 insertions(+), 34 deletions(-)
---
base-commit: c9ba79baca7c673098361e3a687f72d458e0d18a
change-id: 20240624-b4-move-to-freebsd-aafdeb75ef38

Best regards,
-- 
Marcin Juszkiewicz 

[PATCH v2 2/2] tests/avocado: add test for default sbsa-ref cpu

[Marcin Juszkiewicz]

We changed sbsa-ref cpu several times already and may do it again in a
future. To newer core or to enable/disable some properties.

This change switches Neoverse-N2 tests to 'let test default cpu' ones.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index d52f89f756..0e96e7ea16 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -115,7 +115,7 @@ def test_sbsaref_edk2_firmware(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_alpine_linux(self, cpu):
+def boot_alpine_linux(self, cpu=False):
 self.fetch_firmware()
 
 iso_url = (
@@ -128,12 +128,14 @@ def boot_alpine_linux(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={iso_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to Alpine Linux 3.17")
 
@@ -144,12 +146,12 @@ def test_sbsaref_alpine_linux_cortex_a57(self):
 """
 self.boot_alpine_linux("cortex-a57")
 
-def test_sbsaref_alpine_linux_neoverse_n1(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_alpine_linux_default(self):
 """
-:avocado: tags=cpu:neoverse-n1
 :avocado: tags=os:linux
 """
-self.boot_alpine_linux("neoverse-n1")
+self.boot_alpine_linux()
 
 def test_sbsaref_alpine_linux_max_pauth_off(self):
 """
@@ -178,7 +180,7 @@ 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_freebsd(self, cpu):
+def boot_freebsd(self, cpu=False):
 self.fetch_firmware()
 
 img_url = (
@@ -191,12 +193,14 @@ def boot_freebsd(self, cpu):
 
 self.vm.set_console()
 self.vm.add_args(
-"-cpu",
-cpu,
 "-drive",
 f"file={img_path},format=raw",
 )
 
+# let allow test which will use default cpu of platform
+if cpu:
+self.vm.add_args("-cpu", cpu)
+
 self.vm.launch()
 wait_for_console_pattern(self, "Welcome to FreeBSD!")
 
@@ -207,13 +211,12 @@ def test_sbsaref_freebsd_cortex_a57(self):
 """
 self.boot_freebsd("cortex-a57")
 
-# We use Neoverse-N2 as default cpu
-def test_sbsaref_freebsd_neoverse_n2(self):
+# Let test whichever cpu is used as default
+def test_sbsaref_freebsd_default(self):
 """
-:avocado: tags=cpu:neoverse-n2
 :avocado: tags=os:freebsd
 """
-self.boot_freebsd("neoverse-n2")
+self.boot_freebsd()
 
 def test_sbsaref_freebsd_max_pauth_off(self):
 """

-- 
2.45.2

[PATCH v2 1/2] 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.

Moved from Neoverse-N1 to Neoverse-N2 as sbsa-ref defaults were changed.

Timeout messages expanded to mention being affected by PAuth emulation:

test_sbsaref_alpine_linux_cortex_a57: PASS (24.00 s)
test_sbsaref_alpine_linux_neoverse_n2: PASS (82.24 s)
test_sbsaref_alpine_linux_max: PASS (81.10 s)
test_sbsaref_alpine_linux_max_pauth_off: PASS (23.54 s)
test_sbsaref_alpine_linux_max_pauth_impdef: PASS (28.96 s)

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 6bb82f2a03..d52f89f756 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é 
@@ -165,7 +165,8 @@ def test_sbsaref_alpine_linux_max_pauth_impdef(self):
 """
 self.boot_alpine_linux("max,pauth-impdef=on")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
+'Test might timeout due to PAuth emulation')
 def test_sbsaref_alpine_linux_max(self):
 """
 :avocado: tags=cpu:max
@@ -177,14 +178,15 @@ 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_freebsd(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.1/FreeBSD-14.1-RELEASE-arm64-aarch64-bootonly.iso"
 )
 
-img_hash = 
"7fc2c75401d6f01fbfa25f4953f72ad7d7c18650056d30755c44b9c129b707e5"
+img_hash = 
"44cdbae275ef1bb6dab1d5fbb59473d4f741e1c8ea8a80fd9e906b531d6ad461"
 img_path = self.fetch_asset(img_url, algorithm="sha256", 
asset_hash=img_hash)
 
 self.vm.set_console()
@@ -196,43 +198,42 @@ 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_freebsd_cortex_a57(self):
 """
 :avocado: tags=cpu:cortex-a57
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("cortex-a57")
+self.boot_freebsd("cortex-a57")
 
-def test_sbsaref_openbsd73_neoverse_n1(self):
+# We use Neoverse-N2 as default cpu
+def test_sbsaref_freebsd_neoverse_n2(self):
 """
-:avocado: tags=cpu:neoverse-n1
-:avocado: tags=os:openbsd
+:avocado: tags=cpu:neoverse-n2
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("neoverse-n1")
+self.boot_freebsd("neoverse-n2")
 
-def test_sbsaref_openbsd73_max_pauth_off(self):
+def test_sbsaref_freebsd_max_pauth_off(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max,pauth=off")
+self.boot_freebsd("max,pauth=off")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max_pauth_impdef(self):
+def test_sbsaref_freebsd_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_freebsd("max,pauth-impdef=on")
 
-@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
-def test_sbsaref_openbsd73_max(self):
+@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
+'Test might timeout due to PAuth emulation')
+def test_sbsaref_freebsd_max(self):
 """
 :avocado: tags=cpu:max
-:avocado: tags=os:openbsd
+:avocado: tags=os:freebsd
 """
-self.boot_openbsd73("max")
+self.boot_freebsd("max")

-- 
2.45.2

[PATCH v3 2/2] tests/avocado: use default amount of cores on sbsa-ref

[Marcin Juszkiewicz]

The version of the sbsa-ref EDK2 firmware we used to use in this test
had a bug where it might make an unaligned access to the framebuffer,
which causes a guest crash on newer versions of QEMU where we enforce
the architectural requirement that unaligned accesses to Device memory
should take an exception.

We happened to not notice this because our test was booting with "-smp
1" and through luck this didn't write the boot logo to the framebuffer
at an unaligned address; but trying to boot the same firmware with two
CPUs would result in a guest crash. Now we have updated the firmware
we're using for the test, we can make the test use all the cores on the
board, so we are testing the SMP boot path.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index e854ec6a1a..e920bbf08c 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -75,8 +75,6 @@ def fetch_firmware(self):
 f"if=pflash,file={fs0_path},format=raw",
 "-drive",
 f"if=pflash,file={fs1_path},format=raw",
-"-smp",
-"1",
 "-machine",
 "sbsa-ref",
 )

-- 
2.45.1

[PATCH v3 0/2] tests/avocado: make sbsa-ref working with >1 core

[Marcin Juszkiewicz]

Recent changes made sbsa-ref crash when more than 1 cpu core was used.
We handle it in firmware now so one patch updates it to the working
snapshot (TF-A 2.11 + EDK2 snapshot + EDK2-platforms snapshot).

Other change drops "-smp 1" from CI to make sure we test default setup
of sbsa-ref.

Previous firmware worked with 1 cpu by pure luck probably.

To: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org,
Cc: Peter Maydell ,
Cc: Leif Lindholm ,
Cc: Radoslaw Biernacki ,
Cc: Cleber Rosa ,
Cc: Philippe Mathieu-Daudé 
Cc: Wainer dos Santos Moschetta ,
Cc: Beraldo Leal ,
Cc: Ard Biesheuvel 
Cc: Rebecca Cran 

Signed-off-by: Marcin Juszkiewicz 
---
Changes in v3:
- first update firmware, then use all cores (for bisecting)
- changed commit message in 'use all cores' patch

---
Marcin Juszkiewicz (2):
  tests/avocado: update firmware for sbsa-ref
  tests/avocado: use default amount of cores on sbsa-ref

 tests/avocado/machine_aarch64_sbsaref.py | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)
---
base-commit: 02d9c38236cf8c9826e5c5be61780ccb4ae0
change-id: 20240620-b4-new-firmware-177daccc9d76

Best regards,
-- 
Marcin Juszkiewicz 

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

[Marcin Juszkiewicz]

Update firmware to have graphics card memory fix from EDK2 commit
c1d1910be6e04a8b1a73090cf2881fb698947a6e:

OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C

Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
tolerate misaligned accesses to normal memory, and raise alignment
faults on such accesses to device memory, which is the default for PCIe
MMIO BARs.

When emulating a PCIe graphics controller, the framebuffer is typically
exposed via a MMIO BAR, while the disposition of the region is closer to
memory (no side effects on reads or writes, except for the changing
picture on the screen; direct random access to any pixel in the image).

In order to permit the use of such controllers on platforms that only
tolerate these types of accesses for normal memory, it is necessary to
remap the memory. Use the DXE services to set the desired capabilities
and attributes.

Hide this behavior under a feature PCD so only platforms that really
need it can enable it. (OVMF on x86 has no need for this)

With this fix enabled we can boot sbsa-ref with more than one cpu core.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 6bb82f2a03..e854ec6a1a 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.11.0
-- Tianocore EDK2 stable202405
-- Tianocore EDK2-platforms commit 4bbd0ed
+- Trusted Firmware v2.11.0
+- Tianocore EDK2   4d4f569924
+- Tianocore EDK2-platforms 3f08401
 
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
 "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
-"20240528-140808/edk2/SBSA_FLASH0.fd.xz"
+"20240619-148232/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = 
"fa6004900b67172914c908b78557fec4d36a5f784f4c3dd08f49adb75e1892a9"
+fs0_xz_hash = 
"0c954842a590988f526984de22e21ae0ab9cb351a0c99a8a58e928f0c7359cf7"
 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/;
-"20240528-140808/edk2/SBSA_FLASH1.fd.xz"
+"20240619-148232/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = 
"5f3747d4000bc416d9641e33ff4ac60c3cc8cb74ca51b6e932e58531c62eb6f7"
+fs1_xz_hash = 
"c6ec39374c4d79bb9e9cdeeb6db44732d90bb4a334cec92002b3f4b9cac4b5ee"
 tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
   algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)

-- 
2.45.1

Re: [PATCH v2 1/2] tests/avocado: use default amount of cores on sbsa-ref

[Marcin Juszkiewicz]

W dniu 20.06.2024 o 11:34, Peter Maydell pisze:
On Thu, 20 Jun 2024 at 07:00, Marcin Juszkiewicz 
 wrote:


I was wondering why avocado tests passed with firmware which
crashes when anyone else is using it.

Turned out that amount of cores matters. Have to find out why
still.


This commit message confuses me.


Had no idea how to write in more readable form. Will reword it for v3 
(with reverse order of patches as recommended by Philippe.



It reads like "running with two cores will make the guest crash",
i.e. "apply this patch and the test suite will stop passing". I
assume that's not the case, but what's actually going on here?


That's exactly the case. With sbsa-ref firmware which qemu uses now we 
have crash if more than 1 core is used. Avocado test hardcoded "-smp 1" 
and was passing fine.


And I forgot to mail qemu-devel when I got hit by that crash.

This week Rebecca Cran pointed me that crash is in BootLogoLib in EDK2 
and I wrote some workaround for make things work. Then Ard Biesheuvel 
found the real reason, fixed QemuVideoDxe in EDK2 and we got sbsa-ref 
running with any amount of cores.


The commit message of fix:

commit c1d1910be6e04a8b1a73090cf2881fb698947a6e
Author: Ard Biesheuvel 
Date:   Mon Jun 17 17:07:41 2024 +0200

OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C

Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
tolerate misaligned accesses to normal memory, and raise alignment
faults on such accesses to device memory, which is the default for PCIe
MMIO BARs.

When emulating a PCIe graphics controller, the framebuffer is typically
exposed via a MMIO BAR, while the disposition of the region is closer to
memory (no side effects on reads or writes, except for the changing
picture on the screen; direct random access to any pixel in the image).

In order to permit the use of such controllers on platforms that only
tolerate these types of accesses for normal memory, it is necessary to
remap the memory. Use the DXE services to set the desired capabilities
and attributes.

Hide this behavior under a feature PCD so only platforms that really
need it can enable it. (OVMF on x86 has no need for this)

[PATCH v2 0/2] tests/avocado: make sbsa-ref working with >1 core

[Marcin Juszkiewicz]

Recent changes made sbsa-ref crash when more than 1 cpu core was used.
We handle it in firmware now so one patch updates it to the working
snapshot (TF-A 2.11 + EDK2 snapshot + EDK2-platforms snapshot).

Other change drops "-smp 1" from CI to make sure we test default setup
of sbsa-ref.

I have no idea why previous firmware worked with 1 cpu core and failed
with any higher number.


Marcin Juszkiewicz (2):
  tests/avocado: use default amount of cores on sbsa-ref
  tests/avocado: update firmware for sbsa-ref

 tests/avocado/machine_aarch64_sbsaref.py | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

-- 
2.45.1

[PATCH v2 1/2] tests/avocado: use default amount of cores on sbsa-ref

[Marcin Juszkiewicz]

I was wondering why avocado tests passed with firmware which crashes
when anyone else is using it.

Turned out that amount of cores matters. Have to find out why still.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 6bb82f2a03..136b495096 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -75,8 +75,6 @@ def fetch_firmware(self):
 f"if=pflash,file={fs0_path},format=raw",
 "-drive",
 f"if=pflash,file={fs1_path},format=raw",
-"-smp",
-"1",
 "-machine",
 "sbsa-ref",
 )
-- 
2.45.1

[PATCH v2 2/2] tests/avocado: update firmware for sbsa-ref

[Marcin Juszkiewicz]

Update firmware to have graphics card memory fix from EDK2 commit
c1d1910be6e04a8b1a73090cf2881fb698947a6e:

OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C

Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
tolerate misaligned accesses to normal memory, and raise alignment
faults on such accesses to device memory, which is the default for PCIe
MMIO BARs.

When emulating a PCIe graphics controller, the framebuffer is typically
exposed via a MMIO BAR, while the disposition of the region is closer to
memory (no side effects on reads or writes, except for the changing
picture on the screen; direct random access to any pixel in the image).

In order to permit the use of such controllers on platforms that only
tolerate these types of accesses for normal memory, it is necessary to
remap the memory. Use the DXE services to set the desired capabilities
and attributes.

Hide this behavior under a feature PCD so only platforms that really
need it can enable it. (OVMF on x86 has no need for this)

With this fix enabled we can boot sbsa-ref with more than one cpu core.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 136b495096..e920bbf08c 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.11.0
-- Tianocore EDK2 stable202405
-- Tianocore EDK2-platforms commit 4bbd0ed
+- Trusted Firmware v2.11.0
+- Tianocore EDK2   4d4f569924
+- Tianocore EDK2-platforms 3f08401
 
 """
 
 # Secure BootRom (TF-A code)
 fs0_xz_url = (
 "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/;
-"20240528-140808/edk2/SBSA_FLASH0.fd.xz"
+"20240619-148232/edk2/SBSA_FLASH0.fd.xz"
 )
-fs0_xz_hash = 
"fa6004900b67172914c908b78557fec4d36a5f784f4c3dd08f49adb75e1892a9"
+fs0_xz_hash = 
"0c954842a590988f526984de22e21ae0ab9cb351a0c99a8a58e928f0c7359cf7"
 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/;
-"20240528-140808/edk2/SBSA_FLASH1.fd.xz"
+"20240619-148232/edk2/SBSA_FLASH1.fd.xz"
 )
-fs1_xz_hash = 
"5f3747d4000bc416d9641e33ff4ac60c3cc8cb74ca51b6e932e58531c62eb6f7"
+fs1_xz_hash = 
"c6ec39374c4d79bb9e9cdeeb6db44732d90bb4a334cec92002b3f4b9cac4b5ee"
 tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
   algorithm='sha256')
 archive.extract(tar_xz_path, self.workdir)
-- 
2.45.1

[PATCH 1/1] tests/avocado: use default amount of cores on sbsa-ref

[Marcin Juszkiewicz]

I was wondering why avocado tests passed with firmware which crashes
when anyone else is using it.

Turned out that amount of cores matters. Have to find out why still.

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

diff --git a/tests/avocado/machine_aarch64_sbsaref.py 
b/tests/avocado/machine_aarch64_sbsaref.py
index 6bb82f2a03..136b495096 100644
--- a/tests/avocado/machine_aarch64_sbsaref.py
+++ b/tests/avocado/machine_aarch64_sbsaref.py
@@ -75,8 +75,6 @@ def fetch_firmware(self):
 f"if=pflash,file={fs0_path},format=raw",
 "-drive",
 f"if=pflash,file={fs1_path},format=raw",
-"-smp",
-"1",
 "-machine",
 "sbsa-ref",
 )
-- 
2.45.1

Re: [PATCH 1/1] BootLogoLib: align logo coords to be even

[Marcin Juszkiewicz]

W dniu 17.06.2024 o 10:39, Ard Biesheuvel pisze:

If we draw logo at odd coords then BootLogoLib goes into exception and
boot process ends:

Synchronous Exception at 0x0101FB943E48
PC 0x0101FB943E48 (0x0101FB93F000+0x4E48) [ 0] QemuVideoDxe.dll
PC 0x0101FB943314 (0x0101FB93F000+0x4314) [ 0] QemuVideoDxe.dll
PC 0x0101FB92F798 (0x0101FB92D000+0x2798) [ 1] ConSplitterDxe.dll
PC 0x0101FBA96BC4 (0x0101FBA8E000+0x8BC4) [ 2] BdsDxe.dll
PC 0x0101FF7FDF50 (0x0101FF7F3000+0xAF50) [ 3] DxeCore.dll

This change resizes logo from 193x58 to 194x58px to make it's sizes
even. And if coords are odd then they are bumped a bit to make things
work.

Signed-off-by: Marcin Juszkiewicz



This should be fixed in the SBSA firmware


One coffee was not enough so I sent it to QEMU devel instead of EDK2 
devel mailing list...



unaligned accesses are fine on arm64 as long as they don't target
device memory. So this likely implies that the framebuffer is
mapped with device attributes while it should be mapped  > normal-non-cacheable.


OK, so need to go through QEMU source now.

[PATCH 1/1] BootLogoLib: align logo coords to be even

[Marcin Juszkiewicz]

If we draw logo at odd coords then BootLogoLib goes into exception and
boot process ends:

Synchronous Exception at 0x0101FB943E48
PC 0x0101FB943E48 (0x0101FB93F000+0x4E48) [ 0] QemuVideoDxe.dll
PC 0x0101FB943314 (0x0101FB93F000+0x4314) [ 0] QemuVideoDxe.dll
PC 0x0101FB92F798 (0x0101FB92D000+0x2798) [ 1] ConSplitterDxe.dll
PC 0x0101FBA96BC4 (0x0101FBA8E000+0x8BC4) [ 2] BdsDxe.dll
PC 0x0101FF7FDF50 (0x0101FF7F3000+0xAF50) [ 3] DxeCore.dll

This change resizes logo from 193x58 to 194x58px to make it's sizes
even. And if coords are odd then they are bumped a bit to make things
work.

Signed-off-by: Marcin Juszkiewicz 
---
 .../Library/BootLogoLib/BootLogoLib.c |   4 
 MdeModulePkg/Logo/Logo.bmp| Bin 12446 -> 34010 bytes
 2 files changed, 4 insertions(+)

diff --git a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c 
b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
index 478ec2d40e2b..3b7b5f3146e8 100644
--- a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
+++ b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
@@ -205,6 +205,10 @@ BootLogoEnableLogo (
 DestX += OffsetX;
 DestY += OffsetY;
 
+// align logo to even coords
+if (DestX % 2 != 0) DestX++;
+if (DestY % 2 != 0) DestY++;
+
 if ((DestX >= 0) && (DestY >= 0)) {
   if (GraphicsOutput != NULL) {
 Status = GraphicsOutput->Blt (
diff --git a/MdeModulePkg/Logo/Logo.bmp b/MdeModulePkg/Logo/Logo.bmp
index 
3e85229e17595ba1f9c59e13692a4f8362ebc850..136345a56ac44e3ea8d3c91114b5a2676dc90e2a
 100644
GIT binary patch
literal 34010
zcmeHw2Urx>{`QJkDYhh<+$5TAjK*9|ZepcbLBvJ}K|pM%bfq^bf>JDq1rVgFV8H?c
z(!>HvRq1W%EMT=2*>w$T-IFFJqiX)s}<8rXZmFnXouoYqu2>1g2SWPGtBA6)<3Iu~#a|9NV$MPE%F#(nVK;OzOEG
zbNRfJ^#x~}2p3zaW+%48lon?uUrUdRPLGd%d@~^S*h3Blfhn_I9@Sb$9l5
zw@sjnC(ESWNtFgMiN$3I%`FNsD>J
zW-^cOR9BlZMQ!FpW%-FpauczRtdiVdf7@4cNbRjx{oD_)|KrHURo0tUEn!dB>gBKmrEXw-K{Nc^)(ew^U4Zx
z%AY_h%6w3gmnG_FJ$#mN?^VttYF{s%Lg{E~AlB8i*4Gg0s$1)8+8XLg^0JDu9yYu#
zZ*8b;sjZ@s2lzZ5lTKq$DGVBQq()=Vs9X+PB3%Dx!C|v%OJ8=k691}iV30=)2d#DM
zX3DOcHDTSX32L(@teY+BsLh(7qDWAiHDU9-DLrk(xF8=J4JBI*B|A;!(OOR%@p;C*
zXkWLhzOFI;?(eq55dSM)$GeFw-K{N^>59*bIj_F%u@acO>bX
z$O9ZU3$u7a9+%7K@pxP=n*~yZSza!e|19d>&6I5b(GhHj~NYas|-m;>MTHgASj^
z!?%1M55E*J#O30Bfk43Li4HD+7hvK=TX+lh67cz44hN3J<-i<)fWv07Sxhd6jh_i_
zwYh9Io5hrTicl!zayV=zgUw`eIU>gZ8-epg2tJy_2EPLHK)7rs1Dht`aX9$-<2&~E
zbe%tTB>P4Jo5jTc5FVE+6bkTT!es0`VKSR76bj+b;qwFn(F6{g#p80MIXK88rjzz&
zWqDbgL8^)b;L+^CUdQCG6v@>Z!*~<`swCYKL;SA=dPSdb>1iW&
zw-GC!N%2TRC~-%^qmHJAjD%>vy++4(%xEHBJUJ`;3E?H`Ui)?W+st|={ko^k(z
zi|rLJr<&52=?PbhA7_*mZM
zckqmZ)wA@prw{KWg$ATWU3l^6ersLL!)uX2R%SV=NzK)-^KM_SuPCj0`Jx~#wYsFJ
z@c!-EvX?I&-7m^~fU~l!;BjthGKU2uZEL7~l9pPO`5-qnxw-mHU3p1PYGQ5K%be6C
zVr^C7{oAi{vnroINeK@rdy;cED!iro4Y9WBqMLoF?f!(*zB#GMS=Zy}6mm}+G5(Zq
znEk;QkM0WvV1vk{p45miUkm*ZoBcP>2a|hA1K7yvBNkcLuxgQh7FpT81znb~WpMY!6%d0zM`=TS~dQcrtp
zYDDNjPxqb3@TRKDrw{K0TknfM?bqAYk$3xg#nb$j+Nzu9Pm?;@F1kAu-oGtjH$qZ8
z0zH!O2viBsh#AY%|a99jw;<5n^L`Y{!Pn9>?4av@Ur#`s~q7
z3Ojl7fXRc{D~}Rm^7VdGQn>R9F7$X%*_@3P0Sg0$4^8wppuoO4r?F1b5o
zBwS4n3rYzO1r^})QzOF89XrCHQV~Msh4~R~_AvpT5w3RSPjYiolY)=#*d!#@_0A
zMq1Pfm&6eNXkQPrKYj_bJ7B(Iar`OYJ6FzIZ(bAOW`9uix62;Kf{$7@SG~Cx9bvy!
zH90KM&%_T33DYfJuzMM@e3G;6anKj#k+>;*V}xm3r~a2{XN_m(McdV|IQ2
zWoB}0)vFf=Re!sAKG@g7;6dz_Q->{5E`)j*ZI3?T;%lKF;bM2j{*axfN?eeSv$lGa
zk8`+_bzOOhi|&^8#(Kx?8y+Rb9Nw@ZIV{lELO(4kBE))MdVF+QL5}0L^{;Xs9Z>nT
zi`b0+B5@4r5yNr~~giUbw09!c{^WYFsN8Q=KrogXwWm)g{H<#O4dmw$}o^!=0=hx34q#
z^@pngo)K>LX;Bx_nQCWW2sZX?F{d-z!zM!4D)-oKrFGa<&`qwwCXXg{~C
z>(>%a`(8hL3fH5%k>P;{O>0YE(#ZYgg?Sg<>|^}hBV6oC^0IPLlR|CxKe>17tb-Ny
z^YT4+>`2fd(>?$A(PHHilV86Nv9`=gzIJ@qCVMSa+bzm50UlxY2i_Jx3$s6Hv2sb^
z0h8dPd)pi95kkbe>QLJQ**D^aLScDfzO=OXi>4zdK;R@soS0rw?1$s4In7
zTV}*Z>;3da;6YP=OGE73_9TU#bkWu5A~t1Rzvi@SQ>g9!^!VtGrg|H7rGWjrBV6t4
zE6R@T*x1q3;AWr|8|Y=e;wN7V18-C9TNlrsaj?1{bGbAx+ev#%;r(0A+UhI@V`RI=
zu-~dSwjOPrKeMO3^-uE%GiqSVPI^hJQnart*tKE)k=UF`I$|ENFSyv8b+oE3DeCQP
zFUoxAZlL9=ztwU3#=BR-PnhYRI&9{kr51ncgpZl-WshUdI_g)vjz^tv4YAo*T~dS)
zsx5ovVZ8nH5sL^ndoPn+j}l@odmK*)_P=rN^tB)#Y`#;d?fz?l-pOZ9h1woGWn~`j
zZ1X57Hq8Fu6|duAwg-|zPo{*2o<3}m7~=1@*C5)@?Xss+YQ$MFkIq}HT;i;wan;{5
zJw7_p+bJf%^W*`OTNlr!TnKg5)4X{;_=LIst&3+c=5FxYYk0}yxZ%=og01(RJ9aqs
zq*tVmOWdgw9!A?Qdmi`Mqnnj{Ez;ZB-C$e%XW$uPr
z=Nzr9H?K~My5P8deQbcI@Ji804_Zb}RZuvTAt`|>##UCqSMfZ(Hhlg|V>>!?3{
za68i5$$y{m>7#p39X5ZJn`xuIHr(0TRe$S~d$$fKFMpn%W~ZrgFFL|%-R~(ELcL6P
zT?_OIv9`S6Vw;h0)qbn$qr@0n4Q1Lu|7bkYQd65L3raL=&@GZUO6z9-IX#ltHJm%K
z0UpDsB;rvU@wK#{JqnLFZ07x#OD?(^1!<|hT^_$Qkv`5|CcE}4E%P${
zxpnc(33GjS!)+-MVFErMcvM>ze01-lq!=chmUTVONn5?9^yTTp=Erw#iaqIFl=(3J
zly7fmd-9pU{JS?Vy4l-rRSkEtt}QPKJhUhGR{CqMfFSzok)4X>n>qnB%tfF1lN8
zUpo8p@go;q4aaTkeJu<;ckc+c-rLjOnh@+~ucdbK!0yhL#s;Ycb^t9o1IkB!9vQb@~y`3FQ8kI=xJ~3X(Lhx`k8dd
zE7g^k_?qi`n(R7t*xb*;ASWd;!qqM_DOSMeLp(^Ouo#Sl;DF5JxV+mpj&53g1zADu#`k^A

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

[Marcin Juszkiewicz]

W dniu 7.06.2024 o 12:38, 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 /cpus/topology
Device Tree.

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


Reviewed-by: Marcin Juszkiewicz 

[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.