On Tue, Jan 08, 2008 at 06:42:40PM +0900, Saori Fukuta wrote: > Hi, > > There is a difference between 'CPU Affinity' of 'virsh vcpuinfo' and > 'CPU Affinity' of 'xm vcpu-list' when I set the vcpu affinity by > 'virsh vcpupin'. i.e. 'xm vcpu-list' shows wrong value. > But there is no difference between them when I set by 'xm vcpu-pin'. > > (a) set by 'virsh vcpupin' > # virsh vcpupin guest_dom 0 1 > # virsh vcpuinfo guest_dom > VCPU: 0 > CPU: 1 > State: blocked > CPU time: 17.1s > CPU Affinity: -y------ > > # xm vcpu-list guest_dom > Name ID VCPUs CPU State Time(s) CPU Affinity > guest_dom 13 0 1 -b- 17.1 any cpu > > (b) set by 'xm vcpu-pin' > # xm vcpu-pin guest_dom 0 0 > # virsh vcpuinfo guest_dom > VCPU: 0 > CPU: 0 > State: blocked > CPU time: 17.1s > CPU Affinity: y------- > > # xm vcpu-list guest_dom > Name ID VCPUs CPU State Time(s) CPU Affinity > guest_dom 13 0 0 -b- 17.1 0 > > I guess that the allocated memory to cpumap must be 8-byte for Xen > because "xc_vcpu_setaffinity(a)libxc/xc_domain.c" is using uint64_t > as cpumap. But the libvirt is allocating only maplen size for cpumap. > virsh +--- cpumaplen ---+ > (more than 1-byte) > xen +----------------- 8-byte -----------------+ > (uint64_t) > > Then, an irregular value is set to the buffer that is more than the > number of physical CPU, because libvirt initialize maplen size only > (i.e. not initialize 8-byte buffer). Ok I understand what's going on now - Xen expects the CPU map to be exactly 8 bytes long, but libvirt only requires that it be large enough to hold the desired mapping. So the map passed in by the libvirt caller may be too small so the HV ends up reading garbage. This patch looks good to me.