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

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

On Fri, Sep 04, 2026 at 06:04:24PM +0800, Yonggang Luo wrote:
> On Fri, Sep 4, 2026 at 5:55 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> >
> > On Fri, Sep 04, 2026 at 10:13:04AM +0100, Peter Maydell wrote:
> > > On Fri, 4 Sept 2026 at 09:58, Yonggang Luo <luoyonggang@gmail.com>
> wrote:
> > > > On Fri, Sep 4, 2026 at 4:19 PM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> > > > > 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).
> > > >
> > > > 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.
> > >
> > > I was wondering if maybe one way to approach that is some
> > > "disambiguation" syntax on the machine name; so one could write
> > > "-machine aarch64:virt" vs "-machine riscv64:virt" (or whatever) to
> > > disambiguate when just "-machine virt" would be ambiguous; but if
> > > there's only one machine of that name then just "-machine foo" would
> > > work.
> >
> > Currently the QOM type name is directly derived from the machine
> > type name, just with a "-machine" suffix attached. So if the
> > machine name is not unique, then neither is the QOM type name.
> >
> > At the very least we need the QOM type name to be unique. We
> > could de-couple the two to make this work though, which does
> > not seem too hard.
> 
> I have did that, for example:
>  hw/riscv/virt.c         | 3 ++-
>  include/hw/riscv/virt.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index dd396410178..5e57f9443c2 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1739,6 +1739,7 @@ static void virt_machine_class_init(ObjectClass *oc,
> const void *data)
>      HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
> 
>      mc->desc = "RISC-V VirtIO board";
> +    machine_class_set_name(mc, "virt");
>      mc->init = virt_machine_init;
>      mc->max_cpus = VIRT_CPUS_MAX;
>      mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
> @@ -1802,7 +1803,7 @@ static void virt_machine_class_init(ObjectClass *oc,
> const void *data)
>  }
> 
>  static const TypeInfo virt_machine_typeinfo = {
> -    .name       = MACHINE_TYPE_NAME("virt"),
> +    .name       = TYPE_RISCV_VIRT_MACHINE,
>      .parent     = TYPE_MACHINE,
>      .class_init = virt_machine_class_init,
>      .instance_init = virt_machine_instance_init,
> diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
> index 7c862b0da25..9f96dd98c6a 100644
> --- a/include/hw/riscv/virt.h
> +++ b/include/hw/riscv/virt.h
> @@ -30,7 +30,7 @@
>  #define VIRT_SOCKETS_MAX_BITS          2
>  #define VIRT_SOCKETS_MAX               (1 << VIRT_SOCKETS_MAX_BITS)
> 
> -#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
> +#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("riscv-virt")
>  typedef struct RISCVVirtState RISCVVirtState;
>  DECLARE_INSTANCE_CHECKER(RISCVVirtState, RISCV_VIRT_MACHINE,
>                           TYPE_RISCV_VIRT_MACHINE)
> 
> 
> Maybe we have a better way for it?
> 
> For device conflict, that needs to be detected after the qemu-system is
> present.

Our existing qom-test should already be validate that in fact, if we
run them against the qemu-system binary, aas it'll start
'qemu-system -machine none' and list all QOM types & properties,
at least for the targets & associated devices that we have converted
to work with 'qemu-system'. Best coverage would require all targets
to be converted but we don't have to get there straightaway.

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 :|