@@ -2795,9 +2795,12 @@ DEFINE_VIRT_MACHINE_AS_LATEST(6, 2)
static void virt_machine_6_1_options(MachineClass *mc)
{
+ VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc));
+
virt_machine_6_2_options(mc);
compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
mc->smp_props.prefer_sockets = true;
+ vmc->no_cpu_topology = true;
}
DEFINE_VIRT_MACHINE(6, 1)
@@ -124,11 +124,13 @@ struct VirtMachineClass {
bool claim_edge_triggered_timers;
bool smbios_old_sys_ver;
bool no_highmem_ecam;
- bool no_ged; /* Machines < 4.2 has no support for ACPI GED device */
+ bool no_ged; /* Machines < 4.2 have no support for ACPI GED device */
bool kvm_no_adjvtime;
bool no_kvm_steal_time;
bool acpi_expose_flash;
bool no_secure_gpio;
+ /* Machines < 6.2 have no support for describing cpu topology to guest */
+ bool no_cpu_topology;
};
struct VirtMachineState {
On existing older machine types, without cpu topology described in ACPI or DT, the guest will populate one by default. With the topology described, it will read the information and set up its topology as instructed, but that may not be the same as what was getting used by default. It's possible that a user application has a dependency on the default topology and if the default one gets changed it will probably behave differently. So we should only describe cpu topology information to the guest on 6.2 and later machine types. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> --- hw/arm/virt.c | 3 +++ include/hw/arm/virt.h | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-)