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

[Pierre Morel]

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