[PATCH 0/6] target/arm: Fix functional test failures in KVM-only builds

[PATCH 0/6] target/arm: Fix functional test failures in KVM-only builds

[Peter Maydell]

If you build QEMU with --disable-tcg on an AArch64 system, some of the
"make check-functional" tests fail. This patchset fixes them.

The first patch fixes a bug in QEMU proper, where we broke the
"x-remote" machine because we forgot to mark it up as being
OK to expose in the qemu-system-arm and qemu-system-aarch64
binaries, the way we do for "none" and for all the actual Arm
machine types.

The rest are tweaks to the tests:
 * tests that run '-machine virt,virtualization=on' need to
   check for failure because the machine reports that the hypervisor
   can't support nested virt
 * tests that use a specific CPU type need to either be
   restricted to TCG-only, or else changed to use 'max' instead
   (since that's the only CPU that will work on both TCG and KVM)

thanks
-- PMM

Peter Maydell (6):
  hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and
    AArch32
  tests/functional/test_virt_vbsa: Skip UEFI test if virtualization not
    supported
  tests/functional/test_kvm.py: Use -cpu max, not cortex-a72
  tests/functional/test_kvm.py: Skip if virtualization not supported
  tests/functional/test_hotplug_pci.py: Require TCG
  tests/functional/test_tuxrun: Restrict to TCG

 hw/remote/machine.c                          |  3 +++
 tests/functional/aarch64/test_hotplug_pci.py |  1 +
 tests/functional/aarch64/test_kvm.py         | 12 ++++++++++--
 tests/functional/aarch64/test_tuxrun.py      |  2 ++
 tests/functional/aarch64/test_virt_vbsa.py   | 10 +++++++++-
 5 files changed, 25 insertions(+), 3 deletions(-)

-- 
2.43.0

[PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32

[Peter Maydell]

When we updated Arm and AArch64 board types to mark them for the
target_machine_typename() filter, we forgot about the "x-remote"
machine type, which meant that it disappeared from the set of board
types exposed on the qemu-system-arm and qemu-system-aarch64
binaries.  We didn't notice this, because although we have a
functional test for it, it requires the KVM accelerator and we don't
run the functional tests on an AArch64 host in CI.

Mark the machine as being OK to expose in qemu-system-arm and
qemu-system-aarch64, in the same way we do for the "none" machine
type. This fixes a check-functional failure on aarch64 host, where
it would otherwise fail with:
   qemu-system-aarch64: unsupported machine type: "x-remote"

Cc: qemu-stable@nongnu.org
Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
I couldn't figure out which git commit started enforcing the
filtering of machine types based on the TARGET_FOO_MACHINE
interface markings, so I picked the Fixes: commit hash for when
we added them to the "none" machine, on the basis that that's
the point at which we logically ought to have also done x-remote.
---
 hw/remote/machine.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/remote/machine.c b/hw/remote/machine.c
index ced782f6a9..df08f64019 100644
--- a/hw/remote/machine.c
+++ b/hw/remote/machine.c
@@ -24,6 +24,7 @@
 #include "hw/core/qdev.h"
 #include "hw/remote/vfio-user-obj.h"
 #include "hw/pci/msi.h"
+#include "hw/arm/machines-qom.h"
 
 static void remote_machine_init(MachineState *machine)
 {
@@ -148,6 +149,8 @@ static const TypeInfo remote_machine = {
     .class_init = remote_machine_class_init,
     .interfaces = (const InterfaceInfo[]) {
         { TYPE_HOTPLUG_HANDLER },
+        { TYPE_TARGET_AARCH64_MACHINE },
+        { TYPE_TARGET_ARM_MACHINE },
         { }
     }
 };
-- 
2.43.0

[PATCH 2/6] tests/functional/test_virt_vbsa: Skip UEFI test if virtualization not supported

[Peter Maydell]

If you try to run the functional tests on an AArch64 host which doesn't
support nested virtualization in KVM, the UEFI test fails with:

   Output: qemu-system-aarch64: mach-virt: host kernel KVM does
   not support providing Virtualization extensions to the guest CPU

Catch the VMLaunchFailure exception and if it matches the error
messages the virt board puts out for virtualization not being
supported, skip the test.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/functional/aarch64/test_virt_vbsa.py | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tests/functional/aarch64/test_virt_vbsa.py b/tests/functional/aarch64/test_virt_vbsa.py
index 57bfe5d7af..04b5ff0f9e 100755
--- a/tests/functional/aarch64/test_virt_vbsa.py
+++ b/tests/functional/aarch64/test_virt_vbsa.py
@@ -17,6 +17,7 @@
 from qemu_test import get_qemu_img, skipIfMissingCommands
 from qemu_test import wait_for_console_pattern
 from qemu_test import exec_command_and_wait_for_pattern as ec_and_wait
+from qemu.machine.machine import VMLaunchFailure
 
 
 @skipIfMissingCommands("mformat", "mcopy", "mmd")
@@ -96,7 +97,14 @@ def test_aarch64_vbsa_uefi_tests(self):
                          f'file={img_path},format=raw,if=none,id=drive0')
         self.vm.add_args('-device', 'virtio-blk-pci,drive=drive0')
 
-        self.vm.launch()
+        try:
+            self.vm.launch()
+        except VMLaunchFailure as excp:
+            if "does not support providing Virtualization" in excp.output:
+                self.skipTest("accelerator has no virtualization support")
+            else:
+                self.log.info("unhandled launch failure: %s", excp.output)
+                raise excp
 
         # wait for EFI prompt
         self.wait_for_console_pattern('Shell>')
-- 
2.43.0

[PATCH 3/6] tests/functional/test_kvm.py: Use -cpu max, not cortex-a72

[Peter Maydell]

The test_kvm test claims to run on any accelerator supporting
nested virtualization, but it specifies the cortex-a72 CPU.
This doesn't exist for KVM-only builds. Use max instead.

This fixes a failure like
  Output: qemu-system-aarch64: unable to find CPU model 'cortex-a72'

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/functional/aarch64/test_kvm.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/functional/aarch64/test_kvm.py b/tests/functional/aarch64/test_kvm.py
index 7545f5ed55..fed18aba60 100755
--- a/tests/functional/aarch64/test_kvm.py
+++ b/tests/functional/aarch64/test_kvm.py
@@ -38,7 +38,7 @@ def _launch_guest(self, kvm_mode="nvhe"):
         kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
                                f"console=ttyAMA0 kvm-arm.mode={kvm_mode}")
 
-        self.vm.add_args("-cpu", "cortex-a72")
+        self.vm.add_args("-cpu", "max")
         self.vm.add_args("-machine", "virt,gic-version=3,virtualization=on",
                          '-kernel', kernel_path,
                          '-append', kernel_command_line)
-- 
2.43.0

[PATCH 4/6] tests/functional/test_kvm.py: Skip if virtualization not supported

[Peter Maydell]

The test_kvm test runs the virt board with virtualization=on,
which will fail if run with an accelerator that doesn't
support nested virtualization. Catch the VMLaunchFailure
exception and skip the test if startup failed because
the accelerator can't support virtualization.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/functional/aarch64/test_kvm.py | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tests/functional/aarch64/test_kvm.py b/tests/functional/aarch64/test_kvm.py
index fed18aba60..c977e8c6d2 100755
--- a/tests/functional/aarch64/test_kvm.py
+++ b/tests/functional/aarch64/test_kvm.py
@@ -14,6 +14,7 @@
 from qemu_test import Asset
 from qemu_test import exec_command_and_wait_for_pattern as ec_and_wait
 from qemu_test.linuxkernel import LinuxKernelTest
+from qemu.machine.machine import VMLaunchFailure
 
 
 class Aarch64VirtKVMTests(LinuxKernelTest):
@@ -44,7 +45,14 @@ def _launch_guest(self, kvm_mode="nvhe"):
                          '-append', kernel_command_line)
         self.vm.add_args("-smp", "2", "-m", "320")
 
