On Fri, May 04, 2007 at 07:51:51PM +0200, Jan Michael wrote: > Cheers libvirt, > > I've tested the CLI virsh with my recent compiled version of libvirt > and version 0.1.9. In Version 0.2.2 vcpuinfo provides wrong > information. In version 0.1.9 only the values for VCPU and CPU are > wrong. Do you have any idea why? Can you tell me what architecture you are runing, and what Xen HV version is being used ?

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 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.

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 -=|

Hi Daniel, On 07.05.2007, at 22:06, Daniel P. Berrange wrote: >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: Thank you for trying to tracking down this error. Even though I get the following error from virsh command line interface, <error> [root@xen-machine libvirt-0.2.1]# ./src/virsh libvir: error : no support for hypervisor lt-virsh: error: failed to connect to the hypervisor </error>

>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 I'm not really shure about my kernel version and its origin because I didn't compiled it myself. But it is very likely that my kernel is no Fedora one because I use Scientific Linux.

On 10.05.2007, at 15:05, Daniel P. Berrange wrote: > On Thu, May 10, 2007 at 02:55:29PM +0200, Jan Michael wrote: >> <error> >> [root@xen-machine libvirt-0.2.1]# ./src/virsh >> libvir: error : no support for hypervisor >> lt-virsh: error: failed to connect to the hypervisor >> </error> > > Can you re-run with > > strace -f -o virsh.log ./srv/virsh > > And send the resulting log file. Done. Please find attached virsh.log.

Hi, Rich I am just a little time to do on this. If you have time, please do it. Anyway Another way to solve this is off the xen_internal.c function and on the xend_internal.c (This is just a templary.)