|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] caml stubdom crashes
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.cfailed 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |