[PATCH v2 00/12] qom: resolve type name conflicts, avoid target_info() in class_init or type_init

[PATCH v2 00/12] qom: resolve type name conflicts, avoid target_info() in class_init or type_init

[Yonggang Luo]

The goal is a single binary that links several targets, where every QOM type is
registered once for all of them. Types that share a name go into one bucket per
name, each variant tagged with the targets it serves, and the selected target
picks the variant at lookup time. For that to work, registering a type and
building its class must not depend on which target is selected.

Today some class_init and type_init functions call target_info(), directly or
through helpers such as target_s390x(). The result is fixed for the one target
selected when the class is built, so the other targets never get their own form
of that type.

max-v8 called target_aarch64() from its type_init to pick an instance
initializer. scsi-hd, scsi-cd, virtio-blk-pci, virtio-net-pci and virtio-mem
called target_s390x() or target_arch() from class_init to add properties. The
PetaLogix machine called target_big_endian() from class_init to set the default
endianness.

Instead, each target-specific form becomes its own TypeInfo under the same name.
Its is_available callback says which target it belongs to. Today QOM registers
only the one that matches; a bucket can later keep all of them. LoongArch and
Xtensa virt machines are handled the same way, since both share the virt-machine
name. PetaLogix keeps one type: its endianness default is "unspecified" until
the machine starts. A few target_*() helpers are added for the new callbacks.

v1: https://lore.kernel.org/qemu-devel/20261028201557.2688-1-luoyonggang@gmail.com/

Changes v1 -> v2:

- Drop target_not_s390x() from target-info. v1 exported it for scsi-disk,
  virtio-blk-pci, and virtio-net-pci. Each file keeps a static copy
- Drop target_not_base_i386() from target-info. Keep target_base_i386(), and a
  static target_not_base_i386() in virtio-mem
- Split hw/xtensa/virt: select virt machine types with is_available out of the
  DEFINE_MACHINE expansion, so later only that small patch needs a revert

Yonggang Luo (12):
  target-info: add target_loongarch()
  hw/loongarch/virt: select virt machine types with is_available
  target-info: add target_xtensa()
  hw/xtensa: expand DEFINE_MACHINE in virt.c
  hw/xtensa/virt: select virt machine types with is_available
  target/arm: register separate max-v8 CPU types for arm and aarch64
  hw/scsi/scsi-disk: register s390x scsi-hd and scsi-cd variants
  hw/virtio/virtio-pci: pass is_available through
    VirtioPCIDeviceTypeInfo
  hw/virtio: register s390x virtio-blk-pci and virtio-net-pci variants
  target-info: add target_base_i386()
  hw/virtio/virtio-mem: register legacy-guest variant with is_available
  hw/microblaze: defer PetaLogix endianness default until init

 hw/loongarch/virt.c                      |  3 ++
 hw/microblaze/petalogix_s3adsp1800_mmu.c | 11 +++--
 hw/pci/pci.c                             | 13 +++---
 hw/scsi/scsi-disk.c                      | 48 +++++++++++++++++-----
 hw/virtio/virtio-blk-pci.c               | 27 +++++++++++-
 hw/virtio/virtio-mem.c                   | 52 +++++++++++++++---------
 hw/virtio/virtio-net-pci.c               | 27 +++++++++++-
 hw/virtio/virtio-pci.c                   |  4 ++
 hw/xtensa/virt.c                         | 20 ++++++++-
 include/hw/virtio/virtio-mem.h           |  2 +
 include/hw/virtio/virtio-pci.h           |  1 +
 include/qemu/target-info.h               | 21 ++++++++++
 target-info.c                            | 27 ++++++++++++
 target/arm/cpu.c                         |  1 +
 target/arm/cpu.h                         |  1 +
 target/arm/tcg/cpu-max-v8.c              | 16 ++++++--
 16 files changed, 225 insertions(+), 49 deletions(-)

-- 
2.55.0.windows.3

[PATCH v2 01/12] target-info: add target_loongarch()

[Yonggang Luo]

Report whether the selected target architecture is LoongArch.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/qemu/target-info.h | 7 +++++++
 target-info.c              | 5 +++++
 2 files changed, 12 insertions(+)

diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 2cd4cc5671b..6c4e2809ad3 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -92,6 +92,13 @@ bool target_hexagon(void);
  */
 bool target_or1k(void);
 
+/**
+ * target_loongarch:
+ *
+ * Returns whether the target architecture is LoongArch.
+ */
+bool target_loongarch(void);
+
 /**
  * target_base_ppc:
  *
diff --git a/target-info.c b/target-info.c
index e67d7bed520..b6d9cd8d97c 100644
--- a/target-info.c
+++ b/target-info.c
@@ -84,6 +84,11 @@ bool target_or1k(void)
     return target_arch() == SYS_EMU_TARGET_OR1K;
 }
 
+bool target_loongarch(void)
+{
+    return target_arch() == SYS_EMU_TARGET_LOONGARCH64;
+}
+
 bool target_base_ppc(void)
 {
     switch (target_arch()) {
-- 
2.55.0.windows.3

[PATCH v2 02/12] hw/loongarch/virt: select virt machine types with is_available

[Yonggang Luo]

LoongArch virt machines use the same QOM names as virt machines on
other targets. Register them only when the selected target is
LoongArch, via target_loongarch().

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/loongarch/virt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 9c5371af9de..3f1b82f25ef 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -11,6 +11,7 @@
 #include "qapi/error.h"
 #include "exec/target_page.h"
 #include "hw/core/boards.h"
+#include "qemu/target-info.h"
 #include "hw/char/serial-mm.h"
 #include "system/kvm.h"
 #include "system/tcg.h"
@@ -1553,6 +1554,7 @@ static void virt_class_init(ObjectClass *oc, const void *data)
         .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \
         .parent = TYPE_LOONGARCH_VIRT_MACHINE, \
         .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \
+        .is_available = target_loongarch, \
     }; \
     static void MACHINE_VER_SYM(register, virt, __VA_ARGS__)(void) \
     { \
@@ -1587,6 +1589,7 @@ static const TypeInfo virt_machine_info = {
     .class_init     = virt_class_init,
     .instance_init  = virt_initfn,
     .instance_finalize = virt_instance_finalize,
+    .is_available   = target_loongarch,
     .interfaces = (InterfaceInfo[]) {
         { TYPE_HOTPLUG_HANDLER },
         { }
-- 
2.55.0.windows.3

[PATCH v2 03/12] target-info: add target_xtensa()

[Yonggang Luo]

Report whether the selected target architecture is Xtensa.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/qemu/target-info.h |  7 +++++++
 target-info.c              | 11 +++++++++++
 2 files changed, 18 insertions(+)

diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 6c4e2809ad3..1d6c6f4472c 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -99,6 +99,13 @@ bool target_or1k(void);
  */
 bool target_loongarch(void);
 
