Re: caml stubdom crashes

[Patrick Colp <pjcolp@cs.ubc.ca>]

[-- Attachment #1: Type: text/plain, Size: 4293 bytes --]

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@eu.citrix.com> wrote:
> 
>> George S. Coker, II wrote:
>>>
>>> On 4/2/09 12:22 PM, "Patrick Colp" <pjcolp@cs.ubc.ca> 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
> 

[-- Attachment #2: xen_cpu_mcheck_virq_handler_api --]
[-- Type: text/plain, Size: 2836 bytes --]

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);

[-- Attachment #3: xs_wire_extra_includes --]
[-- Type: text/plain, Size: 322 bytes --]

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
 {

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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