-        self.vm.launch()
+        try:
+            self.vm.launch()
+        except VMLaunchFailure as excp:
+            if "does not support providing Virtualization" in excp.output:
+                self.skipTest("accelerator has no virtualization support")
+            else:
+                self.log.info("unhandled launch failure: %s", excp.output)
+                raise excp
 
         self.wait_for_console_pattern('buildroot login:')
         ec_and_wait(self, 'root', '#')
-- 
2.43.0

[PATCH 5/6] tests/functional/test_hotplug_pci.py: Require TCG

[Peter Maydell]

The hotplug test asks for the cortex-a57 CPU type, so it will
fail on an AArch64 system using KVM where TCG is not compiled
into QEMU and the default accelerator is KVM:

   Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Restrict it to the TCG accelerator.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/functional/aarch64/test_hotplug_pci.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/functional/aarch64/test_hotplug_pci.py b/tests/functional/aarch64/test_hotplug_pci.py
index bf67720431..9ee1446a83 100755
--- a/tests/functional/aarch64/test_hotplug_pci.py
+++ b/tests/functional/aarch64/test_hotplug_pci.py
@@ -27,6 +27,7 @@ class HotplugPCI(LinuxKernelTest):
     def test_hotplug_pci(self):
 
         self.set_machine('virt')