+/**
+ * target_xtensa:
+ *
+ * Returns whether the target architecture is Xtensa.
+ */
+bool target_xtensa(void);
+
 /**
  * target_base_ppc:
  *
diff --git a/target-info.c b/target-info.c
index b6d9cd8d97c..07dc88fd366 100644
--- a/target-info.c
+++ b/target-info.c
@@ -89,6 +89,17 @@ bool target_loongarch(void)
     return target_arch() == SYS_EMU_TARGET_LOONGARCH64;
 }
 
+bool target_xtensa(void)
+{
+    switch (target_arch()) {
+    case SYS_EMU_TARGET_XTENSA:
+    case SYS_EMU_TARGET_XTENSAEB:
+        return true;
+    default:
+        return false;
+    }
+}
+
 bool target_base_ppc(void)
 {
     switch (target_arch()) {
-- 
2.55.0.windows.3

[PATCH v2 04/12] hw/xtensa: expand DEFINE_MACHINE in virt.c

[Yonggang Luo]

Expand DEFINE_MACHINE() in hw/xtensa/virt.c to xtensa_virt_machine_typeinfo
and xtensa_virt_machine_register_types() calling type_register_static().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/xtensa/virt.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index 271f06e0953..8c8fdad72f0 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
@@ -115,8 +115,10 @@ static void xtensa_virt_init(MachineState *machine)
     xtensa_sim_load_kernel(cpu, machine);
 }
 
-static void xtensa_virt_machine_init(MachineClass *mc)
+static void xtensa_virt_machine_class_init(ObjectClass *oc, const void *data)
 {
+    MachineClass *mc = MACHINE_CLASS(oc);
+
     mc->desc = "virt machine (" XTENSA_DEFAULT_CPU_MODEL ")";
     mc->init = xtensa_virt_init;
     mc->max_cpus = 32;
@@ -124,4 +126,16 @@ static void xtensa_virt_machine_init(MachineClass *mc)
     mc->default_nic = "virtio-net-pci";
 }
 
-DEFINE_MACHINE("virt", xtensa_virt_machine_init)
+static const TypeInfo xtensa_virt_machine_typeinfo = {
+    .name       = MACHINE_TYPE_NAME("virt"),
+    .parent     = TYPE_MACHINE,
+    .class_init = xtensa_virt_machine_class_init,
+    .instance_size = sizeof(MachineState),
+};
+
+static void xtensa_virt_machine_register_types(void)
+{
+    type_register_static(&xtensa_virt_machine_typeinfo);
+}
+
+type_init(xtensa_virt_machine_register_types)
-- 
2.55.0.windows.3

[PATCH v2 05/12] hw/xtensa/virt: select virt machine types with is_available

[Yonggang Luo]

The Xtensa virt machine uses the QOM name virt-machine, which other
targets register as well. Register it only when the selected target
is Xtensa, via target_xtensa().

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/xtensa/virt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index 8c8fdad72f0..962646ba98d 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
@@ -29,6 +29,7 @@
 #include "qapi/error.h"
 #include "system/reset.h"
 #include "hw/core/boards.h"
+#include "qemu/target-info.h"
 #include "hw/core/loader.h"
 #include "hw/pci-host/gpex.h"
 #include "net/net.h"
@@ -131,6 +132,7 @@ static const TypeInfo xtensa_virt_machine_typeinfo = {
     .parent     = TYPE_MACHINE,
     .class_init = xtensa_virt_machine_class_init,
     .instance_size = sizeof(MachineState),
+    .is_available = target_xtensa,
 };
 
 static void xtensa_virt_machine_register_types(void)
-- 
2.55.0.windows.3

[PATCH v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Yonggang Luo]

max-v8 was one TypeInfo whose instance initializer was chosen from the
selected target at registration. Register both initializers, and let
target_arm() and target_aarch64() select which type is available.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 target/arm/cpu.c            |  1 +
 target/arm/cpu.h            |  1 +
 target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 510fc9eeb3b..6eb55242980 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
         .instance_init = arm_cpu_instance_init,
         .class_init = info->class_init ?: cpu_register_class_init,
         .class_data = info,
+        .is_available = info->is_available,
     };
 
     type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index add993ef101..3240a8633ee 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
     const char *deprecation_note;
     void (*initfn)(Object *obj);
     void (*class_init)(ObjectClass *oc, const void *data);
+    bool (*is_available)(void);
 } ARMCPUInfo;
 
 /**
diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
index 65f851f2006..e819d07e6ce 100644
--- a/target/arm/tcg/cpu-max-v8.c
+++ b/target/arm/tcg/cpu-max-v8.c
@@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
+        .name = "max-v8",
+        .initfn = aarch32_max_v8_tcg_initfn,
+        .is_available = target_arm,
     };
-    arm_cpu_register(&max_v8[target_aarch64()]);
+    static const ARMCPUInfo max_v8_aarch64 = {
+        .name = "max-v8",
+        .initfn = aarch64_max_v8_tcg_initfn,
+        .is_available = target_aarch64,
+    };
+
+    arm_cpu_register(&max_v8_aarch32);
+    arm_cpu_register(&max_v8_aarch64);
 }
 type_init(cpu_max_v8_register_type)
-- 
2.55.0.windows.3

[PATCH v2 07/12] hw/scsi/scsi-disk: register s390x scsi-hd and scsi-cd variants

[Yonggang Luo]

scsi-hd and scsi-cd added the s390x loadparm property from class_init
when target_s390x() was true. Register a second type for each name
that always adds loadparm, and select the two with target_s390x() and
target_not_s390x().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/scsi/scsi-disk.c | 48 +++++++++++++++++++++++++++++++++++----------
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 6341089ddf2..bb5377fb7fa 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -3221,14 +3221,11 @@ static void scsi_property_add_specifics(DeviceClass *dc)
 {
     ObjectClass *oc = OBJECT_CLASS(dc);
 
-    /* The loadparm property is only supported on s390x */
-    if (target_s390x()) {
-        object_class_property_add_str(oc, "loadparm",
-                                      scsi_property_get_loadparm,
-                                      scsi_property_set_loadparm);
-        object_class_property_set_description(oc, "loadparm",
-                                              "load parameter (s390x only)");
-    }
+    object_class_property_add_str(oc, "loadparm",
+                                  scsi_property_get_loadparm,
+                                  scsi_property_set_loadparm);
+    object_class_property_set_description(oc, "loadparm",
+                                          "load parameter (s390x only)");
 }
 
 static void scsi_disk_base_class_initfn(ObjectClass *klass, const void *data)
@@ -3362,14 +3359,31 @@ static void scsi_hd_class_initfn(ObjectClass *klass, const void *data)
     dc->desc = "virtual SCSI disk";
     device_class_set_props(dc, scsi_hd_properties);
     dc->vmsd  = &vmstate_scsi_disk_state;
+}
+
+static void scsi_hd_s390x_class_initfn(ObjectClass *klass, const void *data)
+{
+    scsi_hd_class_initfn(klass, data);
+    scsi_property_add_specifics(DEVICE_CLASS(klass));
+}
 
-    scsi_property_add_specifics(dc);
+static bool target_not_s390x(void)
+{
+    return !target_s390x();
 }
 
 static const TypeInfo scsi_hd_info = {
     .name          = "scsi-hd",
     .parent        = TYPE_SCSI_DISK_BASE,
     .class_init    = scsi_hd_class_initfn,
+    .is_available  = target_not_s390x,
+};
+
+static const TypeInfo scsi_hd_s390x_info = {
+    .name          = "scsi-hd",
+    .parent        = TYPE_SCSI_DISK_BASE,
+    .class_init    = scsi_hd_s390x_class_initfn,
+    .is_available  = target_s390x,
 };
 
 static const Property scsi_cd_properties[] = {
@@ -3405,14 +3419,26 @@ static void scsi_cd_class_initfn(ObjectClass *klass, const void *data)
     dc->desc = "virtual SCSI CD-ROM";
     device_class_set_props(dc, scsi_cd_properties);
     dc->vmsd  = &vmstate_scsi_disk_state;
+}
 
-    scsi_property_add_specifics(dc);
+static void scsi_cd_s390x_class_initfn(ObjectClass *klass, const void *data)
+{
+    scsi_cd_class_initfn(klass, data);
+    scsi_property_add_specifics(DEVICE_CLASS(klass));
 }
 
 static const TypeInfo scsi_cd_info = {
     .name          = "scsi-cd",
     .parent        = TYPE_SCSI_DISK_BASE,
     .class_init    = scsi_cd_class_initfn,
+    .is_available  = target_not_s390x,
+};
+
+static const TypeInfo scsi_cd_s390x_info = {
+    .name          = "scsi-cd",
+    .parent        = TYPE_SCSI_DISK_BASE,
+    .class_init    = scsi_cd_s390x_class_initfn,
+    .is_available  = target_s390x,
 };
 
 #ifdef __linux__
@@ -3462,7 +3488,9 @@ static void scsi_disk_register_types(void)
 {
     type_register_static(&scsi_disk_base_info);
     type_register_static(&scsi_hd_info);
+    type_register_static(&scsi_hd_s390x_info);
     type_register_static(&scsi_cd_info);
+    type_register_static(&scsi_cd_s390x_info);
 #ifdef __linux__
     type_register_static(&scsi_block_info);
 #endif
-- 
2.55.0.windows.3

[PATCH v2 08/12] hw/virtio/virtio-pci: pass is_available through VirtioPCIDeviceTypeInfo

[Yonggang Luo]

virtio_pci_types_register() builds the base, generic, transitional
and non-transitional TypeInfos for one virtio-pci device. Copy an
is_available callback onto each of them so a device can register
target-specific variants of the same names.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/virtio/virtio-pci.c         | 4 ++++
 include/hw/virtio/virtio-pci.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index c73f1f546cb..1ce39e92e9d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2522,11 +2522,13 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t)
         .class_size    = t->class_size,
         .abstract      = true,
         .interfaces    = t->interfaces,
+        .is_available  = t->is_available,
     };
     TypeInfo generic_type_info = {
         .name = t->generic_name,
         .parent = base_type_info.name,
         .class_init = virtio_pci_generic_class_init,
+        .is_available = t->is_available,
         .interfaces = (const InterfaceInfo[]) {
             { INTERFACE_PCIE_DEVICE },
             { INTERFACE_CONVENTIONAL_PCI_DEVICE },
@@ -2562,6 +2564,7 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t)
             .name          = t->non_transitional_name,
             .parent        = base_type_info.name,
             .instance_init = virtio_pci_non_transitional_instance_init,
+            .is_available  = t->is_available,
             .interfaces = (const InterfaceInfo[]) {
                 { INTERFACE_PCIE_DEVICE },
                 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
@@ -2576,6 +2579,7 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t)
             .name          = t->transitional_name,
             .parent        = base_type_info.name,
             .instance_init = virtio_pci_transitional_instance_init,
+            .is_available  = t->is_available,
             .interfaces = (const InterfaceInfo[]) {
                 /*
                  * Transitional virtio devices work only as Conventional PCI
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index ee50fb0d551..6c3561d319a 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -236,6 +236,7 @@ typedef struct VirtioPCIDeviceTypeInfo {
     void (*instance_init)(Object *obj);
     void (*instance_finalize)(Object *obj);
     void (*class_init)(ObjectClass *klass, const void *data);
+    bool (*is_available)(void);
     const InterfaceInfo *interfaces;
 } VirtioPCIDeviceTypeInfo;
 
-- 
2.55.0.windows.3

[PATCH v2 09/12] hw/virtio: register s390x virtio-blk-pci and virtio-net-pci variants

[Yonggang Luo]

virtio-blk-pci and virtio-net-pci added the s390x loadparm property
from class_init when target_s390x() was true. Register each
VirtioPCIDeviceTypeInfo twice. The s390x variant calls
pci_qdev_property_add_specifics(), which now always adds loadparm,
and the other variant does not. target_s390x() and target_not_s390x() select
the two.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/pci/pci.c               | 13 +++++--------
 hw/virtio/virtio-blk-pci.c | 27 ++++++++++++++++++++++++++-
 hw/virtio/virtio-net-pci.c | 27 ++++++++++++++++++++++++++-
 3 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 2d2fe02c68e..b5ea0b049aa 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2901,14 +2901,11 @@ void pci_qdev_property_add_specifics(DeviceClass *dc)
 {
     ObjectClass *oc = OBJECT_CLASS(dc);
 
-    /* The loadparm property is only supported on s390x */
-    if (target_s390x()) {
-        object_class_property_add_str(oc, "loadparm",
-                                      pci_qdev_property_get_loadparm,
-                                      pci_qdev_property_set_loadparm);
-        object_class_property_set_description(oc, "loadparm",
-                                              "load parameter (s390x only)");
-    }
+    object_class_property_add_str(oc, "loadparm",
+                                  pci_qdev_property_get_loadparm,
+                                  pci_qdev_property_set_loadparm);
+    object_class_property_set_description(oc, "loadparm",
+                                          "load parameter (s390x only)");
 }
 
 MemoryRegion *pci_address_space(PCIDevice *dev)
diff --git a/hw/virtio/virtio-blk-pci.c b/hw/virtio/virtio-blk-pci.c
index 3eecc23a657..d15f2d283cb 100644
--- a/hw/virtio/virtio-blk-pci.c
+++ b/hw/virtio/virtio-blk-pci.c
@@ -22,6 +22,7 @@
 #include "hw/virtio/virtio-pci.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#include "qemu/target-info.h"
 #include "qom/object.h"
 
 typedef struct VirtIOBlkPCI VirtIOBlkPCI;
@@ -71,7 +72,6 @@ static void virtio_blk_pci_class_init(ObjectClass *klass, const void *data)
 
     set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
     device_class_set_props(dc, virtio_blk_pci_properties);
-    pci_qdev_property_add_specifics(dc);
     k->realize = virtio_blk_pci_realize;
     pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
     pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_BLOCK;
@@ -89,6 +89,18 @@ static void virtio_blk_pci_instance_init(Object *obj)
                               "bootindex");
 }
 
