New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Upgrade to new (separate) kernel and libm, and drop dietlibc #93

Merged
merged 10 commits into from Jul 8, 2014

Conversation

Projects
None yet
4 participants
@talex5
Contributor

talex5 commented Jul 2, 2014

This patch removes dietlibc, libm and most of the includes, replacing them with external dependencies on Mini-OS and openlibm. I separated out the deletions into their own commits so they don't drown out the other changes.

These changes do not themselves add support for ARM, but they do make it very easy to add, since the new Mini-OS and openlibm both support ARM, unlike the old code.

There is no replacement libc. It turned out that the only thing we needed was support for formatting floating point values. I took the code for that from musl (the FreeBSD code was large and difficult to separate out).

To test:

  1. Download and install libminios from https://github.com/talex5/xen/releases/tag/minios-v0.1
  2. Download and install openlibm from https://github.com/talex5/openlibm/releases/tag/v0.3.1-tal1
  3. Use with mirage from https://github.com/talex5/mirage/commits/master

The openlibm release is from upstream master (while we're waiting for an official release). The ARM support on the minios branch is currently under review, while the changes to make it a library have not been reviewed at all.

talex5 added some commits May 19, 2014

Switched to openlibm
Added missing complex.h include file from FreeBSD.
Updated to new Mini-OS
We now get it via ocamlfind rather than bundling a copy.

We no longer use dietlibc (we want to avoid GPL dependencies), but it
will be removed in a later commit to make this diff more readable.

Moved libxencaml stubs into their own directory (previously, they were
included with the Mini-OS code).

Sleeping works differently on ARM, but luckily Mini-OS provides a
block_domain function for us.

Notes:

- select_next's doc comment says it returns "the earliest time when one
  sleeping thread will wake up", yet the implementation appeared to be
  returning an interval. I changed the implementation to match the spec,
  as that seemed saner. This does mean that the time_fun argument is now
  unused.

- stub_hypervisor_suspend is currently disabled. This code should
  probably be moved to Mini-OS.
Added minimal POSIX API
Just enough to let us compile and run the OCaml runtime. Writing to
stdout or stderr outputs the string with printk, which is useful
for debugging.
Removed dietlibc
No longer needed.
@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 4, 2014

Member

Mirage-platform now builds almost instantly :-) Mirage lives up to its name and disappears when you get close!

Member

avsm commented Jul 4, 2014

Mirage-platform now builds almost instantly :-) Mirage lives up to its name and disappears when you get close!

avsm added a commit to mirage/mirage-xen-minios that referenced this pull request Jul 4, 2014

@avsm avsm referenced this pull request Jul 6, 2014

Merged

Updates to the external MiniOS #94

avsm and others added some commits Jul 6, 2014

set PKG_CONFIG_PATH to the local opam prefix (to find libminios)
and also remove detection of OCaml 4.00.1 from the config script
Remove support for the 4.00.1 runtime, and only support 4.01.0
There are a growing number of 4.01.0-only libraries, and packaging
on most distributions has improved now such that it's reasonable
to require 4.01.0 only.  We also need to prepare for 4.02.0 soon,
and there's no way we can support three concurrent versions of the
compiler.
@talex5

This comment has been minimized.

Show comment
Hide comment
@talex5

talex5 Jul 7, 2014

Contributor

I've now added ARM support to this branch too:

  • xen/runtime/ocaml/libocaml.cclib is now generated by configure.os.
  • I removed the other two cclib files as they didn't seem to be used.
  • The changes to arm.S are just so it doesn't require thumb mode.
Contributor

talex5 commented Jul 7, 2014

I've now added ARM support to this branch too:

  • xen/runtime/ocaml/libocaml.cclib is now generated by configure.os.
  • I removed the other two cclib files as they didn't seem to be used.
  • The changes to arm.S are just so it doesn't require thumb mode.
@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

this was for building a bytecode version of the runtime (so that ocamlclean could generate tiny kernels, since we dont do intra-module dead code elimination in native code yet). Removing it is fine for now as it needs to be resurrected with a more integrated build process anyway.

this was for building a bytecode version of the runtime (so that ocamlclean could generate tiny kernels, since we dont do intra-module dead code elimination in native code yet). Removing it is fine for now as it needs to be resurrected with a more integrated build process anyway.

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

Thanks for merging the ARM support in. It all compiles for me now on a Cubieboard2, but I get this when running the console:

Console is on port 2^M
Console ring is at mfn 10400015^M
Found GIC: gicd_base = ac401000, gicc_base = ac402000^M
Mirage: start_kernel^M
MM: Init^M
    _text: 00408000(VA)^M
    _etext: 004946a8(VA)^M
    _erodata: 004af000(VA)^M
    _edata: 004f0d20(VA)^M
    stack start: 004b5000(VA)^M
    _end: 004fe1fc(VA)^M
