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

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

Single-binary is a step toward heterogeneous emulation, but not (yet) a
new feature of it.

We have been talking about how we would like to approach heterogeneous
emulation problem, but didn't share that
publicly. We submitted a talk for next KVM Forum to present our ideas.

In short: before being able to have any heterogeneous machine, we need
to solve all global state issues we identified so far: sysbus, global
memory address space, cpu indexing, etc. This work will be conducted
with a downstream "fake" machine that we have no plan to upstream.
Our long term goal is to be able to run two kernels on two different
socs with different architectures, different address spaces and set of
devices, unconnected to each other. This would prove we have effectively
achieved heterogeneous emulation.
*Once*, and only *once* all the problems above will be solved, we'll
consider what the command line should be for that. We have some ideas,
but I don't want to present them here and now, because there are many
questions left.

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

Current scope of single-binary qemu-system is only to do a single
target, without any functional change compared to existing binaries.

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

That's correct. It will take time though, and qemu-system + existing
binaries will cohabit for a while.

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

This is where we have a gap in our understanding.
The goal is not to enable multiple targets, not in this way at least.

I give you a simple example about why it's a bad design:
What is the semantic of such a line?
$ qemu-system -target x86_64,aarch64,riscv64 -M virt -cpu max
We now created an ambiguous command line, is virt the virt riscv64 or
aarch64? How about cpu?

Someone with over engineering tendencies will come with the idea:
"Ok let's prefix machine and cpu with target".
$ qemu-system -target x86_64,aarch64,riscv64 -M aarch64:virt -cpu
aarch64:max

And then, someone will say:
$ qemu-system -target x86_64,aarch64,riscv64 -M aarch64:virt -cpu
riscv64:max
And then, we will all go to hell for creating such a thing.

The only sane solution is to restrict to a single -target, and have the
exact same behavior than current binaries. No change, no breakage.

For heterogeneous machines, we want to propose a very different
approach, that requires all QOM types to be registered. Once again, it's
not the time to present/solve that, but it's why we implemented this
runtime filtering instead of exposing only some types.

> 
> With regards,
> Daniel

Finally, I would like to make one thing *crystal* clear.

It's totally ok for you (or anyone) to come on any series, review, and
criticize design, as long as a good suggestion is provided. That's the
force of our community.

However, dropping on a series, saying "NO", "do X", and stop following
it after that is not ok. It happened two months ago, when adding
target-info QOM
(https://patchew.org/QEMU/[email protected]/),
where you suggested and insisted on the wrong design, despite arguments
against it. After, you've been "busy" and stopped answering.
Whether you're busy or not does not matter at all, if you engage in such
a change, you have to ensure you can be present in the next iterations.
It's not the first time you stop answering to a thread when you run out
of arguments or things don't go in your way, and this passive-aggressive
behavior have to stop.
You can be an architect for things, but you can't leave out in the
middle of the construction when it needs you, that's unprofessional. If
you don't have time, don't engage in the first place: pick your battles.

Given this, can you confirm you understood the consequences of asking to
modify current design to register only types needed, and you are ready
to review and accept it will be more verbose than current design? If
yes, I can happily spend my time on refactoring it.

Regards,
Pierrick