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

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

On Thu, Oct 01, 2026 at 09:19:48AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 9:14 AM, Yonggang Luo wrote:
> > On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
> > <philmd@oss.qualcomm.com> wrote:
> >>
> >> On 1/10/26 10:13, Yonggang Luo wrote:
> >>> On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>>>
> >>>> On Wed, Sep 30, 2026 at 09:23:50PM -0700, Pierrick Bouvier wrote:
> >>>>> On 9/30/26 6:55 PM, Yonggang Luo wrote:
> >>>>>> On Thu, Oct 1, 2026 at 2:19 AM Pierrick Bouvier
> >>>>>> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >>>>>>>
> >>>>>>> On 9/26/26 1:15 AM, Yonggang Luo wrote:
> >>>>>>>> - Add machine_class_set_name() so boards can keep a stable -M name
> >>>>>>>>      when the QOM type is uniquified. machine_class_base_init still
> >>>>>>>>      defaults the name to the QOM type without -machine.
> >>>>>>>> - Document that MachineClass::name is the -M name, not the QOM type.
> >>>>>>>> - Sort -M help by MachineClass::name so order matches the printed names
> >>>>>>>>      when QOM types are prefixed (arm-virt-11.1-machine vs virt-11.1).
> >>>>>>>>
> >>>>>>>> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> >>>>>>>> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> >>>>>>>> ---
> >>>>>>>>     hw/core/machine.c        |  6 ++++++
> >>>>>>>>     include/hw/core/boards.h | 12 +++++++++++-
> >>>>>>>>     system/vl.c              |  8 +++-----
> >>>>>>>>     3 files changed, 20 insertions(+), 6 deletions(-)
> >>>>>>>>
> >>>>>>>
> >>>>>>> First, I'm not opposed to this series, and if anyone wants to pull this,
> >>>>>>> I'm ok with that decision. It's just unclear for me what will be
> >>>>>>> direction after this step.
> >>>>>>>
> >>>>>>> If I understand correctly, the goal here is to allow to register
> >>>>>>> multiple "virt" machines, while still having distinct QOM types behind
> >>>>>>> the hood, which does no affect behavior of current binaries who have
> >>>>>>> only a single "virt" type at most.
> >>>>>>>
> >>>>>>> That said, if we project in the future where we have a binary with
> >>>>>>> multiple of those "virt" machines, how will the current series help? The
> >>>>>>> situation we'll have is distinct QOM types, that all answer to the name
> >>>>>>> "virt", so we have no way to select them individually.
> >>>>>>>
> >>>>>>> Slightly worse, find_machine() will just pick the first machine name
> >>>>>>> virt, which is a non-deterministic order at the moment.
> >>>>>>> https://gitlab.com/qemu-project/qemu/-/blob/master/system/vl.c?ref_type=heads#L846
> >>>>>>
> >>>>>> That will handle it properly. For single-target binary qemu-system-$arch.exe,
> >>>>>> this won't be an issue, as there is no conflict as they won't be compiled in.
> >>>>>> For multi-target binary qemu-system.exe, we will choose the target through
> >>>>>> -M $arch:$machine, and when no $arch is specified, the default to arch
> >>>>>> to be "none",
> >>>>>> so still won't be non-deterministic.
> >>>>>>
> >>>>>
> >>>>>> "when no $arch is specified, the default to arch to be "none",so still >
> >>>>> won't be non-deterministic.
> >>>>>
> >>>>> That's my point, the current abstraction will create something ambiguous by
> >>>>> design. When people will specify -M virt, without $arch:, a random machine
> >>>>> will be selected. At least, maybe this series should ensure there is only
> >>>>> one virt alias, or make it forbidden and uses unambiguous names only.
> >>>>
> >>>> Yes, if there are multiple choices, we should not pick an arbitrary one
> >>>> non-deterministically, we must require the user to narrow the choice
> >>>> explicitly in some manner.
> >>>>
> >>>>> "$arch:" is just a workaround to not add -target option, except that it
> >>>>> comes with additional problems, creating inconsistent command lines.
> >>>>> I already expressed my skepticism about the "machine prefix" based approach,
> >>>>> being more in favor to strongly filter types per target with an unambiguous
> >>>>> -target option. I'll accept the community's choice on this, but just wanted
> >>>>> to see this explained before someone hits the pull button on this series, so
> >>>>> they know what will come down the road.
> >>>>
> >>>> Historically, QEMU do alot of things like this where we invented magic
> >>>> syntax that needed custom parsing of the command line. Over time we
> >>>> came to the conclusion this ad-hoc parsing was a bad idea, and we
> >>>> should always explicitly model things, even if it is more verbose.
> >>>>
> >>>> Thus I would not want to see "$target:$machine" as something that is
> >>>> parsed into two pieces.
> >>>>
> >>>> IOW, "aarch64-virt" would be OK as a unique name which treated as an
> >>>> opaque string, but "aarch64:virt" as something split into "aarch64"
> >>>> (target) and "virt" (machine) would be a bad idea.
> >>>>
> >>>> An acceptable way of modelling the latter would be to use
> >>>>
> >>>>    '-machine name=virt,target=aarch64'
> >>
> >> Why mix target information parsing at machine level when the
> >> machine already know it is target specific? People wanting to
> >> use the ARM virt machine don't want to know (and don't care)
> >> about the M68k virt machine.
> >>
> >>>
> >>>>
> >>>> or
> >>>>
> >>>>    -machine virt -target aarch64
> >>>
> >>>
> >>> That's made me confused, as different people propose different ways to
> >>> handle it.
> >>> Can we just choose one first?
> >>> '-machine name=virt,target=aarch64' is introducing new options, so is
> >>> '-machine virt -target aarch64'
> >>> I can not argue which is better, my suggestion may land one first. Both
> >>> "-machine virt -target aarch64" and "-machine $arch:$name" I have
> >>> already implemented. And currently I chose
> >>> "-machine $arch:$name" according to
> >>> https://patchwork.ozlabs.org/project/qemu-devel/cover/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#3749257
> >>
> >> You still did not explained what you are trying to achieve
> >> with all your contributions, so my view is surely biased by
> >> what we envisioned 3 years ago when we started to pave our
> >> way for heterogenous emulation.
> >>
> >> My options so far for a single binary:
> >>
> >> - infer from argv[]
> > This can be easy to implement and can be defer till the qemu-system-$arch
> > is symbolic link to qemu-system.
> > 
> >> - enforce with CLI -target
> > 
> > I want to post my personal options, I'll prefer the -target options as
> > it's far easier to implement than "-machine $arch:$machine".
> > -machine $arch:$machine is very complicated to implement correct.
> > 
> >> - not expose any machine
> > 
> > I think not exposing any machine in the command line is a good option,
> > as it's easier to
> > implement and clean for the user. But I think this series is still needed.
> > As we want the means to inspect all machines and devices for all
> > targets(that need all of them
> > to be registered into the QOM type hash table).
> 
> It's not strictly needed to expose all types. -target can be parsed
> first, and influence what is visible from help (including -M help) also.
> 
> Also, if we go down the -target option, we should decide if we expose
> all types or not, which means if we implement filtering or not. If we
> expose all the types, I'm not sure what -target is supposed to choose.
> 
> Daniel, what do you think about this one?

*If* we take the starting assumption that the new multi-target
binary does not need to be a perfect replica of the existing
binaries, then filtering devices is creating extra work for
ourselves, to solve a problem that isn't especially important.

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.

A --target option (or similar -machine name,target=xxx) could
be used to dis-ambiguate between 'virt' machines if keeping
their user facing machine names as-is, or it could be used as
a way to be more explicit about the 32-bit vs 64-bit choice
and sanity checked against the CPU model choice.

So overall "device filtering" or not is the key question to
decide IMHO.

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