|
xen-devel
Re: [Xen-devel] caml stubdom crashes
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
|
|
|
Home