Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32
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 signature.asc Description: PGP signature
Re: [PATCH 1/6] hw/remote/machine.c: Mark x-remote machine as OK for AArch64 and AArch32
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 >> --- >> 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 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 --- 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
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: [email protected] Fixes: eb796c55513d9d39 ("hw/core: Allow ARM/Aarch64 binaries to use the 'none' machine") Signed-off-by: Peter Maydell --- 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é
