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

[Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>]

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 <pierrick.bouvier@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>>   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 ?
>

I have been experimenting today with static filtering of types, as you
suggested, and came up with two possibilities. Before implementing this
for all types, I would like to get some feedback on which way is the
best for you.

1. Add a new callback is_available to TypeInfo, similar to existing
interface.
Pros: local information is present in type definition, making obvious
      why a type is available or not. Very easy to implement
      since only type_register_static has to be modified to check it.
Cons: Add a new field to each existing type. Not the end of the world
      in terms of memory consumption, but worth mentioning.
2. Add conditional around each type_register_static, or add an
alternative type_register_static_cond function.
Pros: I don't see any
Cons: Decouples type information from type definition, makes it harder
      to follow why a type is available or not. Much more verbose since
      we need to modify all type_register_static buried in macros.

Based on this, I'm much more in favor or 1. The fact availability
information is in the same location than type definition is the biggest
advantage for me.

On example given above, this would give something like this:
static const TypeInfo emulated_card_info = {
     .name          = TYPE_EMULATED_CCID,
     .parent        = TYPE_CCID_CARD,
     .instance_size = sizeof(EmulatedState),
     .class_init    = emulated_class_initfn,
     .is_available  = target_config_X,
};

Would that work for you?
Do you have a 3rd way to offer to solve the problem we have?

> With regards,
> Daniel

Thanks,
Pierrick