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 08:40:54AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 7:00 PM, 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.
> >
> 
> @Daniel: would that work for you? I feel like it limits the way to
> introspect qom objects, but maybe not if we export the right thing on
> QAPI side based on that.

"is_available" is probably a bit overkill as a mechanism for
introspecting, when we just need to return a list of targets,
Since we have that already we might as well use it initially
though.

> >> Does it matches what you would expect?
> >>
> >> Also, for compatibility with existing binaries, should we accept -M
> >> $arch-virt also? I feel like it does not hurt and would make thing
> >> simpler to switch between existing and new binary.
> > 
> > Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> > would be even harder.
> > Because "-" is a valid separator in machine names, ":" is not a valid
> > machine name.
> > So without init QOM, we can not reliably identify "$arch-virt" belongs
> > to which target.
> >
> 
> From the conversation above, Daniel and I are not in favor to have any
> kind of parsing based on this string. So either we'll pick virt, or the
> real qom name, but not anything else.

Yeah, I'm leaning more towards always exposing the $arch-virt names
in all binaries, and also exposing 'virt' in the traditional
binaries only.


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