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

[Janis Schoetterl-Glausch]

On 7/21/22 13:41, Pierre Morel wrote:
> 
> 
> On 7/21/22 10:16, Janis Schoetterl-Glausch wrote:
>> On 7/21/22 09:58, Pierre Morel wrote:
>>>
>>>
> 
> ...snip...
> 
>>>
>>> You are right, numa is redundant for us as we specify the topology using 
>>> the core-id.
>>> The roadmap I would like to discuss is using a new:
>>>
>>> (qemu) cpu_move src dst
>>>
>>> where src is the current core-id and dst is the destination core-id.
>>>
>>> I am aware that there are deep implication on current cpu code but I do not 
>>> think it is not possible.
>>> If it is unpossible then we would need a new argument to the device_add for 
>>> cpu to define the "effective_core_id"
>>> But we will still need the new hmp command to update the topology.

Why the requirement for a hmp command specifically? Would qom-set on a cpu 
property work?
>>>
>> I don't think core-id is the right one, that's the guest visible CPU 
>> address, isn't it?
> 
> Yes, the topology is the one seen by the guest.
> 
>> Although it seems badly named then, since multiple threads are part of the 
>> same core (ok, we don't support threads).
> 
> I guess that threads will always move with the core or... we do not support 
> threads.
> 
>> Instead socket-id, book-id could be changed dynamically instead of being 
>> computed from the core-id.
>>
> 
> What becomes of the core-id ?

It would stay the same. It has to, right? Can't change the address as reported 
by STAP.
I would just be completely independent of the other ids.