Addressing that FIXME, as part of my memory reclamation series. But this
is ready to go already. The goal is to retry to serve the allocation if a
huge page allocation fails, and fill the range with the 4k pages.

The simplest and most robust way I've found to do that was to propagate the
error up until we reach operate(). Being there, all we need to do is to
re-walk the range with 4k pages instead of 2Mb.

We could theoretically just bail out on huge pages and move hp_end, but,
specially when we have reclaim, it is likely that one operation will fail while
the upcoming ones may succeed.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
[ penberg: s/NULL/nullptr/ ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

main.cc was still using tab characters instead of spaces as our coding
conventions dictate. Reindent it, using Eclipse's ctrl-I.
This patch doesn't change anything else.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

This reverts commit e4aad1ba.

It causes tst-vfs.so to just hang.

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

This reverts commit bdd99c7b.

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

tst-pipe.cc read a buffer after freeing it, which could have theoretically
caused segfaults (it didn't in practice, but better fix this oversight).

Also, it forgot to return a return code, so it doesn't play nicely in
a test framework like testrunner.so. I'm surprised the C++ compiler wasn't
bothered by an int main() not returning an int.

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

The remove() function is part of the ISO C 1989 standard, and used, for
example, to implement Java's File.delete(). It's supposed to remove a
file, regardless of whether unlink() or rmdir() is needed to remove it.

Our implementation (from Musl's) assumed that unlink() on a directory fails
with EISDIR, and only on that case it tried rmdir(). However, returning
EISDIR on unlink() is a Linux extension, which (deliberately) goes against
the Posix standard - which specified EPERM should be returned in that case.
Our ZFS implementation of unlink, following Solaris and FreeBSD (and not
Linux), returns EPERM in that case.

This meant that remove() used to fail deleting empty directories, and
Java code (like the SpecJVM2008 "derby" benchmark) using it to recursively
delete a directory, left behind undeleted empty directories.

So this patch fixes remove() to try rmdir() if unlink() returned either
the Linux-specific EISDIR, or the Posix-standard EPERM. It also adds
to the readdir test another test which verifies that remove() can delete
all files in a directory - both regular files and empty directories.

Fixes #112.

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

Before this patch, tst-readdir.cc assert()ed on every test, meaning that
a failure will cause a crash. Change this to use a report() function,
which counts failures instead of immediately crashing on the first one.

This patch doesn't change anything in what this test actually tests for.

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

gcc recommends -Og for debugging; follow its advice.

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

When the _avail_count is less than 1/3 of the ring, we start using
indirect descriptor.

Signed-off-by: Asias He <asias@cloudius-systems.com>
Signed-off-by: Dor Laor <dor@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

There is no reason we should do the scale.

Signed-off-by: Asias He <asias@cloudius-systems.com>
Signed-off-by: Dor Laor <dor@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

That test goes together with thread detach, but I am also calling joins
to make sure we're not breaking them. It is unfortunate that this is quite
non-deterministic and we can't really surely test for failure. But on the
flip side, it did help me catch a couple of bugs in my implementation. So
it will eventually explode somewhere if a bug appears.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

I needed to call detach in a test code of mine, and this is isn't implemented.
The code I wrote to use it may or may not stay in the end, but nevertheless,
let's implement it.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

set_cleanup is quite a complicated piece of code. It is very easy to get it to
race with other thread destruction sites, which was made abundantly clear when
we tried to implement pthread detach.

This patch tries to make it easier, by restricting how and when set_cleanup can
be called. The trick here is that currently, a thread may or may not have a
cleanup function, and through a call to set_cleanup, our decision to cleanup
may change.

From this point on, set_cleanup will only tell us *how* to cleanup. If and
when, is a decision that we will make ourselves. For instance, if a thread
is block-local, the destructor will be called by the end of the block. In
that case, the _cleanup function will be there anyhow: we'll just not call
it.

We're setting here a default cleanup function for all created threads, that
just deletes the current thread object. Anything coming from pthread will try
to override it by also deleting the pthread object. And again, it is important
to node that they will set up those cleanup function unconditionally.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Linux uses a 32-bit integer for pid_t, so let's do it as well. This is because
there are function in which we have to return our id back to the application.
One application is gettid, that we already have in the tree.

Theoretically, we could come up with a mapping between our 64-bit id and the
Linux one, but since we have to maintain the mapping anyway, we might as well
just use the Linux pids as our default IDs. The max size for that is 32-bit. It
is not enough if we're just allocating pids by bumping the counter, but again,
since we will have to maintain the bitmaps, 32-bit will allow us as much as 4
billion PIDs.

avi: remove unneeded #include

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Xen's shared info contains hardcoded space for only 32 CPUs.  Because we use
those structure to derive timing information, we would be basically accessing
random memory after that. This is very hard to test and trigger, so what I'd
did to demonstrate I was right (although that wasn't really needed, math could
be used for that...) was to print the first timing information a cpu would
produce. I could verify that the timing on CPUs > 32 was behind in time than
the time produced in CPUs < 32.

It is possible to move the vcpu area to a different location, but this is a
relatively new feature of the Xen Hypervisor: Amazon won't support it. So
we need a disable path anyway. I will open up an issue for somebody to implement
that support eventually.

Another user of the vcpu structure is interrupts. But for interrupts the story
is easier, since we can select which CPUs we can take interrupts at, and only
take them in the first 32 CPUs. In any case, we're taking them all in CPU0 now,
so already under control

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

Right now we are taking a clock measure very early for cpu initialization.
That forces an unnecessary dependency between sched and clock initializations.

Since that lock is used to determine for how long the cpu has been running, we
can initialize the runtime later, when we init the idle thread. Nothing should
be running before it. After doing this, we can move the sched initialization
a bit earlier.

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

It seems that we also had problems with our own code for int vs long
issues. I am really surprised that the C++ compiler didn't throw any
warnings for this since all word sizes are quite explicit. In any case,
this seems to be the missing piece for xen booting with many CPUs.

It boots fine now with up to 32 CPUs. After that, other problems start
to appear.

Fixes #113

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

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Currently, namei() does vget() unconditionally if no dentry is found.
This is wrong because the path can be a hard link that points to a vnode
that's already in memory.

To fix the problem:

  - Use inode number as part of the hash in vget()

  - Use vn_lookup() in vget() to make sure we have one vnode in memory
    per inode number.

  - Push the vget() calls down to individual filesystems and make
    VOP_LOOKUP return an vnode

  - Drop lock in vn_lookup() and assert that vnode_lock is held.

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

My thread patch broke info threads. My bad: Nadav noticed in his review
that it would, but I ended up forgetting about when I reworked it. In
any case, with the following fix it works again.

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

1. Use multithreaded build when possible
2. Suppress output on bucket removal

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

1. It turned out that Amazon changes standard AMIs from time to time,
   AMI ID changes as well in this case. As a result Windows AMI we
   used as a template for OSv releases became anavailable.
   The script will use earlier OSv release AMI instead to avoid
   this class of problems.

2. Invalid strings compare syntax fixed.

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

This patch fixes:

- The order of _used_ring_host_head and _used->_idx, the latter is more
  advanced than the former.
- The unwanted promotion to "int"

Pekka wrote:

   However, on the right-hand side, the expression type in master
   evaluates to "int" because of that innocent-looking constant "2" and
   lack of parenthesis after the cast.  That will also force the
   left-hand side to promote to "int".

   And no, I really don't claim to follow integer promotion rules so I
   used typeid().name() verify what the compiler is doing:

   [penberg@localhost tmp]$ cat types.cpp
   #include <typeinfo>
   #include <stdint.h>
   #include <cstdio>

   using namespace std;

   int main()
   {
       unsigned int _num = 1;

       printf("int                = %s\n", typeid(int).name());
       printf("uint16_t           = %s\n", typeid(uint16_t).name());
       printf("(uint16_t)_num/2)  = %s\n", typeid((uint16_t)_num/2).name());
       printf("(uint16_t)(_num/2) = %s\n", typeid((uint16_t)(_num/2)).name());
   }
   [penberg@localhost tmp]$ g++ -std=c++11 -Wall types.cpp
   [penberg@localhost tmp]$ ./a.out
   int                = i
   uint16_t           = t
   (uint16_t)_num/2)  = i
   (uint16_t)(_num/2) = t

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

Now, the tx gc thread is gonna. The gc code can only be called in one
place. We do not need the lock anymore.

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

This unifies the code a bit: we do all the tx queue gc in one common
code path.

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

We do tx queue gc on the tx path if there is not enough space. The tx
queue gc thread is not a must.

Dropping it saves us a running thread and saves a thread wakeup on every
interrupt.

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

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

This is used by QEMU to determine if the guest will be using explicit
flush requests. If this is not enabled, it will flush using
fdatasync() after every write request.

This is causing dramatic performance degradation when using spinning
disk. This

The test "tests/tst-bdev-write.so" exposes the issue:

=== Before ===

0.469 Mb/s
0.312 Mb/s
0.323 Mb/s
0.354 Mb/s
0.163 Mb/s
0.100 Mb/s
0.388 Mb/s
0.293 Mb/s
0.401 Mb/s
Written 3.117 MB in 10.02 s

=== After ===

49.151 Mb/s
53.126 Mb/s
32.079 Mb/s
49.082 Mb/s
29.575 Mb/s
42.553 Mb/s
35.909 Mb/s
37.592 Mb/s
67.425 Mb/s
Written 440.562 MB in 10.00 s

Using "tests/tst-fs-stress.so":

=== Before ===

2.414 Mb/s
3.633 Mb/s
0.630 Mb/s
0.279 Mb/s
2.497 Mb/s
Written 15.379 MB in 10.51 s

Latency of write() [s]:
0     0.000000090
0.5   0.000004532
0.9   0.000005969
0.99  0.000022659
0.999 0.001138458
1.0   4.020670891

=== After ===

11.893 Mb/s
20.292 Mb/s
13.801 Mb/s
16.102 Mb/s
24.811 Mb/s
18.113 Mb/s
21.336 Mb/s
18.976 Mb/s
Written 182.254 MB in 10.00 s

Latency of write() [s]:
0     0.000000089
0.5   0.000004497
0.9   0.000005878
0.99  0.000018114
0.999 0.000111873
1.0   0.681828260

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>

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

KVM always have a network interface provided by QEMU, Xen not necessarily so. I
fixed this before, but it was probably broken by the multiple interfaces work.
The interface list is not a C++ structure, so the easiest way to handle that is
to keep track of whether or not we have any non-loopback interface. (No need to
know how many). If we don't, skip DHCP startup.

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

Since we are using ZFS now, we don't need workarounds
for tmpfs bugs.

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

Revive testrunner.so (run with run.py -e testrunner.so), which runs all tests
in the tests/ directory in the image.

Changed it to C++, and for simplicity use the osv::run() API.

The next steps on the TODO list should be:
1. Change the manifest so that non-tests are NOT copied to the tests/ on the
   image.
2. Add an option to run tests in parallel, for maximum testing speed. Will not
   be trivial (will need to redirect the tests' output so they don't mix, and
   also figure out the load so we can run as many tests in parallel as we need
   to fill up the CPUs).

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

The exact location of the stack end is not needed by java so move back this
variable to restore the state to what was done before the mkfs.so/cpiod.so split.

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Add file needed for "make image=specjvm" using osv-apps.git.
It builds an image containing both the management tools and specjvm.
The default command line is the management - you can run specjvm
explicitly, e.g.,
 run.py -m3G -c2 -e "java.so -jar specjvm.jar -ikv -bt 2 -it 10 -wt 10 derby"

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

Unfortunately, in addition to the changes in osv-apps.git needed for the
"rogue" image, I also need to make a couple of changes in this repository.

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

pthread_condattr_init() is needed for JDK8 to run. Add stub for now.

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

Some objects have DPTMOD64 relocations with the null symbol, presumably to
set the value to 0 (it is too much trouble to write zero into the file during
the link phase, apparently).  Detect this condition and write the zero.

Needed by JDK8.

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

Fixes the following error during SSH daemon startup which started
appearing after commit c0daa41a ("external: update openjdk to
1.7.0.60-2.4.3.0.fc19"):

2013-12-05 13:59:11,596 ERROR org.crsh.ssh.term.SSHLifeCycle:177 - Could not start CRaSSHD
java.lang.RuntimeException: Failed to register BouncyCastle as the defaut JCE provider
	at org.apache.sshd.common.util.SecurityUtils.register(SecurityUtils.java:83) ~[crash-1.0.0.jar:na]
	at org.apache.sshd.common.util.SecurityUtils.isBouncyCastleRegistered(SecurityUtils.java:68) ~[crash-1.0.0.jar:na]
	at org.apache.sshd.SshServer.setUpDefaultServer(SshServer.java:430) ~[crash-1.0.0.jar:na]
	at org.crsh.ssh.term.SSHLifeCycle.doInit(SSHLifeCycle.java:112) ~[crash-1.0.0.jar:na]
	at org.crsh.term.TermLifeCycle.init(TermLifeCycle.java:42) [crash-1.0.0.jar:na]
	at org.crsh.ssh.SSHPlugin.init(SSHPlugin.java:134) [crash-1.0.0.jar:na]
	at org.crsh.plugin.PluginManager.getPlugins(PluginManager.java:83) [crash-1.0.0.jar:na]
	at org.crsh.plugin.PluginContext.start(PluginContext.java:340) [crash-1.0.0.jar:na]
	at org.crsh.plugin.PluginLifeCycle.start(PluginLifeCycle.java:96) [crash-1.0.0.jar:na]
	at org.crsh.standalone.Bootstrap.bootstrap(Bootstrap.java:205) [crash-1.0.0.jar:na]
	at org.crsh.standalone.CRaSH.main(CRaSH.java:332) [crash-1.0.0.jar:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_45]
	at org.crsh.cli.impl.lang.MethodDescriptor$1.invoke(MethodDescriptor.java:189) [crash-1.0.0.jar:na]
	at org.crsh.cli.impl.invocation.InvocationMatch.invoke(InvocationMatch.java:106) [crash-1.0.0.jar:na]
	at org.crsh.cli.impl.invocation.InvocationMatch.invoke(InvocationMatch.java:100) [crash-1.0.0.jar:na]
	at org.crsh.cli.impl.bootstrap.Main.handle(Main.java:62) [crash-1.0.0.jar:na]
	at org.crsh.cli.impl.bootstrap.Main.main(Main.java:52) [crash-1.0.0.jar:na]
	at com.cloudius.cli.Main.main(Main.java:6) [crash-1.0.0.jar:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_45]
	at io.osv.RunJava.runMain(RunJava.java:153) [runjava.jar:na]
	at io.osv.RunJava$1.run(RunJava.java:124) [runjava.jar:na]
	at io.osv.OsvSystemClassLoader$1.run(OsvSystemClassLoader.java:70) [runjava.jar:na]
Caused by: java.lang.ExceptionInInitializerError: null
	at javax.crypto.KeyAgreement.getInstance(KeyAgreement.java:223) ~[na:1.7.0_45]
	at org.apache.sshd.common.util.SecurityUtils$BouncyCastleRegistration.run(SecurityUtils.java:97) ~[crash-1.0.0.jar:na]
	at org.apache.sshd.common.util.SecurityUtils.register(SecurityUtils.java:77) ~[crash-1.0.0.jar:na]
	... 27 common frames omitted
Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
	at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86) ~[na:1.7.0_45]
	... 30 common frames omitted
Caused by: java.lang.SecurityException: Cannot locate policy or framework files!
	at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:254) ~[na:1.7.0_45]
	at javax.crypto.JceSecurity.access$000(JceSecurity.java:48) ~[na:1.7.0_45]
	at javax.crypto.JceSecurity$1.run(JceSecurity.java:78) ~[na:1.7.0_45]
	at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_45]
	at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:76) ~[na:1.7.0_45]
	... 30 common frames omitted

Needed for SSH daemon to start up after the openjdk upgrade.

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

Switch to latest apps.git that fixes Cassandra JNA woes.

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