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

On 8/6/2026 11:15 AM, Daniel P. Berrangé wrote:
> 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.
>

That's always welcome, but there is a difference between a suggestion
and insisting on something. Suggestions can be ignored.

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

We came from a specific need "We need to filter machines, cpus and
devices per target" to "Let's make all the types filterable in a generic
way that unify modules and the rest we have". This is some serious and
dangerous over engineering.

Feel free to have fun and send us the series implementing that.
> With regards,
> Daniel

Regards
Pierrick