[PATCH v3 00/10] machine: uniquify virt QOM names

[PATCH v3 00/10] machine: uniquify virt QOM names

[Yonggang Luo]

Multiple targets register a virt board as MACHINE_TYPE_NAME("virt").
Those QOM types collide if more than one board is linked into one
qemu-system process. This series splits the QOM type from the -M name
so each virt board can keep a unique type while -M virt, help, and
migration stay the same.

- Add machine_class_set_name() so boards can set MachineClass::name
  when it must differ from the QOM type. 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 that name so order matches the printed names after types are
  prefixed (arm-virt-11.1-machine vs virt-11.1).
- Give each colliding virt board a unique QOM type and keep the
  existing -M name via machine_class_set_name(): riscv-virt, arm-virt,
  or1k-virt, hexagon-virt, loongarch-virt, m68k-virt, and xtensa-virt.
  Versioned ARM, LoongArch, and M68K boards keep virt-<ver>. Latest
  ARM virt still sets mc->alias to virt.
- query-machines returns MachineInfo typename, the QOM type from
  object_class_get_name(), for qom-list-properties. The -M name alone
  is not that type once virt boards are prefixed.

Changes v2 -> v3:
The versioned-machine example in boards.h now follows hw/arm/virt.c.
machine_class_set_name() keeps the -M name as virt-<version>, the QOM type in
the example is arm-virt, and the latest helper is DEFINE_VIRT_MACHINE_AS_LATEST.

Changes v1 -> v2:
- query-machines returns MachineInfo typename. v1 returned only the
  -M name, so a client that appended "-machine" looked up the wrong
  type for a prefixed board such as arm-virt-11.1-machine versus
  -M virt-11.1.

Yonggang Luo (10):
  machine: allow -M name to differ from QOM type
  hw/riscv/virt: use unique QOM name
  hw/arm/virt: use unique QOM name
  hw/or1k/virt: use unique QOM name
  hw/hexagon/virt: use unique QOM name
  hw/loongarch/virt: use unique QOM name
  hw/m68k/virt: use unique QOM name
  hw/xtensa/virt: use unique QOM name
  qapi: return MachineInfo typename from query-machines
  machine: match the versioned virt example to arm virt

 hw/arm/virt.c               |  3 +-
 hw/core/machine-qmp-cmds.c  |  1 +
 hw/core/machine.c           |  6 ++++
 hw/hexagon/virt.c           |  1 +
 hw/loongarch/virt.c         |  3 +-
 hw/m68k/virt.c              |  7 ++--
 hw/or1k/virt.c              |  3 +-
 hw/riscv/virt.c             |  3 +-
 hw/xtensa/virt.c            |  3 +-
 include/hw/arm/virt.h       |  2 +-
 include/hw/core/boards.h    | 26 +++++++++++----
 include/hw/hexagon/virt.h   |  2 +-
 include/hw/loongarch/virt.h |  2 +-
 include/hw/riscv/virt.h     |  2 +-
 qapi/machine.json           |  6 +++-
 system/vl.c                 |  8 ++---
 tests/qtest/qom-test.c      | 65 +++++++++++++++++++++++++++++++++----
 17 files changed, 113 insertions(+), 30 deletions(-)

-- 
2.52.0.windows.1

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

[Yonggang Luo]

- 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(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 92f7be52a13..6b933f2302d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1215,6 +1215,12 @@ static void machine_class_init(ObjectClass *oc, const void *data)
         "Memory size configuration");
 }
 
+void machine_class_set_name(MachineClass *mc, const char *name)
+{
+    g_free(mc->name);
+    mc->name = g_strdup(name);
+}
+
 static void machine_class_base_init(ObjectClass *oc, const void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h
index 3b86724cf00..851140ad052 100644
--- a/include/hw/core/boards.h
+++ b/include/hw/core/boards.h
@@ -36,6 +36,16 @@ const char *machine_default_cpu_type(const MachineState *ms);
  * @mc: Machine class
  */
 const char *machine_class_default_cpu_type(MachineClass *mc);
+/**
+ * machine_class_set_name: Set the -M name when it differs from the QOM type
+ * @mc: Machine class
+ * @name: Name used by -M lookup, help, and migration
+ *
+ * machine_class_base_init sets MachineClass::name from the QOM type with
+ * the -machine suffix removed. Call this from board class_init when the
+ * CLI name must stay stable after the QOM type is uniquified.
+ */
+void machine_class_set_name(MachineClass *mc, const char *name);
 
 void machine_add_audiodev_property(MachineClass *mc);
 void machine_run_board_init(MachineState *machine, const char *mem_path, Error **errp);
@@ -269,7 +279,7 @@ struct MachineClass {
     /*< public >*/
 
     const char *family; /* NULL iff @name identifies a standalone machtype */
-    char *name;
+    char *name; /* -M name; default is QOM type without -machine */
     const char *alias;
     const char *desc;
     const char *deprecation_reason;
diff --git a/system/vl.c b/system/vl.c
index 468a9fc247a..0d52c5d0a46 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -1538,10 +1538,9 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b, gpointer d)
     if (mc1->family == NULL) {
         if (mc2->family == NULL) {
             /* Compare standalone machine types against each other; they sort
-             * in increasing order.
+             * in increasing order by the name shown in -M help.
              */
-            return strcmp(object_class_get_name(OBJECT_CLASS(mc1)),
-                          object_class_get_name(OBJECT_CLASS(mc2)));
+            return strcmp(mc1->name, mc2->name);
         }
 
         /* Standalone machine types sort after families. */
@@ -1560,8 +1559,7 @@ static gint machine_class_cmp(gconstpointer a, gconstpointer b, gpointer d)
     }
 
     /* Within the same family, machine types sort in decreasing order. */
-    return strcmp(object_class_get_name(OBJECT_CLASS(mc2)),
-                  object_class_get_name(OBJECT_CLASS(mc1)));
+    return strcmp(mc2->name, mc1->name);
 }
 
 static void machine_help_func(const QDict *qdict)
-- 
2.52.0.windows.1

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

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:41PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:41 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 01/10] machine: allow -M name to differ from QOM type
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> - 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(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

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

[Pierrick Bouvier]

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

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.

Again, I'm ok if anyone wants to pull this.

Regards,
Pierrick

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

[Yonggang Luo]

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.


>

> 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

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

[Pierrick Bouvier]

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.

"$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
> 
> 
> 

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

[Daniel P. Berrangé]

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

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

[Yonggang Luo]

On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
> > > <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


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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#3749257

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


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Philippe Mathieu-Daudé]

On 1/10/26 10:13, Yonggang Luo wrote:
> On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
>>>> <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'

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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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/20260930020108.217892-1-pierrick.bouvier@oss.qualcomm.com/

Regards,

Phil.

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

[Yonggang Luo]

On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
<philmd@oss.qualcomm.com> wrote:
>
> On 1/10/26 10:13, Yonggang Luo wrote:
> > On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
> >>>> <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'
>
> 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.

Hi Philippe,
Fair point. Users shouldn’t need to know about other targets to use ARM
virt. Keep the machine name as virt; target selection in a combined
binary should be separate from -machine. This series doesn’t choose that
interface. With no target selected, help can list machines across targets,
but QEMU must not choose one arbitrarily.

>
> >
> >>
> >> 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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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/20260930020108.217892-1-pierrick.bouvier@oss.qualcomm.com/

Hi Philippe,

You’re right: I haven’t clearly explained what I’m trying to achieve, and
I’m sorry for not answering your questions sooner.

My goal is specifically to let a combined binary list all target-specific
machines when the target is none. This is for inspection, not for
selecting an arbitrary machine to run. Today, linking machines from
different targets hits QOM type-name conflicts. This series gives the
machine classes unique QOM names while preserving their familiar machine
names.

Pierrick’s series adds targets to a single linked binary and filters
machines according to the selected target. Its do not care about
machine listing for target "none". These patches address that separate
case and the QOM-name conflicts; they are not intended to conflict with
Pierrick’s target-selection work.

I’m not proposing argv-based target inference or a new -target interface
in this series. qemu-system-$arch is currently a separate executable,
not a symlink to qemu-system, so argv-based selection is outside this
work. This series do not conflict with either "-target $arch -machine $machine"
or "-machine $arch:$machine"


>
> Regards,
>
> Phil.



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Yonggang Luo]

On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
<philmd@oss.qualcomm.com> wrote:
>
> On 1/10/26 10:13, Yonggang Luo wrote:
> > On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
> >>>> <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'
>
> 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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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

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

[Pierrick Bouvier]

On 10/1/2026 9:14 AM, Yonggang Luo wrote:
> On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
>>
>> On 1/10/26 10:13, Yonggang Luo wrote:
>>> On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
>>>>>> <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'
>>
>> 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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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).
>

It's not strictly needed to expose all types. -target can be parsed
first, and influence what is visible from help (including -M help) also.

Also, if we go down the -target option, we should decide if we expose
all types or not, which means if we implement filtering or not. If we
expose all the types, I'm not sure what -target is supposed to choose.

Daniel, what do you think about this one?

>>
> 
>> Phil.
> 
> 
> 

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

[Daniel P. Berrangé]

On Thu, Oct 01, 2026 at 09:19:48AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 9:14 AM, Yonggang Luo wrote:
> > On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
> > <philmd@oss.qualcomm.com> wrote:
> >>
> >> On 1/10/26 10:13, Yonggang Luo wrote:
> >>> On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
> >>>>>> <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'
> >>
> >> 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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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).
> 
> It's not strictly needed to expose all types. -target can be parsed
> first, and influence what is visible from help (including -M help) also.
> 
> Also, if we go down the -target option, we should decide if we expose
> all types or not, which means if we implement filtering or not. If we
> expose all the types, I'm not sure what -target is supposed to choose.
> 
> Daniel, what do you think about this one?

*If* we take the starting assumption that the new multi-target
binary does not need to be a perfect replica of the existing
binaries, then filtering devices is creating extra work for
ourselves, to solve a problem that isn't especially important.

Even with the current per-target binaries there are countless
devices linked in which are incompatible / not usable with
certain machine types. A new multi-target binary with a union
of all devices will just be a bigger example of a scenario that
already has to be dealt with for today's binaries.

