[Libvir] Bug with libvirt in Xen 3.0.1?

[Daniel Veillard]

On Thu, Jul 20, 2006 at 04:14:49PM -0400, Peter Vetere wrote:
> 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

  okay, failure with the new hypercall structure, that's normal.

> 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 

  And here that succeed, now I would have to find why subsequent 
hypercall are failing even though libvirt detected it was the old 
interface.

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

  Well if it was compiled against 3.0.1 that would not have changed
I guess but it's another thing to test.

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

  I'm afraid now that the easy potential error has been dismissed, it will
be a real debug needed to find out why other hypercalls are failing.
Best is probably to bugzilla this and add a pointer to this thread for
reference (the recompilation against 3.0.1 should be tested too :-)

   thanks again,

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/