On Mon, Oct 12, 2026 at 10:13 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/11/26 1:22 PM, Yonggang Luo wrote:
> > On Fri, Oct 9, 2026 at 2:34 AM Pierrick Bouvier
> > <[email protected]> wrote:
> >>
> >> On 10/8/2026 10:13 AM, Yonggang Luo wrote:
> >>> On Fri, Oct 9, 2026 at 12:06 AM Pierrick Bouvier
> >>> <[email protected]> wrote:
> >>>>
> >>>> On 10/8/2026 2:46 AM, Yonggang Luo wrote:
> >>>>> On Thu, Oct 8, 2026 at 5:42 PM Daniel P. Berrangé <[email protected]>
> >>>>> wrote:
> >>>>>>
> >>>>>> On Wed, Oct 07, 2026 at 01:25:46PM -0700, Pierrick Bouvier wrote:
> >>>>>>> On 10/7/2026 4:47 AM, Yonggang Luo wrote:
> >>>>>>>> This allows a combined binary to register machine types from all its
> >>>>>>>> targets.
> >>>>>>>> Consequently, QMP `query-machines` can return machine entries from
> >>>>>>>> every
> >>>>>>>> target, even when `none` is selected. For example, a client can
> >>>>>>>> query the
> >>>>>>>> combined machine list with:
> >>>>>>>>
> >>>>>>>> ```json
> >>>>>>>> { "execute": "query-machines" }
> >>>>>>>> ```
> >>>>>>>>
> >>>>>>>> The returned list includes the registered machine classes from all
> >>>>>>>> linked
> >>>>>>>> targets. This is separate from selecting a machine: with `-target
> >>>>>>>> none`,
> >>>>>>>> `-M virt` reports the targets that provide `virt` instead of
> >>>>>>>> choosing one
> >>>>>>>> arbitrarily:
> >>>>>>>>
> >>>>>>>> ```text
> >>>>>>>> qemu-system -target none -M virt
> >>>>>>>> unsupported machine type: "virt" for target "none"
> >>>>>>>> Available for targets:
> >>>>>>>> aarch64
> >>>>>>>> arm
> >>>>>>>> ```
> >>>>>>>>
> >>>>>>>
> >>>>>>> From the long conversation on a previous thread, I thought we reached
> >>>>>>> the conclusion that if we didn't expose any ambiguous name, then
> >>>>>>> -target
> >>>>>>> option is unnecessary, or maybe I got lost on track of this thread.
> >>>>>>>
> >>>>>>> https://lore.kernel.org/qemu-devel/[email protected]/
> >>>>>>>
> >>>>>>> I'm not sure which semantic we want to have with -target none. If
> >>>>>>> there
> >>>>>>> is no ambiguous name registered, we just don't need it at all. It's a
> >>>>>>> win-win IMHO.
> >>>>>>
> >>>>>> Yes, if we expose unique names for every machine, then -target is then
> >>>>>> redundant.
> >>>>>
> >>>>> so how to diff riscv32-virt and risv64-virt? oh so for this machine we
> >>>>> needs two name?
> >>>>> "virt" needs register twice for it? or register only a single time,
> >>>>> but we prefix the target_name()
> >>>>> automatically? for example machine::name === "virt", but we can use
> >>>>> "riscv32-virt" "risv64-virt" to reach it?
> >>>>>
> >>>>
> >>>> Yes, ideally we should have different variant of virt for 32/64 bit.
> >>>> Same goes for cpu max types.
> >>>>
> >>>> QOM type is always registered unambiguously ("$arch-virt"). Then, for
> >>>> the "alias" name, which is virt, in case multiple matches are found,
> >>>> command line can return an error with list of unambiguous names to call
> >>>> it.
> >>>>
> >>>> $ qemu-system -M virt
> >>>> Multiple virt machines are available. Please choose one of them:
> >>>> - aarch64-virt
> >>>> - riscv64-virt
> >>>>
> >>>> There is no "parsing" of the argument, it's just the real QOM type. Then
> >>>> we can find which target it implements from mc->targets.
> >>>> And then, we can automatically choose which cpus should be available
> >>>> based on that, thanks to cpu->targets.
> >>>>
> >>>> For existing binaries, nothing change.
> >>>
> >>> Good, I think we found a clean way now, is_available should be
> >>> removed, and TypeInfo::targets and TypeImpl::targets should be added.
> >>
> >> It goes into MachineClass only for now.
> >>
> >>> I think
> >>> for "virt" we can add a shared hw/machine-virt.c instead, and forwarding
> >>> to
> >>> the $arch specific virt. so that we only have a single "virt" registered.
> >>> And it's
> >>> targets is
> >>> QEMU_ARCH_I386 |
> >>> QEMU_ARCH_ARM |
> >>> QEMU_ARCH_RISCV |
> >>> QEMU_ARCH_LOONGARCH |
> >>> QEMU_ARCH_M68K |
> >>> QEMU_ARCH_OR1K |
> >>> QEMU_ARCH_XTENSA |
> >>> QEMU_ARCH_HEXAGON
> >>>
> >>> So that we won't have a list of conflict QOM names for "virt" machines.
> >>> As now we indeed have only a single "virt" machine that redirects to
> >>> different targets.
> >>>
> >>
> >> The idea looks appealing, but I don't think it solves the problem to
> >> have multiple virt variants available at the same time.
> >>
> >> The "alias" idea you introduced before is good, we just need to add a
> >> check if an alias is really unique, else return an error, as explained
> >> previously.
> >>
> >> If "-M aarch64-virt" works for both the new and existing binary, and -M
> >> virt only for existing binaries (and ambiguous for new one), I think
> >> that's a safe approach.
> >>
> >>>
> >>> For other types also conflict can be handled in the same way, such as
> >>> "-cpu host" "-cpu max"
> >>> maybe others, but I think they all have the same way to deal with.
> >>>
> >>>
> >>> That's why TypeInfo::targets and TypeImpl::targets better than sole
> >>> Machine::targets
> >>>
> >>
> >> One step at a time.
> >> Let's keep focused on declaring targets for a single machine first.
> >> Then we can iterate to solve the "virt" problem.
> >> Then convert all the existing machines and add a check in machine-target.c
> >> Then, and only then, we can see what happens with cpus.
> >
> > I tried this idea, but I faced a fatal error, because the
> > target_info() is not available until
> > the machine selected(the target arch will be select just along with
> > the machine selected), so basically
> > all calls to target_info() would raise an error(null pointer), how to
> > deal with it?
> >
>
> I see. Indeed, since we can't set a target before registering all types,
> it implies that all the types class_init can't use target_* functions.
>
>
> - register_accel_target_type
> - cpu_max_v8_register_type
Hi Pierrick
These two I can handle it properly, only for the "virt" machine I can
not handle it properly
What you suggest, it's a must-be requirement now.
for example, cpu_max_v8_register_type can be handle in such way:
target/arm/tcg/cpu-max-v8.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
index 65f851f2006..d7323ab431c 100644
--- a/target/arm/tcg/cpu-max-v8.c
+++ b/target/arm/tcg/cpu-max-v8.c
@@ -119,12 +119,21 @@ void aarch32_max_v8_tcg_initfn(Object *obj)
#endif
}
+static void max_v8_tcg_initfn(Object *obj)
+{
+ if (target_aarch64()) {
+ aarch64_max_v8_tcg_initfn(obj);
+ } else {
+ aarch32_max_v8_tcg_initfn(obj);
+ }
+}
+
static void cpu_max_v8_register_type(void)
{
- static const ARMCPUInfo max_v8[2] = {
- { .name = "max-v8", .initfn = aarch32_max_v8_tcg_initfn },
- { .name = "max-v8", .initfn = aarch64_max_v8_tcg_initfn },
+ static const ARMCPUInfo max_v8 = {
+ .name = "max-v8",
+ .initfn = max_v8_tcg_initfn,
};
- arm_cpu_register(&max_v8[target_aarch64()]);
+ arm_cpu_register(&max_v8);
}
type_init(cpu_max_v8_register_type)
register_accel_target_type:
accel/accel-common.c | 21 ++++++---------------
include/accel/accel-cpu-target.h | 3 +--
include/accel/accel-cpu.h | 2 ++
3 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/accel/accel-common.c b/accel/accel-common.c
index 00a400243f0..c4c365f38c7 100644
--- a/accel/accel-common.c
+++ b/accel/accel-common.c
@@ -126,21 +126,12 @@ static const TypeInfo accel_types[] = {
.instance_size = sizeof(AccelState),
.abstract = true,
},
+ {
+ .name = TYPE_ACCEL_CPU,
+ .parent = TYPE_OBJECT,
+ .abstract = true,
+ .class_size = sizeof(AccelCPUClass),
+ },
};
DEFINE_TYPES(accel_types)
-
-static void register_accel_target_type(void)
-{
- g_autofree char *name = g_strconcat("accel-", target_cpu_type(), NULL);
- const TypeInfo accel_cpu_type = {
- .name = name,
- .parent = TYPE_OBJECT,
- .abstract = true,
- .class_size = sizeof(AccelCPUClass),
- };
-
- type_register_static(&accel_cpu_type);
-}
-
-type_init(register_accel_target_type);
diff --git a/include/accel/accel-cpu-target.h b/include/accel/accel-cpu-target.h
index 6feb344e29b..cf33ebd79fc 100644
--- a/include/accel/accel-cpu-target.h
+++ b/include/accel/accel-cpu-target.h
@@ -24,8 +24,7 @@
#include "accel/accel-cpu.h"
#include "cpu.h"
-#define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
-#define ACCEL_CPU_NAME(name) (name "-" TYPE_ACCEL_CPU)
+#define ACCEL_CPU_NAME(name) (name "-accel-" CPU_RESOLVING_TYPE)
DECLARE_CLASS_CHECKERS(AccelCPUClass, ACCEL_CPU, TYPE_ACCEL_CPU)
#endif /* ACCEL_CPU_H */
diff --git a/include/accel/accel-cpu.h b/include/accel/accel-cpu.h
index 9e7eede7c3c..5cfc2b24223 100644
--- a/include/accel/accel-cpu.h
+++ b/include/accel/accel-cpu.h
@@ -12,6 +12,8 @@
#include "qom/object.h"
#include "hw/core/cpu.h"
+#define TYPE_ACCEL_CPU "accel-cpu"
+
typedef struct AccelCPUClass {
ObjectClass parent_class;
>
>
> >>
> >> Regards,
> >> Pierrick
> >
> >
> >
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
