On Fri, Mar 29, 2019 at 01:36:02PM +0000, Allen, John wrote:
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.
It's probably some internal data malloc keeps there.
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?
virBitmapToDataBuf is a generic helper so I think we can expect it to convert the smaller bitmap to a larger bitmap instead of accessing data out of bounds. Also, my cpumasks have a bitmap of either VIR_DOMAIN_CPUMASK_LEN (which is the magic number used in our XML parser) or 8 which is my host thread count and maplen passed by virsh is always '1', which seems to be the opposite of what you're seeing here Jano
-John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