So if we have that assumption that we don't need to do device
filtering, at that point, a --target option doesn't have as
big of a role to play. The machine type code knows what target(s)
it wants (1 or 2 targets depending on if there are 32 + 64 bit
varaints. The CPU model the user requests (if the CPU is not
hardcoded by the machine), determines 32 bit vs 64 bit.

A --target option (or similar -machine name,target=xxx) could
be used to dis-ambiguate between 'virt' machines if keeping
their user facing machine names as-is, or it could be used as
a way to be more explicit about the 32-bit vs 64-bit choice
and sanity checked against the CPU model choice.

So overall "device filtering" or not is the key question to
decide IMHO.

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

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

[Pierrick Bouvier]

On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> On Thu, Oct 01, 2026 at 09:19:48AM -0700, Pierrick Bouvier wrote:
>> On 10/1/2026 9:14 AM, Yonggang Luo wrote:
>>> On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé
>>> <philmd@oss.qualcomm.com> wrote:
>>>>
>>>> On 1/10/26 10:13, Yonggang Luo wrote:
>>>>> On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <berrange@redhat.com> 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
>>>>>>>> <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'
>>>>
>>>> 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/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/#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).
>>
>> It's not strictly needed to expose all types. -target can be parsed
>> first, and influence what is visible from help (including -M help) also.
>>
>> Also, if we go down the -target option, we should decide if we expose
>> all types or not, which means if we implement filtering or not. If we
>> expose all the types, I'm not sure what -target is supposed to choose.
>>
>> Daniel, what do you think about this one?
> 
> *If* we take the starting assumption that the new multi-target
> binary does not need to be a perfect replica of the existing
> binaries, then filtering devices is creating extra work for
> ourselves, to solve a problem that isn't especially important.
>

Yes sure, just brainstorming here, to help Yonggang moving forward with
a clear direction.

> Even with the current per-target binaries there are countless
> devices linked in which are incompatible / not usable with
> certain machine types. A new multi-target binary with a union
> of all devices will just be a bigger example of a scenario that
> already has to be dealt with for today's binaries.
> 
> So if we have that assumption that we don't need to do device
> filtering, at that point, a --target option doesn't have as
> big of a role to play. The machine type code knows what target(s)
> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> varaints. The CPU model the user requests (if the CPU is not
> hardcoded by the machine), determines 32 bit vs 64 bit.
>

How can we deduce this information (bitness or target for existing
machines/cpus)?
Also, how to deal with devices that are only available for some targets,
but not others, depending on various Kconfig knobs?

> A --target option (or similar -machine name,target=xxx) could
> be used to dis-ambiguate between 'virt' machines if keeping
> their user facing machine names as-is, or it could be used as
> a way to be more explicit about the 32-bit vs 64-bit choice
> and sanity checked against the CPU model choice.
>

We could also not register them as virt if more than one target is
detected, so people have to call explicitly aarch64-virt.
Would that be a possible way to move forward?

> So overall "device filtering" or not is the key question to
> decide IMHO.
>

Fine for me. Just want to see how things will be before spending the
effort to review many patches when outcome is uncertain.

> With regards,
> Daniel

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

[Daniel P. Berrangé]

On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > Even with the current per-target binaries there are countless
> > devices linked in which are incompatible / not usable with
> > certain machine types. A new multi-target binary with a union
> > of all devices will just be a bigger example of a scenario that
> > already has to be dealt with for today's binaries.
> > 
> > So if we have that assumption that we don't need to do device
> > filtering, at that point, a --target option doesn't have as
> > big of a role to play. The machine type code knows what target(s)
> > it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > varaints. The CPU model the user requests (if the CPU is not
> > hardcoded by the machine), determines 32 bit vs 64 bit.
> >
> 
> How can we deduce this information (bitness or target for existing
> machines/cpus)?

It would require that we introduce a new field in MachineClass
that returned that information about what target a machine is
associated with.

I note the SysEmuTarget covers both 32-bit and 64-bit variants.

It might be better use QEMU_ARCH which correlates directly to
the TCG targets, rather than the traditional binary target
names ?

Likely the CPU class would also want to declare its list of
supported targets.

> Also, how to deal with devices that are only available for some targets,
> but not others, depending on various Kconfig knobs?

IMHO just leave devices to raise an error when passed to '-device'
if not compatible with the requested machine.

eg this example from x86 world:

  $ qemu-system-x86_64 -M microvm -device xen-disk
  qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'

  $ qemu-system-x86_64 -M isapc -device virtio-net-pci
  qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'

Hopefully most devices have sane error reporting when they
find a dependancy they have is not satisfied by the machine,
but if some end up asserting with crashes that's not a
blocker. Those asserts can be turned into pretty error
messages at our leisure by whomever cares about improving
error diagnosis.

> > A --target option (or similar -machine name,target=xxx) could
> > be used to dis-ambiguate between 'virt' machines if keeping
> > their user facing machine names as-is, or it could be used as
> > a way to be more explicit about the 32-bit vs 64-bit choice
> > and sanity checked against the CPU model choice.
> >
> 
> We could also not register them as virt if more than one target is
> detected, so people have to call explicitly aarch64-virt.
> Would that be a possible way to move forward?

Yes, we could diverge in the naming of the machines for the
existing binary, vs the new multi-binary, and that could well
be the sanest & simplest option in fact.

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

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

[Pierrick Bouvier]

On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
>> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
>>> Even with the current per-target binaries there are countless
>>> devices linked in which are incompatible / not usable with
>>> certain machine types. A new multi-target binary with a union
>>> of all devices will just be a bigger example of a scenario that
>>> already has to be dealt with for today's binaries.
>>>
>>> So if we have that assumption that we don't need to do device
>>> filtering, at that point, a --target option doesn't have as
>>> big of a role to play. The machine type code knows what target(s)
>>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
>>> varaints. The CPU model the user requests (if the CPU is not
>>> hardcoded by the machine), determines 32 bit vs 64 bit.
>>>
>>
>> How can we deduce this information (bitness or target for existing
>> machines/cpus)?
> 
> It would require that we introduce a new field in MachineClass
> that returned that information about what target a machine is
> associated with.
> 
> I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> 
> It might be better use QEMU_ARCH which correlates directly to
> the TCG targets, rather than the traditional binary target
> names ?
> 
> Likely the CPU class would also want to declare its list of
> supported targets.
>

QEMU_ARCH only represents base architectures, and not variant, so
SysEmuTarget is the right choice.

So, we would need a list of SysEmuTarget for every cpu/machine that is
target specific, since one could be available for variants of base arch?

@Yonggang: can you try to provide a RFC based on this, to see what it
could look like? No need to cover all machines/cpus, just select one of
machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
for aarch64), and let's iterate from this.

@Daniel: how do we deal with machines available for all targets like
null? We would need a way to ensure all machines/cpus are tagged
correctly, in an independent way from "available for all", without
having to repeat all existing SysEmuTarget.

>> Also, how to deal with devices that are only available for some targets,
>> but not others, depending on various Kconfig knobs?
> 
> IMHO just leave devices to raise an error when passed to '-device'
> if not compatible with the requested machine.
> 
> eg this example from x86 world:
> 
>   $ qemu-system-x86_64 -M microvm -device xen-disk
>   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> 
>   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
>   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> 
> Hopefully most devices have sane error reporting when they
> find a dependancy they have is not satisfied by the machine,
> but if some end up asserting with crashes that's not a
> blocker. Those asserts can be turned into pretty error
> messages at our leisure by whomever cares about improving
> error diagnosis.
>

Fine for me. I am a bit skeptical this will be possible to catch all
issues, but let's try!

>>> A --target option (or similar -machine name,target=xxx) could
>>> be used to dis-ambiguate between 'virt' machines if keeping
>>> their user facing machine names as-is, or it could be used as
>>> a way to be more explicit about the 32-bit vs 64-bit choice
>>> and sanity checked against the CPU model choice.
>>>
>>
>> We could also not register them as virt if more than one target is
>> detected, so people have to call explicitly aarch64-virt.
>> Would that be a possible way to move forward?
> 
> Yes, we could diverge in the naming of the machines for the
> existing binary, vs the new multi-binary, and that could well
> be the sanest & simplest option in fact.
>

So, for existing binary: -M virt works as before.

For new multi binary:
$ qemu-system -M virt:
Multiple machines were found, select one among:
- aarch64-virt
- riscv64-virt

Does it matches what you would expect?

Also, for compatibility with existing binaries, should we accept -M
$arch-virt also? I feel like it does not hurt and would make thing
simpler to switch between existing and new binary.

> With regards,
> Daniel

Regards,
Pierrick

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

[Yonggang Luo]

On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> >>> Even with the current per-target binaries there are countless
> >>> devices linked in which are incompatible / not usable with
> >>> certain machine types. A new multi-target binary with a union
> >>> of all devices will just be a bigger example of a scenario that
> >>> already has to be dealt with for today's binaries.
> >>>
> >>> So if we have that assumption that we don't need to do device
> >>> filtering, at that point, a --target option doesn't have as
> >>> big of a role to play. The machine type code knows what target(s)
> >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> >>> varaints. The CPU model the user requests (if the CPU is not
> >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> >>>
> >>
> >> How can we deduce this information (bitness or target for existing
> >> machines/cpus)?
> >
> > It would require that we introduce a new field in MachineClass
> > that returned that information about what target a machine is
> > associated with.
> >
> > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> >
> > It might be better use QEMU_ARCH which correlates directly to
> > the TCG targets, rather than the traditional binary target
> > names ?
> >
> > Likely the CPU class would also want to declare its list of
> > supported targets.
> >
>
> QEMU_ARCH only represents base architectures, and not variant, so
> SysEmuTarget is the right choice.
>
> So, we would need a list of SysEmuTarget for every cpu/machine that is
> target specific, since one could be available for variants of base arch?

For this, adding TargetInfo parameter to is_avaible callback will let us get the
list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
then check if that TargetInfo is present for every cpu/machine.
And indeed for devices if you want. That's what my patches are already done.

And also I have an idea about the set is_avaiable in an easy way. As
QOM basically
is a TREE, so for example x86_32 and x86_64 can share a same "i386"
base, all children's
is_avaiable inherent from parents is_avaiable, we can ensure every QOM
object have a
is_avaiable by update children is_avaiable from parents one.

>
> @Yonggang: can you try to provide a RFC based on this, to see what it
> could look like? No need to cover all machines/cpus, just select one of
> machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> for aarch64), and let's iterate from this.
>
> @Daniel: how do we deal with machines available for all targets like
> null? We would need a way to ensure all machines/cpus are tagged
> correctly, in an independent way from "available for all", without
> having to repeat all existing SysEmuTarget.
>
> >> Also, how to deal with devices that are only available for some targets,
> >> but not others, depending on various Kconfig knobs?
> >
> > IMHO just leave devices to raise an error when passed to '-device'
> > if not compatible with the requested machine.
> >
> > eg this example from x86 world:
> >
> >   $ qemu-system-x86_64 -M microvm -device xen-disk
> >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> >
> >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> >
> > Hopefully most devices have sane error reporting when they
> > find a dependancy they have is not satisfied by the machine,
> > but if some end up asserting with crashes that's not a
> > blocker. Those asserts can be turned into pretty error
> > messages at our leisure by whomever cares about improving
> > error diagnosis.
> >
>
> Fine for me. I am a bit skeptical this will be possible to catch all
> issues, but let's try!
>
> So, for existing binary: -M virt works as before.
>
> For new multi binary:
> $ qemu-system -M virt:
> Multiple machines were found, select one among:
> - aarch64-virt
> - riscv64-virt

This would be very hard, that means QOM must be initialized. but we need
ensure the target is selected before the QOM init. it's the current
qemu_init workflow
A possible solution with add TargetInfo parameter on is_avaible is
that we can listing
all machines that named with virt, and listing which targets support
"virt". For example

$qemu-system -M virt:
Multiple machines were found, select one among:
-target aarch64 -M virt
-target riscv64 -M virt

As for qemu-system -M virt:, default to none target. That means all
machines are registered
into QOM, so we can list all machines. to help us identify which
targets that those
machines belongs to

>
> Does it matches what you would expect?
>
> Also, for compatibility with existing binaries, should we accept -M
> $arch-virt also? I feel like it does not hurt and would make thing
> simpler to switch between existing and new binary.

Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
would be even harder.
Because "-" is a valid separator in machine names, ":" is not a valid
machine name.
So without init QOM, we can not reliably identify "$arch-virt" belongs
to which target.

>
> Regards,
> Pierrick



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Pierrick Bouvier]

