Re: [PATCH 0/4] hw: support machine filtering without is_available

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

On Thu, Nov 05, 2026 at 09:25:28AM -0800, Pierrick Bouvier wrote:
> On 11/5/2026 2:24 AM, Daniel P. Berrangé wrote:
> > The 'is_available' callback on TypeInfo is based on a mistaken
> > notion that we should filter out classes at registration time
> > based on architecture.
> > 
> > This creates new problems however, some already present and
> > some which will impact a future multi-target binary
> > 
> >  * For introspection of the binaries' features, we have
> >    a dependancy on selecting a target before we can
> >    introspect features. It would require re-launching
> >    QEMU for each target, leading to lots of redundant
> >    introspection and a big time sink. It would also not
> >    be possible to introspect targets
> > 
> >  * It creates a circular dependancy on QOM initialization
> >    inside the QOM initialization code, since 'target_info()'
> >    itself uses QOM. This then requires further work to break
> >    by initializing QOM target info before the rest of QOM.
> > 
> >  * We have no means to introspect what targets a machine
> >    type can be used with, as this information is expressed
> >    as code (in target_XXXX() methods), instead of as data.
> > 
> >  * New fields in TypeInfo requires more changes to macros
> >    used for initializing machines.
> > 
> > There is no inherant conceptual reason why we must filter out
> > classes at type registration time. This is just a shortcut to
> > workaround historical technical debt where certain classes
> > have clashing names. This is an undesirable approach, as it
> > is trading one set of problems for a new set of problems.
> > 
> > This series proposes removal of the 'is_available' concept
> > from QOM, and illustrates handling machines with full introspection
> > support available from the MachineClass.
> > 
> > This implies fixing the root cause, of clashing class names,
> > but does not include patches since various series have already
> > been posted for machine class name fixes.
> > 
> > The machine changes are fairly simple
> > 
> >  * MachineClass gains a 'targets' field which is a bit mask
> >    of SysEmuTarget
> >  * machine_class_is_available() matches 'targets' against
> >    'target_info()'
> >  * -machine CLI enforces machine_class_is_available()
> >  * query-machines filters on machine_class_is_available
> >    by default
> >  * query-machines gains 'all-targets': 'bool' to opt-in
> >    to returning the unfiltered list, with a 'targets'
> >    list present
> > 
> > NB, this removes filtering from riscv CPUs with no
> > alternative proposed. I'm unclear what this was trying
> > to address to begin with, but utlimately it should be
> > possible to address it with runtime filtering/matching
> > of classes, instead of hiding TypeInfo registration.
> > If someone gives me info on the CPUs problem I can a
> > make a design suggestion.
> > 
> > Daniel P. Berrangé (4):
> >   hw/core: record permitted targets against MachineClass
> >   hw: replace 'is_available' with 'targets' in machines
> >   target/riscv: remove 'is_available' from riscv CPUs
> >   qom: drop the 'is_available' callback from TypeInfo
> > 
> >  hw/arm/aspeed_ast27x0-fc.c  |  3 ++-
> >  hw/arm/aspeed_ast27x0_evb.c |  5 +++--
> >  hw/arm/raspi.c              | 21 +++++++++++++--------
> >  hw/arm/raspi4b.c            |  3 ++-
> >  hw/arm/virt.c               |  5 +++--
> >  hw/core/machine-qmp-cmds.c  | 18 ++++++++++++++++++
> >  hw/core/machine.c           | 13 +++++++++++++
> >  hw/hexagon/virt.c           |  3 ++-
> >  hw/m68k/virt.c              |  4 ++--
> >  hw/or1k/virt.c              |  3 ++-
> >  hw/riscv/virt.c             |  4 +++-
> >  include/hw/core/boards.h    |  3 +++
> >  include/qom/object.h        |  3 ---
> >  qapi/machine.json           | 12 +++++++++++-
> >  qom/object.c                |  4 ----
> >  rust/qom/src/qom.rs         |  1 -
> >  system/vl.c                 |  9 +++++++++
> >  target/riscv/kvm/kvm-cpu.c  |  1 -
> >  target/riscv/tcg/tcg-cpu.c  |  1 -
> >  19 files changed, 86 insertions(+), 30 deletions(-)
> > 
> 
> Thanks for posting the series.
> 
> Would that be possible to complete it so that beyond compilation, test
> ./build/tests/unit/test-multi-target passes also? At the moment it fails
> with duplicated types being registered.

Oh I see, it didn't failure because I only enabled
the two arm/aarch64 targets, once i add in more
targets we get a clash on the virt-machine class.

FYI, it also fails without my patch series present
in some scenarios:

# child process (/multi-targets/qom-types-are-unique/aarch64 [1950288]) stderr: "Registering `vm-launch-update' which already exists\n"
**
ERROR:../tests/unit/test-multi-target.c:41:test_qom_types_are_unique: child process (/multi-targets/qom-types-are-unique/aarch64 [1950288]) failed unexpectedly
not ok /multi-targets/qom-types-are-unique/aarch64 - ERROR:../tests/unit/test-multi-target.c:41:test_qom_types_are_unique: child process (/multi-targets/qom-types-are-unique/aarch64 [1950288]) failed unexpectedly
Bail out!
Aborted                    (core dumped) tests/unit/test-multi-target

This is caused by presence of 'igvm-devel' at build time on
one of my machines (Fedora), which enables this device type,
if you have both arm and aarch64 targets enabled.

We need to add igvm to our Fedora dockerfile to catch this
in CI.

Moving it from specific_ss to system_ss make the test pass,
but I'm unclear if it is sufficient to rely on lack of
compiler and test complaints ? Or it needs manual code
inspection to make sure the device is safe in this
scenario ?

> That's why this is_available was introduced in the first place. It was
> just a way to move forward and provide the multi-target test to prevent
> regression while work on single-binary is continued by Yonggang.

Right, so with my series, we would first need the class
renames to fix the multi-target test.

I should have labelled this posting "POC" as it was not
tested thoroughly.

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