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

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.

thanks
-- PMM