[Libvir] virsh - vcpuinfo cmd not working in 0.2.2

[Daniel P. Berrange]

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