On 7/22/22 14:08, Janis Schoetterl-Glausch wrote:
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?
We will work on modifying the topology in another series.
Let's discuss this at that moment.
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.
We will work on modifying the topology in another series.
--
Pierre Morel
IBM Lab Boeblingen
