Re: [Libvir] virsh - vcpuinfo cmd not working in 0.2.2

On Mon, May 07, 2007 at 10:13:57AM +0900, Atsushi SAKAI wrote: > Hi, Jan > > I think you should use 0.2.1 at this moment. > libvirt cannot handle Xen-hypervisor-domctl correctly on 0.2.2. > But Xen-hypervisor-sysctl works fine. > This problem recognized in two weeks ago, > but I have no time to investigate this issue. I've been trying to reproduce / diagnose the problems you reported too but not had much luck so far. Every way I look at it the code looks to be using the correct hypercall numbers, operation numbers & structs. Until I just noticed this: xenHypervisorDoV2Dom(int handle, xen_op_v2_dom* op) { .... if (mlock(op, sizeof(dom0_op_t)) < 0) { Notice that it is doing sizeof(dom0_op_t) instead of sizeof(xen_op_v2_dom) There is the same typo with xenHypervisorDoV2Sys. Now dom0_op_t is defined as struct dom0_op { uint32_t cmd; uint32_t interface_version; /* DOM0_INTERFACE_VERSION */ union { struct dom0_msr msr; struct dom0_settime settime; struct dom0_add_memtype add_memtype; struct dom0_del_memtype del_memtype; struct dom0_read_memtype read_memtype; struct dom0_microcode microcode; struct dom0_platform_quirk platform_quirk; struct dom0_memory_map_entry physical_memory_map; uint8_t pad[128]; } u; }; Which is 4 + 4 + 128 bytes == 136 Nexzt, xen_sysctl is defined as struct xen_sysctl { uint32_t cmd; uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */ union { struct xen_sysctl_readconsole readconsole; struct xen_sysctl_tbuf_op tbuf_op; struct xen_sysctl_physinfo physinfo; struct xen_sysctl_sched_id sched_id; struct xen_sysctl_perfc_op perfc_op; struct xen_sysctl_getdomaininfolist getdomaininfolist; uint8_t pad[128]; } u; }; Which is also 4 + 4 + 128 bytes == 136 Finally, xen_domctl is defined as struct xen_domctl { uint32_t cmd; uint32_t interface_version; /* XEN_DOMCTL_INTERFACE_VERSION */ domid_t domain; union { struct xen_domctl_createdomain createdomain; struct xen_domctl_getdomaininfo getdomaininfo; struct xen_domctl_getmemlist getmemlist; struct xen_domctl_getpageframeinfo getpageframeinfo; struct xen_domctl_getpageframeinfo2 getpageframeinfo2; struct xen_domctl_vcpuaffinity vcpuaffinity; struct xen_domctl_shadow_op shadow_op; struct xen_domctl_max_mem max_mem; struct xen_domctl_vcpucontext vcpucontext; struct xen_domctl_getvcpuinfo getvcpuinfo; struct xen_domctl_max_vcpus max_vcpus; struct xen_domctl_scheduler_op scheduler_op; struct xen_domctl_setdomainhandle setdomainhandle; struct xen_domctl_setdebugging setdebugging; struct xen_domctl_irq_permission irq_permission; struct xen_domctl_iomem_permission iomem_permission; struct xen_domctl_ioport_permission ioport_permission; struct xen_domctl_hypercall_init hypercall_init; struct xen_domctl_arch_setup arch_setup; struct xen_domctl_settimeoffset settimeoffset; uint8_t pad[128]; } u; }; Which is cruicially different 4 + 4 + 2 + 128 bytes == 138 So the buffer we're mlock()ing is 2 bytes too small for domctl hypercalls. This may or may not explan the bugs, but its a worthwhile bug fix to try if you have a system where you can reliably reproduce the vcpu problems. The second thing is that we've just discovered a bug in the Fedora Xen kernels 2.6.20 wrt to SMP which could cause random bad things to happen So if you're using a Fedora 2.6.20 kernel it is also worth seeing if it is still a problem with an older Fedora 2.6.19/18 kernel, or with the vanilla upstream Xen 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 -=|