+        self.require_accelerator('tcg')
 
         self.vm.add_args('-m', '512M',
                          '-cpu', 'cortex-a57',
-- 
2.43.0

[PATCH 6/6] tests/functional/test_tuxrun: Restrict to TCG

[Peter Maydell]

The tuxrun tests specify the cortex-a57 CPU; this doesn't work on a
KVM-only QEMU build, where the default accelerator is KVM but KVM
doesn't support that CPU type.  Restrict the test to TCG, to avoid
failures on KVM-only AArch64 builds:
        Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 tests/functional/aarch64/test_tuxrun.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/functional/aarch64/test_tuxrun.py b/tests/functional/aarch64/test_tuxrun.py
index 75adc8acb8..7dd50c3de1 100755
--- a/tests/functional/aarch64/test_tuxrun.py
+++ b/tests/functional/aarch64/test_tuxrun.py
@@ -25,6 +25,7 @@ class TuxRunAarch64Test(TuxRunBaselineTest):
 
     def test_arm64(self):
         self.set_machine('virt')
+        self.require_accelerator('tcg')
         self.cpu='cortex-a57'
         self.console='ttyAMA0'
         self.wait_for_shutdown=False
@@ -40,6 +41,7 @@ def test_arm64(self):
 
     def test_arm64be(self):
         self.set_machine('virt')
+        self.require_accelerator('tcg')
         self.cpu='cortex-a57'
         self.console='ttyAMA0'
         self.wait_for_shutdown=False
-- 
2.43.0

Re: [PATCH 0/6] target/arm: Fix functional test failures in KVM-only builds

[Pierrick Bouvier]

On 5/7/2026 12:47 PM, Peter Maydell wrote:
> If you build QEMU with --disable-tcg on an AArch64 system, some of the
> "make check-functional" tests fail. This patchset fixes them.
> 
> The first patch fixes a bug in QEMU proper, where we broke the
> "x-remote" machine because we forgot to mark it up as being
> OK to expose in the qemu-system-arm and qemu-system-aarch64
> binaries, the way we do for "none" and for all the actual Arm
> machine types.
> 
> The rest are tweaks to the tests:
>  * tests that run '-machine virt,virtualization=on' need to
>    check for failure because the machine reports that the hypervisor
>    can't support nested virt
>  * tests that use a specific CPU type need to either be
>    restricted to TCG-only, or else changed to use 'max' instead
>    (since that's the only CPU that will work on both TCG and KVM)
> 
> thanks
> -- PMM
> 
> Peter Maydell (6):
>   hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and
>     AArch32
>   tests/functional/test_virt_vbsa: Skip UEFI test if virtualization not
>     supported
>   tests/functional/test_kvm.py: Use -cpu max, not cortex-a72
>   tests/functional/test_kvm.py: Skip if virtualization not supported
>   tests/functional/test_hotplug_pci.py: Require TCG
>   tests/functional/test_tuxrun: Restrict to TCG
> 
>  hw/remote/machine.c                          |  3 +++
>  tests/functional/aarch64/test_hotplug_pci.py |  1 +
>  tests/functional/aarch64/test_kvm.py         | 12 ++++++++++--
>  tests/functional/aarch64/test_tuxrun.py      |  2 ++
>  tests/functional/aarch64/test_virt_vbsa.py   | 10 +++++++++-
>  5 files changed, 25 insertions(+), 3 deletions(-)
> 

For series:
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

Re: [PATCH 5/6] tests/functional/test_hotplug_pci.py: Require TCG

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> The hotplug test asks for the cortex-a57 CPU type, so it will
> fail on an AArch64 system using KVM where TCG is not compiled
> into QEMU and the default accelerator is KVM:
> 
>     Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
> 
> Restrict it to the TCG accelerator.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_hotplug_pci.py | 1 +
>   1 file changed, 1 insertion(+)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 6/6] tests/functional/test_tuxrun: Restrict to TCG

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> The tuxrun tests specify the cortex-a57 CPU; this doesn't work on a
> KVM-only QEMU build, where the default accelerator is KVM but KVM
> doesn't support that CPU type.  Restrict the test to TCG, to avoid
> failures on KVM-only AArch64 builds:
>          Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_tuxrun.py | 2 ++
>   1 file changed, 2 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> When we updated Arm and AArch64 board types to mark them for the
> target_machine_typename() filter, we forgot about the "x-remote"
> machine type, which meant that it disappeared from the set of board
> types exposed on the qemu-system-arm and qemu-system-aarch64
> binaries.  We didn't notice this, because although we have a
> functional test for it, it requires the KVM accelerator and we don't
> run the functional tests on an AArch64 host in CI.
> 
> Mark the machine as being OK to expose in qemu-system-arm and
> qemu-system-aarch64, in the same way we do for the "none" machine
> type. This fixes a check-functional failure on aarch64 host, where
> it would otherwise fail with:
>     qemu-system-aarch64: unsupported machine type: "x-remote"
> 
> Cc: qemu-stable@nongnu.org
> Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine")
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> I couldn't figure out which git commit started enforcing the
> filtering of machine types based on the TARGET_FOO_MACHINE
> interface markings, so I picked the Fixes: commit hash for when
> we added them to the "none" machine, on the basis that that's
> the point at which we logically ought to have also done x-remote.

Preliminary filtering commits:

28502121be7 ("system/vl: Filter machine list available for a particular 
target binary")
2c6fab1c143 ("hw/core: Filter machine list available for a particular 
target binary")

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 4/6] tests/functional/test_kvm.py: Skip if virtualization not supported

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> The test_kvm test runs the virt board with virtualization=on,
> which will fail if run with an accelerator that doesn't
> support nested virtualization. Catch the VMLaunchFailure
> exception and skip the test if startup failed because
> the accelerator can't support virtualization.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_kvm.py | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 2/6] tests/functional/test_virt_vbsa: Skip UEFI test if virtualization not supported

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> If you try to run the functional tests on an AArch64 host which doesn't
> support nested virtualization in KVM, the UEFI test fails with:
> 
>     Output: qemu-system-aarch64: mach-virt: host kernel KVM does
>     not support providing Virtualization extensions to the guest CPU
> 
> Catch the VMLaunchFailure exception and if it matches the error
> messages the virt board puts out for virtualization not being
> supported, skip the test.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_virt_vbsa.py | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 3/6] tests/functional/test_kvm.py: Use -cpu max, not cortex-a72

[Philippe Mathieu-Daudé]

On 7/5/26 21:47, Peter Maydell wrote:
> The test_kvm test claims to run on any accelerator supporting
> nested virtualization, but it specifies the cortex-a72 CPU.
> This doesn't exist for KVM-only builds. Use max instead.
> 
> This fixes a failure like
>    Output: qemu-system-aarch64: unable to find CPU model 'cortex-a72'
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_kvm.py | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 3/6] tests/functional/test_kvm.py: Use -cpu max, not cortex-a72

