Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32
Pierrick Bouvier <[email protected]>
| Newsgroups | org.nongnu.qemu-arm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
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: [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 }, > > ... 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. >> { } >> } >> }; >