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

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

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'

or

  -machine virt -target aarch64

Inferring from the binary name would be acceptable too, as that can
be thought of a syntax sugar for "-target aarch64".

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