On 10/1/2026 7:00 PM, Yonggang Luo wrote:
> On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
>>
>> On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
>>> On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
>>>> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
>>>>> Even with the current per-target binaries there are countless
>>>>> devices linked in which are incompatible / not usable with
>>>>> certain machine types. A new multi-target binary with a union
>>>>> of all devices will just be a bigger example of a scenario that
>>>>> already has to be dealt with for today's binaries.
>>>>>
>>>>> So if we have that assumption that we don't need to do device
>>>>> filtering, at that point, a --target option doesn't have as
>>>>> big of a role to play. The machine type code knows what target(s)
>>>>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
>>>>> varaints. The CPU model the user requests (if the CPU is not
>>>>> hardcoded by the machine), determines 32 bit vs 64 bit.
>>>>>
>>>>
>>>> How can we deduce this information (bitness or target for existing
>>>> machines/cpus)?
>>>
>>> It would require that we introduce a new field in MachineClass
>>> that returned that information about what target a machine is
>>> associated with.
>>>
>>> I note the SysEmuTarget covers both 32-bit and 64-bit variants.
>>>
>>> It might be better use QEMU_ARCH which correlates directly to
>>> the TCG targets, rather than the traditional binary target
>>> names ?
>>>
>>> Likely the CPU class would also want to declare its list of
>>> supported targets.
>>>
>>
>> QEMU_ARCH only represents base architectures, and not variant, so
>> SysEmuTarget is the right choice.
>>
>> So, we would need a list of SysEmuTarget for every cpu/machine that is
>> target specific, since one could be available for variants of base arch?
> 
> For this, adding TargetInfo parameter to is_avaible callback will let us get the
> list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
> then check if that TargetInfo is present for every cpu/machine.
> And indeed for devices if you want. That's what my patches are already done.
>

@Daniel: would that work for you? I feel like it limits the way to
introspect qom objects, but maybe not if we export the right thing on
QAPI side based on that.

> And also I have an idea about the set is_avaiable in an easy way. As
> QOM basically
> is a TREE, so for example x86_32 and x86_64 can share a same "i386"
> base, all children's
> is_avaiable inherent from parents is_avaiable, we can ensure every QOM
> object have a
> is_avaiable by update children is_avaiable from parents one.
> 
>>
>> @Yonggang: can you try to provide a RFC based on this, to see what it
>> could look like? No need to cover all machines/cpus, just select one of
>> machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
>> for aarch64), and let's iterate from this.
>>
>> @Daniel: how do we deal with machines available for all targets like
>> null? We would need a way to ensure all machines/cpus are tagged
>> correctly, in an independent way from "available for all", without
>> having to repeat all existing SysEmuTarget.
>>
>>>> Also, how to deal with devices that are only available for some targets,
>>>> but not others, depending on various Kconfig knobs?
>>>
>>> IMHO just leave devices to raise an error when passed to '-device'
>>> if not compatible with the requested machine.
>>>
>>> eg this example from x86 world:
>>>
>>>   $ qemu-system-x86_64 -M microvm -device xen-disk
>>>   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
>>>
>>>   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
>>>   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
>>>
>>> Hopefully most devices have sane error reporting when they
>>> find a dependancy they have is not satisfied by the machine,
>>> but if some end up asserting with crashes that's not a
>>> blocker. Those asserts can be turned into pretty error
>>> messages at our leisure by whomever cares about improving
>>> error diagnosis.
>>>
>>
>> Fine for me. I am a bit skeptical this will be possible to catch all
>> issues, but let's try!
>>
>> So, for existing binary: -M virt works as before.
>>
>> For new multi binary:
>> $ qemu-system -M virt:
>> Multiple machines were found, select one among:
>> - aarch64-virt
>> - riscv64-virt
> 
> This would be very hard, that means QOM must be initialized. but we need
> ensure the target is selected before the QOM init. it's the current
> qemu_init workflow
> A possible solution with add TargetInfo parameter on is_avaible is
> that we can listing
> all machines that named with virt, and listing which targets support
> "virt". For example
> 
> $qemu-system -M virt:
> Multiple machines were found, select one among:
> -target aarch64 -M virt
> -target riscv64 -M virt
> 
> As for qemu-system -M virt:, default to none target. That means all
> machines are registered
> into QOM, so we can list all machines. to help us identify which
> targets that those
> machines belongs to
> 
>>
>> Does it matches what you would expect?
>>
>> Also, for compatibility with existing binaries, should we accept -M
>> $arch-virt also? I feel like it does not hurt and would make thing
>> simpler to switch between existing and new binary.
> 
> Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> would be even harder.
> Because "-" is a valid separator in machine names, ":" is not a valid
> machine name.
> So without init QOM, we can not reliably identify "$arch-virt" belongs
> to which target.
>

From the conversation above, Daniel and I are not in favor to have any
kind of parsing based on this string. So either we'll pick virt, or the
real qom name, but not anything else.

>>
>> Regards,
>> Pierrick
> 
> 
> 

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

[Daniel P. Berrangé]

On Fri, Oct 02, 2026 at 08:40:54AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 7:00 PM, Yonggang Luo wrote:
> > On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
> > <pierrick.bouvier@oss.qualcomm.com> wrote:
> >>
> >> On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> >>> On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> >>>> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> >>>>> Even with the current per-target binaries there are countless
> >>>>> devices linked in which are incompatible / not usable with
> >>>>> certain machine types. A new multi-target binary with a union
> >>>>> of all devices will just be a bigger example of a scenario that
> >>>>> already has to be dealt with for today's binaries.
> >>>>>
> >>>>> So if we have that assumption that we don't need to do device
> >>>>> filtering, at that point, a --target option doesn't have as
> >>>>> big of a role to play. The machine type code knows what target(s)
> >>>>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> >>>>> varaints. The CPU model the user requests (if the CPU is not
> >>>>> hardcoded by the machine), determines 32 bit vs 64 bit.
> >>>>>
> >>>>
> >>>> How can we deduce this information (bitness or target for existing
> >>>> machines/cpus)?
> >>>
> >>> It would require that we introduce a new field in MachineClass
> >>> that returned that information about what target a machine is
> >>> associated with.
> >>>
> >>> I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> >>>
> >>> It might be better use QEMU_ARCH which correlates directly to
> >>> the TCG targets, rather than the traditional binary target
> >>> names ?
> >>>
> >>> Likely the CPU class would also want to declare its list of
> >>> supported targets.
> >>>
> >>
> >> QEMU_ARCH only represents base architectures, and not variant, so
> >> SysEmuTarget is the right choice.
> >>
> >> So, we would need a list of SysEmuTarget for every cpu/machine that is
> >> target specific, since one could be available for variants of base arch?
> > 
> > For this, adding TargetInfo parameter to is_avaible callback will let us get the
> > list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
> > then check if that TargetInfo is present for every cpu/machine.
> > And indeed for devices if you want. That's what my patches are already done.
> >
> 
> @Daniel: would that work for you? I feel like it limits the way to
> introspect qom objects, but maybe not if we export the right thing on
> QAPI side based on that.

"is_available" is probably a bit overkill as a mechanism for
introspecting, when we just need to return a list of targets,
Since we have that already we might as well use it initially
though.

> >> Does it matches what you would expect?
> >>
> >> Also, for compatibility with existing binaries, should we accept -M
> >> $arch-virt also? I feel like it does not hurt and would make thing
> >> simpler to switch between existing and new binary.
> > 
> > Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> > would be even harder.
> > Because "-" is a valid separator in machine names, ":" is not a valid
> > machine name.
> > So without init QOM, we can not reliably identify "$arch-virt" belongs
> > to which target.
> >
> 
> From the conversation above, Daniel and I are not in favor to have any
> kind of parsing based on this string. So either we'll pick virt, or the
> real qom name, but not anything else.

Yeah, I'm leaning more towards always exposing the $arch-virt names
in all binaries, and also exposing 'virt' in the traditional
binaries only.


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

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

[Yonggang Luo]

On Sat, Oct 3, 2026 at 12:32 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> "is_available" is probably a bit overkill as a mechanism for
> introspecting, when we just need to return a list of targets,
> Since we have that already we might as well use it initially
> though.

I have experimented with x86_64/i386 arm/aarch64 riscv32/riscv64 so
that I can tell:
using is_available will be a better option. As we can use inherent the
is_available from
parent, if we just use a bit set like QEMU_ARCH_ARM, then that means we need
specify it for every single machine. And if any customization is
needed, for example, depends
on KVM config or other accel config or any condition not just
QEMU_ARCH_*, then is_available
still needed, so I would insist is_available with a TargetInfo*
parameter, then all concern
will be addressed.



>
> > >> Does it matches what you would expect?
> > >>
> > >> Also, for compatibility with existing binaries, should we accept -M
> > >> $arch-virt also? I feel like it does not hurt and would make thing
> > >> simpler to switch between existing and new binary.
> > >
> > > Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> > > would be even harder.
> > > Because "-" is a valid separator in machine names, ":" is not a valid
> > > machine name.
> > > So without init QOM, we can not reliably identify "$arch-virt" belongs
> > > to which target.
> > >
> >
> > From the conversation above, Daniel and I are not in favor to have any
> > kind of parsing based on this string. So either we'll pick virt, or the
> > real qom name, but not anything else.
>
> Yeah, I'm leaning more towards always exposing the $arch-virt names
> in all binaries, and also exposing 'virt' in the traditional
> binaries only.

I have a question, do we expose the "$arch-virt" as a machine "name"
and expose "$arch-virt" as machine qom "typename";
or expose "virt" as a machine "name" and expose "$arch-virt" as
machine qom "typename".

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


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Daniel P. Berrangé]

On Sat, Oct 03, 2026 at 12:43:19AM +0800, Yonggang Luo wrote:
> On Sat, Oct 3, 2026 at 12:32 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > "is_available" is probably a bit overkill as a mechanism for
> > introspecting, when we just need to return a list of targets,
> > Since we have that already we might as well use it initially
> > though.
> 
> I have experimented with x86_64/i386 arm/aarch64 riscv32/riscv64 so
> that I can tell:
> using is_available will be a better option. As we can use inherent the
> is_available from
> parent, if we just use a bit set like QEMU_ARCH_ARM, then that means we need
> specify it for every single machine. And if any customization is
> needed, for example, depends
> on KVM config or other accel config or any condition not just
> QEMU_ARCH_*, then is_available
> still needed, so I would insist is_available with a TargetInfo*
> parameter, then all concern
> will be addressed.
> 
> 
> 
> >
> > > >> Does it matches what you would expect?
> > > >>
> > > >> Also, for compatibility with existing binaries, should we accept -M
> > > >> $arch-virt also? I feel like it does not hurt and would make thing
> > > >> simpler to switch between existing and new binary.
> > > >
> > > > Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> > > > would be even harder.
> > > > Because "-" is a valid separator in machine names, ":" is not a valid
> > > > machine name.
> > > > So without init QOM, we can not reliably identify "$arch-virt" belongs
> > > > to which target.
> > > >
> > >
> > > From the conversation above, Daniel and I are not in favor to have any
> > > kind of parsing based on this string. So either we'll pick virt, or the
> > > real qom name, but not anything else.
> >
> > Yeah, I'm leaning more towards always exposing the $arch-virt names
> > in all binaries, and also exposing 'virt' in the traditional
> > binaries only.
> 
> I have a question, do we expose the "$arch-virt" as a machine "name"
> and expose "$arch-virt" as machine qom "typename";
> or expose "virt" as a machine "name" and expose "$arch-virt" as
> machine qom "typename".

The human facing machine "name" is the important one.