+static void virtio_blk_pci_s390x_class_init(ObjectClass *klass,
+                                            const void *data)
+{
+    virtio_blk_pci_class_init(klass, data);
+    pci_qdev_property_add_specifics(DEVICE_CLASS(klass));
+}
+
+static bool target_not_s390x(void)
+{
+    return !target_s390x();
+}
+
 static const VirtioPCIDeviceTypeInfo virtio_blk_pci_info = {
     .base_name              = TYPE_VIRTIO_BLK_PCI,
     .generic_name           = "virtio-blk-pci",
@@ -97,11 +109,24 @@ static const VirtioPCIDeviceTypeInfo virtio_blk_pci_info = {
     .instance_size = sizeof(VirtIOBlkPCI),
     .instance_init = virtio_blk_pci_instance_init,
     .class_init    = virtio_blk_pci_class_init,
+    .is_available  = target_not_s390x,
+};
+
+static const VirtioPCIDeviceTypeInfo virtio_blk_pci_s390x_info = {
+    .base_name              = TYPE_VIRTIO_BLK_PCI,
+    .generic_name           = "virtio-blk-pci",
+    .transitional_name      = "virtio-blk-pci-transitional",
+    .non_transitional_name  = "virtio-blk-pci-non-transitional",
+    .instance_size = sizeof(VirtIOBlkPCI),
+    .instance_init = virtio_blk_pci_instance_init,
+    .class_init    = virtio_blk_pci_s390x_class_init,
+    .is_available  = target_s390x,
 };
 
 static void virtio_blk_pci_register(void)
 {
     virtio_pci_types_register(&virtio_blk_pci_info);
+    virtio_pci_types_register(&virtio_blk_pci_s390x_info);
 }
 
 type_init(virtio_blk_pci_register)
diff --git a/hw/virtio/virtio-net-pci.c b/hw/virtio/virtio-net-pci.c
index 893d1905a97..0b018e6b094 100644
--- a/hw/virtio/virtio-net-pci.c
+++ b/hw/virtio/virtio-net-pci.c
@@ -22,6 +22,7 @@
 #include "hw/virtio/virtio-pci.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#include "qemu/target-info.h"
 #include "qom/object.h"
 
 typedef struct VirtIONetPCI VirtIONetPCI;
@@ -77,7 +78,6 @@ static void virtio_net_pci_class_init(ObjectClass *klass, const void *data)
     k->sriov_vf_user_creatable = true;
     set_bit(DEVICE_CATEGORY_NETWORK, dc->categories);
     device_class_set_props(dc, virtio_net_properties);
-    pci_qdev_property_add_specifics(dc);
     vpciklass->realize = virtio_net_pci_realize;
 }
 
@@ -91,6 +91,18 @@ static void virtio_net_pci_instance_init(Object *obj)
                               "bootindex");
 }
 
+static void virtio_net_pci_s390x_class_init(ObjectClass *klass,
+                                            const void *data)
+{
+    virtio_net_pci_class_init(klass, data);
+    pci_qdev_property_add_specifics(DEVICE_CLASS(klass));
+}
+
+static bool target_not_s390x(void)
+{
+    return !target_s390x();
+}
+
 static const VirtioPCIDeviceTypeInfo virtio_net_pci_info = {
     .base_name             = TYPE_VIRTIO_NET_PCI,
     .generic_name          = "virtio-net-pci",
@@ -99,11 +111,24 @@ static const VirtioPCIDeviceTypeInfo virtio_net_pci_info = {
     .instance_size = sizeof(VirtIONetPCI),
     .instance_init = virtio_net_pci_instance_init,
     .class_init    = virtio_net_pci_class_init,
+    .is_available  = target_not_s390x,
+};
+
+static const VirtioPCIDeviceTypeInfo virtio_net_pci_s390x_info = {
+    .base_name             = TYPE_VIRTIO_NET_PCI,
+    .generic_name          = "virtio-net-pci",
+    .transitional_name     = "virtio-net-pci-transitional",
+    .non_transitional_name = "virtio-net-pci-non-transitional",
+    .instance_size = sizeof(VirtIONetPCI),
+    .instance_init = virtio_net_pci_instance_init,
+    .class_init    = virtio_net_pci_s390x_class_init,
+    .is_available  = target_s390x,
 };
 
 static void virtio_net_pci_register(void)
 {
     virtio_pci_types_register(&virtio_net_pci_info);
+    virtio_pci_types_register(&virtio_net_pci_s390x_info);
 }
 
 type_init(virtio_net_pci_register)
-- 
2.55.0.windows.3

[PATCH v2 10/12] target-info: add target_base_i386()

[Yonggang Luo]

target_base_arm(), target_base_ppc() and target_base_riscv() report
whether the selected target belongs to a CPU family. Add the same
predicate for i386 and x86_64.

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 include/qemu/target-info.h |  7 +++++++
 target-info.c              | 11 +++++++++++
 2 files changed, 18 insertions(+)

diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 1d6c6f4472c..beb7980ca87 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -57,6 +57,13 @@ bool target_heterogeneous(void);
  */
 bool target_base_arm(void);
 
+/**
+ * target_base_i386:
+ *
+ * Returns whether the target architecture is i386 or x86_64.
+ */
+bool target_base_i386(void);
+
 /**
  * target_arm:
  *
diff --git a/target-info.c b/target-info.c
index 07dc88fd366..d8cd2209018 100644
--- a/target-info.c
+++ b/target-info.c
@@ -59,6 +59,17 @@ bool target_base_arm(void)
     }
 }
 
+bool target_base_i386(void)
+{
+    switch (target_arch()) {
+    case SYS_EMU_TARGET_I386:
+    case SYS_EMU_TARGET_X86_64:
+        return true;
+    default:
+        return false;
+    }
+}
+
 bool target_arm(void)
 {
     return target_arch() == SYS_EMU_TARGET_ARM;
-- 
2.55.0.windows.3

[PATCH v2 11/12] hw/virtio/virtio-mem: register legacy-guest variant with is_available

[Yonggang Luo]

virtio-mem decided in class_init and realize whether x86 guests can
leave unplugged memory accessible. Register a second virtio-mem type
that adds virtio_mem_legacy_guests_properties and sets
VirtIOMEMClass.has_legacy_guests. Select the two with
target_base_i386() and target_not_base_i386().

Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/virtio/virtio-mem.c         | 52 +++++++++++++++++++++-------------
 include/hw/virtio/virtio-mem.h |  2 ++
 2 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index ee6a0c206af..ab2864d18c3 100644
--- a/hw/virtio/virtio-mem.c
+++ b/hw/virtio/virtio-mem.c
@@ -15,6 +15,7 @@
 #include "qemu/cutils.h"
 #include "qemu/error-report.h"
 #include "qemu/units.h"
+#include "qemu/target-info.h"
 #include "qemu/target-info-qapi.h"
 #include "system/memory.h"
 #include "system/numa.h"
@@ -35,22 +36,6 @@
 
 static const VMStateDescription vmstate_virtio_mem_device_early;
 
-static bool virtio_mem_has_legacy_guests(void)
-{
-    /*
-     * We only had legacy x86 guests that did not support
-     * VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. Other targets don't have
-     * legacy guests.
-     */
-    switch (target_arch()) {
-    case SYS_EMU_TARGET_I386:
-    case SYS_EMU_TARGET_X86_64:
-        return true;
-    default:
-        return false;
-    }
-}
-
 /*
  * Let's not allow blocks smaller than 1 MiB, for example, to keep the tracking
  * bitmap small.
@@ -859,7 +844,7 @@ static void virtio_mem_device_realize(DeviceState *dev, Error **errp)
     rb = vmem->memdev->mr.ram_block;
     page_size = qemu_ram_pagesize(rb);
 
-    if (virtio_mem_has_legacy_guests()) {
+    if (VIRTIO_MEM_GET_CLASS(vmem)->has_legacy_guests) {
         switch (vmem->unplugged_inaccessible) {
         case ON_OFF_AUTO_AUTO:
             if (virtio_mem_has_shared_zeropage(rb)) {
@@ -1635,9 +1620,6 @@ static void virtio_mem_class_init(ObjectClass *klass, const void *data)
     RamDiscardSourceClass *rdsc = RAM_DISCARD_SOURCE_CLASS(klass);
 
     device_class_set_props(dc, virtio_mem_properties);
-    if (virtio_mem_has_legacy_guests()) {
-        device_class_set_props(dc, virtio_mem_legacy_guests_properties);
-    }
     dc->vmsd = &vmstate_virtio_mem;
 
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
@@ -1660,6 +1642,19 @@ static void virtio_mem_class_init(ObjectClass *klass, const void *data)
     rdsc->is_populated = virtio_mem_rds_is_populated;
 }
 
+static void virtio_mem_legacy_class_init(ObjectClass *klass, const void *data)
+{
+    virtio_mem_class_init(klass, data);
+    device_class_set_props(DEVICE_CLASS(klass),
+                           virtio_mem_legacy_guests_properties);
+    VIRTIO_MEM_CLASS(klass)->has_legacy_guests = true;
+}
+
+static bool target_not_base_i386(void)
+{
+    return !target_base_i386();
+}
+
 static const TypeInfo virtio_mem_info = {
     .name = TYPE_VIRTIO_MEM,
     .parent = TYPE_VIRTIO_DEVICE,
@@ -1668,6 +1663,22 @@ static const TypeInfo virtio_mem_info = {
     .instance_finalize = virtio_mem_instance_finalize,
     .class_init = virtio_mem_class_init,
     .class_size = sizeof(VirtIOMEMClass),
+    .is_available = target_not_base_i386,
+    .interfaces = (const InterfaceInfo[]) {
+        { TYPE_RAM_DISCARD_SOURCE },
+        { }
+    },
+};
+
+static const TypeInfo virtio_mem_legacy_info = {
+    .name = TYPE_VIRTIO_MEM,
+    .parent = TYPE_VIRTIO_DEVICE,
+    .instance_size = sizeof(VirtIOMEM),
+    .instance_init = virtio_mem_instance_init,
+    .instance_finalize = virtio_mem_instance_finalize,
+    .class_init = virtio_mem_legacy_class_init,
+    .class_size = sizeof(VirtIOMEMClass),
+    .is_available = target_base_i386,
     .interfaces = (const InterfaceInfo[]) {
         { TYPE_RAM_DISCARD_SOURCE },
         { }
@@ -1677,6 +1688,7 @@ static const TypeInfo virtio_mem_info = {
 static void virtio_register_types(void)
 {
     type_register_static(&virtio_mem_info);
+    type_register_static(&virtio_mem_legacy_info);
 }
 
 type_init(virtio_register_types)
diff --git a/include/hw/virtio/virtio-mem.h b/include/hw/virtio/virtio-mem.h
index 5d1d19c6bec..f367959ecb0 100644
--- a/include/hw/virtio/virtio-mem.h
+++ b/include/hw/virtio/virtio-mem.h
@@ -134,6 +134,8 @@ struct VirtIOMEMClass {
     VirtioDeviceClass parent_class;
 
     /* public */
