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.
"$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.
A possible alternative could be to use ".is_available = target_X" on
those virt types, which will ensure only one is effectively registered
at runtime, thus, there is no ambiguity on name or who is the "virt"
machine.
That's the issue I want to fix, ensure it is registered at runtime. So
we can list them
all when a "none" target is selected.
Again, I'm ok if anyone wants to pull this.
Regards,
Pierrick
