Re: [PATCH 00/47] single-binary: implement dynamic filtering for QOM types

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote:
> On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> >
> > On Fri, Aug 28, 2026 at 04:13:32PM -0700, Pierrick Bouvier wrote:
> > > On 8/28/2026 3:58 PM, Pierrick Bouvier wrote:
> > > > Now that we can link a single-binary with at least two targets (arm,
> aarch64),
> > > > we want to make sure that we expose the same set of machines (later
> devices and
> > > > cpus) than target binaries. For that, we implemented a static
> filtering based on
> > > > target interfaces that each machine will implement to declare which
> targets have
> > > > this machine.
> > > >
> > > > However, we discovered that this static filtering is not enough.
> Indeed, some
> > > > machines and devices do not depend only on target, and their presence
> can depend
> > > > on Kconfig or host/target combination. Thus, our static approach
> can't work, and
> > > > we need something more flexible.
> > > >
> > > > The goal of this series is to focus on the filtering mechanism, not
> on the
> > > > qemu-system binary itself, even though it's included here to give a
> full picture
> > > > of what we are building.
> > > >
> > > > v3
> > > > --
> > > >
> > > > Suggested by Richard, we simply use a callback added to TypeInfo.
> > > > Added full example with a single binary for arm+aarch64, and then
> > > > arm+aarch64+microblaze.
> > > > Also, added scripts/single-binary-compare-cmdline.sh, which compares
> list of
> > > > cpus, devices and machines between single-binary and original
> binaries.
> > > > This is what we can use in CI to ensure we correctly tagged all QOM
> types.
> > > >
> > >
> > > After applying this series, and running
> > > scripts/single-binary-compare-cmdline.sh, you'll see than many devices
> > > are visible for microblaze, and should not.
> > >
> > > microblaze+arm is a more interesting combination than riscv+arm because
> > > riscv has a lot of devices in common with arm. On the opposite,
> > > microblaze has a very reduced set (no virtio, no pci, etc).
> > >
> > > I would like to focus the conversation on how to filter the remaining
> > > types. We could maybe generate something directly from Kconfig output,
> > > so we don't need boilerplate for each CONFIG_X entry.
> >
> > I'm still not clear on why we need to filter the devices at all for
> > a new "qemu-system" binary ?
> >
> > Looking at the device delta listed in your other mail, a large number
> > of those are PCI based. The microblaze machine types don't expose a
> > PCI controller, so those PCI devices are redundant / won't be used
> > with microblaze machines, which is why existing qemu-system-microblaze
> > doesn't link to those devices.
> >
> > The same is true of many of the arm machines too though. Only a subset
> > of arm machines have PCI, but the qemu-system-arm binary still includes
> > and lists all these PCI devices. Users simply can't create a PCI device
> > for the arm machines that lack a PCI controller, or they'll receive an
> > error.
> >
> > Why doesn't this approach extend into the future qemu-system binary ?
> > List everything, and if the user tries to add a device that's not
> > compatible with a machine, then it will simply result in an error.
> 
> Device filtering would be complicated, I guess, as there is so much
> CONFIG_* for devices. Another approach is to just place devices under an
> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
> listed(memory consumption will also be reduced when it's not needed).

While modules are important for reducing memory consumption, I don't think
they need to be a blocker - making more things into modules can be done
in the backaround as & when people want to work on it.

> But machine listings still need the filtering, considering virt is present
> for many different arches(riscv/arm/i686). so machine listing is still a
> thing.

We still need the ability to query all machines present in the binary
and what targets they can be used with, for the purposes of introspection,
which the filtering doesn't allow for AFAICT. Renaming the clashing
machine names looks inescapable for the new qemu-system binary.

> The current is_avaible works fine for machines.
> Pierrick is already pending the device filtering work, so I guess it's fine
> now, we are just filtering the machines according to
> https://lore.kernel.org/qemu-devel/20260901202043.26532-1-pierrick.bouvier@oss.qualcomm.com/
> ?
> 
> I also add patches based on this, so that we can list machines for
> different  arches(riscv/arm/i686) properly for qemu-system, as I add a
> TargetInfo parameter to is_available callback.
> The patches is at
> https://lore.kernel.org/qemu-devel/20260903205018.975-1-luoyonggang@gmail.com/

For listing machines I'd expect to see the "MachineInfo" QAPI type
gain a "targets" parameter. eg something like this:

diff --git a/qapi/machine.json b/qapi/machine.json
index 2d63c1bac3..a614baa03a 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -195,6 +195,7 @@
 # @compat-props: The machine type's compatibility properties.  Only
 #     present when `query-machines` argument @compat-props is true.
 #     (since 9.1)
+# @targets: list of targets that can run this machine (since 11.2)
 #
 # Features:
 #
@@ -207,6 +208,7 @@
             '*is-default': 'bool', 'cpu-max': 'int',
             'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
             'deprecated': 'bool', '*default-cpu-type': 'str',
+            'targets': ['SysEmuTarget'],
             '*default-ram-id': 'str', 'acpi': 'bool',
             '*compat-props': { 'type': ['CompatProperty'],
                                'features': ['unstable'] } } }


which can be populated from the machine class

diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 543dd3201b..4852be25ca 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -104,6 +104,8 @@ MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
         MachineClass *mc = el->data;
         const char *default_cpu_type = machine_class_default_cpu_type(mc);
         MachineInfo *info;
+        SysEmuTargetList **tgts;
+        int n;
 
         info = g_malloc0(sizeof(*info));
         if (mc->is_default) {
@@ -120,6 +122,11 @@ MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
         info->hotpluggable_cpus = mc->has_hotpluggable_cpus;
         info->numa_mem_supported = mc->numa_mem_supported;
         info->deprecated = !!mc->deprecation_reason;
+
+        tgts = &(info->targets);
+        for (n = 0; mc->targets && mc->targets[n] != SYS_EMU_TARGET__MAX; n++) {
+            QAPI_LIST_APPEND(tgts, mc->targets[n]);
+        }
         info->acpi = !!object_class_property_find(OBJECT_CLASS(mc), "acpi");
         if (default_cpu_type) {
             info->default_cpu_type = g_strdup(default_cpu_type);
diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h
index a436d48c8e..436eb9fe84 100644
--- a/include/hw/core/boards.h
+++ b/include/hw/core/boards.h
@@ -322,6 +322,8 @@ struct MachineClass {
     SMPCompatProps smp_props;
     const char *default_ram_id;
 
+    SysEmuTarget *targets;
+
     HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
                                            DeviceState *dev);
     bool (*hotplug_allowed)(MachineState *state, DeviceState *dev,


This MachineInfo QAPI type is how to report other key information
about the machine classes.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|