I was setting up an OSv with network today, following README instructions
and noticed that to run the test an invoke command is missing.

Maybe it's a syntax change from older versions.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

3c16063a forgot to make recv() as having C linkage.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

don't copy a virtio virtio_net_hdr to a local buffer in receiver().
This prevents CPU's optimizations.
Cast the mbuf's beginning to the virtio_net_hdr and use the relevant
fields where needed allowing a proper load prediction (as a result of
branch prediction).

Reviewed-by: Dor Laor <dor@cloudius-systems.com>
Reviewed-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

BacktraceFormatter expects a string, not a syminfo, as Python was kind enough
not to point out.

Reviewed-by: Tomasz Grabiec <tgrabiec@gmail.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Caching allocations can hide use-after-free bugs.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Easier to add tracepoints, etc.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Using malloc() fails with the debug allocator, and can fail for the normal
allocator as well since it does not guarantee physical memory.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Some tracepoints are called after their arguments are freed.  Reverse the
order.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

The debug allocator does not recycle virtual addresses in order to
improve detection of use-after-free bugs.  This creates a lot of intermediate
pages as address space is consumed, leading to a very rapid OOM.

Fix by reclaiming intermediate pages that point nowhere.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

unpopulate<> (used by vdepopulate()) maintains an std::stack<> of pages
to be freed, in order to defer the tlb flush (that must be done after
pages are unlinked from the page table, but before they are actually freed).

However, the debug allocator uses vdepopulate() to ensure freed memory is
made inaccessible (so detecting use-after-free bugs).  This causes endless
recursion.

Fix by using a fixed-size queue of free pages and flushing it if it fills up.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

If a char* tracepoint argument points into demand paged memory, we may
try to access it while it is unmapped, in a non-preemptible context.

Fix by handling the fault gracefully.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This patch reverts commit 831b017e,
which stopped stripping the tests in order to fix "make check", and
instead just fixes the latter.

The fix is trivial: "make check" finds the list of tests not from the
image or the manifest, but from the list of files in build/release/tests.
So all we need to do is to subtract from that list the list of *-stripped.so.

As to the question *why* to strip the tests:

In the past, several people raised the desire to include our tests on some
production images (not just the "make image=tests" one). The rationale behind
this is that if the image encounters unexpected problems on some cloud, we
can run the included tests to see if something if it can find a problem.

I'm not sure this is a compelling reason to include tests in every image,
but let's at least not rule the option to include them on some image.

The difference in size between the stripped and unstripped tests is huge:
Currently, unstripped tests total 18 MB, while the stripped are just 2.2 MB.
That's more than 8 times smaller! We can easily imagine that in the future
we'll have more tests - perhaps many, many more tests, making this difference
even more significant.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Since commit 54d6472ec67ea73e23b30b1534320fbe637, we need the Maven "shade"
plugin. This is yet another dependency we need to list in README.md...

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Stripping tests breaks "make check":

  TEST tst-af-local-stripped.so OSv v0.05-386-gdf0fd92
  run_main(): cannot execute /tests/tst-af-local-stripped.so. Powering off.
  Test tst-af-local-stripped.so FAILED
  make: *** [check] Error 1

Fix the problem by not stripping tests.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Currently files which are part of 'java' module are built as part of
the main osv build. These files need to be ready before the module is
processed because the module relies on them.

Because we didn't have explicit dependency between processing modules
and building java artifacts the build failed when parallel jobs were
used. The proper fix is to move all java stuff to modules/java so that it
would be built as part of the module build. Before that happens here's
a quick fix which adds explicit dependency to build.mk.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Commit 211bb7fb introduced masking of
system classes from the isolate point of view in order to prevent
runjava dependencies form becoming visible, which might cause
conflicts if application would like to use the same classes but of
different version. Currently the dependencies include cglib and asm
which are also used by spring framework and hibernate. Making them
visible would force the applications to use our version of these
libraries, which can be older or newer than the required one.

