[Libvir] Bug with libvirt in Xen 3.0.1?

Peter Vetere pvetere at redhat.com
Thu Jul 20 20:14:49 UTC 2006

>>> I've tried this same test on a system running xen 3.0.2, and as I 
>>> expected
>>> everything works fine.  So, there must be something different about 
>>> xen 3.0.1
>>> that libvirt is not accounting for.
>>  That's possible. If you still have that setup around, could you rerun
>> virsh (as root ) under gdb and put a breakpoint in xenHypervisorInit
>> and see what's happening in the first hypervisor call values of hc.op and
>> cmd, and return value (hv_version). Then what's happen in the second call
>> (is it failing too ?) in that same routine.
> Sure, I can do this.  I'll let you know what I find later on today.

Ok, I had a chance to run libvirt through the debugger as you asked. 
Here's what I got back:

After the first ioctl:

(gdb) ptype hc
type = struct privcmd_hypercall {
     __u64 op;
     __u64 arg[5];
(gdb) print hc.op
$6 = 17
(gdb) print cmd
$7 = 3166208
(gdb) print ret
$8 = -1

Then, after the second ioctl:

(gdb) ptype old_hc
type = struct old_hypercall_struct {
     long unsigned int op;
     long unsigned int arg[5];
(gdb) print old_hc.op
$11 = 17
(gdb) print cmd
$12 = 1593344
(gdb) print ret
$13 = 196608

The second ioctl appears to succeed.  One additional item of note is 
that I am running code that was compiled against xen 3.0.2, but is 
running on 3.0.1.  This may be part of the problem.

If there are any other quick tests you'd like me to run, just let me know.


More information about the libvir-list mailing list