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