Re: [PATCH v3 01/10] machine: allow -M name to differ from QOM type

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Oct 02, 2026 at 10:00:24AM +0800, Yonggang Luo wrote:
> On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >
> > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > >>> Even with the current per-target binaries there are countless
> > >>> devices linked in which are incompatible / not usable with
> > >>> certain machine types. A new multi-target binary with a union
> > >>> of all devices will just be a bigger example of a scenario that
> > >>> already has to be dealt with for today's binaries.
> > >>>
> > >>> So if we have that assumption that we don't need to do device
> > >>> filtering, at that point, a --target option doesn't have as
> > >>> big of a role to play. The machine type code knows what target(s)
> > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > >>> varaints. The CPU model the user requests (if the CPU is not
> > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > >>>
> > >>
> > >> How can we deduce this information (bitness or target for existing
> > >> machines/cpus)?
> > >
> > > It would require that we introduce a new field in MachineClass
> > > that returned that information about what target a machine is
> > > associated with.
> > >
> > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > >
> > > It might be better use QEMU_ARCH which correlates directly to
> > > the TCG targets, rather than the traditional binary target
> > > names ?
> > >
> > > Likely the CPU class would also want to declare its list of
> > > supported targets.
> > >
> >
> > QEMU_ARCH only represents base architectures, and not variant, so
> > SysEmuTarget is the right choice.
> >
> > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > target specific, since one could be available for variants of base arch?
> 
> For this, adding TargetInfo parameter to is_avaible callback will let us get the
> list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
> then check if that TargetInfo is present for every cpu/machine.
> And indeed for devices if you want. That's what my patches are already done.
> 
> And also I have an idea about the set is_avaiable in an easy way. As
> QOM basically
> is a TREE, so for example x86_32 and x86_64 can share a same "i386"
> base, all children's
> is_avaiable inherent from parents is_avaiable, we can ensure every QOM
> object have a
> is_avaiable by update children is_avaiable from parents one.
> 
> >
> > @Yonggang: can you try to provide a RFC based on this, to see what it
> > could look like? No need to cover all machines/cpus, just select one of
> > machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> > for aarch64), and let's iterate from this.
> >
> > @Daniel: how do we deal with machines available for all targets like
> > null? We would need a way to ensure all machines/cpus are tagged
> > correctly, in an independent way from "available for all", without
> > having to repeat all existing SysEmuTarget.
> >
> > >> Also, how to deal with devices that are only available for some targets,
> > >> but not others, depending on various Kconfig knobs?
> > >
> > > IMHO just leave devices to raise an error when passed to '-device'
> > > if not compatible with the requested machine.
> > >
> > > eg this example from x86 world:
> > >
> > >   $ qemu-system-x86_64 -M microvm -device xen-disk
> > >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> > >
> > >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> > >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> > >
> > > Hopefully most devices have sane error reporting when they
> > > find a dependancy they have is not satisfied by the machine,
> > > but if some end up asserting with crashes that's not a
> > > blocker. Those asserts can be turned into pretty error
> > > messages at our leisure by whomever cares about improving
> > > error diagnosis.
> > >
> >
> > Fine for me. I am a bit skeptical this will be possible to catch all
> > issues, but let's try!
> >
> > So, for existing binary: -M virt works as before.
> >
> > For new multi binary:
> > $ qemu-system -M virt:
> > Multiple machines were found, select one among:
> > - aarch64-virt
> > - riscv64-virt
> 
> This would be very hard, that means QOM must be initialized. but we need
> ensure the target is selected before the QOM init.

We don't need to have initialized anything. We just need a single
global variable, whose default initializer is true vs false, for
for the separate vs multi-target binaries. That's just a pair of
.o files with a single bool variable, that we choose between when
linking.


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