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.
>
> 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
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