For the QOM typename, I don't really mind either way. If we can keep
the QOM typename and human "name" matching that's nice, but if they
differ, then it is not a big deal - your series has the patch to
expose the QOM typename in QAPI 'MachineInfo' which addresses the
only downside of them differing. So whatever approach works best when
implementing the ideas...

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

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

[Yonggang Luo]

On Sat, Oct 3, 2026 at 12:52 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sat, Oct 03, 2026 at 12:43:19AM +0800, Yonggang Luo wrote:
> > On Sat, Oct 3, 2026 at 12:32 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > "is_available" is probably a bit overkill as a mechanism for
> > > introspecting, when we just need to return a list of targets,
> > > Since we have that already we might as well use it initially
> > > though.
> >
> > I have experimented with x86_64/i386 arm/aarch64 riscv32/riscv64 so
> > that I can tell:
> > using is_available will be a better option. As we can use inherent the
> > is_available from
> > parent, if we just use a bit set like QEMU_ARCH_ARM, then that means we need
> > specify it for every single machine. And if any customization is
> > needed, for example, depends
> > on KVM config or other accel config or any condition not just
> > QEMU_ARCH_*, then is_available
> > still needed, so I would insist is_available with a TargetInfo*
> > parameter, then all concern
> > will be addressed.
> >
> >
> >
> > >
> > > > >> Does it matches what you would expect?
> > > > >>
> > > > >> Also, for compatibility with existing binaries, should we accept -M
> > > > >> $arch-virt also? I feel like it does not hurt and would make thing
> > > > >> simpler to switch between existing and new binary.
> > > > >
> > > > > Same reason -M $arch-virt, indeed like -M $arch:virt,  but $arch-virt
> > > > > would be even harder.
> > > > > Because "-" is a valid separator in machine names, ":" is not a valid
> > > > > machine name.
> > > > > So without init QOM, we can not reliably identify "$arch-virt" belongs
> > > > > to which target.
> > > > >
> > > >
> > > > From the conversation above, Daniel and I are not in favor to have any
> > > > kind of parsing based on this string. So either we'll pick virt, or the
> > > > real qom name, but not anything else.
> > >
> > > Yeah, I'm leaning more towards always exposing the $arch-virt names
> > > in all binaries, and also exposing 'virt' in the traditional
> > > binaries only.
> >
> > I have a question, do we expose the "$arch-virt" as a machine "name"
> > and expose "$arch-virt" as machine qom "typename";
> > or expose "virt" as a machine "name" and expose "$arch-virt" as
> > machine qom "typename".
>
> The human facing machine "name" is the important one.
>
> For the QOM typename, I don't really mind either way. If we can keep
> the QOM typename and human "name" matching that's nice, but if they
> differ, then it is not a big deal - your series has the patch to
> expose the QOM typename in QAPI 'MachineInfo' which addresses the
> only downside of them differing. So whatever approach works best when
> implementing the ideas...

Then it's clear, for
single-target binary:
"virt" as machine "name" and "virt" as qom "typename"
multi-target binary:
"virt" as machine "name" and "$arch-virt" as qom "typename"


So for humans, we still use the familiar "virt". And for libvirt and so on
they still can use the old way to talk with qemu-system-$arch.
And to talk with the new qemu-system, we have returned qom "typename"
for them, the libvirt and so
on needs to be updated(not a big deal) as the qemu-system is a new
thing. If no more new concern
I'll go this direction for this series.

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


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Daniel P. Berrangé]

On Fri, Oct 02, 2026 at 10:00:24AM +0800, Yonggang Luo wrote:
> On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >
> > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > >>> Even with the current per-target binaries there are countless
> > >>> devices linked in which are incompatible / not usable with
> > >>> certain machine types. A new multi-target binary with a union
> > >>> of all devices will just be a bigger example of a scenario that
> > >>> already has to be dealt with for today's binaries.
> > >>>
> > >>> So if we have that assumption that we don't need to do device
> > >>> filtering, at that point, a --target option doesn't have as
> > >>> big of a role to play. The machine type code knows what target(s)
> > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > >>> varaints. The CPU model the user requests (if the CPU is not
> > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > >>>
> > >>
> > >> How can we deduce this information (bitness or target for existing
> > >> machines/cpus)?
> > >
> > > It would require that we introduce a new field in MachineClass
> > > that returned that information about what target a machine is
> > > associated with.
> > >
> > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > >
> > > It might be better use QEMU_ARCH which correlates directly to
> > > the TCG targets, rather than the traditional binary target
> > > names ?
> > >
> > > Likely the CPU class would also want to declare its list of
> > > supported targets.
> > >
> >
> > QEMU_ARCH only represents base architectures, and not variant, so
> > SysEmuTarget is the right choice.
> >
> > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > target specific, since one could be available for variants of base arch?
> 
> For this, adding TargetInfo parameter to is_avaible callback will let us get the
> list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
> then check if that TargetInfo is present for every cpu/machine.
> And indeed for devices if you want. That's what my patches are already done.
> 
> And also I have an idea about the set is_avaiable in an easy way. As
> QOM basically
> is a TREE, so for example x86_32 and x86_64 can share a same "i386"
> base, all children's
> is_avaiable inherent from parents is_avaiable, we can ensure every QOM
> object have a
> is_avaiable by update children is_avaiable from parents one.
> 
> >
> > @Yonggang: can you try to provide a RFC based on this, to see what it
> > could look like? No need to cover all machines/cpus, just select one of
> > machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> > for aarch64), and let's iterate from this.
> >
> > @Daniel: how do we deal with machines available for all targets like
> > null? We would need a way to ensure all machines/cpus are tagged
> > correctly, in an independent way from "available for all", without
> > having to repeat all existing SysEmuTarget.
> >
> > >> Also, how to deal with devices that are only available for some targets,
> > >> but not others, depending on various Kconfig knobs?
> > >
> > > IMHO just leave devices to raise an error when passed to '-device'
> > > if not compatible with the requested machine.
> > >
> > > eg this example from x86 world:
> > >
> > >   $ qemu-system-x86_64 -M microvm -device xen-disk
> > >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> > >
> > >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> > >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> > >
> > > Hopefully most devices have sane error reporting when they
> > > find a dependancy they have is not satisfied by the machine,
> > > but if some end up asserting with crashes that's not a
> > > blocker. Those asserts can be turned into pretty error
> > > messages at our leisure by whomever cares about improving
> > > error diagnosis.
> > >
> >
> > Fine for me. I am a bit skeptical this will be possible to catch all
> > issues, but let's try!
> >
> > So, for existing binary: -M virt works as before.
> >
> > For new multi binary:
> > $ qemu-system -M virt:
> > Multiple machines were found, select one among:
> > - aarch64-virt
> > - riscv64-virt
> 
> This would be very hard, that means QOM must be initialized. but we need
> ensure the target is selected before the QOM init.

We don't need to have initialized anything. We just need a single
global variable, whose default initializer is true vs false, for
for the separate vs multi-target binaries. That's just a pair of
.o files with a single bool variable, that we choose between when
linking.


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

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

[Yonggang Luo]

On Sat, Oct 3, 2026 at 12:17 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Oct 02, 2026 at 10:00:24AM +0800, Yonggang Luo wrote:
> > On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
> > <pierrick.bouvier@oss.qualcomm.com> wrote:
> > >
> > > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > > >>> Even with the current per-target binaries there are countless
> > > >>> devices linked in which are incompatible / not usable with
> > > >>> certain machine types. A new multi-target binary with a union
> > > >>> of all devices will just be a bigger example of a scenario that
> > > >>> already has to be dealt with for today's binaries.
> > > >>>
> > > >>> So if we have that assumption that we don't need to do device
> > > >>> filtering, at that point, a --target option doesn't have as
> > > >>> big of a role to play. The machine type code knows what target(s)
> > > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > > >>> varaints. The CPU model the user requests (if the CPU is not
> > > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > > >>>
> > > >>
> > > >> How can we deduce this information (bitness or target for existing
> > > >> machines/cpus)?
> > > >
> > > > It would require that we introduce a new field in MachineClass
> > > > that returned that information about what target a machine is
> > > > associated with.
> > > >
> > > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > > >
> > > > It might be better use QEMU_ARCH which correlates directly to
> > > > the TCG targets, rather than the traditional binary target
> > > > names ?
> > > >
> > > > Likely the CPU class would also want to declare its list of
> > > > supported targets.
> > > >
> > >
> > > QEMU_ARCH only represents base architectures, and not variant, so
> > > SysEmuTarget is the right choice.
> > >
> > > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > > target specific, since one could be available for variants of base arch?
> >
> > For this, adding TargetInfo parameter to is_avaible callback will let us get the
> > list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
> > then check if that TargetInfo is present for every cpu/machine.
> > And indeed for devices if you want. That's what my patches are already done.
> >
> > And also I have an idea about the set is_avaiable in an easy way. As
> > QOM basically
> > is a TREE, so for example x86_32 and x86_64 can share a same "i386"
> > base, all children's
> > is_avaiable inherent from parents is_avaiable, we can ensure every QOM
> > object have a
> > is_avaiable by update children is_avaiable from parents one.
> >
> > >
> > > @Yonggang: can you try to provide a RFC based on this, to see what it
> > > could look like? No need to cover all machines/cpus, just select one of
> > > machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> > > for aarch64), and let's iterate from this.
> > >
> > > @Daniel: how do we deal with machines available for all targets like
> > > null? We would need a way to ensure all machines/cpus are tagged
> > > correctly, in an independent way from "available for all", without
> > > having to repeat all existing SysEmuTarget.
> > >
> > > >> Also, how to deal with devices that are only available for some targets,
> > > >> but not others, depending on various Kconfig knobs?
> > > >
> > > > IMHO just leave devices to raise an error when passed to '-device'
> > > > if not compatible with the requested machine.
> > > >
> > > > eg this example from x86 world:
> > > >
> > > >   $ qemu-system-x86_64 -M microvm -device xen-disk
> > > >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> > > >
> > > >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> > > >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> > > >
> > > > Hopefully most devices have sane error reporting when they
> > > > find a dependancy they have is not satisfied by the machine,
> > > > but if some end up asserting with crashes that's not a
> > > > blocker. Those asserts can be turned into pretty error
> > > > messages at our leisure by whomever cares about improving
> > > > error diagnosis.
> > > >
> > >
> > > Fine for me. I am a bit skeptical this will be possible to catch all
> > > issues, but let's try!
> > >
> > > So, for existing binary: -M virt works as before.
> > >
> > > For new multi binary:
> > > $ qemu-system -M virt:
> > > Multiple machines were found, select one among:
> > > - aarch64-virt
> > > - riscv64-virt
> >
> > This would be very hard, that means QOM must be initialized. but we need
> > ensure the target is selected before the QOM init.
>
> We don't need to have initialized anything. We just need a single
> global variable, whose default initializer is true vs false, for
> for the separate vs multi-target binaries. That's just a pair of
> .o files with a single bool variable, that we choose between when
> linking.

Use functions have a better property that it won't be modified when
running as it's not data.
And using "extern bool multi_target;" is also fine.

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


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Yonggang Luo]

On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> So, for existing binary: -M virt works as before.
>
> For new multi binary:
> $ qemu-system -M virt:
> Multiple machines were found, select one among:
> - aarch64-virt
> - riscv64-virt


This is what I implemented:
 ./qemu-system -M virt
qemu-system: unsupported machine type: "virt" for target "none"
Available for targets: aarch64, arm


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Yonggang Luo]

On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
>
> @Yonggang: can you try to provide a RFC based on this, to see what it
> could look like? No need to cover all machines/cpus, just select one of
> machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> for aarch64), and let's iterate from this.


