Re: [Xen-devel] caml stubdom crashes

[Alex Zeffertt <alex.zeffertt@xxxxxxxxxxxxx>]

Patrick Colp wrote:
> I tried running the regular XenStore (C xenstored) in a stubdomain using 
> your patches, but have run into some difficulty.
> What revision are the patches against? I noticed that not all of the 
> patches applied cleanly. In particular with the xen_use_virq_handler_api 
> patch, the files:
>    xen/arch/x86/cpu/mcheck/amd_nonfatal.c
>    xen/arch/x86/cpu/mcheck/mce_intel.c
My qparent is xen-unstable.hg: 19355:0e1449d6f231.  I'm afraid this is a couple 
of weeks old and I haven't refreshed the patch queue for the current head.

> failed to patch. I looked at the patch files and made the changes myself 
> (as best I could).
> I also had some issues with files missing (sysconfig.xenstore)) and some 
> missing header files in xen/io/xs_wire.h.
> For sysconfig.xenstore I just put one line in the file:
>
>    STUBDOM=yes
If you run "make dist" you should find that it creates this file in
  dist/install/etc/sysconfig/xenstore

and it's contents should be
  ## Uncomment to start xenstored in a dedicated stub domain (requires reboot)
  #STUBDOM=yes

I.e. by default you get a xenstore dom0 daemon and not a xenstore stubdom.  See 
the "independent-xend-and-xenstored" patch.
> Is that sufficient or are there other options that should be in there?
>
> I've attached the patches for the changes I made. I've managed to get 
> everything to compile and boot, however when I try to fire up xend, it 
> dies. I tried to start xenconsoled by hand. It seems to run OK (no error 
> messages or anything printed out), but it doesn't actually run.
> Is there something I'm missing? A boot option I need to pass to Xen or 
> anything? I used the patches you provided for Linux as well.
It sounds like you may not have rsync'd the whole dist/install directory across 
after rebuilding xen-unstable with the patches.  In addition to 
/etc/sysconfig/xenstore there is a new file called /etc/init.d/xenstore.  The 
problem you are seeing sounds like what would happen if this file was not present.
BTW, I've added a bit of code to /etc/init.d/xend  which runs 
"/etc/init.d/xenstored start" if it hasn't already been started.  This is there 
just in case users don't chkconfig this new script.
Regards,

Alex

> Thanks,
> Patrick
>
>
> George S. Coker, II wrote:
> > On 4/3/09 4:53 AM, "Alex Zeffertt" <alex.zeffertt@xxxxxxxxxxxxx> wrote:
> >
> > > George S. Coker, II wrote:
> > > > On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@xxxxxxxxx> wrote:
> > > >
> > > > > Alex Zeffertt wrote:
> > > > > > Hello ocaml minios stubdomain experts (that's narrowed down the list
> > > > > > somewhat!)
> > > > > >
> > > > > > I've been playing with the caml version of the "hello world" example
> > > > > > stubdomain that can be found in xen-unstable.hg/stubdom/caml/.
> > > > > >
> > > > > > If I make the following trivial modification to stubdom/caml/hello.ml
> > > > > > the stub domain page faults.  According to addr2line the page fault is
> > > > > > in ungetc.c:0.
> > > > > >
> > > > > > --- a/stubdom/caml/hello.ml    Mon Mar 30 11:42:16 2009 +0100
> > > > > > +++ b/stubdom/caml/hello.ml    Thu Apr 02 15:15:45 2009 +0100
> > > > > > @@ -1,4 +1,6 @@
> > > > > > +let yr = 2009
> > > > > > +
> > > > > >  let main arg =
> > > > > > -  Printf.printf "Hello, world!\n%!."
> > > > > > +  Printf.printf "Hello, world %d!\n%!." yr
> > > > > >
> > > > > >  let _ = Callback.register "main" main
> > > > > >
> > > > > >
> > > > > > Without the above change the stub domain runs as expected, i.e. it does
> > > > > > not page fault.
> > > > > >
> > > > > > I suspect the problem is that the caml-stubdom target in
> > > > > > stubdom/caml/Makefile compiles stubdom/caml/hello.ml and links it with
> > > > > > $(CAMLLIB)/libasmrun.a.  But this is a library compiled for the
> > > > > > development machine platform (linux-i386-glibc) not for the stubdomain
> > > > > > platform (minios-i386-newlib).
> > > > I don't think this is a linux-i386-glibc vs minios-i386-newlib issue but
> > > > rather the FORTIFY compiler options that introduce the
> > > > __fprintf_chk/__sprintf_chk funcs.  There is still something about the
> > > > behavior of the FORTIFY options that I am still not accounting for.  As
> > > > Patrick points out, special ports of ocaml should not be (and have not been)
> > > > necessary.
> > > >  
> > > Hi George, thanks for replying.
> > >
> > > Is this an option that was used when the ubuntu package managers built ocaml,
> > > but was not used by Debian.  Or have I misunderstood.
> > >
> > > I'm using your "_chk and _fail canaries" patch (actually I've had to extend it
> > > as I got even more undefined syms when I tried to compile
> > > xen-ocaml-tools/xenstored.)  Are you saying that there is a problem with this
> > > patch?
> > I think my patch is correct, but as you have found out my patch is also
> > incomplete.  I was not able to test with the ocaml xenstored when I created
> > the patch.
> >
> > The issues that this patch and your other patch address are introduced by
> > the FORTIFY and -Wstack-protector options that are used to compile the
> > system ocaml libraries.  Debian is the last hold out to implement these
> > options (and I *think* the most recent versions of Debian have started to
> > build system tools with these protections).  So I attempted to sketch out a
> > patch that would point the way for allowing mini-os to be linked with and
> > leverage these system libraries without pulling in special builds of system
> > tools or distro development dependencies.
> >
> > Thanks for your patch.  I'm going to have a further look into this issue
> > today.
> >
> > > Regards,
> > >
> > > Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel