Re: [PATCH v14 08/11] qapi/s390/cpu topology: change-topology monitor command

[Thomas Huth]

On 17/01/2023 14.31, Nina Schoetterl-Glausch wrote:
> On Tue, 2023-01-17 at 08:30 +0100, Thomas Huth wrote:
> > On 16/01/2023 22.09, Nina Schoetterl-Glausch wrote:
> > > On Thu, 2023-01-05 at 15:53 +0100, Pierre Morel wrote:
> > > > The modification of the CPU attributes are done through a monitor
> > > > commands.
> > > >
> > > > It allows to move the core inside the topology tree to optimise
> > > > the cache usage in the case the host's hypervizor previously
> > > > moved the CPU.
> > > >
> > > > The same command allows to modifiy the CPU attributes modifiers
> > > > like polarization entitlement and the dedicated attribute to notify
> > > > the guest if the host admin modified scheduling or dedication of a vCPU.
> > > >
> > > > With this knowledge the guest has the possibility to optimize the
> > > > usage of the vCPUs.
> > > >
> > > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> > > > ---
...
> > > > +    s390_topology.sockets[s390_socket_nb(id)]--;
> > >
> > > I suppose this function cannot run concurrently, so the same CPU doesn't get 
> > > removed twice.
> >
> > QEMU has the so-called BQL - the Big Qemu Lock. Instructions handlers are
> > normally called with the lock taken, see qemu_mutex_lock_iothread() in
> > target/s390x/kvm/kvm.c.
>
> That is good to know, but is that the relevant lock here?
> We don't want to concurrent qmp commands. I looked at the code and it's pretty 
> complicated.

Not sure, but I believe that QMP commands are executed from the main 
iothread, so I think this should be safe? ... CC:-ing some more people who 
might know the correct answer.

 Thomas