Hi, I provided the RFC at https://gitlab.com/qemu-project/qemu/-/work_items/4635
Not sure if anything is lost, if there is some, I can update that
work_items easily.



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Daniel P. Berrangé]

On Thu, Oct 01, 2026 at 11:56:13AM -0700, Pierrick Bouvier wrote:
> On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> >>> Even with the current per-target binaries there are countless
> >>> devices linked in which are incompatible / not usable with
> >>> certain machine types. A new multi-target binary with a union
> >>> of all devices will just be a bigger example of a scenario that
> >>> already has to be dealt with for today's binaries.
> >>>
> >>> So if we have that assumption that we don't need to do device
> >>> filtering, at that point, a --target option doesn't have as
> >>> big of a role to play. The machine type code knows what target(s)
> >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> >>> varaints. The CPU model the user requests (if the CPU is not
> >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> >>>
> >>
> >> How can we deduce this information (bitness or target for existing
> >> machines/cpus)?
> > 
> > It would require that we introduce a new field in MachineClass
> > that returned that information about what target a machine is
> > associated with.
> > 
> > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > 
> > It might be better use QEMU_ARCH which correlates directly to
> > the TCG targets, rather than the traditional binary target
> > names ?
> > 
> > Likely the CPU class would also want to declare its list of
> > supported targets.
> >
> 
> QEMU_ARCH only represents base architectures, and not variant, so
> SysEmuTarget is the right choice.
> 
> So, we would need a list of SysEmuTarget for every cpu/machine that is
> target specific, since one could be available for variants of base arch?

Ok

> @Daniel: how do we deal with machines available for all targets like
> null? We would need a way to ensure all machines/cpus are tagged
> correctly, in an independent way from "available for all", without
> having to repeat all existing SysEmuTarget.

Or could the 'none' machine simply report '0xffffffff' for the
list of targets so it includes everything today & in the future,
or specialize "0" to mean everything ?


> > eg this example from x86 world:
> > 
> >   $ qemu-system-x86_64 -M microvm -device xen-disk
> >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> > 
> >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> > 
> > Hopefully most devices have sane error reporting when they
> > find a dependancy they have is not satisfied by the machine,
> > but if some end up asserting with crashes that's not a
> > blocker. Those asserts can be turned into pretty error
> > messages at our leisure by whomever cares about improving
> > error diagnosis.
> >
> 
> Fine for me. I am a bit skeptical this will be possible to catch all
> issues, but let's try!

I'm confident that we will find badly behaviour devices,
but we don't need to fix it all upfront, and they would
arguably be considered buggy already today.

> >>> A --target option (or similar -machine name,target=xxx) could
> >>> be used to dis-ambiguate between 'virt' machines if keeping
> >>> their user facing machine names as-is, or it could be used as
> >>> a way to be more explicit about the 32-bit vs 64-bit choice
> >>> and sanity checked against the CPU model choice.
> >>>
> >>
> >> We could also not register them as virt if more than one target is
> >> detected, so people have to call explicitly aarch64-virt.
> >> Would that be a possible way to move forward?
> > 
> > Yes, we could diverge in the naming of the machines for the
> > existing binary, vs the new multi-binary, and that could well
> > be the sanest & simplest option in fact.
> >
> 
> So, for existing binary: -M virt works as before.

Yes.


> For new multi binary:
> $ qemu-system -M virt:
> Multiple machines were found, select one among:
> - aarch64-virt
> - riscv64-virt
> 
> Does it matches what you would expect?


One idea I had was that when define the 'virt' class type we could
have a way to identify whether it is linked into the traditional
binaries, or linked into the multi-target binary, and from
that choose what name to register it under. eg

  "extern bool multi_target;"

and have two .c files, one setting it 'true' and one 'false',
and link each to the respective binaries. So we know statically
before main() has even run, what mode this binary is intended
to operate in.

> Also, for compatibility with existing binaries, should we accept -M
> $arch-virt also? I feel like it does not hurt and would make thing
> simpler to switch between existing and new binary.

Yes, that's another viable option. Always register '$arch-virt' and
only register 'virt' for traditional binaries.


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

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

[Yonggang Luo]

On Sat, Oct 3, 2026 at 12:14 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Oct 01, 2026 at 11:56:13AM -0700, Pierrick Bouvier wrote:
> > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > >>> Even with the current per-target binaries there are countless
> > >>> devices linked in which are incompatible / not usable with
> > >>> certain machine types. A new multi-target binary with a union
> > >>> of all devices will just be a bigger example of a scenario that
> > >>> already has to be dealt with for today's binaries.
> > >>>
> > >>> So if we have that assumption that we don't need to do device
> > >>> filtering, at that point, a --target option doesn't have as
> > >>> big of a role to play. The machine type code knows what target(s)
> > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > >>> varaints. The CPU model the user requests (if the CPU is not
> > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > >>>
> > >>
> > >> How can we deduce this information (bitness or target for existing
> > >> machines/cpus)?
> > >
> > > It would require that we introduce a new field in MachineClass
> > > that returned that information about what target a machine is
> > > associated with.
> > >
> > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > >
> > > It might be better use QEMU_ARCH which correlates directly to
> > > the TCG targets, rather than the traditional binary target
> > > names ?
> > >
> > > Likely the CPU class would also want to declare its list of
> > > supported targets.
> > >
> >
> > QEMU_ARCH only represents base architectures, and not variant, so
> > SysEmuTarget is the right choice.
> >
> > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > target specific, since one could be available for variants of base arch?
>
> Ok
>
> > @Daniel: how do we deal with machines available for all targets like
> > null? We would need a way to ensure all machines/cpus are tagged
> > correctly, in an independent way from "available for all", without
> > having to repeat all existing SysEmuTarget.
>
> Or could the 'none' machine simply report '0xffffffff' for the
> list of targets so it includes everything today & in the future,
> or specialize "0" to mean everything ?
I think for is_avaible give a
bool target_is_any(const TargetInfo *ti)
{
    (void)ti;
    return true;
}
is enough. then we iterate the target list we will found every target
support for it.



>
>
> > > eg this example from x86 world:
> > >
> > >   $ qemu-system-x86_64 -M microvm -device xen-disk
> > >   qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'
> > >
> > >   $ qemu-system-x86_64 -M isapc -device virtio-net-pci
> > >   qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'
> > >
> > > Hopefully most devices have sane error reporting when they
> > > find a dependancy they have is not satisfied by the machine,
> > > but if some end up asserting with crashes that's not a
> > > blocker. Those asserts can be turned into pretty error
> > > messages at our leisure by whomever cares about improving
> > > error diagnosis.
> > >
> >
> > Fine for me. I am a bit skeptical this will be possible to catch all
> > issues, but let's try!
>
> I'm confident that we will find badly behaviour devices,
> but we don't need to fix it all upfront, and they would
> arguably be considered buggy already today.
>
> > >>> A --target option (or similar -machine name,target=xxx) could
> > >>> be used to dis-ambiguate between 'virt' machines if keeping
> > >>> their user facing machine names as-is, or it could be used as
> > >>> a way to be more explicit about the 32-bit vs 64-bit choice
> > >>> and sanity checked against the CPU model choice.
> > >>>
> > >>
> > >> We could also not register them as virt if more than one target is
> > >> detected, so people have to call explicitly aarch64-virt.
> > >> Would that be a possible way to move forward?
> > >
> > > Yes, we could diverge in the naming of the machines for the
> > > existing binary, vs the new multi-binary, and that could well
> > > be the sanest & simplest option in fact.
> > >
> >
> > So, for existing binary: -M virt works as before.
>
> Yes.
>
>
> > For new multi binary:
> > $ qemu-system -M virt:
> > Multiple machines were found, select one among:
> > - aarch64-virt
> > - riscv64-virt
> >
> > Does it matches what you would expect?
>
>
> One idea I had was that when define the 'virt' class type we could
> have a way to identify whether it is linked into the traditional
> binaries, or linked into the multi-target binary, and from
> that choose what name to register it under. eg
>
>   "extern bool multi_target;"

This idea already resolved,  see commit
https://gitlab.com/lygstate-qemu/qemu/-/commit/3342c04451bb21174e6bd53a7040e4929008b9d0
The idea is
bool target_combined_binary(void)
{
    return true;
}
for multi-target binary, and stub for single-target binary
for single-target binary
bool target_combined_binary(void)
{
    return false;
}

>
> and have two .c files, one setting it 'true' and one 'false',
> and link each to the respective binaries. So we know statically
> before main() has even run, what mode this binary is intended
> to operate in.
>
> > Also, for compatibility with existing binaries, should we accept -M
> > $arch-virt also? I feel like it does not hurt and would make thing
> > simpler to switch between existing and new binary.
>
> Yes, that's another viable option. Always register '$arch-virt' and
> only register 'virt' for traditional binaries.
Oh, I see, for single-target binary, the "virt" is QOM name, and for
multi-target binary.
"$arch-virt" is the QOM name? So this series needs to consider this. made sense.
>
>
> 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 :|
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Daniel P. Berrangé]

On Sat, Oct 03, 2026 at 12:27:08AM +0800, Yonggang Luo wrote:
> On Sat, Oct 3, 2026 at 12:14 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Oct 01, 2026 at 11:56:13AM -0700, Pierrick Bouvier wrote:
> > > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > > >>> Even with the current per-target binaries there are countless
> > > >>> devices linked in which are incompatible / not usable with
> > > >>> certain machine types. A new multi-target binary with a union
> > > >>> of all devices will just be a bigger example of a scenario that
> > > >>> already has to be dealt with for today's binaries.
> > > >>>
> > > >>> So if we have that assumption that we don't need to do device
> > > >>> filtering, at that point, a --target option doesn't have as
> > > >>> big of a role to play. The machine type code knows what target(s)
> > > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > > >>> varaints. The CPU model the user requests (if the CPU is not
> > > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > > >>>
> > > >>
> > > >> How can we deduce this information (bitness or target for existing
> > > >> machines/cpus)?
> > > >
> > > > It would require that we introduce a new field in MachineClass
> > > > that returned that information about what target a machine is
> > > > associated with.
> > > >
> > > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > > >
> > > > It might be better use QEMU_ARCH which correlates directly to
> > > > the TCG targets, rather than the traditional binary target
> > > > names ?
> > > >
> > > > Likely the CPU class would also want to declare its list of
> > > > supported targets.
> > > >
> > >
> > > QEMU_ARCH only represents base architectures, and not variant, so
> > > SysEmuTarget is the right choice.
> > >
> > > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > > target specific, since one could be available for variants of base arch?
> >
> > Ok
> >
> > > @Daniel: how do we deal with machines available for all targets like
> > > null? We would need a way to ensure all machines/cpus are tagged
> > > correctly, in an independent way from "available for all", without
> > > having to repeat all existing SysEmuTarget.
> >
> > Or could the 'none' machine simply report '0xffffffff' for the
> > list of targets so it includes everything today & in the future,
> > or specialize "0" to mean everything ?
> I think for is_avaible give a
> bool target_is_any(const TargetInfo *ti)
> {
>     (void)ti;
>     return true;
> }
> is enough. then we iterate the target list we will found every target
> support for it.

Yep, that would work.


> > One idea I had was that when define the 'virt' class type we could
> > have a way to identify whether it is linked into the traditional
> > binaries, or linked into the multi-target binary, and from
> > that choose what name to register it under. eg
> >
> >   "extern bool multi_target;"
> 
> This idea already resolved,  see commit
> https://gitlab.com/lygstate-qemu/qemu/-/commit/3342c04451bb21174e6bd53a7040e4929008b9d0
> The idea is
> bool target_combined_binary(void)
> {
>     return true;
> }
> for multi-target binary, and stub for single-target binary
> for single-target binary
> bool target_combined_binary(void)
> {
>     return false;
> }

Ok, yes, that works, even if that feels a bit like overkill
vs a global variable !

> > and have two .c files, one setting it 'true' and one 'false',
> > and link each to the respective binaries. So we know statically
> > before main() has even run, what mode this binary is intended
> > to operate in.
> >
> > > Also, for compatibility with existing binaries, should we accept -M
> > > $arch-virt also? I feel like it does not hurt and would make thing
> > > simpler to switch between existing and new binary.
> >
> > Yes, that's another viable option. Always register '$arch-virt' and
> > only register 'virt' for traditional binaries.
> Oh, I see, for single-target binary, the "virt" is QOM name, and for
> multi-target binary.
> "$arch-virt" is the QOM name? So this series needs to consider this. made sense.



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

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

[Yonggang Luo]

On Sat, Oct 3, 2026 at 12:35 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sat, Oct 03, 2026 at 12:27:08AM +0800, Yonggang Luo wrote:
> > On Sat, Oct 3, 2026 at 12:14 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Thu, Oct 01, 2026 at 11:56:13AM -0700, Pierrick Bouvier wrote:
> > > > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > > > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > > > >>> Even with the current per-target binaries there are countless
> > > > >>> devices linked in which are incompatible / not usable with
> > > > >>> certain machine types. A new multi-target binary with a union
> > > > >>> of all devices will just be a bigger example of a scenario that
> > > > >>> already has to be dealt with for today's binaries.
> > > > >>>
> > > > >>> So if we have that assumption that we don't need to do device
> > > > >>> filtering, at that point, a --target option doesn't have as
> > > > >>> big of a role to play. The machine type code knows what target(s)
> > > > >>> it wants (1 or 2 targets depending on if there are 32 + 64 bit
> > > > >>> varaints. The CPU model the user requests (if the CPU is not
> > > > >>> hardcoded by the machine), determines 32 bit vs 64 bit.
> > > > >>>
> > > > >>
> > > > >> How can we deduce this information (bitness or target for existing
> > > > >> machines/cpus)?
> > > > >
> > > > > It would require that we introduce a new field in MachineClass
> > > > > that returned that information about what target a machine is
> > > > > associated with.
> > > > >
> > > > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > > > >
> > > > > It might be better use QEMU_ARCH which correlates directly to
> > > > > the TCG targets, rather than the traditional binary target
> > > > > names ?
> > > > >
> > > > > Likely the CPU class would also want to declare its list of
> > > > > supported targets.
> > > > >
> > > >
> > > > QEMU_ARCH only represents base architectures, and not variant, so
> > > > SysEmuTarget is the right choice.
> > > >
> > > > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > > > target specific, since one could be available for variants of base arch?
> > >
> > > Ok
> > >
> > > > @Daniel: how do we deal with machines available for all targets like
> > > > null? We would need a way to ensure all machines/cpus are tagged
> > > > correctly, in an independent way from "available for all", without
> > > > having to repeat all existing SysEmuTarget.
> > >
> > > Or could the 'none' machine simply report '0xffffffff' for the
> > > list of targets so it includes everything today & in the future,
> > > or specialize "0" to mean everything ?
> > I think for is_avaible give a
> > bool target_is_any(const TargetInfo *ti)
> > {
> >     (void)ti;
> >     return true;
> > }
> > is enough. then we iterate the target list we will found every target
> > support for it.
>
> Yep, that would work.
>
>
> > > One idea I had was that when define the 'virt' class type we could
> > > have a way to identify whether it is linked into the traditional
> > > binaries, or linked into the multi-target binary, and from
> > > that choose what name to register it under. eg
> > >
> > >   "extern bool multi_target;"
> >
> > This idea already resolved,  see commit
> > https://gitlab.com/lygstate-qemu/qemu/-/commit/3342c04451bb21174e6bd53a7040e4929008b9d0
> > The idea is
> > bool target_combined_binary(void)
> > {
> >     return true;
> > }
> > for multi-target binary, and stub for single-target binary
> > for single-target binary
> > bool target_combined_binary(void)
> > {
> >     return false;
> > }
>
> Ok, yes, that works, even if that feels a bit like overkill
> vs a global variable !

Forget to tell, the overkill is intentionally,for multi-target binary
is we want to compat the future that qemu-system-$arch is symlink to
qemu-system,
then we will need

bool target_combined_binary(void)
{
    return program_name.ends("$arch");
}

>
> > > and have two .c files, one setting it 'true' and one 'false',
> > > and link each to the respective binaries. So we know statically
> > > before main() has even run, what mode this binary is intended
> > > to operate in.
> > >
> > > > Also, for compatibility with existing binaries, should we accept -M
> > > > $arch-virt also? I feel like it does not hurt and would make thing
> > > > simpler to switch between existing and new binary.
> > >
> > > Yes, that's another viable option. Always register '$arch-virt' and
> > > only register 'virt' for traditional binaries.
> > Oh, I see, for single-target binary, the "virt" is QOM name, and for
> > multi-target binary.
> > "$arch-virt" is the QOM name? So this series needs to consider this. made sense.
>
>
>
> 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 :|
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

[Yonggang Luo]

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.

https://gitlab.com/lygstate-qemu/qemu/-/blob/combined-binary-multi-targets/tests/qtest/machine-option-test.c?ref_type=heads#L393

This is the tests example to demo this, and all tests are already passed
that in combine of a

multi_target_supported_targets = [
  'none-softmmu',

  'aarch64-softmmu',
  'arm-softmmu',
  'i386-softmmu',
  'microblaze-softmmu',
  'riscv32-softmmu',
  'riscv64-softmmu',
  'x86_64-softmmu',
]

I tried hard to get 'i386-softmmu' 'x86_64-softmmu' to work. As they are the
most complicated targets. And now it works. so this patch series is fine.

>
> 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
>
> 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.
>
> Again, I'm ok if anyone wants to pull this.
>
> Regards,
> Pierrick



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[PATCH v3 02/10] hw/riscv/virt: use unique QOM name

[Yonggang Luo]

Use TYPE_RISCV_VIRT_MACHINE so the RISC-V virt QOM type does not
collide with ARM virt in a combined qemu-system binary. Keep the
-M / help / migration name as virt via machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/riscv/virt.c         | 3 ++-
 include/hw/riscv/virt.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d4b501802f6..b29182cb39b 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1134,6 +1134,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
 
     mc->desc = "RISC-V VirtIO board";
+    machine_class_set_name(mc, "virt");
     mc->init = virt_machine_init;
     mc->max_cpus = VIRT_CPUS_MAX;
     mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
@@ -1197,7 +1198,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
 }
 
 static const TypeInfo virt_machine_typeinfo = {
-    .name       = MACHINE_TYPE_NAME("virt"),
+    .name       = TYPE_RISCV_VIRT_MACHINE,
     .parent     = TYPE_MACHINE,
     .class_init = virt_machine_class_init,
     .instance_init = virt_machine_instance_init,
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index e516898f9ad..969aa5866ee 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -30,7 +30,7 @@
 #define VIRT_SOCKETS_MAX_BITS          2
 #define VIRT_SOCKETS_MAX               (1 << VIRT_SOCKETS_MAX_BITS)
 
-#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
+#define TYPE_RISCV_VIRT_MACHINE MACHINE_TYPE_NAME("riscv-virt")
 typedef struct RISCVVirtState RISCVVirtState;
 DECLARE_INSTANCE_CHECKER(RISCVVirtState, RISCV_VIRT_MACHINE,
                          TYPE_RISCV_VIRT_MACHINE)
-- 
2.52.0.windows.1

Re: [PATCH v3 02/10] hw/riscv/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:42PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:42 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 02/10] hw/riscv/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Use TYPE_RISCV_VIRT_MACHINE so the RISC-V virt QOM type does not
> collide with ARM virt in a combined qemu-system binary. Keep the
> -M / help / migration name as virt via machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/riscv/virt.c         | 3 ++-
>  include/hw/riscv/virt.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 03/10] hw/arm/virt: use unique QOM name

[Yonggang Luo]

Set TYPE_VIRT_MACHINE to MACHINE_TYPE_NAME("arm-virt") so ARM virt
no longer collides with other virt-machine types in one process.
Keep the -M / help / migration name as virt-* via
machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/arm/virt.c         | 3 ++-
 include/hw/arm/virt.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 3eecf094bcc..c8ffa1ceaf4 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -123,13 +123,14 @@ static void arm_virt_compat_default_set(MachineClass *mc)
         MACHINE_VER_SYM(options, virt, __VA_ARGS__)(mc); \
         mc->desc = "QEMU " MACHINE_VER_STR(__VA_ARGS__) " ARM Virtual Machine"; \
         MACHINE_VER_DEPRECATION(__VA_ARGS__); \
+        machine_class_set_name(mc, "virt-" MACHINE_VER_STR(__VA_ARGS__)); \
         if (latest) { \
             mc->alias = "virt"; \
         } \
     } \
     static const TypeInfo MACHINE_VER_SYM(info, virt, __VA_ARGS__) = \
     { \
-        .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \
+        .name = MACHINE_VER_TYPE_NAME("arm-virt", __VA_ARGS__), \
         .parent = TYPE_VIRT_MACHINE, \
         .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \
     }; \
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index 22e66d1a113..383ee320948 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -215,7 +215,7 @@ struct VirtMachineState {
 
 #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
 
-#define TYPE_VIRT_MACHINE   MACHINE_TYPE_NAME("virt")
+#define TYPE_VIRT_MACHINE   MACHINE_TYPE_NAME("arm-virt")
 OBJECT_DECLARE_TYPE(VirtMachineState, VirtMachineClass, VIRT_MACHINE)
 
 void virt_acpi_setup(VirtMachineState *vms);
-- 
2.52.0.windows.1

Re: [PATCH v3 03/10] hw/arm/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:43PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:43 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 03/10] hw/arm/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Set TYPE_VIRT_MACHINE to MACHINE_TYPE_NAME("arm-virt") so ARM virt
> no longer collides with other virt-machine types in one process.
> Keep the -M / help / migration name as virt-* via
> machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/arm/virt.c         | 3 ++-
>  include/hw/arm/virt.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 04/10] hw/or1k/virt: use unique QOM name

