Re: [PATCH 00/27] single-binary: implement dynamic filtering for machine types

On 8/10/2026 9:00 AM, Peter Maydell wrote:
> On Mon, 10 Aug 2026 at 16:55, Pierrick Bouvier
> <[email protected]> wrote:
>>
>> 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.
> 
>> 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?
> 
> No, I'm not particularly strongly opinionated about the approach,
> I was just trying to understand the background motivation for it.
>

It would be more easy if we could expose the patches we have to enable
the single-binary itself, so people can test and see what is the value
of current series. However, given reception of such patches in the past,
we decided to present them as the last piece of puzzle, and not before.

So we're trying to make sure that existing targets (arm, aarch64) have
the exact same set of devices/machines/cpu, before adding the machinery
to build and run the single-binary.

> thanks
> -- PMM