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>

OSv does not support xattrs in ZFS. Fix up a build breakage reported by Glauber:

  /home/ubuntu/osv/bsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function ‘zfs_setattr’:
  /home/ubuntu/osv/bsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2152:12: error: ‘xoap’ may be used uninitialized in this function [-Werror=uninitialized]

Reported-by: Glauber Costa <glommer@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>

Fixes #114.

When building OSv image we should use set of paths from 'prod' config.

This was introduced in commit c29222c6
and then copied to module.py.

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

Currently, clicking on the "monitor" link of OSv web console, you get a
nasty crash.  Switch to 2 GB to make things work out of the box.

Fixes #63.

Cc: Tzach Livyatan <tzach@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

There's absolutely no reason to delay web startup for 20 seconds. 2
seconds is more than enough to make Crash start up quickly.

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

Probably the worst indented file in the whole tree.  Set Eclipse Ctrl-I
on it.

Also fix a unicode character in the author's name.

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

Prior to 65ccda4c (net: use a file derived class for sockets
 (socket_file)), ioctl()s for socket were directed to linux_ioctl_socket()
and thence to soo_ioctl().  However that commit short-circuited
linux_ioctl_socket() out and dipatched directly to what was previously
known as soo_ioctl() (and became socket_file::ioctl()).  The caused
interface enumeration ioctl()s to fail, for example in Cassandra.

Fix by bringing back the previous behaviour.

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

Cassandra is crashing for me in some invocations (I really don't understand how
it was running before), because it can't find setpriority and getpriority
symbols.

Since now we have priorities implemented in our scheduler, we can implement the
equivalent functions of linux' getpriority and setpriority. We will ignore all
non-thread entities for now (and possibly forever).

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

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

A list can be slow to search for an element if we have many threads. Even under
normal load, the number of threads we span may not be classified as huge, but it
is not tiny either.

Change it to a map so we can implement functions that operate on a given thread
without that much overhead - O(1) for the common case. Note that ideally we would
use an unordered_set, that doesn't require an extra key. However, that would also
mean that the key is implicit and set to be of type key_type&. Threads are not very
lightweight to create for search purposes, so we go for a id-as-key approach.

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