[Yonggang Luo]

Set TYPE_VIRT_MACHINE to MACHINE_TYPE_NAME("or1k-virt") so OpenRISC
virt no longer collides with other virt-machine types in one process.
Keep the -M / help / migration name as virt via
machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/or1k/virt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/or1k/virt.c b/hw/or1k/virt.c
index 2ff5c084a2b..35884252379 100644
--- a/hw/or1k/virt.c
+++ b/hw/or1k/virt.c
@@ -34,7 +34,7 @@
 #define VIRT_CPUS_MAX 4
 #define VIRT_CLK_MHZ 20000000
 
-#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
+#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("or1k-virt")
 #define VIRT_MACHINE(obj) \
     OBJECT_CHECK(OR1KVirtState, (obj), TYPE_VIRT_MACHINE)
 
@@ -548,6 +548,7 @@ static void openrisc_virt_machine_init(ObjectClass *oc, const void *data)
     MachineClass *mc = MACHINE_CLASS(oc);
 
     mc->desc = "or1k virtual machine";
+    machine_class_set_name(mc, "virt");
     mc->init = openrisc_virt_init;
     mc->max_cpus = VIRT_CPUS_MAX;
     mc->is_default = false;
-- 
2.52.0.windows.1

Re: [PATCH v3 04/10] hw/or1k/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:44PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:44 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 04/10] hw/or1k/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Set TYPE_VIRT_MACHINE to MACHINE_TYPE_NAME("or1k-virt") so OpenRISC
> virt no longer collides with other virt-machine types in one process.
> Keep the -M / help / migration name as virt via
> machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/or1k/virt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 05/10] hw/hexagon/virt: use unique QOM name