Found memory at 80000000 (len 0x10000000)^M
Using pages 524543 to 589824 as free space for heap.^M
MM: Initialise page allocator for 4ff000(800ff000)-103ff000(8ffff000)^M
MM: done^M
Initialising timer interface^M
Virtual Count register is 8b31dd, freq = 24000000 Hz^M
Initialising console ... done.^M
FDT suggests grant table base b0000000^M
gnttab_table mapped at 30400000.^M
xencaml: app_main_thread^M
getenv(OCAMLRUNPARAM) -> null^M
getenv(CAMLRUNPARAM) -> null^M
Fault handler at 408174 called (undefined_instruction)^M
r0 = 4de814^M
r1 = 7fffffff^M
r2 = 0^M
r3 = 7ff00000^M
r4 = 44c2af^M
r5 = 4faf90^M
r6 = 4f99c8^M
r7 = 47d608^M
r8 = 4b8f40^M
r9 = 7fc00000^M
r10 = 10100ff8^M
r11 = 10001000^M
r12 = 80000001^M
r13 = 4b8f30^M
r14 = 46fb90^M
r15 = 47d610^M
CPSR = 1d3^M
Stack dump (innermost last)^M
Stack dump (innermost last)^M
  [  4b8ffc]   408160^M
  [  4b8ff8] 10001000^M
  [  4b8ff4]   4b9000^M
  [  4b8ff0]   4b8ff0^M
  [  4b8fec]   494af8^M
  [  4b8fe8]       10^M
  [  4b8fe4]   408174^M
  [  4b8fe0]   4b8f30^M
  [  4b8fdc]   4ba004^M
  [  4b8fd8]     7ff0^M
  [  4b

Is the undefined instructions related to thumb mode? ARM debugging hints welcome...

Member

avsm commented Jul 7, 2014

Thanks for merging the ARM support in. It all compiles for me now on a Cubieboard2, but I get this when running the console:

Console is on port 2^M
Console ring is at mfn 10400015^M
Found GIC: gicd_base = ac401000, gicc_base = ac402000^M
Mirage: start_kernel^M
MM: Init^M
    _text: 00408000(VA)^M
    _etext: 004946a8(VA)^M
    _erodata: 004af000(VA)^M
    _edata: 004f0d20(VA)^M
    stack start: 004b5000(VA)^M
    _end: 004fe1fc(VA)^M
Found memory at 80000000 (len 0x10000000)^M
Using pages 524543 to 589824 as free space for heap.^M
MM: Initialise page allocator for 4ff000(800ff000)-103ff000(8ffff000)^M
MM: done^M
Initialising timer interface^M
Virtual Count register is 8b31dd, freq = 24000000 Hz^M
Initialising console ... done.^M
FDT suggests grant table base b0000000^M
gnttab_table mapped at 30400000.^M
xencaml: app_main_thread^M
getenv(OCAMLRUNPARAM) -> null^M
getenv(CAMLRUNPARAM) -> null^M
Fault handler at 408174 called (undefined_instruction)^M
r0 = 4de814^M
r1 = 7fffffff^M
r2 = 0^M
r3 = 7ff00000^M
r4 = 44c2af^M
r5 = 4faf90^M
r6 = 4f99c8^M
r7 = 47d608^M
r8 = 4b8f40^M
r9 = 7fc00000^M
r10 = 10100ff8^M
r11 = 10001000^M
r12 = 80000001^M
r13 = 4b8f30^M
r14 = 46fb90^M
r15 = 47d610^M
CPSR = 1d3^M
Stack dump (innermost last)^M
Stack dump (innermost last)^M
  [  4b8ffc]   408160^M
  [  4b8ff8] 10001000^M
  [  4b8ff4]   4b9000^M
  [  4b8ff0]   4b8ff0^M
  [  4b8fec]   494af8^M
  [  4b8fe8]       10^M
  [  4b8fe4]   408174^M
  [  4b8fe0]   4b8f30^M
  [  4b8fdc]   4ba004^M
  [  4b8fd8]     7ff0^M
  [  4b

Is the undefined instructions related to thumb mode? ARM debugging hints welcome...

@talex5

This comment has been minimized.

Show comment
Hide comment
@talex5

talex5 Jul 7, 2014

Contributor

I'd run objdump -d on the .elf image, then search for the address in r15 (the program counter).

If that doesn't help, try r14 (the return address), then addresses on the stack. Or send me the elf file and I'll try it here.

(note: if you're doing networking, it's probably the 1st complement stuff though)

Contributor

talex5 commented Jul 7, 2014

I'd run objdump -d on the .elf image, then search for the address in r15 (the program counter).

If that doesn't help, try r14 (the return address), then addresses on the stack. Or send me the elf file and I'll try it here.

(note: if you're doing networking, it's probably the 1st complement stuff though)

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

Tis just the console, so it's some other bug. Searching for instruction now...

Member

avsm commented Jul 7, 2014

Tis just the console, so it's some other bug. Searching for instruction now...

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

Looks like a floating point problem;

0047d608 <caml_int64_float_of_bits>:
  47d608:       e990000c        ldmib   r0, {r2, r3}
  47d60c:       ec432b10        vmov    d0, r2, r3
  47d610:       eaffe060        b       475798 <caml_copy_double>
Member

avsm commented Jul 7, 2014

Looks like a floating point problem;

0047d608 <caml_int64_float_of_bits>:
  47d608:       e990000c        ldmib   r0, {r2, r3}
  47d60c:       ec432b10        vmov    d0, r2, r3
  47d610:       eaffe060        b       475798 <caml_copy_double>
@talex5

This comment has been minimized.

Show comment
Hide comment
@talex5

talex5 Jul 7, 2014

Contributor

Maybe compiled with a hard-float version of ocamlopt?

Contributor

talex5 commented Jul 7, 2014

Maybe compiled with a hard-float version of ocamlopt?

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

aaaaargh, I knew I was missing a step :-)

Member

avsm commented Jul 7, 2014

aaaaargh, I knew I was missing a step :-)

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

