Re: [PATCH 01/27] include/qemu/target-info-qom.h: declare TYPE_TARGET_SPECIFIC interface

On Thu, Aug 06, 2026 at 04:52:20PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/8/26 12:21, Daniel P. Berrangé wrote:
> > On Wed, Aug 05, 2026 at 12:10:27PM -0700, Pierrick Bouvier wrote:
> > > On 8/5/2026 9:53 AM, Daniel P. Berrangé wrote:
> > > > On Wed, Aug 05, 2026 at 09:16:20AM -0700, Pierrick Bouvier wrote:
> > > > > On 8/5/2026 7:05 AM, Daniel P. Berrangé wrote:
> > > > > > On Fri, Jul 24, 2026 at 12:09:21AM +0000, Pierrick Bouvier wrote:
> > > > > > > In the next commits, We'll replace the logic to filter QOM types per
> > > > > > > target from a static one (based on INTERFACES) to a runtime one, based
> > > > > > > on is_available() function, that can be overriden per class.
> > > > > > > 
> > > > > > > Introduce the new interface we'll use for that.
> > > > > > > 
> > > > > > > Signed-off-by: Pierrick Bouvier <[email protected]>
> > > > > > > ---
> > > > > > >   include/qemu/target-info-qom.h | 15 +++++++++++++++
> > > > > > >   target-info-qom.c              |  5 +++++
> > > > > > >   2 files changed, 20 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h
> > > > > > > index 91be415ed33..83eb537333b 100644
> > > > > > > --- a/include/qemu/target-info-qom.h
> > > > > > > +++ b/include/qemu/target-info-qom.h
> > > > > > > @@ -14,6 +14,21 @@
> > > > > > >   #define TYPE_TARGET_INFO "target-info"
> > > > > > > +#define TYPE_TARGET_SPECIFIC "target-specific"
> > > > > > > +
> > > > > > > +typedef struct TargetSpecific TargetSpecific;
> > > > > > > +
> > > > > > > +typedef struct TargetSpecificClass {
> > > > > > > +    InterfaceClass parent_class;
> > > > > > > +
> > > > > > > +    bool (*is_available)(void);
> > > > > > > +} TargetSpecificClass;
> > > > > > > +
> > > > > > > +#define TARGET_SPECIFIC(obj) \
> > > > > > > +    INTERFACE_CHECK(TargetSpecific, (obj), TYPE_TARGET_SPECIFIC)
> > > > > > > +DECLARE_CLASS_CHECKERS(TargetSpecificClass, TARGET_SPECIFIC,
> > > > > > > +                       TYPE_TARGET_SPECIFIC)
> > > > > > 
> > > > > > Looking through the series,I don't really see the point
> > > > > > in this interface.   Why is this not possible to do by
> > > > > > adding 'is_available' to MachineClass.  It would make
> > > > > > the rest of the series simpler and especially avoid the
> > > > > > need to introduced yet more series of macros for defining
> > > > > > machine classes.
> > > > > > 
> > > > > 
> > > > > We'll need the exact same interface for cpus, and devices also. IMHO, it
> > > > > makes sense to have this in an external interface, instead of forcing it
> > > > > to be present in all cpus/devices/machines. I also considered adding it
> > > > > directly in Object class directly (would be the simplest), but I felt it
> > > > > would be hard to motivate it.
> > > > 
> > > > I don't see a need for the common interface across cpus/devices/etc as
> > > > as code that's filtering only cares about the specific types. It also
> > > > definitely doesn't beloong in Object class, but the Object class could
> > > > be changed to make it simpler.
> > > > 
> > > 
> > > We agree on this.
> > > 
> > > > The object_class_get_list() method could get a 'bool filter(ObjectClass *cl)'
> > > > callback which could be invoked on each class to filter it.
> > > > 
> > > > That said I find it pretty undesirable as an approach that we're
> > > > registering classes that can't then be used in a given situation.
> > > > This has a ripple effect where every bit of code that iterates over
> > > > classes needs changing to add filtering after the fact. It is also
> > > > not great for scalability, as it means every QEMU process will have
> > > > the union of all classes for all targets registered, most of which
> > > > have to be discarded / ignored at runtime.
> > > > 
> > > 
> > > This is inherent to the nature of having a single binary.
> > > We need to cover those two requirements:
> > > 1. having a filter mechanism (per target)
> > > 2. have all the classes accessible for the heterogeneous machines that
> > > will be coming in the future
> > > 
> > > 1. could be covered by what you describe, however, it breaks 2. For
> > > this, you need to be able to register all types by design.
> > 
> > 
> > Even the heterogeneous machines aren't going to need all the
> > classes from all 30+ targets that QEMU supports.
> > 
> > IIUC, the current approach relies on '--target <blah>' to select
> > which target we need. Would the heterogeneous machines not just
> > change that to allow "--target <this> --target <that>". It still
> > looks like we should be able to significantly limit  what we
> > register for heterogeneous machines.
> 
> Heterogeneous binary won't filter anything at runtime (if we want
> to filter components we already have Kconfig at compile time).
> 
> "--target <foo>" is only needed to have a single binary backward
> compatible. If you use it, you fall back to single architecture
> (our current binaries). If you want anything heterogeneous, you
> can not use it. This will be by design.

I wonder if we've got a disconnect in our respective understanding
of what we're aiming to create ? You seem to be suggesting heterogeneous
binary and single binary are not ultimately the same thing, but I saw
heterogeneous machines as a new feature of the single binary.

IOW my interpretation is that the end point that we eventually reach
is that we have  "qemu-system" as a binary, and that can be used
to host **anything** we want to deliver, whether that's a traditional
machine like  x86 'i440fx', or aarch64 'virt', or some new fancy
machine which has multiple heterogeneous CPU types.

All the existing qemu-system-$TARGET machines would go away,
becoming hardlinks to "qemu-system" where argv0 name represents
an implicit $TARGET.


What machines you could see when doing "qemu-system --machine help"
would depend on which/how many "--target NAME" args you enable.

 qemu-system -target x86_64 -machine help
   -> x86_64 machines
   (equiv of qemu-system-x86_64)

 qemu-system -target aarch64
   -> aarch64 machines
   (equiv of qemu-system-aarch64)

 qemu-system -target x86_64,aarch64
   -> aarch64 machines
   -> x86_64 machines
   -> aarch64+x86_64 machines
   (equiv of qemu-system-aarch64 plus qemu-system-x86_64 plus new heterogenous machines)

 qemu-system -target x86_64,aarch64,riscv64
   -> aarch64 machines
   -> x86_64 machines
   -> riscv64 machines
   -> aarch64+x86_64 machines
   -> aarch64+riscv64 machines
   -> riscv64+x86_64 machines
   -> aarch64+riscv64+x86_64 machines
   (equiv of qemu-system-aarch64 plus qemu-system-x86_64
    plus qemu-system-riscv64 plus new heterogenous machines
    for any combo of x86_64, aarch64 and riscv64)


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