[Yonggang Luo]

Set TYPE_HEXAGON_VIRT_MACHINE to MACHINE_TYPE_NAME("hexagon-virt") so
Hexagon virt no longer collides with other virt-machine types in one
process. Keep the -M / help / migration name as virt via
machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/hexagon/virt.c         | 1 +
 include/hw/hexagon/virt.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/hexagon/virt.c b/hw/hexagon/virt.c
index 64d8366d27d..04591066bef 100644
--- a/hw/hexagon/virt.c
+++ b/hw/hexagon/virt.c
@@ -359,6 +359,7 @@ static void virt_class_init(ObjectClass *oc, const void *data)
     MachineClass *mc = MACHINE_CLASS(oc);
 
     mc->desc = "Hexagon Virtual Machine";
+    machine_class_set_name(mc, "virt");
     mc->init = virt_init;
     mc->default_cpu_type = HEXAGON_CPU_TYPE_NAME("v68");
     mc->default_ram_size = 4 * GiB;
diff --git a/include/hw/hexagon/virt.h b/include/hw/hexagon/virt.h
index 4ca2f1ef859..523c4858036 100644
--- a/include/hw/hexagon/virt.h
+++ b/include/hw/hexagon/virt.h
@@ -26,7 +26,7 @@ struct HexagonVirtMachineState {
 
 void hexagon_load_fdt(const struct HexagonVirtMachineState *vms);
 
-#define TYPE_HEXAGON_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
+#define TYPE_HEXAGON_VIRT_MACHINE MACHINE_TYPE_NAME("hexagon-virt")
 OBJECT_DECLARE_SIMPLE_TYPE(HexagonVirtMachineState, HEXAGON_VIRT_MACHINE)
 
 #endif /* HW_HEXAGONVIRT_H */
-- 
2.52.0.windows.1

Re: [PATCH v3 05/10] hw/hexagon/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:45PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:45 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 05/10] hw/hexagon/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Set TYPE_HEXAGON_VIRT_MACHINE to MACHINE_TYPE_NAME("hexagon-virt") so
> Hexagon virt no longer collides with other virt-machine types in one
> process. Keep the -M / help / migration name as virt via
> machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/hexagon/virt.c         | 1 +
>  include/hw/hexagon/virt.h | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 06/10] hw/loongarch/virt: use unique QOM name

[Yonggang Luo]

Set TYPE_LOONGARCH_VIRT_MACHINE to MACHINE_TYPE_NAME("loongarch-virt")
so LoongArch virt no longer collides with other virt-machine types in
one process. Keep the -M / help / migration name as virt-* via
machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/loongarch/virt.c         | 3 ++-
 include/hw/loongarch/virt.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 9c5371af9de..2b003443eb0 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -1543,6 +1543,7 @@ static void virt_class_init(ObjectClass *oc, const void *data)
         MACHINE_VER_SYM(options, virt, __VA_ARGS__)(mc); \
         mc->desc = "QEMU " MACHINE_VER_STR(__VA_ARGS__) " LoongArch Virtual Machine"; \
         MACHINE_VER_DEPRECATION(__VA_ARGS__); \
+        machine_class_set_name(mc, "virt-" MACHINE_VER_STR(__VA_ARGS__)); \
         if (latest) { \
             mc->alias = "virt"; \
             mc->is_default = true; \
@@ -1550,7 +1551,7 @@ static void virt_class_init(ObjectClass *oc, const void *data)
     } \
     static const TypeInfo MACHINE_VER_SYM(info, virt, __VA_ARGS__) = \
     { \
-        .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \
+        .name = MACHINE_VER_TYPE_NAME("loongarch-virt", __VA_ARGS__), \
         .parent = TYPE_LOONGARCH_VIRT_MACHINE, \
         .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \
     }; \
diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
index d39a9bbf5dd..09529de48bd 100644
--- a/include/hw/loongarch/virt.h
+++ b/include/hw/loongarch/virt.h
@@ -130,7 +130,7 @@ struct LoongArchVirtMachineState {
     bool highmem_mmio;
 };
 
-#define TYPE_LOONGARCH_VIRT_MACHINE  MACHINE_TYPE_NAME("virt")
+#define TYPE_LOONGARCH_VIRT_MACHINE  MACHINE_TYPE_NAME("loongarch-virt")
 OBJECT_DECLARE_SIMPLE_TYPE(LoongArchVirtMachineState, LOONGARCH_VIRT_MACHINE)
 void virt_acpi_setup(LoongArchVirtMachineState *lvms);
 void virt_fdt_setup(LoongArchVirtMachineState *lvms);
-- 
2.52.0.windows.1

Re: [PATCH v3 06/10] hw/loongarch/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:46PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:46 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 06/10] hw/loongarch/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Set TYPE_LOONGARCH_VIRT_MACHINE to MACHINE_TYPE_NAME("loongarch-virt")
> so LoongArch virt no longer collides with other virt-machine types in
> one process. Keep the -M / help / migration name as virt-* via
> machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/loongarch/virt.c         | 3 ++-
>  include/hw/loongarch/virt.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 07/10] hw/m68k/virt: use unique QOM name

[Yonggang Luo]

Set the parent and versioned QOM types to m68k-virt so M68K virt no
longer collides with other virt-machine types in one process. Keep
the -M / help / migration name as virt-* via
machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/m68k/virt.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 274970978ff..1faa178bdfc 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -323,7 +323,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
 }
 
 static const TypeInfo virt_machine_info = {
-    .name       = MACHINE_TYPE_NAME("virt"),
+    .name       = MACHINE_TYPE_NAME("m68k-virt"),
     .parent     = TYPE_MACHINE,
     .abstract   = true,
     .class_init = virt_machine_class_init,
@@ -345,14 +345,15 @@ type_init(virt_machine_register_types)
         MACHINE_VER_SYM(options, virt, __VA_ARGS__)(mc); \
         mc->desc = "QEMU " MACHINE_VER_STR(__VA_ARGS__) " M68K Virtual Machine"; \
         MACHINE_VER_DEPRECATION(__VA_ARGS__); \
+        machine_class_set_name(mc, "virt-" MACHINE_VER_STR(__VA_ARGS__)); \
         if (latest) { \
             mc->alias = "virt"; \
         } \
     } \
     static const TypeInfo MACHINE_VER_SYM(info, virt, __VA_ARGS__) = \
     { \
-        .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \
-        .parent = MACHINE_TYPE_NAME("virt"), \
+        .name = MACHINE_VER_TYPE_NAME("m68k-virt", __VA_ARGS__), \
+        .parent = MACHINE_TYPE_NAME("m68k-virt"), \
         .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \
     }; \
     static void MACHINE_VER_SYM(register, virt, __VA_ARGS__)(void) \
-- 
2.52.0.windows.1

Re: [PATCH v3 07/10] hw/m68k/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:47PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:47 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 07/10] hw/m68k/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Set the parent and versioned QOM types to m68k-virt so M68K virt no
> longer collides with other virt-machine types in one process. Keep
> the -M / help / migration name as virt-* via
> machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/m68k/virt.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 08/10] hw/xtensa/virt: use unique QOM name

[Yonggang Luo]

Register the board as xtensa-virt so Xtensa virt no longer collides
with other virt-machine types in one process. Keep the -M / help /
migration name as virt via machine_class_set_name().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/xtensa/virt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index 271f06e0953..dc5b255b9b1 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
@@ -118,10 +118,11 @@ static void xtensa_virt_init(MachineState *machine)
 static void xtensa_virt_machine_init(MachineClass *mc)
 {
     mc->desc = "virt machine (" XTENSA_DEFAULT_CPU_MODEL ")";
+    machine_class_set_name(mc, "virt");
     mc->init = xtensa_virt_init;
     mc->max_cpus = 32;
     mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
     mc->default_nic = "virtio-net-pci";
 }
 
-DEFINE_MACHINE("virt", xtensa_virt_machine_init)
+DEFINE_MACHINE("xtensa-virt", xtensa_virt_machine_init)
-- 
2.52.0.windows.1

Re: [PATCH v3 08/10] hw/xtensa/virt: use unique QOM name

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:48PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:48 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 08/10] hw/xtensa/virt: use unique QOM name
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> Register the board as xtensa-virt so Xtensa virt no longer collides
> with other virt-machine types in one process. Keep the -M / help /
> migration name as virt via machine_class_set_name().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/xtensa/virt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 09/10] qapi: return MachineInfo typename from query-machines

[Yonggang Luo]

query-machines returned only the -M name, so management apps inferred
the QOM type as that name plus "-machine". A prefixed type such as
arm-virt-11.1-machine no longer matches -M virt-11.1. Return the QOM
type in MachineInfo typename from object_class_get_name() in
qmp_query_machines(). test_query_machines_typename checks that
qom-list-properties accepts it.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/core/machine-qmp-cmds.c |  1 +
 qapi/machine.json          |  6 +++-
 tests/qtest/qom-test.c     | 65 ++++++++++++++++++++++++++++++++++----
 3 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 9c08b17510a..27ceed54a14 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -116,6 +116,7 @@ MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
         }
 
         info->name = g_strdup(mc->name);
+        info->q_typename = g_strdup(object_class_get_name(OBJECT_CLASS(mc)));
         info->cpu_max = !mc->max_cpus ? 1 : mc->max_cpus;
         info->hotpluggable_cpus = mc->has_hotpluggable_cpus;
         info->numa_mem_supported = mc->numa_mem_supported;
diff --git a/qapi/machine.json b/qapi/machine.json
index b1be5608b61..f5ead98e174 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -168,6 +168,9 @@
 #
 # @name: the name of the machine
 #
+# @typename: QOM type name of the machine, for qom-list-properties
+#     (since 11.2)
+#
 # @alias: an alias for the machine name
 #
 # @is-default: whether the machine is default
