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.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|