WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] caml stubdom crashes

To: Alex Zeffertt <alex.zeffertt@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] caml stubdom crashes
From: Patrick Colp <pjcolp@xxxxxxxxx>
Date: Fri, 03 Apr 2009 14:07:44 -0700
Cc: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Delivery-date: Fri, 03 Apr 2009 14:09:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5FB9B3A.2C6AD%gscoker@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C5FB9B3A.2C6AD%gscoker@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090318)
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

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

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.


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

diff -r d5ddc782bc49 xen/arch/x86/cpu/mcheck/amd_nonfatal.c
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c    Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c    Fri Apr 03 13:53:59 2009 -0700
@@ -103,7 +103,7 @@
 
                if (event_enabled) {
                        mctelem_commit(mctc);
-                       send_guest_global_virq(dom0, VIRQ_MCA);
+                       send_handler_global_virq(VIRQ_MCA);
                } else if (++dumpcount >= 10) {
                        x86_mcinfo_dump((struct mc_info 
*)mctelem_dataptr(mctc));
                        mctelem_dismiss(mctc);
diff -r d5ddc782bc49 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Apr 03 13:53:59 2009 -0700
@@ -350,6 +350,7 @@
     }
     /* We choose severity_cpu for further processing */
     if (severity_cpu == cpu) {
+        struct domain *handler;
 
         /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
          * vMCE MSRs virtualization buffer
@@ -359,9 +360,10 @@
                      "virtualization data failed!\n");
 
         /* Step2: Send Log to DOM0 through vIRQ */
-        if (dom0 && guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             printk(KERN_DEBUG "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         }
 
         /* Step3: Inject vMCE to impacted DOM. Currently we cares DOM0 only */
@@ -591,9 +593,11 @@
         MCA_CMCI_HANDLER, __get_cpu_var(mce_banks_owned), &bs);
 
     if (bs.errcnt && mctc != NULL) {
-        if (guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        struct domain *handler;
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -705,10 +709,12 @@
         MCA_CMCI_HANDLER, __get_cpu_var(mce_banks_owned), &bs);
 
     if (bs.errcnt && mctc != NULL) {
-        if (guest_enabled_event(dom0->vcpu[0], VIRQ_MCA)) {
+        struct domain *handler;
+        handler = get_global_virq_handler(VIRQ_MCA);
+        if (handler && guest_enabled_event(handler->vcpu[0], VIRQ_MCA)) {
             mctelem_commit(mctc);
             printk(KERN_DEBUG "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_guest_global_virq(handler, VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff -r d5ddc782bc49 xen/include/public/io/xs_wire.h
--- a/xen/include/public/io/xs_wire.h   Mon Mar 30 16:48:26 2009 +0100
+++ b/xen/include/public/io/xs_wire.h   Fri Apr 03 13:52:44 2009 -0700
@@ -25,6 +25,9 @@
 
 #ifndef _XS_WIRE_H
 #define _XS_WIRE_H
+
+#include <errno.h>
+#include <stdint.h>
 
 enum xsd_sockmsg_type
 {
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>