Re: xen-backend

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Christoph Egger wrote:
> Manuel Bouyer wrote:
> > On Sun, May 25, 2008 at 05:56:33PM +0200, Christoph Egger wrote:
> > > I think, it is best to start with a (stupid) question:
> > >
> > >
> > > When launching a PV guest with one disk and no vif,
> > > what is the successful code-path from "xm create"
> > > to the guest kernels boot message ?
> > >
> > > Somewhere in between must be obviously the error.
> > > I turned on all dom0 xen debug messages and all
> > > what I get are debug messages from the xenbus_xs.c
> >
> > > > From what I remeber, xm (or xend) creates the new domain's memory space
> > and loads it with the kernel, and create the new domain's entries (both
> > frontend and backend) in xenstore. Writing the backend values to xenstore
> > should trigger a call to *xenbus_create in backend drivers.
> > This will set a watch on the corresponding frontend entries, and 
> > switch the
> > backend state to XenbusStateInitWait. This should wakeup xenbackendd
> > which calls the scripts for the corresponding backends. The script
> > does whatever config is needed and writes to the store the 
> > informations for
> > the backend, and write the backend's "hotplug-status" entry to
> > "connected". I think writing hotplug-status is what cause xm or xend to
> > unpause the domU, which starts booting.
>
> When I fill up src/sys/arch/xen/xenbus/xenbus_probe.c with debug code
> (see attached diff), then *xenbus_create is called in backend drivers
> and things go fine.
>
> But without the debug code, *xenbus_create is never called and backend
> state stays in XenbusStateInitialising.
>
> What could be going on? Is there a timing problem? Is there a signal 
> delivery bug? Is there a gcc bug?

I identified the debug printf's that make it work. See attached diff.
Commenting out one of them or both results in *xenbus_create not being 
called and produces a "Hotplug scripts not working" error.

A comparison of the assembler snippet in xenbus_probe_init:


1) Without the debug diff:

ffffffff804e01d7:       0f 85 c2 00 00 00       jne    ffffffff804e029f 
<xenbus_probe_init+0x17f>
ffffffff804e01dd:       8b 45 c8                mov 
0xffffffffffffffc8(%rbp),%eax
ffffffff804e01e0:       89 05 ba c7 6b 00       mov 
%eax,7063482(%rip)        # ffffffff80b9c9a0 <start_info_union+0x40>
ffffffff804e01e6:       e8 c5 ef ff ff          callq  ffffffff804df1b0 
<xenbus_kernfs_init>
ffffffff804e01eb:       48 8b 3d 26 61 6c 00    mov 
7102758(%rip),%rdi        # ffffffff80ba6318 <xenbus_sc>
ffffffff804e01f2:       e8 09 ec ff ff          callq  ffffffff804dee00 
<xb_init_comms>
ffffffff804e01f7:       e8 74 02 00 00          callq  ffffffff804e0470 
<xs_init>
ffffffff804e01fc:       85 c0                   test   %eax,%eax
ffffffff804e01fe:       89 c3                   mov    %eax,%ebx
ffffffff804e0200:       74 25                   je     ffffffff804e0227 
<xenbus_probe_init+0x107>


2) With the debug diff:

ffffffff804e01d7:       0f 85 ec 00 00 00       jne    ffffffff804e02c9 
<xenbus_probe_init+0x1a9>
ffffffff804e01dd:       8b 45 c8                mov 
0xffffffffffffffc8(%rbp),%eax
ffffffff804e01e0:       48 c7 c6 00 68 6d 80    mov 
$0xffffffff806d6800,%rsi
ffffffff804e01e7:       48 c7 c7 48 87 84 80    mov 
$0xffffffff80848748,%rdi
ffffffff804e01ee:       89 05 ac c7 6b 00       mov 
%eax,7063468(%rip)        # ffffffff80b9c9a0 <start_info_union+0x40>
ffffffff804e01f4:       31 c0                   xor    %eax,%eax
ffffffff804e01f6:       e8 75 98 f3 ff          callq  ffffffff80419a70 
<printf>
ffffffff804e01fb:       e8 b0 ef ff ff          callq  ffffffff804df1b0 
<xenbus_kernfs_init>
ffffffff804e0200:       48 c7 c6 00 68 6d 80    mov 
$0xffffffff806d6800,%rsi
ffffffff804e0207:       31 c0                   xor    %eax,%eax
ffffffff804e0209:       48 c7 c7 56 87 84 80    mov 
$0xffffffff80848756,%rdi
ffffffff804e0210:       e8 5b 98 f3 ff          callq  ffffffff80419a70 
<printf>
ffffffff804e0215:       48 8b 3d fc 60 6c 00    mov 
7102716(%rip),%rdi        # ffffffff80ba6318 <xenbus_sc>
ffffffff804e021c:       e8 df eb ff ff          callq  ffffffff804dee00 
<xb_init_comms>
ffffffff804e0221:       e8 7a 02 00 00          callq  ffffffff804e04a0 
<xs_init>
ffffffff804e0226:       85 c0                   test   %eax,%eax
ffffffff804e0228:       89 c3                   mov    %eax,%ebx
ffffffff804e022a:       74 25                   je     ffffffff804e0251 
<xenbus_probe_init+0x131>


Anyone seeing the impact ?

Christoph

Index: sys/arch/xen/xenbus/xenbus_probe.c
===================================================================
RCS file: /cvsroot/src/sys/arch/xen/xenbus/xenbus_probe.c,v
retrieving revision 1.20
diff -u -p -r1.20 xenbus_probe.c
--- sys/arch/xen/xenbus/xenbus_probe.c  16 Apr 2008 18:41:48 -0000      1.20
+++ sys/arch/xen/xenbus/xenbus_probe.c  28 May 2008 22:41:58 -0000
@@ -548,6 +548,7 @@ xenbus_probe_init(void *unused)
                        panic("can't register xenstore event");
                xen_start_info.store_evtchn = op.u.alloc_unbound.port;
 
+printf("%s: check A\n", __func__);
                /* And finally publish the above info in /kern/xen */
                xenbus_kernfs_init();
 #else /* DOM0OPS */
@@ -555,6 +556,7 @@ xenbus_probe_init(void *unused)
 #endif /* DOM0OPS */
        }
 
+printf("%s: check B\n", __func__);
        /* register event handler */
        xb_init_comms(xenbus_sc);