[libvirt] [PATCH 31/34] qemu: Replace checking for vcpu<->pid mapping availability with a helper

Peter Krempa pkrempa at redhat.com
Fri Nov 27 07:29:36 UTC 2015


On Mon, Nov 23, 2015 at 18:19:18 -0500, John Ferlan wrote:
> On 11/20/2015 10:22 AM, Peter Krempa wrote:
> > Add qemuDomainHasVCpuPids to do the checking and replace in place checks
> > with it.
> > ---
> >  src/qemu/qemu_cgroup.c  |  7 ++-----
> >  src/qemu/qemu_domain.c  | 15 +++++++++++++++
> >  src/qemu/qemu_domain.h  |  2 ++
> >  src/qemu/qemu_driver.c  | 29 +++++++++++++----------------
> >  src/qemu/qemu_process.c |  7 ++++---
> >  5 files changed, 36 insertions(+), 24 deletions(-)
> > 
> 
> Well I got close - reached critical mass here.
> 
> > diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
> > index 3c7694a..56c2e90 100644
> > --- a/src/qemu/qemu_cgroup.c
> > +++ b/src/qemu/qemu_cgroup.c
> > @@ -1005,12 +1005,9 @@ qemuSetupCgroupForVcpu(virDomainObjPtr vm)
> >          !virCgroupHasController(priv->cgroup, VIR_CGROUP_CONTROLLER_CPUSET))
> >          return 0;
> > 
> > -    if (priv->nvcpupids == 0 || priv->vcpupids[0] == vm->pid) {
> > -        /* If we don't know VCPU<->PID mapping or all vcpu runs in the same
> > -         * thread, we cannot control each vcpu.
> > -         */
> 
> 
> I'm curious about the vcpupids[0] == vm->pid checks... I feel like I
> missed some nuance with the last patch. Perhaps a bit more explanation
> with regard to what happened will help. What up to this point so far
> including this patch allows the "safe" removal of that check

Hmmm, it indeed isn't really obvious due to the fact that the code that
allows all these checks to be removed actually wasn't touched by this
series. In commits b07f3d821dfb11a118ee75ea275fd6ab737d9500 and
65686e5a81d654d834d338fceeaf0229b2ca4f0d. Implication of those commits
is that if qemu doesn't support vCPU pinning, the thread array is never
allocated rather than creating a fake one.

This implies that all vcpu-thread-id related operations are relevant
only if the array is allocated. That also implies that it contains
correct data. I'll try to compile the above info into the commit
message.

Sorry for causing misunderstandings :), it was actually obvious to me
what is happening solely due to the fact that I've seen the above
commits.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151127/2a4cdeed/attachment-0001.sig>


More information about the libvir-list mailing list