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: [email protected] Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine") Signed-off-by: Peter Maydell <[email protected]> --- 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