Unfortunately this causes extension classes from jre/lib/ext to be
unavailable to the application. They are part of the system class
loader, not bootstrap. One of the side effects is that security
providers are not found (See issue #208).

This fix chooses another approach to fix the problem. Instead of
masking dependencies we move them under io.osv.* namespace so that
they will not cause conflicts. For this task I use apache plugin for
maven which automatically renames packages in our uber runjava jar.

Fixes #208.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

With this patch we strip all .so included in our build images,
regardless if it's a debug or a release build.

Basically any object ended with .so is stripped and sent to the
image without the -strip suffix. The code will check if there isn't
already an stripped object and if timestamp matches it, so it won't
strip unecessary files.

Everything outside build/target is ignored.

Fixes #133

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

In the process of making the lzloader, I noticed that boot.S and boot16.S
uses tabs.

Changes done using regexp.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

On build.mk two image targets are created: lzloader.elf and lzloader-stripped.elf.

The lzloader-stripped.elf is not the imaged included on loader.img. For this process
we need to call the fastlz/lz tool and link it with fastlz/fastlz.o, so those dependencies
are added.

We're calling our lzloader from boot16.S, hence we need to compile all fastlz related
stuff as -m32, so we have 32 bits binary code. This design was used in order to
do as minimal changes to the OSv core as possible and since on boot.S we have
all page tables, GDT and so on, all this are also compressed and remain on the
same address as before lzloader was introduced.

With this design it's easier to revert this patch (if needed) and also
we could add a make target to build OSv without compression (with such scenario exists)
with minimal effort.

The address 0x1800000 is choosen so we still have enough memory to uncompress the kernel
and at the same times make OSv boot with less then 32Mb of memory. If some day this
is not enough to decompress the kernel, build will fail.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This script is called from build.mk to check if enough space exists for kernel
decompression. If not, break the build.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

The lzloader itself is very simple, it read all data that was
compressed using the lz command line tool and uncompress it on
the address the kernel should be running, i.e.: 0x200000.

The MAX_BUFFER is the address range from 0x200000 to 0x0x1800000.

_binary_loader_stripped_elf_lz_start is an extern symbol to the
compressed kernel image. This is created during the build process
using objcopy command line tool.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Fastlz library provides two default tools for compression and uncompression:
6pack and 6unpack. We are not using those tools since they work with chuncks
and checksums, because they assume we have a restriction on buffer size
(because the most common usage for compression tools is reading from disk
and writting it back the compressed image).

Since we're working with all the image in memory and our output buffer
is the memory itself, we can uncompress all the data at once, making it
a much simpler and faster solution.

But, to do that, we must compress the image in the same way, that's why
this simple command line was written.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Added source code of fastlz from fastlz.org.

The original library is written in C, but it was also C++ compatible,
hence in this patch I added as a C++ source code and without
preprocessor and extern "C" code.

Signed-off-by: Eduardo Piva <efpiva@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

_flags is currently being used to determine which page_ops will be assigned to
the anonymous VMA, however, the variable flags received as a parameter is the
one that must be used for that purpose.

This problem was found while searching for the root of the general protection
faults that were often happening when running our test suite.
Bisect pointed to the commit 55693e5c
The GPF was probably happening due to code that should only proceed with
completely initialized anonymous VMAs.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Reviewed-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Current code injects vnc parameters into XL domain configuration
file improperly thus broking run.py for Xen

Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Make it explicit that the use of common sense is required when applying
the rules of the style guide.  Also point out explicitly that in
multiple variable declarations, you're supposed to "violate" an earlier
rule.

Reviewed-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

C++ coding convention is to bind '*' and '&' to the type,
not to the variable.

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Zero is a regularly used value, so let's instead use a rare one to compare the
content of the symbols against. Addressing some stylistic issues as well.

Follow the new output:
$ sudo scripts/run.py -e 'tests/tst-resolve.so'
OSv v0.05-348-g8b39f8c
Target value:   0x05050505
Success:        nonexistant = 0x05050505
Success:        debug = 0x05050505
Success:        condvar_wait = 0x05050505
The time:       1392076964
success.

Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

When multiple threads concurrently use a function which has a static
variable with a constructor, gcc guarantees that only one thread will run
the constructor, and the other ones waits.  It uses __cxa_guard_acquire()/
release()/abort() for implementing this guarantee. Unfortunately these
functions, implemented in the C++ standard library, use the Linux futex
syscall which we don't implement. The futex system call is only used in
the rare case of contention - in the normal case, the __cxa_guard_*
functions uses just atomic memory operations.

This patch implements the bare minimum we need from futex to make the
__cxa_guard_* functions work: All we need is FUTEX_WAIT and FUTEX_WAKE,
with 0 timeout in FUTEX_WAIT and wake all in FUTEX_WAKE.

It's nice how the new waitqueues fit this implementation like glove to
a hand: We could use condvars too, but we anyway need to do the wake()
with the mutex locked (to get the futex's atomic test-and-wait), and in
that case we can use waitqueues without their additional internal mutex.

This patch also adds a test for this bug. Catching this bug in a real
application is very rare, but the test exposes it by defining an function-
static object with a very slow constructor (it sleeps for a second), and
calls the function from several threads concurrently.
Before this patch the test fails with:
   constructing
   syscall(): unimplemented system call 202. Aborting.

Fixes #199.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

It can reduce the duplicated code

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Signed-off-by: Zhi Yong Wu <zwu.kernel@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>