Sent this out to the list a few days ago, but never saw it appear on the archives. Resending--hopefully this makes it to the list. --- 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