On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
<[email protected]> wrote:
>
> On 1/10/26 10:13, Yonggang Luo wrote:
> > On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <[email protected]>
> > 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
> >>>> <[email protected]> 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 <[email protected]>
> >>>>>> Reviewed-by: Daniel P. Berrangé <[email protected]>
> >>>>>> ---
> >>>>>> 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/[email protected]/#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).
>
> Phil.
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