+    bool has_legacy_guests;
+
     void (*fill_device_info)(const VirtIOMEM *vmen, VirtioMEMDeviceInfo *vi);
     MemoryRegion *(*get_memory_region)(VirtIOMEM *vmem, Error **errp);
     void (*decide_memslots)(VirtIOMEM *vmem, unsigned int limit);
-- 
2.55.0.windows.3

[PATCH v2 12/12] hw/microblaze: defer PetaLogix endianness default until init

[Yonggang Luo]

The PetaLogix machine read its endianness default from
target_big_endian() in class_init. In a multi-target binary the target
is not selected yet at class_init, so the default cannot be computed
there. Set the property default to "unspecified" instead, and resolve
it to big or little in petalogix_s3adsp1800_init(), where the target is
known.

Until the machine is initialized, endianness reads back as
"unspecified" rather than big or little.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 hw/microblaze/petalogix_s3adsp1800_mmu.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/microblaze/petalogix_s3adsp1800_mmu.c b/hw/microblaze/petalogix_s3adsp1800_mmu.c
index c5f64319009..4abb6e0f0bf 100644
--- a/hw/microblaze/petalogix_s3adsp1800_mmu.c
+++ b/hw/microblaze/petalogix_s3adsp1800_mmu.c
@@ -83,7 +83,13 @@ petalogix_s3adsp1800_init(MachineState *machine)
     MemoryRegion *phys_ram = g_new(MemoryRegion, 1);
     qemu_irq irq[32];
     MemoryRegion *sysmem = get_system_memory();
-    EndianMode endianness = psms->endianness;
+    EndianMode endianness;
+
+    if (psms->endianness == ENDIAN_MODE_UNSPECIFIED) {
+        psms->endianness = target_big_endian() ? ENDIAN_MODE_BIG :
+                                                 ENDIAN_MODE_LITTLE;
+    }
+    endianness = psms->endianness;
 
     cpu = MICROBLAZE_CPU(object_new(TYPE_MICROBLAZE_CPU));
     object_property_set_str(OBJECT(cpu), "version", "7.10.d", &error_abort);
@@ -178,8 +184,7 @@ static void petalogix_s3adsp1800_machine_class_init(ObjectClass *oc,
                                           &EndianMode_lookup,
                                           machine_get_endianness,
                                           machine_set_endianness);
-    object_property_set_default_str(prop, target_big_endian() ? "big"
-                                                              : "little");
+    object_property_set_default_str(prop, "unspecified");
     object_class_property_set_description(oc, "endianness",
             "Defines whether the machine runs in big or little endian mode");
 }
-- 
2.55.0.windows.3

Re: [PATCH v2 04/12] hw/xtensa: expand DEFINE_MACHINE in virt.c

[Yonggang Luo]

On Sun, Nov 1, 2026 at 12:40 AM Yonggang Luo <luoyonggang@gmail.com> wrote:
>
> Expand DEFINE_MACHINE() in hw/xtensa/virt.c to xtensa_virt_machine_typeinfo
> and xtensa_virt_machine_register_types() calling type_register_static().
>
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  hw/xtensa/virt.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
> index 271f06e0953..8c8fdad72f0 100644
> --- a/hw/xtensa/virt.c
> +++ b/hw/xtensa/virt.c
> @@ -115,8 +115,10 @@ static void xtensa_virt_init(MachineState *machine)
>      xtensa_sim_load_kernel(cpu, machine);
>  }
>
> -static void xtensa_virt_machine_init(MachineClass *mc)
> +static void xtensa_virt_machine_class_init(ObjectClass *oc, const void *data)
>  {
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
>      mc->desc = "virt machine (" XTENSA_DEFAULT_CPU_MODEL ")";
>      mc->init = xtensa_virt_init;
>      mc->max_cpus = 32;
> @@ -124,4 +126,16 @@ static void xtensa_virt_machine_init(MachineClass *mc)
>      mc->default_nic = "virtio-net-pci";
>  }
>
> -DEFINE_MACHINE("virt", xtensa_virt_machine_init)
> +static const TypeInfo xtensa_virt_machine_typeinfo = {
> +    .name       = MACHINE_TYPE_NAME("virt"),
> +    .parent     = TYPE_MACHINE,
> +    .class_init = xtensa_virt_machine_class_init,
> +    .instance_size = sizeof(MachineState),
> +};

In case I forgot,     .instance_size = sizeof(MachineState), should be removed
from this, it's redundant. And maybe for less boilerplate, we should
use DEFINE_TYPES
instead.


> +
> +static void xtensa_virt_machine_register_types(void)
> +{
> +    type_register_static(&xtensa_virt_machine_typeinfo);
> +}
> +
> +type_init(xtensa_virt_machine_register_types)
> --
> 2.55.0.windows.3
>


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

Re: [PATCH v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Daniel P. Berrangé]

