Re: [PATCH 00/48] hw: resolve QOM type conflicts in multi-target builds

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

On Thu, Nov 12, 2026 at 11:08:02PM +0800, Yonggang Luo wrote:
> On Thu, Nov 12, 2026 at 9:31 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > When building a multi-target binary, QOM types from multiple targets
> > will be linked together. QOM types are required to have unique names
> > when registered, so linking multiple targets in turn requires QOM type
> > names to be unique across the QEMU codebase.
> >
> > Global QOM type name uniqueness is a desirable property for QEMU
> > regardless of multi-target work, so that QEMU presents a non-ambiguous
> > object model to applications regardless of context.
> >
> > In a multi-target binary, it is desirable to applications are able to
> > introspect all types linked into QEMU, when launching with '-machine
> > none'. Dynamic filtering of registered classes at runtime, to resolving
> > QOM naming conflicts is undesirable, as it requires introspection
> > to be repeated for each available target in order to discover the full
> > set of available types in a binary.
> >
> > Introspection is a fairly heavy weight process due to QEMU's vast size,
> > so enabling introspection to be done once only for all targets will be a
> > very significant benefit for management applications with a multi-target
> > binary.
> >
> > The glaring problem is that our historical design has led to multiple
> > targets all providing a 'virt' machine type, which leads to multiple QOM
> > types call 'virt-machine' which are all different.
> >
> > Having a common short name "virt" is a useful characteristic for users,
> > but this does not imply we need to use that as the basis for primary QOM
> > typename. It is sufficient to have an alias called 'virt'.
> >
> > In terms of implementation there are two core pieces
> >
> >  * An 'Aliased' interface which can be implemented by QOM types which
> >    want to support type aliases.
> >
> >  * A 'TargetSpecific' interface which can be implemented by QOM types
> >    which want to declare  they can only be used with a subset of targets.
> >
> > With those foundational pieces
> >
> >  * Machine implements Aliased and TargetSpecific
> >
> >  * query-machines reports multiple aliases and declared supported
> >    targets per machine for introspection
> >
> >  * All the 'virt' machines are renamed to $target-virt, and aliases
> >    added for the shorter 'virt' names to retain compatibility and
> >    convenience when a target is selected
> >
> >  * All the machines which have 'is_available' set now report their
> >    targets via the TargetSpecific  interface
> >
> >  * Creating machines validates declared targets from TargetSpecific
> >
> > An apparent design mistake in TYPE_ACCEL_CPU is resolved which allows
> 
> Target independent TYPE_ACCEL_CPU  is my first choice, if the QOM name is
> do not have to be kept, I think this is better.
> 
> > removal of the is_available hooks from target specific CPU impls, which
> > were working around the bug.
> >
> > The original proposed patches to unconditionally register some object
> > properties is pulled in.
> >
> > Overall this brings us closer to having a single unified object model
> > across all targets, without having to make runtime variations of what
> > is exposed/reported by a given QOM class name.
> 
> 
> Thanks, overall looks good to me.
> 
> hw/microblaze: defer PetaLogix endianness default until init:
> https://lore.kernel.org/qemu-devel/20261105194958.1117-5-luoyonggang@gmail.com/
> 
> is also for avoid target_info in class_init

I added a R-B to that.

> The last gap is how to handling cpu class name conflict
> target/arm: register separate max-v8 CPU types for arm and aarch64:
> https://lore.kernel.org/qemu-devel/20261031164009.2048-7-luoyonggang@gmail.com/

I had a look at your earlier proposal here:

  https://lore.kernel.org/qemu-devel/20261013195606.152-1-luoyonggang@gmail.com/

and to me that looks like it should do what we need.

 * In existing qemu-system-arm and qemu-system-aarch64 it will
   "just work"

 * In qemu-system-aarch64, users can still opt-in to 32-bit
   mode only by using "-cpu max-v8:aarch64=off"

So based on Peter's comment it does not look like we need to
have the ability to register two distnict "max-v8" CPU classes,
a single class can do the right thing at runtime in its
instance constructor.

I see Pierrick commented that it would not work in multi-target:

  https://lore.kernel.org/qemu-devel/f3649d73-1edf-440a-9534-7b00da4d075d@oss.qualcomm.com/

I'm not understanding why that is ? The choice of 32-bit vs 64-bit
is made at Object initialization time, so if the

     if (target_aarch64()) {
        ...

condition is not sufficient, it seems like we could add more logic
to that condition easily and to make it do the right thing at runtime.

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