[Richard Henderson]

On 5/7/26 14:47, Peter Maydell wrote:
> The test_kvm test claims to run on any accelerator supporting
> nested virtualization, but it specifies the cortex-a72 CPU.
> This doesn't exist for KVM-only builds. Use max instead.
> 
> This fixes a failure like
>    Output: qemu-system-aarch64: unable to find CPU model 'cortex-a72'
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_kvm.py | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/functional/aarch64/test_kvm.py b/tests/functional/aarch64/test_kvm.py
> index 7545f5ed55..fed18aba60 100755
> --- a/tests/functional/aarch64/test_kvm.py
> +++ b/tests/functional/aarch64/test_kvm.py
> @@ -38,7 +38,7 @@ def _launch_guest(self, kvm_mode="nvhe"):
>           kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
>                                  f"console=ttyAMA0 kvm-arm.mode={kvm_mode}")
>   
> -        self.vm.add_args("-cpu", "cortex-a72")
> +        self.vm.add_args("-cpu", "max")
>           self.vm.add_args("-machine", "virt,gic-version=3,virtualization=on",
>                            '-kernel', kernel_path,
>                            '-append', kernel_command_line)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 4/6] tests/functional/test_kvm.py: Skip if virtualization not supported

[Richard Henderson]

On 5/7/26 14:47, Peter Maydell wrote:
> The test_kvm test runs the virt board with virtualization=on,
> which will fail if run with an accelerator that doesn't
> support nested virtualization. Catch the VMLaunchFailure
> exception and skip the test if startup failed because
> the accelerator can't support virtualization.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_kvm.py | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/functional/aarch64/test_kvm.py b/tests/functional/aarch64/test_kvm.py
> index fed18aba60..c977e8c6d2 100755
> --- a/tests/functional/aarch64/test_kvm.py
> +++ b/tests/functional/aarch64/test_kvm.py
> @@ -14,6 +14,7 @@
>   from qemu_test import Asset
>   from qemu_test import exec_command_and_wait_for_pattern as ec_and_wait
>   from qemu_test.linuxkernel import LinuxKernelTest
> +from qemu.machine.machine import VMLaunchFailure
>   
>   
>   class Aarch64VirtKVMTests(LinuxKernelTest):
> @@ -44,7 +45,14 @@ def _launch_guest(self, kvm_mode="nvhe"):
>                            '-append', kernel_command_line)
>           self.vm.add_args("-smp", "2", "-m", "320")
>   
> -        self.vm.launch()
> +        try:
> +            self.vm.launch()
> +        except VMLaunchFailure as excp:
> +            if "does not support providing Virtualization" in excp.output:
> +                self.skipTest("accelerator has no virtualization support")
> +            else:
> +                self.log.info("unhandled launch failure: %s", excp.output)
> +                raise excp
>   
>           self.wait_for_console_pattern('buildroot login:')
>           ec_and_wait(self, 'root', '#')

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 5/6] tests/functional/test_hotplug_pci.py: Require TCG