@@ -208,7 +211,7 @@
 # Since: 1.2
 ##
 { 'struct': 'MachineInfo',
-  'data': { 'name': 'str', '*alias': 'str',
+  'data': { 'name': 'str', 'typename': 'str', '*alias': 'str',
             '*is-default': 'bool', 'cpu-max': 'int',
             'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
             'deprecated': 'bool', '*default-cpu-type': 'str',
@@ -238,6 +241,7 @@
 #               {
 #                  "hotpluggable-cpus": true,
 #                  "name": "pc-q35-6.2",
+#                  "typename": "pc-q35-6.2-machine",
 #                  "compat-props": [
 #                       {
 #                          "qom-type": "virtio-mem",
diff --git a/tests/qtest/qom-test.c b/tests/qtest/qom-test.c
index cf4c6b5add5..4ee95af6d94 100644
--- a/tests/qtest/qom-test.c
+++ b/tests/qtest/qom-test.c
@@ -200,13 +200,32 @@ static void test_machine(gconstpointer data)
 
     if (g_test_slow()) {
         /* Make sure we can get the machine class properties: */
-        g_autofree char *qom_machine = g_strdup_printf("%s-machine", machine);
-
-        response = qtest_qmp(qts, "{ 'execute': 'qom-list-properties',"
-                                  "  'arguments': { 'typename': %s } }",
-                             qom_machine);
-        g_assert(response);
+        QList *list;
+        const QListEntry *p;
+        bool found = false;
+
+        response = qtest_qmp(qts, "{ 'execute': 'query-machines' }");
+        g_assert(!qdict_haskey(response, "error"));
+        list = qdict_get_qlist(response, "return");
+        g_assert(list);
+        for (p = qlist_first(list); p; p = qlist_next(p)) {
+            QDict *minfo = qobject_to(QDict, qlist_entry_obj(p));
+            QDict *props;
+
+            if (strcmp(qdict_get_str(minfo, "name"), machine)) {
+                continue;
+            }
+            props = qtest_qmp(qts, "{ 'execute': 'qom-list-properties',"
+                                   "  'arguments': { 'typename': %s } }",
+                              qdict_get_str(minfo, "typename"));
+            g_assert(!qdict_haskey(props, "error"));
+            g_assert(qdict_haskey(props, "return"));
+            qobject_unref(props);
+            found = true;
+            break;
+        }
         qobject_unref(response);
+        g_assert(found);
     }
 
     test_properties(qts, "/machine", true);
@@ -218,6 +237,39 @@ static void test_machine(gconstpointer data)
     qtest_quit(qts);
 }
 
+static void test_query_machines_typename(void)
+{
+    QTestState *qts;
+    QDict *response;
+    QList *list;
+    const QListEntry *p;
+    bool saw = false;
+
+    qts = qtest_init("-machine none");
+    response = qtest_qmp(qts, "{ 'execute': 'query-machines' }");
+    g_assert(!qdict_haskey(response, "error"));
+    list = qdict_get_qlist(response, "return");
+    g_assert(list);
+
+    for (p = qlist_first(list); p; p = qlist_next(p)) {
+        QDict *minfo = qobject_to(QDict, qlist_entry_obj(p));
+        const char *typename = qdict_get_str(minfo, "typename");
+        g_autoptr(QDict) props = NULL;
+
+        g_assert(g_str_has_suffix(typename, "-machine"));
+        props = qtest_qmp(qts, "{ 'execute': 'qom-list-properties',"
+                               "  'arguments': { 'typename': %s } }",
+                          typename);
+        g_assert(!qdict_haskey(props, "error"));
+        g_assert(qdict_haskey(props, "return"));
+        saw = true;
+    }
+
+    g_assert(saw);
+    qobject_unref(response);
+    qtest_quit(qts);
+}
+
 static void add_machine_test_case(const char *mname)
 {
     char *path;
@@ -250,6 +302,7 @@ int main(int argc, char **argv)
 
     qtest_cb_for_every_machine(add_machine_test_case, g_test_quick());
     qtest_add_func("qom/qom-qtests", test_qom_qtests);
+    qtest_add_func("qom/machine-typename", test_query_machines_typename);
 
     return g_test_run();
 }
-- 
2.52.0.windows.1

Re: [PATCH v3 09/10] qapi: return MachineInfo typename from query-machines

[Markus Armbruster]

Yonggang Luo <luoyonggang@gmail.com> writes:

> query-machines returned only the -M name, so management apps inferred
> the QOM type as that name plus "-machine". A prefixed type such as
> arm-virt-11.1-machine no longer matches -M virt-11.1. Return the QOM
> type in MachineInfo typename from object_class_get_name() in
> qmp_query_machines(). test_query_machines_typename checks that
> qom-list-properties accepts it.
>
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Acked-by: Markus Armbruster <armbru@redhat.com>

Re: [PATCH v3 09/10] qapi: return MachineInfo typename from query-machines

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:49PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:49 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 09/10] qapi: return MachineInfo typename from
>  query-machines
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> query-machines returned only the -M name, so management apps inferred
> the QOM type as that name plus "-machine". A prefixed type such as
> arm-virt-11.1-machine no longer matches -M virt-11.1. Return the QOM
> type in MachineInfo typename from object_class_get_name() in
> qmp_query_machines(). test_query_machines_typename checks that
> qom-list-properties accepts it.
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/core/machine-qmp-cmds.c |  1 +
>  qapi/machine.json          |  6 +++-
>  tests/qtest/qom-test.c     | 65 ++++++++++++++++++++++++++++++++++----
>  3 files changed, 65 insertions(+), 7 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

[PATCH v3 10/10] machine: match the versioned virt example to arm virt

[Yonggang Luo]

The comment still showed MACHINE_VER_TYPE_NAME("virt") and left out
machine_class_set_name(). Show the arm-virt QOM type, keep the -M name
as virt-<version>, and name the latest helper
DEFINE_VIRT_MACHINE_AS_LATEST.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/hw/core/boards.h | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h
index 851140ad052..8525e1f2288 100644
--- a/include/hw/core/boards.h
+++ b/include/hw/core/boards.h
@@ -474,21 +474,25 @@ struct MachineState {
  * For example, a macro that can be used to define versioned
  * 'virt' machine types would look like:
  *
+ *  #define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("arm-virt")
+ *
  *  #define DEFINE_VIRT_MACHINE_IMPL(latest, ...) \
  *      static void MACHINE_VER_SYM(class_init, virt, __VA_ARGS__)( \
  *          ObjectClass *oc, \
- *          void *data) \
+ *          const void *data) \
  *      { \
  *          MachineClass *mc = MACHINE_CLASS(oc); \
  *          MACHINE_VER_SYM(options, virt, __VA_ARGS__)(mc); \
- *          mc->desc = "QEMU " MACHINE_VER_STR(__VA_ARGS__) " Virtual Machine"; \
+ *          mc->desc = "QEMU " MACHINE_VER_STR(__VA_ARGS__) " ARM Virtual Machine"; \
  *          MACHINE_VER_DEPRECATION(__VA_ARGS__); \
+ *          machine_class_set_name(mc, "virt-" MACHINE_VER_STR(__VA_ARGS__)); \
  *          if (latest) { \
  *              mc->alias = "virt"; \
  *          } \
  *      } \
- *      static const TypeInfo MACHINE_VER_SYM(info, virt, __VA_ARGS__) = { \
- *          .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \
+ *      static const TypeInfo MACHINE_VER_SYM(info, virt, __VA_ARGS__) = \
+ *      { \
+ *          .name = MACHINE_VER_TYPE_NAME("arm-virt", __VA_ARGS__), \
  *          .parent = TYPE_VIRT_MACHINE, \
  *          .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \
  *      }; \
@@ -503,7 +507,7 @@ struct MachineState {
  * whichever scenarios need to be catered for with a machine:
  *
  *  // Normal 2 digit, marked as latest e.g. 'virt-9.0'
- *  #define DEFINE_VIRT_MACHINE_LATEST(major, minor) \
+ *  #define DEFINE_VIRT_MACHINE_AS_LATEST(major, minor) \
  *      DEFINE_VIRT_MACHINE_IMPL(true, major, minor)
  *
  *  // Normal 2 digit e.g. 'virt-9.0'
-- 
2.52.0.windows.1

Re: [PATCH v3 10/10] machine: match the versioned virt example to arm virt

[Zhao Liu]

On Sat, Sep 26, 2026 at 04:15:50PM +0800, Yonggang Luo wrote:
> Date: Sat, 26 Sep 2026 16:15:50 +0800
> From: Yonggang Luo <luoyonggang@gmail.com>
> Subject: [PATCH v3 10/10] machine: match the versioned virt example to arm
>  virt
> X-Mailer: git-send-email 2.52.0.windows.1
> 
> The comment still showed MACHINE_VER_TYPE_NAME("virt") and left out
> machine_class_set_name(). Show the arm-virt QOM type, keep the -M name
> as virt-<version>, and name the latest helper
> DEFINE_VIRT_MACHINE_AS_LATEST.
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  include/hw/core/boards.h | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

Re: [PATCH v3 00/10] machine: uniquify virt QOM names

[Yonggang Luo]

Can this be queued now?

On Sat, Sep 26, 2026 at 4:15 PM Yonggang Luo <luoyonggang@gmail.com> wrote:
>
> Multiple targets register a virt board as MACHINE_TYPE_NAME("virt").
> Those QOM types collide if more than one board is linked into one
> qemu-system process. This series splits the QOM type from the -M name
> so each virt board can keep a unique type while -M virt, help, and
> migration stay the same.
>
> - Add machine_class_set_name() so boards can set MachineClass::name
>   when it must differ from the QOM type. 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 that name so order matches the printed names after types are
>   prefixed (arm-virt-11.1-machine vs virt-11.1).
> - Give each colliding virt board a unique QOM type and keep the
>   existing -M name via machine_class_set_name(): riscv-virt, arm-virt,
>   or1k-virt, hexagon-virt, loongarch-virt, m68k-virt, and xtensa-virt.
>   Versioned ARM, LoongArch, and M68K boards keep virt-<ver>. Latest
>   ARM virt still sets mc->alias to virt.
> - query-machines returns MachineInfo typename, the QOM type from
>   object_class_get_name(), for qom-list-properties. The -M name alone
>   is not that type once virt boards are prefixed.
>
> Changes v2 -> v3:
> The versioned-machine example in boards.h now follows hw/arm/virt.c.
> machine_class_set_name() keeps the -M name as virt-<version>, the QOM type in
> the example is arm-virt, and the latest helper is DEFINE_VIRT_MACHINE_AS_LATEST.
>
> Changes v1 -> v2:
> - query-machines returns MachineInfo typename. v1 returned only the
>   -M name, so a client that appended "-machine" looked up the wrong
>   type for a prefixed board such as arm-virt-11.1-machine versus
>   -M virt-11.1.
>
> Yonggang Luo (10):
>   machine: allow -M name to differ from QOM type
>   hw/riscv/virt: use unique QOM name
>   hw/arm/virt: use unique QOM name
>   hw/or1k/virt: use unique QOM name
>   hw/hexagon/virt: use unique QOM name
>   hw/loongarch/virt: use unique QOM name
>   hw/m68k/virt: use unique QOM name
>   hw/xtensa/virt: use unique QOM name
>   qapi: return MachineInfo typename from query-machines
>   machine: match the versioned virt example to arm virt
>
>  hw/arm/virt.c               |  3 +-
>  hw/core/machine-qmp-cmds.c  |  1 +
>  hw/core/machine.c           |  6 ++++
>  hw/hexagon/virt.c           |  1 +
>  hw/loongarch/virt.c         |  3 +-
>  hw/m68k/virt.c              |  7 ++--
>  hw/or1k/virt.c              |  3 +-
>  hw/riscv/virt.c             |  3 +-
>  hw/xtensa/virt.c            |  3 +-
>  include/hw/arm/virt.h       |  2 +-
>  include/hw/core/boards.h    | 26 +++++++++++----
>  include/hw/hexagon/virt.h   |  2 +-
>  include/hw/loongarch/virt.h |  2 +-
>  include/hw/riscv/virt.h     |  2 +-
>  qapi/machine.json           |  6 +++-
>  system/vl.c                 |  8 ++---
>  tests/qtest/qom-test.c      | 65 +++++++++++++++++++++++++++++++++----
>  17 files changed, 113 insertions(+), 30 deletions(-)
>
> --
> 2.52.0.windows.1
>


-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo