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