[Richard Henderson]

On 5/7/26 14:47, Peter Maydell wrote:
> The hotplug test asks for the cortex-a57 CPU type, so it will
> fail on an AArch64 system using KVM where TCG is not compiled
> into QEMU and the default accelerator is KVM:
> 
>     Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
> 
> Restrict it to the TCG accelerator.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_hotplug_pci.py | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/tests/functional/aarch64/test_hotplug_pci.py b/tests/functional/aarch64/test_hotplug_pci.py
> index bf67720431..9ee1446a83 100755
> --- a/tests/functional/aarch64/test_hotplug_pci.py
> +++ b/tests/functional/aarch64/test_hotplug_pci.py
> @@ -27,6 +27,7 @@ class HotplugPCI(LinuxKernelTest):
>       def test_hotplug_pci(self):
>   
>           self.set_machine('virt')
> +        self.require_accelerator('tcg')
>   
>           self.vm.add_args('-m', '512M',
>                            '-cpu', 'cortex-a57',

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 6/6] tests/functional/test_tuxrun: Restrict to TCG

[Richard Henderson]

On 5/7/26 14:47, Peter Maydell wrote:
> The tuxrun tests specify the cortex-a57 CPU; this doesn't work on a
> KVM-only QEMU build, where the default accelerator is KVM but KVM
> doesn't support that CPU type.  Restrict the test to TCG, to avoid
> failures on KVM-only AArch64 builds:
>          Output: qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   tests/functional/aarch64/test_tuxrun.py | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/tests/functional/aarch64/test_tuxrun.py b/tests/functional/aarch64/test_tuxrun.py
> index 75adc8acb8..7dd50c3de1 100755
> --- a/tests/functional/aarch64/test_tuxrun.py
> +++ b/tests/functional/aarch64/test_tuxrun.py
> @@ -25,6 +25,7 @@ class TuxRunAarch64Test(TuxRunBaselineTest):
>   
>       def test_arm64(self):
>           self.set_machine('virt')
> +        self.require_accelerator('tcg')
>           self.cpu='cortex-a57'
>           self.console='ttyAMA0'
>           self.wait_for_shutdown=False
> @@ -40,6 +41,7 @@ def test_arm64(self):
>   
>       def test_arm64be(self):
>           self.set_machine('virt')
> +        self.require_accelerator('tcg')
>           self.cpu='cortex-a57'
>           self.console='ttyAMA0'
>           self.wait_for_shutdown=False

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32

