Re: [PATCH v8 08/12] s390x/cpu_topology: implementing numa for the s390x topology

[Pierre Morel <pmorel@linux.ibm.com>]

On 7/14/22 16:57, Janis Schoetterl-Glausch wrote:
> On 6/20/22 16:03, Pierre Morel wrote:
>> S390x CPU Topology allows a non uniform repartition of the CPU
>> inside the topology containers, sockets, books and drawers.
>>
>> We use numa to place the CPU inside the right topology container
>> and report the non uniform topology to the guest.
>>
>> Note that s390x needs CPU0 to belong to the topology and consequently
>> all topology must include CPU0.
>>
>> We accept a partial QEMU numa definition, in that case undefined CPUs
>> are added to free slots in the topology starting with slot 0 and going
>> up.
> 
> I don't understand why doing it this way, via numa, makes sense for us.
> We report the topology to the guest via STSI, which tells the guest
> what the topology "tree" looks like. We don't report any numa distances to the guest.
> The natural way to specify where a cpu is added to the vm, seems to me to be
> by specify the socket, book, ... IDs when doing a device_add or via -device on
> the command line.
> 
> [...]
> 

It is a choice to have the core-id to determine were the CPU is situated 
in the topology.

But yes we can chose the use drawer-id,book-id,socket-id and use a 
core-id starting on 0 on each socket.

It is not done in the current implementation because the core-id implies 
the socket-id, book-id and drawer-id together with the smp parameters.


-- 
Pierre Morel
IBM Lab Boeblingen