For pinned vcpus, vcpupin will report inaccurate affinity values on machines
with high core counts (256 cores in my case). The problem is produced as
follows:
$ virsh vcpupin myguest 0 4
$ virsh vcpupin myguest 0
VCPU CPU Affinity
---------------------------
0 4,192,194,196-197
Running taskset on the qemu threads shows the correct affinity, so this seems
to be a reporting problem. Strangely, the value "192" is significant. If I pin
a cpu greater than 192, the problem no longer appears.
I believe the cause of the problem in my case is that in this case in
src/conf/domain_conf.c:virDomainDefGetVcpuPinInfoHelper:
...
if (vcpu && vcpu->cpumask)
bitmap = vcpu->cpumask;
...
vcpu->cpumask is "shortened" in that it is only long enough to contain the last
set bit in the mask. However, when we go to copy the mask to the buffer that is
returned, we use the masklen passed to the function which is the "full"
masklen with a bit for each cpu. So it seems virBitmapToDataBuf copies some
extra data past the end of the bitmask. Why the "192" value is always set and I
typically see similar bogus bits set is still unknown.
What is the function meant to assume in this case? Is it sane to assume that
the bitmask is the full length of the buffer here and it's the responsibility
of the setter of vcpu->cpumask to provide the length of the bitmap we're
expecting? Or should we assume that we may receive a shortened bitmask here and
expand the bitmask before copying to the buffer?
-John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
