[Libvir] virsh - vcpuinfo cmd not working in 0.2.2

[Atsushi SAKAI]

Hi, Dan

Thanks for your information.
I am also wondering mlock data.
(I guess old variable used in historical reason.)
I try to check it.

Anyway I change the struct(xen_v2_vcpuinfo) ordering.
(vcpu goes last and other goes to front in Dom0-vcpu0 case.)
Then I successfully get the information.
(This is just temporary, I investigate this issue in my side work)

Thanks
Atsushi SAKAI


"Daniel P. Berrange" <berrange at redhat.com> 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:
> 
> 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  -=|