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.
