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

On Mon, Aug 10, 2026 at 09:14:49AM -0700, Pierrick Bouvier wrote:
> 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.

This is the big challege of large work like this.

Saving everything up until a complete solution is done leads to giant
patch series that no one likes reviewing, and potentially wastes effort
if the design took a poor direction before being shared.

Drip-feeding though means the reviewers are evaluating patches without
being able to fully understand how it all goes together, or even how it
interacts with the next incremental chunk of work. Each small series in
isolation may look ok but put together may look undesirable. So it is a
bit like reviewing with a blindfold on.

Doing arm + aarch64 may be simple but also doesn't expose the full
scope of the complexity that two fully separate arches would
experiance given their commonality.

I see there are patches related to riscv64 in flight. Is there a
buildable single binary covering risc64 + aarch64, as that would
be a more compelling demonstration of edge cases and the possible
final state.

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