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

[Pierre Morel]

On 1/18/23 11:53, Thomas Huth wrote:
> 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

That is what I understand from the doc too.
See:
docs/devel/qapi-code-gen.rst
One must specify allow-oob:true to avoid the BQL, default is false.

Regards,
Pierre



--
Pierre Morel
IBM Lab Boeblingen