[Philippe Mathieu-Daudé]

+Stefan

On 7/5/26 21:47, Peter Maydell wrote:
> When we updated Arm and AArch64 board types to mark them for the
> target_machine_typename() filter, we forgot about the "x-remote"
> machine type, which meant that it disappeared from the set of board
> types exposed on the qemu-system-arm and qemu-system-aarch64
> binaries.  We didn't notice this, because although we have a
> functional test for it, it requires the KVM accelerator and we don't

I don't remember why it requires KVM.

$ git grep -i kvm hw/remote/
hw/remote/Kconfig:3:    depends on PCI && PCI_EXPRESS && KVM
hw/remote/proxy.c:36: 
kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state, &dev->intr, dev->virq);
hw/remote/proxy.c:45: 
kvm_irqchip_add_irqfd_notifier_gsi(kvm_state, &dev->intr,

I suppose these 2 calls should be replaced by generic equivalents:
- accel_irqchip_remove_irqfd_notifier_gsi()
- accel_irqchip_add_irqfd_notifier_gsi()

> run the functional tests on an AArch64 host in CI.
> 
> Mark the machine as being OK to expose in qemu-system-arm and

Otherwise if it is tied to KVM, we removed support for 32-bit ARM
KVM in commit 82bf7ae84ce; ...

> qemu-system-aarch64, in the same way we do for the "none" machine
> type. This fixes a check-functional failure on aarch64 host, where
> it would otherwise fail with:
>     qemu-system-aarch64: unsupported machine type: "x-remote"
> 
> Cc: qemu-stable@nongnu.org
> Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine")
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> I couldn't figure out which git commit started enforcing the
> filtering of machine types based on the TARGET_FOO_MACHINE
> interface markings, so I picked the Fixes: commit hash for when
> we added them to the "none" machine, on the basis that that's
> the point at which we logically ought to have also done x-remote.
> ---
>   hw/remote/machine.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/hw/remote/machine.c b/hw/remote/machine.c
> index ced782f6a9..df08f64019 100644
> --- a/hw/remote/machine.c
> +++ b/hw/remote/machine.c
> @@ -24,6 +24,7 @@
>   #include "hw/core/qdev.h"
>   #include "hw/remote/vfio-user-obj.h"
>   #include "hw/pci/msi.h"
> +#include "hw/arm/machines-qom.h"
>   
>   static void remote_machine_init(MachineState *machine)
>   {
> @@ -148,6 +149,8 @@ static const TypeInfo remote_machine = {
>       .class_init = remote_machine_class_init,
>       .interfaces = (const InterfaceInfo[]) {
>           { TYPE_HOTPLUG_HANDLER },
> +        { TYPE_TARGET_AARCH64_MACHINE },
> +        { TYPE_TARGET_ARM_MACHINE },

... so exposing this machine on 32-bit host binary doesn't
look right.

>           { }
>       }
>   };

Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32

[Pierrick Bouvier]

On 7/20/2026 5:39 AM, Philippe Mathieu-Daudé wrote:
> +Stefan
> 
> On 7/5/26 21:47, Peter Maydell wrote:
>> When we updated Arm and AArch64 board types to mark them for the
>> target_machine_typename() filter, we forgot about the "x-remote"
>> machine type, which meant that it disappeared from the set of board
>> types exposed on the qemu-system-arm and qemu-system-aarch64
>> binaries.  We didn't notice this, because although we have a
>> functional test for it, it requires the KVM accelerator and we don't
> 
> I don't remember why it requires KVM.
> 
> $ git grep -i kvm hw/remote/
> hw/remote/Kconfig:3:    depends on PCI && PCI_EXPRESS && KVM
> hw/remote/proxy.c:36: kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state,
> &dev->intr, dev->virq);
> hw/remote/proxy.c:45: kvm_irqchip_add_irqfd_notifier_gsi(kvm_state,
> &dev->intr,
> 
> I suppose these 2 calls should be replaced by generic equivalents:
> - accel_irqchip_remove_irqfd_notifier_gsi()
> - accel_irqchip_add_irqfd_notifier_gsi()
> 
>> run the functional tests on an AArch64 host in CI.
>>
>> Mark the machine as being OK to expose in qemu-system-arm and
> 
> Otherwise if it is tied to KVM, we removed support for 32-bit ARM
> KVM in commit 82bf7ae84ce; ...
> 
>> qemu-system-aarch64, in the same way we do for the "none" machine
>> type. This fixes a check-functional failure on aarch64 host, where
>> it would otherwise fail with:
>>     qemu-system-aarch64: unsupported machine type: "x-remote"
>>
>> Cc: qemu-stable@nongnu.org
>> Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use
>> the 'none' machine")
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> ---
>> I couldn't figure out which git commit started enforcing the
>> filtering of machine types based on the TARGET_FOO_MACHINE
>> interface markings, so I picked the Fixes: commit hash for when
>> we added them to the "none" machine, on the basis that that's
>> the point at which we logically ought to have also done x-remote.
>> ---
>>   hw/remote/machine.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/hw/remote/machine.c b/hw/remote/machine.c
>> index ced782f6a9..df08f64019 100644
>> --- a/hw/remote/machine.c
>> +++ b/hw/remote/machine.c
>> @@ -24,6 +24,7 @@
>>   #include "hw/core/qdev.h"
>>   #include "hw/remote/vfio-user-obj.h"
>>   #include "hw/pci/msi.h"
>> +#include "hw/arm/machines-qom.h"
>>     static void remote_machine_init(MachineState *machine)
>>   {
>> @@ -148,6 +149,8 @@ static const TypeInfo remote_machine = {
>>       .class_init = remote_machine_class_init,
>>       .interfaces = (const InterfaceInfo[]) {
>>           { TYPE_HOTPLUG_HANDLER },
>> +        { TYPE_TARGET_AARCH64_MACHINE },
>> +        { TYPE_TARGET_ARM_MACHINE },
> 
> ... so exposing this machine on 32-bit host binary doesn't
> look right.
>

I noticed that and fix it in the upcoming series for single-binary.

>>           { }
>>       }
>>   };
> 

Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

On Mon, Jul 20, 2026 at 02:39:06PM +0200, Philippe Mathieu-Daudé wrote:
> +Stefan
> 
> On 7/5/26 21:47, Peter Maydell wrote:
> > When we updated Arm and AArch64 board types to mark them for the
> > target_machine_typename() filter, we forgot about the "x-remote"
> > machine type, which meant that it disappeared from the set of board
> > types exposed on the qemu-system-arm and qemu-system-aarch64
> > binaries.  We didn't notice this, because although we have a
> > functional test for it, it requires the KVM accelerator and we don't
> 
> I don't remember why it requires KVM.
> 
> $ git grep -i kvm hw/remote/
> hw/remote/Kconfig:3:    depends on PCI && PCI_EXPRESS && KVM
> hw/remote/proxy.c:36: kvm_irqchip_remove_irqfd_notifier_gsi(kvm_state,
> &dev->intr, dev->virq);
> hw/remote/proxy.c:45: kvm_irqchip_add_irqfd_notifier_gsi(kvm_state,
> &dev->intr,
> 
> I suppose these 2 calls should be replaced by generic equivalents:
> - accel_irqchip_remove_irqfd_notifier_gsi()
> - accel_irqchip_add_irqfd_notifier_gsi()

The generic functions call into KVM or MSHV or return -ENOSYS if neither
are available in. While QEMU will compile, x-remote won't work at
runtime.

If someone wants to make x-remote actually work at runtime without KVM
then that should be possible too: set up an EventNotifier that handles
interrupt requests from the remote process and invokes QEMU's internal
irq APIs to inject them into the guest. There may already be code to do
that somewhere or, if not, it shouldn't be hard to write.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]