Re: caml stubdom crashes

[Alex Zeffertt <alex.zeffertt@eu.citrix.com>]

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@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