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

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

On Mon, Aug 10, 2026 at 03:26:26PM -0700, Pierrick Bouvier wrote:
> 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?

In the case of user creatable objects, we represented a classes'
conditional availablity in QAPI schema. For example:

  { 'struct': 'InputLinuxProperties',
    'data': { 'evdev': 'str',
              '*grab_all': 'bool',
              '*repeat': 'bool',
              '*grab-toggle': 'GrabToggleKeys' },
    'if': 'CONFIG_LINUX' }

Now this isn't quite a match for what we want, as QAPI schema is
common to all targets and used to control the code generator to
turn off output. Thus the permitted CONFIG_xxx are only those in
config-host.mak, not any from $TARGET-softmmu-config-devices.mak

The other scenario in QAPI is the concept of features:

{ 'struct': 'SevCommonProperties',
  'data': { '*sev-device': 'str',
            '*cbitpos': 'uint32',
            'reduced-phys-bits': 'uint32',
            '*kernel-hashes': 'bool' },
  'features': ['confidential-guest-reset']}

where again we just have a list of named strings. Features are fully
dynamic, and crucially they are introspectable so applications can
query at runtime what is available.

The introspection concept is something that is highly likely to be
relevant to our use cases here. If we have a single binary with all
types, it would be very valuable to be able to query it once to
discover everything in one go, instead of havnig to query it over
and over again for each target. That implies the application doing
the query needs to be told about per-target usage restrictions on
types it is querying.

We don't have QAPI schema for QDev devices currently, but it is likely
we will do so in the future. We can't wait for that though as there is
no clear ETA.

What this all says to me though, is that instead of an 'is_available'
method, we should instead just list the conditions as data in the
TypeInfo struct directly. IOW a list of const strings 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,
      .available     = (const char *[]){ TARGET_AARCH64, CONFIG_something .... },
 };

This will make it easy to add in introspection at a later date.

The limitation is that this can only express an "AND" condition.
You can not do complex AND+OR+grouping conditions that you could
express in code, but IMHO that is not likely to be a problem.
In the worst case you can define a higher level "CONFIG_BLAH"
that encapsulates the complex condition.

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