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.
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.
All the existing qemu-system-$TARGET machines would go away,
becoming hardlinks to "qemu-system" where argv0 name represents
an implicit $TARGET.
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)
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 :|