On Sun, Nov 01, 2026 at 12:40:01AM +0800, Yonggang Luo wrote:
> max-v8 was one TypeInfo whose instance initializer was chosen from the
> selected target at registration. Register both initializers, and let
> target_arm() and target_aarch64() select which type is available.
> 
> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  target/arm/cpu.c            |  1 +
>  target/arm/cpu.h            |  1 +
>  target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 510fc9eeb3b..6eb55242980 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
>          .instance_init = arm_cpu_instance_init,
>          .class_init = info->class_init ?: cpu_register_class_init,
>          .class_data = info,
> +        .is_available = info->is_available,
>      };
>  
>      type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index add993ef101..3240a8633ee 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
>      const char *deprecation_note;
>      void (*initfn)(Object *obj);
>      void (*class_init)(ObjectClass *oc, const void *data);
> +    bool (*is_available)(void);
>  } ARMCPUInfo;
>  
>  /**
> diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> index 65f851f2006..e819d07e6ce 100644
> --- a/target/arm/tcg/cpu-max-v8.c
> +++ b/target/arm/tcg/cpu-max-v8.c
> @@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
> +        .name = "max-v8",
> +        .initfn = aarch32_max_v8_tcg_initfn,
> +        .is_available = target_arm,
>      };
> -    arm_cpu_register(&max_v8[target_aarch64()]);
> +    static const ARMCPUInfo max_v8_aarch64 = {
> +        .name = "max-v8",
> +        .initfn = aarch64_max_v8_tcg_initfn,
> +        .is_available = target_aarch64,
> +    };
> +
> +    arm_cpu_register(&max_v8_aarch32);
> +    arm_cpu_register(&max_v8_aarch64);
>  }
>  type_init(cpu_max_v8_register_type)

Conceptually these are two separate CPUs one 32-bit featureset
and one 64-bit featureset, but both given the same name. The
current code registers them only in the respective arm and aarch64
target binaries, but this CPU is an oddity overall.

More generally the aarch64 emulator includes all the 32-bit CPUs
that the arm emulator includes, and just adds extra 64-bit CPUs.
IOW, excluding the 32-bit max-v8 CPU is a special case - if it
were not for the clashing name, it would be included like all the
other 32-bit CPUs.

Thus rather than using is_available to continue to exclude it,
we must instead resolve the naming problem, such that both
models can be included concurrently.

One approach to this is to consider  the generic 'max-v8' name
to be an alias, that is resolved to the underlying real CPU
name 'max-v8-64' vs 'max-v8-32'. Allow the aliases to be
ambiguous, and either the selected target_info() disambiguates
aliases, or apps can use the canonical name instead of the alias.

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 v2 07/12] hw/scsi/scsi-disk: register s390x scsi-hd and scsi-cd variants

[Daniel P. Berrangé]

On Sun, Nov 01, 2026 at 12:40:02AM +0800, Yonggang Luo wrote:
> scsi-hd and scsi-cd added the s390x loadparm property from class_init
> when target_s390x() was true. Register a second type for each name
> that always adds loadparm, and select the two with target_s390x() and
> target_not_s390x().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  hw/scsi/scsi-disk.c | 48 +++++++++++++++++++++++++++++++++++----------
>  1 file changed, 38 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index 6341089ddf2..bb5377fb7fa 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -3221,14 +3221,11 @@ static void scsi_property_add_specifics(DeviceClass *dc)
>  {
>      ObjectClass *oc = OBJECT_CLASS(dc);
>  
> -    /* The loadparm property is only supported on s390x */
> -    if (target_s390x()) {
> -        object_class_property_add_str(oc, "loadparm",
> -                                      scsi_property_get_loadparm,
> -                                      scsi_property_set_loadparm);
> -        object_class_property_set_description(oc, "loadparm",
> -                                              "load parameter (s390x only)");
> -    }
> +    object_class_property_add_str(oc, "loadparm",
> +                                  scsi_property_get_loadparm,
> +                                  scsi_property_set_loadparm);
> +    object_class_property_set_description(oc, "loadparm",
> +                                          "load parameter (s390x only)");
>  }

IMHO this is the only change  that should be made. It is harmless to
have the property unconditionally registered for the class. Creating
extra duplicate named classes is expanding a problem that we should
be trying to eliminate, such that we have unique named classes.

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 v2 09/12] hw/virtio: register s390x virtio-blk-pci and virtio-net-pci variants

[Daniel P. Berrangé]

On Sun, Nov 01, 2026 at 12:40:04AM +0800, Yonggang Luo wrote:
> virtio-blk-pci and virtio-net-pci added the s390x loadparm property
> from class_init when target_s390x() was true. Register each
> VirtioPCIDeviceTypeInfo twice. The s390x variant calls
> pci_qdev_property_add_specifics(), which now always adds loadparm,
> and the other variant does not. target_s390x() and target_not_s390x() select
> the two.
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  hw/pci/pci.c               | 13 +++++--------
>  hw/virtio/virtio-blk-pci.c | 27 ++++++++++++++++++++++++++-
>  hw/virtio/virtio-net-pci.c | 27 ++++++++++++++++++++++++++-
>  3 files changed, 57 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 2d2fe02c68e..b5ea0b049aa 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2901,14 +2901,11 @@ void pci_qdev_property_add_specifics(DeviceClass *dc)
>  {
>      ObjectClass *oc = OBJECT_CLASS(dc);
>  
> -    /* The loadparm property is only supported on s390x */
> -    if (target_s390x()) {
> -        object_class_property_add_str(oc, "loadparm",
> -                                      pci_qdev_property_get_loadparm,
> -                                      pci_qdev_property_set_loadparm);
> -        object_class_property_set_description(oc, "loadparm",
> -                                              "load parameter (s390x only)");
> -    }
> +    object_class_property_add_str(oc, "loadparm",
> +                                  pci_qdev_property_get_loadparm,
> +                                  pci_qdev_property_set_loadparm);
> +    object_class_property_set_description(oc, "loadparm",
> +                                          "load parameter (s390x only)");
>  }
>  
>  MemoryRegion *pci_address_space(PCIDevice *dev)

Again this is the only bit that we need IMHO, as it is harmless to
register these properties unconditionally.

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 v2 11/12] hw/virtio/virtio-mem: register legacy-guest variant with is_available

[Daniel P. Berrangé]

On Sun, Nov 01, 2026 at 12:40:06AM +0800, Yonggang Luo wrote:
> virtio-mem decided in class_init and realize whether x86 guests can
> leave unplugged memory accessible. Register a second virtio-mem type
> that adds virtio_mem_legacy_guests_properties and sets
> VirtIOMEMClass.has_legacy_guests. Select the two with
> target_base_i386() and target_not_base_i386().
> 
> Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> ---
>  hw/virtio/virtio-mem.c         | 52 +++++++++++++++++++++-------------
>  include/hw/virtio/virtio-mem.h |  2 ++
>  2 files changed, 34 insertions(+), 20 deletions(-)
> 
> diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
> index ee6a0c206af..ab2864d18c3 100644
> --- a/hw/virtio/virtio-mem.c
> +++ b/hw/virtio/virtio-mem.c
> @@ -15,6 +15,7 @@
>  #include "qemu/cutils.h"
>  #include "qemu/error-report.h"
>  #include "qemu/units.h"
> +#include "qemu/target-info.h"
>  #include "qemu/target-info-qapi.h"
>  #include "system/memory.h"
>  #include "system/numa.h"
> @@ -35,22 +36,6 @@
>  
>  static const VMStateDescription vmstate_virtio_mem_device_early;
>  
> -static bool virtio_mem_has_legacy_guests(void)
> -{
> -    /*
> -     * We only had legacy x86 guests that did not support
> -     * VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. Other targets don't have
> -     * legacy guests.
> -     */
> -    switch (target_arch()) {
> -    case SYS_EMU_TARGET_I386:
> -    case SYS_EMU_TARGET_X86_64:
> -        return true;
> -    default:
> -        return false;
> -    }
> -}
> -
>  /*
>   * Let's not allow blocks smaller than 1 MiB, for example, to keep the tracking
>   * bitmap small.
> @@ -859,7 +844,7 @@ static void virtio_mem_device_realize(DeviceState *dev, Error **errp)
>      rb = vmem->memdev->mr.ram_block;
>      page_size = qemu_ram_pagesize(rb);
>  
> -    if (virtio_mem_has_legacy_guests()) {
> +    if (VIRTIO_MEM_GET_CLASS(vmem)->has_legacy_guests) {
>          switch (vmem->unplugged_inaccessible) {
>          case ON_OFF_AUTO_AUTO:
>              if (virtio_mem_has_shared_zeropage(rb)) {
> @@ -1635,9 +1620,6 @@ static void virtio_mem_class_init(ObjectClass *klass, const void *data)
>      RamDiscardSourceClass *rdsc = RAM_DISCARD_SOURCE_CLASS(klass);
>  
>      device_class_set_props(dc, virtio_mem_properties);
> -    if (virtio_mem_has_legacy_guests()) {
> -        device_class_set_props(dc, virtio_mem_legacy_guests_properties);
> -    }

Again IMHO the conditional property registration is an
unneccessary step. Just fold virtio_mem_legacy_guests_properties
into virtio_mem_properties.

In the realize() method, check virtio_mem_has_legacy_guests()
and reject values that are invalid for the non-x86 targets.


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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Yonggang Luo]

On Thu, Nov 5, 2026 at 6:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sun, Nov 01, 2026 at 12:40:01AM +0800, Yonggang Luo wrote:
> > max-v8 was one TypeInfo whose instance initializer was chosen from the
> > selected target at registration. Register both initializers, and let
> > target_arm() and target_aarch64() select which type is available.
> >
> > Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > ---
> >  target/arm/cpu.c            |  1 +
> >  target/arm/cpu.h            |  1 +
> >  target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
> >  3 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > index 510fc9eeb3b..6eb55242980 100644
> > --- a/target/arm/cpu.c
> > +++ b/target/arm/cpu.c
> > @@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
> >          .instance_init = arm_cpu_instance_init,
> >          .class_init = info->class_init ?: cpu_register_class_init,
> >          .class_data = info,
> > +        .is_available = info->is_available,
> >      };
> >
> >      type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
> > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > index add993ef101..3240a8633ee 100644
> > --- a/target/arm/cpu.h
> > +++ b/target/arm/cpu.h
> > @@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
> >      const char *deprecation_note;
> >      void (*initfn)(Object *obj);
> >      void (*class_init)(ObjectClass *oc, const void *data);
> > +    bool (*is_available)(void);
> >  } ARMCPUInfo;
> >
> >  /**
> > diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> > index 65f851f2006..e819d07e6ce 100644
> > --- a/target/arm/tcg/cpu-max-v8.c
> > +++ b/target/arm/tcg/cpu-max-v8.c
> > @@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
> > +        .name = "max-v8",
> > +        .initfn = aarch32_max_v8_tcg_initfn,
> > +        .is_available = target_arm,
> >      };
> > -    arm_cpu_register(&max_v8[target_aarch64()]);
> > +    static const ARMCPUInfo max_v8_aarch64 = {
> > +        .name = "max-v8",
> > +        .initfn = aarch64_max_v8_tcg_initfn,
> > +        .is_available = target_aarch64,
> > +    };
> > +
> > +    arm_cpu_register(&max_v8_aarch32);
> > +    arm_cpu_register(&max_v8_aarch64);
> >  }
> >  type_init(cpu_max_v8_register_type)
>
> Conceptually these are two separate CPUs one 32-bit featureset
> and one 64-bit featureset, but both given the same name. The
> current code registers them only in the respective arm and aarch64
> target binaries, but this CPU is an oddity overall.

This is the one I did before
https://lore.kernel.org/qemu-devel/20261013195606.152-1-luoyonggang@gmail.com/

target/arm: defer max-v8 initializer selection until CPU creation
but rejected, and I think it's fine.

>
> More generally the aarch64 emulator includes all the 32-bit CPUs
> that the arm emulator includes, and just adds extra 64-bit CPUs.
> IOW, excluding the 32-bit max-v8 CPU is a special case - if it
> were not for the clashing name, it would be included like all the
> other 32-bit CPUs.
>
> Thus rather than using is_available to continue to exclude it,
> we must instead resolve the naming problem, such that both
> models can be included concurrently.

I have already implemented the TypeBucket over targets/arch_mask that works
properly. That same QOM name will have multiple TypeImpl.

If you allow me, I'd like to post them all with TypeBucket implemented
so we have
a clean discussion basepoint.

>
> One approach to this is to consider  the generic 'max-v8' name
> to be an alias, that is resolved to the underlying real CPU
> name 'max-v8-64' vs 'max-v8-32'. Allow the aliases to be
> ambiguous, and either the selected target_info() disambiguates
> aliases, or apps can use the canonical name instead of the alias.
>
> 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 v2 09/12] hw/virtio: register s390x virtio-blk-pci and virtio-net-pci variants

[Yonggang Luo]

On Thu, Nov 5, 2026 at 7:03 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sun, Nov 01, 2026 at 12:40:04AM +0800, Yonggang Luo wrote:
> > virtio-blk-pci and virtio-net-pci added the s390x loadparm property
> > from class_init when target_s390x() was true. Register each
> > VirtioPCIDeviceTypeInfo twice. The s390x variant calls
> > pci_qdev_property_add_specifics(), which now always adds loadparm,
> > and the other variant does not. target_s390x() and target_not_s390x() select
> > the two.
> >
> > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > ---
> >  hw/pci/pci.c               | 13 +++++--------
> >  hw/virtio/virtio-blk-pci.c | 27 ++++++++++++++++++++++++++-
> >  hw/virtio/virtio-net-pci.c | 27 ++++++++++++++++++++++++++-
> >  3 files changed, 57 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 2d2fe02c68e..b5ea0b049aa 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -2901,14 +2901,11 @@ void pci_qdev_property_add_specifics(DeviceClass *dc)
> >  {
> >      ObjectClass *oc = OBJECT_CLASS(dc);
> >
> > -    /* The loadparm property is only supported on s390x */
> > -    if (target_s390x()) {
> > -        object_class_property_add_str(oc, "loadparm",
> > -                                      pci_qdev_property_get_loadparm,
> > -                                      pci_qdev_property_set_loadparm);
> > -        object_class_property_set_description(oc, "loadparm",
> > -                                              "load parameter (s390x only)");
> > -    }
> > +    object_class_property_add_str(oc, "loadparm",
> > +                                  pci_qdev_property_get_loadparm,
> > +                                  pci_qdev_property_set_loadparm);
> > +    object_class_property_set_description(oc, "loadparm",
> > +                                          "load parameter (s390x only)");
> >  }
> >
> >  MemoryRegion *pci_address_space(PCIDevice *dev)
>
> Again this is the only bit that we need IMHO, as it is harmless to
> register these properties unconditionally.

