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

[Pierre Morel]

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