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[]
- enforce with CLI -target
- not expose any machine
That said I asked you multiple times what you are trying to
achieve to understand and get a consensus or pick the best
approach (we do not want to compete here, the point of the
community is to join efforts).
You are ignoring my questions, so this post is my last try
before I ignore you on your future contributions. Sorry if
it sounds unfriendly but you are about to reach the end of
my patience, exhausting my review time.
If you have AI power, please have a look at semcode + lore
to dig in the mailing list archive and summarize the previous
work and discussions we had before offering distinct single
binary alternatives.
https://github.com/facebookexperimental/semcode/blob/main/docs/lore.md
Once installed and configured, you only need to run:
$ semcode-index --lore qemu-devel/3
Inferring from the binary name would be acceptable too, as that can
be thought of a syntax sugar for "-target aarch64".
Yes. Better for my mental health to defer the merge of this work
to you Daniel, since you already had a look a reviewed it. But
please compare with Pierrick approach before doing so:
https://lore.kernel.org/qemu-devel/[email protected]/
Regards,
Phil.