Hi that's the first choice of mine, I have did it a long ago

https://patchew.org/QEMU/20261013200525.1340-1-luoyonggang@gmail.com/

>
> 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 v2 09/12] hw/virtio: register s390x virtio-blk-pci and virtio-net-pci variants

[Daniel P. Berrangé]

On Thu, Nov 05, 2026 at 07:20:27PM +0800, Yonggang Luo wrote:
> On Thu, Nov 5, 2026 at 7:03 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Sun, Nov 01, 2026 at 12:40:04AM +0800, Yonggang Luo wrote:
> > > virtio-blk-pci and virtio-net-pci added the s390x loadparm property
> > > from class_init when target_s390x() was true. Register each
> > > VirtioPCIDeviceTypeInfo twice. The s390x variant calls
> > > pci_qdev_property_add_specifics(), which now always adds loadparm,
> > > and the other variant does not. target_s390x() and target_not_s390x() select
> > > the two.
> > >
> > > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > > ---
> > >  hw/pci/pci.c               | 13 +++++--------
> > >  hw/virtio/virtio-blk-pci.c | 27 ++++++++++++++++++++++++++-
> > >  hw/virtio/virtio-net-pci.c | 27 ++++++++++++++++++++++++++-
> > >  3 files changed, 57 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 2d2fe02c68e..b5ea0b049aa 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -2901,14 +2901,11 @@ void pci_qdev_property_add_specifics(DeviceClass *dc)
> > >  {
> > >      ObjectClass *oc = OBJECT_CLASS(dc);
> > >
> > > -    /* The loadparm property is only supported on s390x */
> > > -    if (target_s390x()) {
> > > -        object_class_property_add_str(oc, "loadparm",
> > > -                                      pci_qdev_property_get_loadparm,
> > > -                                      pci_qdev_property_set_loadparm);
> > > -        object_class_property_set_description(oc, "loadparm",
> > > -                                              "load parameter (s390x only)");
> > > -    }
> > > +    object_class_property_add_str(oc, "loadparm",
> > > +                                  pci_qdev_property_get_loadparm,
> > > +                                  pci_qdev_property_set_loadparm);
> > > +    object_class_property_set_description(oc, "loadparm",
> > > +                                          "load parameter (s390x only)");
> > >  }
> > >
> > >  MemoryRegion *pci_address_space(PCIDevice *dev)
> >
> > Again this is the only bit that we need IMHO, as it is harmless to
> > register these properties unconditionally.
> 
> Hi that's the first choice of mine, I have did it a long ago
> 
> https://patchew.org/QEMU/20261013200525.1340-1-luoyonggang@gmail.com/

Oh, I missed that series. That is exactly how I think it ought to
be done.


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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Daniel P. Berrangé]

