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

On Thu, Aug 06, 2026 at 09:38:43AM -0700, Pierrick Bouvier wrote:
> On 8/6/2026 7:52 AM, 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've been thinking about it yesterday, and we could apply the paradigm
> "register only classes that will be used". For heterogeneous machine,
> either we'll provide a "none" target, which enables all target, or use
> --target aarch64,riscv64, like Daniel proposed.
>
> I will implement what Daniel asked for v2.
> However, please be aware it will be probably be more invasive and
> verbose, since we'll need to add macros and stuff to have conditional
> type_register_static.
> 
> I would like to avoid doing a change you asked, and have no further
> comment after that or something like "it was better before".
> Do we agree on this Daniel?

That is an unreasonable request - I can't approve of a patch series
that doesn't exist yet.

I can only say that I don't think the current series is a desirable
approach and make suggestions of what I think is (hopefully) a
better way.


Something else that I didn't consider previously is possible interaction
with modules. Much of our use of modules is to make backends loadable,
but we've got a few loadable devices too. It seems likely that with the
single binary model we'll have greater motivation to make more device &
machine code into loadable modules, as people have repeatedly pushed us
to have a lower mandatory footprint for QEMU.

The loadable modules relies on some metadata defined in the source
code alongside the type info. For example

  static const TypeInfo emulated_card_info = {
    .name          = TYPE_EMULATED_CCID,
    .parent        = TYPE_CCID_CARD,
    .instance_size = sizeof(EmulatedState),
    .class_init    = emulated_class_initfn,
  };
  module_obj(TYPE_EMULATED_CCID);
  module_kconfig(USB);

In particular it feels like the module_kconfig() and module_arch()
metadata have overlap with what you're trying todo in this series.

So I wonder if we could generalize the module metadata so that it
serves a broader set of use cases. Instead of having to manually
write conditional logic in XXX_register_type() methods, perhaps we
can do the right thing automatically in type_register() using the
metadata we collect from the code ?

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