[libvirt] vcpupin reports bogus vcpu affinities

[Ján Tomko]

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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190401/551a8556/attachment-0001.sig>