On 8/10/2026 8:46 AM, Peter Maydell wrote:
> On Fri, 24 Jul 2026 at 01:09, Pierrick Bouvier
> <[email protected]> wrote:
>>
>> Now that we can link a single-binary with at least two targets (arm,
>> aarch64),
>> we want to make sure that we expose the same set of machines (later devices
>> and
>> cpus) than target binaries. For that, we implemented a static filtering
>> based on
>> target interfaces that each machine will implement to declare which targets
>> have
>> this machine.
>>
>> However, we discovered that this static filtering is not enough. Indeed, some
>> machines and devices do not depend only on target, and their presence can
>> depend
>> on Kconfig or host/target combination. Thus, our static approach can't work,
>> and
>> we need something more flexible.
>
> Do you have some specific examples of where the static filtering isn't
> sufficient? I can certainly believe that we have some at the moment,
> but I'm curious about how much of that is "just by accident because
> ifdefs were the easy thing to do" versus when the filtering makes
> sense for avoiding showing the user things that won't work.
>
> -- PMM
As you can see in the series, machines nitro and x-remote are concerned
(they depend on host/guest combination - summarized by a target config
entry). There are additional devices I found also (igpd bus, plus nitro
devices), but I wanted to validate approach on machines first.
I didn't observe any cpu (yet) that needs this extra flexibility.
This is only for arm/aarch64 combination, I expect we'll have other
cases as we add new archs in single-binary.
Also, there is a benefit to register *all* types and filter them
afterward: we can identify conflicting QOM types with any combination,
and not only depending on which targets gets enabled.
Finally, this approach is much less verbose than adding an if (cond) {}
on every type_register_static location.
Do you have an alternative suggestion that would retain all those
benefits, but would be better in your option?
Thanks,
Pierrick
