Re: [PATCH v12 1/7] s390x/cpu topology: Creating CPU topology device

[Thomas Huth]

On 29/11/2022 18.42, Pierre Morel wrote:
> We will need a Topology device to transfer the topology
> during migration and to implement machine reset.
>
> The device creation is fenced by s390_has_topology().
>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> ---
...
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 2e64ffab45..973bbdd36e 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -44,6 +44,7 @@
>   #include "hw/s390x/pv.h"
>   #include "migration/blocker.h"
>   #include "qapi/visitor.h"
> +#include "hw/s390x/cpu-topology.h"
>   
>   static Error *pv_mig_blocker;
>   
> @@ -102,6 +103,24 @@ static void s390_init_cpus(MachineState *machine)
>       }
>   }
>   
> +static DeviceState *s390_init_topology(MachineState *machine, Error **errp)
> +{
> +    DeviceState *dev;
> +
> +    dev = qdev_new(TYPE_S390_CPU_TOPOLOGY);
> +
> +    object_property_add_child(&machine->parent_obj,
> +                              TYPE_S390_CPU_TOPOLOGY, OBJECT(dev));
> +    object_property_set_int(OBJECT(dev), "num-cores",
> +                            machine->smp.cores * machine->smp.threads, errp);

I wonder what will happen if we ever support multithreading on s390x later? 
... won't this cause some oddities when migrating older machines types with 
smp.threads > 1 later? Maybe we should prohibit to enable the CPU topology 
instead if a user tried to use threads > 1 with an older machine type?

 Thomas


> +    object_property_set_int(OBJECT(dev), "num-sockets",
> +                            machine->smp.sockets, errp);
> +
> +    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), errp);
> +
> +    return dev;
> +}