On Thu, Nov 05, 2026 at 07:14:35PM +0800, Yonggang Luo wrote:
> On Thu, Nov 5, 2026 at 6:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Sun, Nov 01, 2026 at 12:40:01AM +0800, Yonggang Luo wrote:
> > > max-v8 was one TypeInfo whose instance initializer was chosen from the
> > > selected target at registration. Register both initializers, and let
> > > target_arm() and target_aarch64() select which type is available.
> > >
> > > Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> > > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > > ---
> > >  target/arm/cpu.c            |  1 +
> > >  target/arm/cpu.h            |  1 +
> > >  target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
> > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > > index 510fc9eeb3b..6eb55242980 100644
> > > --- a/target/arm/cpu.c
> > > +++ b/target/arm/cpu.c
> > > @@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
> > >          .instance_init = arm_cpu_instance_init,
> > >          .class_init = info->class_init ?: cpu_register_class_init,
> > >          .class_data = info,
> > > +        .is_available = info->is_available,
> > >      };
> > >
> > >      type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
> > > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > > index add993ef101..3240a8633ee 100644
> > > --- a/target/arm/cpu.h
> > > +++ b/target/arm/cpu.h
> > > @@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
> > >      const char *deprecation_note;
> > >      void (*initfn)(Object *obj);
> > >      void (*class_init)(ObjectClass *oc, const void *data);
> > > +    bool (*is_available)(void);
> > >  } ARMCPUInfo;
> > >
> > >  /**
> > > diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> > > index 65f851f2006..e819d07e6ce 100644
> > > --- a/target/arm/tcg/cpu-max-v8.c
> > > +++ b/target/arm/tcg/cpu-max-v8.c
> > > @@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
> > > +        .name = "max-v8",
> > > +        .initfn = aarch32_max_v8_tcg_initfn,
> > > +        .is_available = target_arm,
> > >      };
> > > -    arm_cpu_register(&max_v8[target_aarch64()]);
> > > +    static const ARMCPUInfo max_v8_aarch64 = {
> > > +        .name = "max-v8",
> > > +        .initfn = aarch64_max_v8_tcg_initfn,
> > > +        .is_available = target_aarch64,
> > > +    };
> > > +
> > > +    arm_cpu_register(&max_v8_aarch32);
> > > +    arm_cpu_register(&max_v8_aarch64);
> > >  }
> > >  type_init(cpu_max_v8_register_type)
> >
> > Conceptually these are two separate CPUs one 32-bit featureset
> > and one 64-bit featureset, but both given the same name. The
> > current code registers them only in the respective arm and aarch64
> > target binaries, but this CPU is an oddity overall.
> 
> This is the one I did before
> https://lore.kernel.org/qemu-devel/20261013195606.152-1-luoyonggang@gmail.com/
>
> target/arm: defer max-v8 initializer selection until CPU creation
> but rejected, and I think it's fine.

So that essentially matches the historical semantics where one
CPU class magically changes its behaviour based on what target
is running.  So in that sense, it works, and is no worse than
the semantics we've had for 'max' models forever.

Splitting into 2 distinct types is worthwhile if we want to
make it possible for the aarch64 emulator to support a runtime
choice of both 32-bit and 64-bit "max" models.

This patch doesn't allow that though, as it is creating two
classes with the same name and filtering which is registered.
If we don't intend to allow 64-bit target to ever use a 32-bit
'max' CPU, then your original patch is better IMHO.

> > More generally the aarch64 emulator includes all the 32-bit CPUs
> > that the arm emulator includes, and just adds extra 64-bit CPUs.
> > IOW, excluding the 32-bit max-v8 CPU is a special case - if it
> > were not for the clashing name, it would be included like all the
> > other 32-bit CPUs.
> >
> > Thus rather than using is_available to continue to exclude it,
> > we must instead resolve the naming problem, such that both
> > models can be included concurrently.
> 
> I have already implemented the TypeBucket over targets/arch_mask that works
> properly. That same QOM name will have multiple TypeImpl.

I'm not sure what you mean by TypeBucket, but my general thought is that
at the QOM class/type naming level everything must always be unique,
such that we have a single object modelk across QEMU.

Any ambiguitity & its resolution (if needed) should live outside core
QOM typework, such as with aliases in machines/CPUs.

If we have a common pattern for aliases, perhaps we could create a
standard QOM Interface for resolving aliases.


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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Yonggang Luo]

On Thursday, November 5, 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Nov 05, 2026 at 07:14:35PM +0800, Yonggang Luo wrote:
> > On Thu, Nov 5, 2026 at 6:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Sun, Nov 01, 2026 at 12:40:01AM +0800, Yonggang Luo wrote:
> > > > max-v8 was one TypeInfo whose instance initializer was chosen from the
> > > > selected target at registration. Register both initializers, and let
> > > > target_arm() and target_aarch64() select which type is available.
> > > >
> > > > Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> > > > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > > > ---
> > > >  target/arm/cpu.c            |  1 +
> > > >  target/arm/cpu.h            |  1 +
> > > >  target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
> > > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > > > index 510fc9eeb3b..6eb55242980 100644
> > > > --- a/target/arm/cpu.c
> > > > +++ b/target/arm/cpu.c
> > > > @@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
> > > >          .instance_init = arm_cpu_instance_init,
> > > >          .class_init = info->class_init ?: cpu_register_class_init,
> > > >          .class_data = info,
> > > > +        .is_available = info->is_available,
> > > >      };
> > > >
> > > >      type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
> > > > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > > > index add993ef101..3240a8633ee 100644
> > > > --- a/target/arm/cpu.h
> > > > +++ b/target/arm/cpu.h
> > > > @@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
> > > >      const char *deprecation_note;
> > > >      void (*initfn)(Object *obj);
> > > >      void (*class_init)(ObjectClass *oc, const void *data);
> > > > +    bool (*is_available)(void);
> > > >  } ARMCPUInfo;
> > > >
> > > >  /**
> > > > diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> > > > index 65f851f2006..e819d07e6ce 100644
> > > > --- a/target/arm/tcg/cpu-max-v8.c
> > > > +++ b/target/arm/tcg/cpu-max-v8.c
> > > > @@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
> > > > +        .name = "max-v8",
> > > > +        .initfn = aarch32_max_v8_tcg_initfn,
> > > > +        .is_available = target_arm,
> > > >      };
> > > > -    arm_cpu_register(&max_v8[target_aarch64()]);
> > > > +    static const ARMCPUInfo max_v8_aarch64 = {
> > > > +        .name = "max-v8",
> > > > +        .initfn = aarch64_max_v8_tcg_initfn,
> > > > +        .is_available = target_aarch64,
> > > > +    };
> > > > +
> > > > +    arm_cpu_register(&max_v8_aarch32);
> > > > +    arm_cpu_register(&max_v8_aarch64);
> > > >  }
> > > >  type_init(cpu_max_v8_register_type)
> > >
> > > Conceptually these are two separate CPUs one 32-bit featureset
> > > and one 64-bit featureset, but both given the same name. The
> > > current code registers them only in the respective arm and aarch64
> > > target binaries, but this CPU is an oddity overall.
> >
> > This is the one I did before
> > https://lore.kernel.org/qemu-devel/20261013195606.152-1-luoyonggang@gmail.com/
> >
> > target/arm: defer max-v8 initializer selection until CPU creation
> > but rejected, and I think it's fine.
>
> So that essentially matches the historical semantics where one
> CPU class magically changes its behaviour based on what target
> is running.  So in that sense, it works, and is no worse than
> the semantics we've had for 'max' models forever.
>
> Splitting into 2 distinct types is worthwhile if we want to
> make it possible for the aarch64 emulator to support a runtime
> choice of both 32-bit and 64-bit "max" models.
>
> This patch doesn't allow that though, as it is creating two
> classes with the same name and filtering which is registered.
> If we don't intend to allow 64-bit target to ever use a 32-bit
> 'max' CPU, then your original patch is better IMHO.


Hi Daniel, this is a prepare to allow creating two classes with the same name,
the is_available will be removed later.

Maybe I should directly replace is_available with TypeBucket to get
things be clear to review,
but that is explicitly rejected by Pierrick

>
>
> > > More generally the aarch64 emulator includes all the 32-bit CPUs
> > > that the arm emulator includes, and just adds extra 64-bit CPUs.
> > > IOW, excluding the 32-bit max-v8 CPU is a special case - if it
> > > were not for the clashing name, it would be included like all the
> > > other 32-bit CPUs.
> > >
> > > Thus rather than using is_available to continue to exclude it,
> > > we must instead resolve the naming problem, such that both
> > > models can be included concurrently.
> >
> > I have already implemented the TypeBucket over targets/arch_mask that works
> > properly. That same QOM name will have multiple TypeImpl.
>
> I'm not sure what you mean by TypeBucket, but my general thought is that
> at the QOM class/type naming level everything must always be unique,
> such that we have a single object modelk across QEMU.
>
> Any ambiguitity & its resolution (if needed) should live outside core
> QOM typework, such as with aliases in machines/CPUs.

Yeap, it's a design choice, both renaming the QOM type with
MachineClass::targets;
or using TypeBucket in object.c(so all QOM types do not need rename
including "virt" machines)
is implemented by me, it's just finally what we want to do.

>
> If we have a common pattern for aliases, perhaps we could create a
> standard QOM Interface for resolving aliases.
>
>
> 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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Peter Maydell]

On Thu, 5 Nov 2026 at 12:42, Daniel P. Berrangé <berrange@redhat.com> wrote:
> So that essentially matches the historical semantics where one
> CPU class magically changes its behaviour based on what target
> is running.  So in that sense, it works, and is no worse than
> the semantics we've had for 'max' models forever.
>
> Splitting into 2 distinct types is worthwhile if we want to
> make it possible for the aarch64 emulator to support a runtime
> choice of both 32-bit and 64-bit "max" models.

What would the difference between that and configuring the 64-bit
capable "max" to not have AArch64 via "-cpu max-v8:aarch64=off"
(which should work today) ?

-- PMM

Re: [PATCH v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Daniel P. Berrangé]

On Thu, Nov 05, 2026 at 01:45:00PM +0000, Peter Maydell wrote:
> On Thu, 5 Nov 2026 at 12:42, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > So that essentially matches the historical semantics where one
> > CPU class magically changes its behaviour based on what target
> > is running.  So in that sense, it works, and is no worse than
> > the semantics we've had for 'max' models forever.
> >
> > Splitting into 2 distinct types is worthwhile if we want to
> > make it possible for the aarch64 emulator to support a runtime
> > choice of both 32-bit and 64-bit "max" models.
> 
> What would the difference between that and configuring the 64-bit
> capable "max" to not have AArch64 via "-cpu max-v8:aarch64=off"
> (which should work today) ?

Is that really the same result ?

It seems like aarch64_max_v8_tcg_initfn does alot more CPU modelling
than aarch32_max_v8_tcg_initfn, than just a single flag ?


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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Peter Maydell]

On Thu, 5 Nov 2026 at 13:48, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Nov 05, 2026 at 01:45:00PM +0000, Peter Maydell wrote:
> > On Thu, 5 Nov 2026 at 12:42, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > So that essentially matches the historical semantics where one
> > > CPU class magically changes its behaviour based on what target
> > > is running.  So in that sense, it works, and is no worse than
> > > the semantics we've had for 'max' models forever.
> > >
> > > Splitting into 2 distinct types is worthwhile if we want to
> > > make it possible for the aarch64 emulator to support a runtime
> > > choice of both 32-bit and 64-bit "max" models.
> >
> > What would the difference between that and configuring the 64-bit
> > capable "max" to not have AArch64 via "-cpu max-v8:aarch64=off"
> > (which should work today) ?
>
> Is that really the same result ?
>
> It seems like aarch64_max_v8_tcg_initfn does alot more CPU modelling
> than aarch32_max_v8_tcg_initfn, than just a single flag ?

Conceptually it gets you to the same place -- a 32-bit only CPU
with all the 32-bit features turned on that we support.

aarch64_max_v8_tcg_initfn() sets up all the 64-bit-only ID registers,
which is most of what its code is doing. But the handling of
"aarch64=off" then clears them all out via arm_clear_aarch64_idregs(),
and even if it didn't, any 64-bit-only features are by definition
unreachable from 32-bit code.

It's possible it might not get you 100% absolutely an identical thing
from the guest's point of view, but any deviations should be minor
and I think we might consider them bugs.

There are some minor UI-level things relating to CPU properties,
e.g. "qemu-system-arm -cpu max,sve=on" gives a property not found
error, but "qemu-system-aarch64 -cpu max-v8,aarch64=off,sve=on"
will run (with no visible difference to the guest since SVE
is AArch64 only). It probably ought to error out complaining
that you've asked for two things that conflict, but this is
"minor bug" I think.

-- PMM

Re: [PATCH v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Daniel P. Berrangé]

On Thu, Nov 05, 2026 at 01:56:51PM +0000, Peter Maydell wrote:
> On Thu, 5 Nov 2026 at 13:48, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Nov 05, 2026 at 01:45:00PM +0000, Peter Maydell wrote:
> > > On Thu, 5 Nov 2026 at 12:42, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > So that essentially matches the historical semantics where one
> > > > CPU class magically changes its behaviour based on what target
> > > > is running.  So in that sense, it works, and is no worse than
> > > > the semantics we've had for 'max' models forever.
> > > >
> > > > Splitting into 2 distinct types is worthwhile if we want to
> > > > make it possible for the aarch64 emulator to support a runtime
> > > > choice of both 32-bit and 64-bit "max" models.
> > >
> > > What would the difference between that and configuring the 64-bit
> > > capable "max" to not have AArch64 via "-cpu max-v8:aarch64=off"
> > > (which should work today) ?
> >
> > Is that really the same result ?
> >
> > It seems like aarch64_max_v8_tcg_initfn does alot more CPU modelling
> > than aarch32_max_v8_tcg_initfn, than just a single flag ?
> 
> Conceptually it gets you to the same place -- a 32-bit only CPU
> with all the 32-bit features turned on that we support.
> 
> aarch64_max_v8_tcg_initfn() sets up all the 64-bit-only ID registers,
> which is most of what its code is doing. But the handling of
> "aarch64=off" then clears them all out via arm_clear_aarch64_idregs(),
> and even if it didn't, any 64-bit-only features are by definition
> unreachable from 32-bit code.
> 
> It's possible it might not get you 100% absolutely an identical thing
> from the guest's point of view, but any deviations should be minor
> and I think we might consider them bugs.
> 
> There are some minor UI-level things relating to CPU properties,
> e.g. "qemu-system-arm -cpu max,sve=on" gives a property not found
> error, but "qemu-system-aarch64 -cpu max-v8,aarch64=off,sve=on"
> will run (with no visible difference to the guest since SVE
> is AArch64 only). It probably ought to error out complaining
> that you've asked for two things that conflict, but this is
> "minor bug" I think.

Ok, in that case I'd agree aarch64 wouldn't need to expose a
distinct 32-bit CPU model for max


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 v2 06/12] target/arm: register separate max-v8 CPU types for arm and aarch64

[Daniel P. Berrangé]

On Thu, Nov 05, 2026 at 09:25:39PM +0800, Yonggang Luo wrote:
> On Thursday, November 5, 2026, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Nov 05, 2026 at 07:14:35PM +0800, Yonggang Luo wrote:
> > > On Thu, Nov 5, 2026 at 6:55 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > >
> > > > On Sun, Nov 01, 2026 at 12:40:01AM +0800, Yonggang Luo wrote:
> > > > > max-v8 was one TypeInfo whose instance initializer was chosen from the
> > > > > selected target at registration. Register both initializers, and let
> > > > > target_arm() and target_aarch64() select which type is available.
> > > > >
> > > > > Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> > > > > Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
> > > > > ---
> > > > >  target/arm/cpu.c            |  1 +
> > > > >  target/arm/cpu.h            |  1 +
> > > > >  target/arm/tcg/cpu-max-v8.c | 16 ++++++++++++----
> > > > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > > > > index 510fc9eeb3b..6eb55242980 100644
> > > > > --- a/target/arm/cpu.c
> > > > > +++ b/target/arm/cpu.c
> > > > > @@ -2695,6 +2695,7 @@ void arm_cpu_register(const ARMCPUInfo *info)
> > > > >          .instance_init = arm_cpu_instance_init,
> > > > >          .class_init = info->class_init ?: cpu_register_class_init,
> > > > >          .class_data = info,
> > > > > +        .is_available = info->is_available,
> > > > >      };
> > > > >
> > > > >      type_info.name = g_strdup_printf("%s-" TYPE_ARM_CPU, info->name);
> > > > > diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> > > > > index add993ef101..3240a8633ee 100644
> > > > > --- a/target/arm/cpu.h
> > > > > +++ b/target/arm/cpu.h
> > > > > @@ -1203,6 +1203,7 @@ typedef struct ARMCPUInfo {
> > > > >      const char *deprecation_note;
> > > > >      void (*initfn)(Object *obj);
> > > > >      void (*class_init)(ObjectClass *oc, const void *data);
> > > > > +    bool (*is_available)(void);
> > > > >  } ARMCPUInfo;
> > > > >
> > > > >  /**
> > > > > diff --git a/target/arm/tcg/cpu-max-v8.c b/target/arm/tcg/cpu-max-v8.c
> > > > > index 65f851f2006..e819d07e6ce 100644
> > > > > --- a/target/arm/tcg/cpu-max-v8.c
> > > > > +++ b/target/arm/tcg/cpu-max-v8.c
> > > > > @@ -121,10 +121,18 @@ void aarch32_max_v8_tcg_initfn(Object *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_aarch32 = {
> > > > > +        .name = "max-v8",
> > > > > +        .initfn = aarch32_max_v8_tcg_initfn,
> > > > > +        .is_available = target_arm,
> > > > >      };
> > > > > -    arm_cpu_register(&max_v8[target_aarch64()]);
> > > > > +    static const ARMCPUInfo max_v8_aarch64 = {
> > > > > +        .name = "max-v8",
> > > > > +        .initfn = aarch64_max_v8_tcg_initfn,
> > > > > +        .is_available = target_aarch64,
> > > > > +    };
> > > > > +
> > > > > +    arm_cpu_register(&max_v8_aarch32);
> > > > > +    arm_cpu_register(&max_v8_aarch64);
> > > > >  }
> > > > >  type_init(cpu_max_v8_register_type)
> > > >
> > > > Conceptually these are two separate CPUs one 32-bit featureset
> > > > and one 64-bit featureset, but both given the same name. The
> > > > current code registers them only in the respective arm and aarch64
> > > > target binaries, but this CPU is an oddity overall.
> > >
> > > This is the one I did before
> > > https://lore.kernel.org/qemu-devel/20261013195606.152-1-luoyonggang@gmail.com/
> > >
> > > target/arm: defer max-v8 initializer selection until CPU creation
> > > but rejected, and I think it's fine.
> >
> > So that essentially matches the historical semantics where one
> > CPU class magically changes its behaviour based on what target
> > is running.  So in that sense, it works, and is no worse than
> > the semantics we've had for 'max' models forever.
> >
> > Splitting into 2 distinct types is worthwhile if we want to
> > make it possible for the aarch64 emulator to support a runtime
> > choice of both 32-bit and 64-bit "max" models.
> >
> > This patch doesn't allow that though, as it is creating two
> > classes with the same name and filtering which is registered.
> > If we don't intend to allow 64-bit target to ever use a 32-bit
> > 'max' CPU, then your original patch is better IMHO.
> 
> 
> Hi Daniel, this is a prepare to allow creating two classes with
> the same name, the is_available will be removed later.

Sending patches to implement an approach which is already planned
to be removed is rather making life hard on reviewers.

> 
> Maybe I should directly replace is_available with TypeBucket to get
> things be clear to review,
> but that is explicitly rejected by Pierrick
> 
> >
> >
> > > > More generally the aarch64 emulator includes all the 32-bit CPUs
> > > > that the arm emulator includes, and just adds extra 64-bit CPUs.
> > > > IOW, excluding the 32-bit max-v8 CPU is a special case - if it
> > > > were not for the clashing name, it would be included like all the
> > > > other 32-bit CPUs.
> > > >
> > > > Thus rather than using is_available to continue to exclude it,
> > > > we must instead resolve the naming problem, such that both
> > > > models can be included concurrently.
> > >
> > > I have already implemented the TypeBucket over targets/arch_mask that works
> > > properly. That same QOM name will have multiple TypeImpl.
> >
> > I'm not sure what you mean by TypeBucket, but my general thought is that
> > at the QOM class/type naming level everything must always be unique,
> > such that we have a single object modelk across QEMU.
> >
> > Any ambiguitity & its resolution (if needed) should live outside core
> > QOM typework, such as with aliases in machines/CPUs.
> 
> Yeap, it's a design choice, both renaming the QOM type with
> MachineClass::targets;
> or using TypeBucket in object.c(so all QOM types do not need rename
> including "virt" machines)
> is implemented by me, it's just finally what we want to do.

I don't know what you mean with this TypeBucket concept, can you
share more info ?

IMHO, renaming the non-unique QOM types is inescapable. From a POV of
introspecting a binary, we need to get to a single uniform type
hierarchy across QEMU where the classes are all statically defined
and unique.  This complements the work to replace instance properties
with class properties, to also give us unambiguously introspectable
types.


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