Skip to content
Snippets Groups Projects
  1. Apr 24, 2013
  2. Apr 23, 2013
  3. Apr 22, 2013
    • Nadav Har'El's avatar
      Fix tlb_flush() to also flush other CPUs. · f76138e0
      Nadav Har'El authored
      Previously, on mmap()/munmap()/mprotect() we only flushed the current
      processor's TLB. This was wrong, and this patch adds a test in tst-mmap.cc
      to check this case - one thread writes to memory successfully, a second
      thread on a second cpu mprotects() this memory, and the first thread then
      writes - and wrongfully succeeds because the TLB was not flushed on its CPU.
      
      Fixed the bug by having tlb_flush() send an IPI to all processors (but
      itself) telling them to flush their TLB. The call to tlb_flush() doesn't
      return until all processors flush their TLB. All of this is slow, but
      necessary for correctness...
      
      The new test in tst-mmap.cc now passes (i.e., the second write fails as
      expected).
      
      Unfortunately, this doesn't fix any of the systemic bugs we noticed earlier,
      but will surely have caused some bug in the future if we didn't fix it.
      f76138e0
    • Nadav Har'El's avatar
      Allow setting SIGSEGV handler even when not using pthreads. · b58cde5b
      Nadav Har'El authored
      The page fault handler used to abort() if the current thread wasn't a
      pthread thread - instead of calling the handler. I don't see any reason
      to do this - and it ruined my ability to catch desired write faults in
      the two-thread (and two cpu) mprotect() tests.
      b58cde5b
    • Nadav Har'El's avatar
      Allow creation of a new sched::thread pinned to a specific CPU. · 9e7ee944
      Nadav Har'El authored
      Previously, we had the option to create a pinned thread, but it always
      runs on the same CPU as the current thread, which is kind of odd. Changed
      the boolean attribute "pinned" to a cpu* attribute specifying the cpu to
      pin to.
      
      Example code to run a start a new thread pinned on cpu 1:
      new sched::thread([&]{...}, sched::thread::attr(sched::cpus[1]));
      
      I need this feature to test the cross-CPU TLB flushing feature - I need
      to be able to run two threads on two different CPUs.
      9e7ee944
    • Nadav Har'El's avatar
      Changed mmap tests from tst-hub include to a separate .so · 74ed795b
      Nadav Har'El authored
      Changed mmap tests from tst-hub include to a separate .so, making it easier to
      run separately. Also removed a bunch of redundant dependencies from build.mak.
      74ed795b
    • Nadav Har'El's avatar
      Add build framework for Java classes and JNI · 448a1d51
      Nadav Har'El authored
      Added build ("make") framework for compiling Java code we want to run in
      OSv (in/with the Java payload), as well as JNI, i.e., OSv-specific C code
      we want to run from the above Java code.
      
      The Java source files in java/src/ are now all compiled during build
      (see java/build.xml for the Ant file doing this compilation) and the
      result is one JAR, build/$mode/java/cloudius.jar (/cloudius.jar in bootfs).
      We can easily change build.xml to create more than one if we want.
      
      As an example of JNI, I used the not-working-yet balloon feature.
      java/src/com/cloudius/balloon/Balloon.java is the class
      com.cloudius.balloon.Balloon which is supposed to have one "native"
      (implemented in C) function giveup(). This function's implementation is
      in java/jni/balloon.c. We get this file to compile to balloon.so (put
      in /usr/lib/jni in the bootfs) by adding java/jni/balloon.so to the
      "jni" list in build.mak.
      
      If you don't know how write the ugly function signature as seen in
      java/jni/balloon.c, you can run "javah com.cloudius.balloon.Balloon"
      to build the empty functions needed for implementing the native functions
      defined in the above class.
      448a1d51
Loading