Could you remind what the latest procedure is to get a soft-float compiler -- was there an OPAM switch or is it still a full debootstrap required?

Member

avsm commented Jul 7, 2014

Could you remind what the latest procedure is to get a soft-float compiler -- was there an OPAM switch or is it still a full debootstrap required?

@talex5

This comment has been minimized.

Show comment
Hide comment
@talex5

talex5 Jul 7, 2014

Contributor

I'm using a full debootstrap, but it looked like fixing the compiler wouldn't be too hard. Haven't tried it yet, though, and I'll probably work on getting hard-float working before that.

Contributor

talex5 commented Jul 7, 2014

I'm using a full debootstrap, but it looked like fixing the compiler wouldn't be too hard. Haven't tried it yet, though, and I'll probably work on getting hard-float working before that.

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

I've kicked off a debootstrap -- I agree with the priority of fixing hard-float ahead of worrying about the soft-float fix in the compiler.

Member

avsm commented Jul 7, 2014

I've kicked off a debootstrap -- I agree with the priority of fixing hard-float ahead of worrying about the soft-float fix in the compiler.

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

And console boots just fine! One difference between x86 and ARM that I note is that all the MiniOS messages go to the emergency console on ARM. Is this intended? (I don't think it's particularly a problem in the short-term, but the PV console code should be arch independent I thought)

Member

avsm commented Jul 7, 2014

And console boots just fine! One difference between x86 and ARM that I note is that all the MiniOS messages go to the emergency console on ARM. Is this intended? (I don't think it's particularly a problem in the short-term, but the PV console code should be arch independent I thought)

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 7, 2014

Member

Ok, ready to merge this. Will do so tomorrow unless you have any other blockers @talex5

Member

avsm commented Jul 7, 2014

Ok, ready to merge this. Will do so tomorrow unless you have any other blockers @talex5

@talex5

This comment has been minimized.

Show comment
Hide comment
@talex5

talex5 Jul 8, 2014

Contributor

No blockers from me. Once this is in, everything else should just be incremental changes. As far as I know, the only regression is suspend support on x86 (in mirage-platform), which I guess can be fixed fairly easily afterwards by someone who understands x86 code (and in particular, what arch_rebuild_p2m does).

Contributor

talex5 commented Jul 8, 2014

No blockers from me. Once this is in, everything else should just be incremental changes. As far as I know, the only regression is suspend support on x86 (in mirage-platform), which I guess can be fixed fairly easily afterwards by someone who understands x86 code (and in particular, what arch_rebuild_p2m does).

avsm added a commit that referenced this pull request Jul 8, 2014

Merge pull request #93 from talex5/new-minios
[RFC] Upgrade to new (separate) kernel and libm, and drop dietlibc

@avsm avsm merged commit 01b7cf4 into mirage:master Jul 8, 2014

1 check failed

continuous-integration/travis-ci The Travis CI build failed
Details
@jonludlam

This comment has been minimized.

Show comment
Hide comment
@jonludlam

jonludlam Jul 8, 2014

Contributor

Good description of the p2m map here: http://lxr.linux.no/linux+v3.15.4/arch/x86/xen/p2m.c

Contributor

jonludlam commented Jul 8, 2014

Good description of the p2m map here: http://lxr.linux.no/linux+v3.15.4/arch/x86/xen/p2m.c

@samoht

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Jan 29, 2015

Member

This is used by float_of_string so would be nice to have in the runtime if possible (and Magnus will be happy then :p)

This is used by float_of_string so would be nice to have in the runtime if possible (and Magnus will be happy then :p)

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jan 29, 2015

Member

a separate issue would be good, please -- it's not a small function to add in

Member

avsm replied Jan 29, 2015

a separate issue would be good, please -- it's not a small function to add in

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Jan 29, 2015

Member

See #118

Member

samoht replied Jan 29, 2015

See #118

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment