From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Colp Subject: Re: caml stubdom crashes Date: Fri, 03 Apr 2009 14:07:44 -0700 Message-ID: <49D67AA0.1030902@cs.ubc.ca> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070603040005020108030903" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Alex Zeffertt Cc: Samuel Thibault , xen-devel , "George S. Coker, II" List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------070603040005020108030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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" wrote: > >> George S. Coker, II wrote: >>> >>> On 4/2/09 12:22 PM, "Patrick Colp" 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 > --------------070603040005020108030903 Content-Type: text/plain; name="xen_cpu_mcheck_virq_handler_api" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xen_cpu_mcheck_virq_handler_api" 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); --------------070603040005020108030903 Content-Type: text/plain; name="xs_wire_extra_includes" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xs_wire_extra_includes" 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 +#include enum xsd_sockmsg_type { --------------070603040005020108030903 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------070603040005020108030903--