- Jun 26, 2013
-
-
Glauber Costa authored
Because we are now pre-computing wall clock, we only need preemption disabled during system time calculation.
-
Nadav Har'El authored
The tracepoints in lfmutex.cc referred to the type "mutex" outside the "lockfree" namespace. When LOCKFREE_MUTEX is disabled in osv/mutex.h, "mutex" is not an alias of "lockfree::mutex" so this does not compile. Move the tracepoints inside the namespace, so they can use "mutex" and got the right one.
-
Nadav Har'El authored
A bunch of improvements to tst-mutex. Add another mutual-exclusion test case, some asserts, and a benchmark of the "handoff" corner case.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
This is a bit different from FreeBSD (which already differs from Solaris) because our VFS generally already has an allocated vnode around.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
- Jun 25, 2013
-
-
Glauber Costa authored
Xen defines a protocol for defining whether or not PV drivers are available in an HVM guest. Upon successful negotiation, the documentation states that: "The relevant emulated devices then disappear from the relevant buses. For most guest operating systems, you want to do this before device enumeration happens." This patch basically follows this protocol and stores the result for future usage. See more at: docs/misc/hvm-emulated-unplug.markdown
-
Glauber Costa authored
-
Glauber Costa authored
This reverts commit dae99589.
-
Glauber Costa authored
-
Glauber Costa authored
Xen's information can be in a variety of MSRs. We need to test for them all and figure out in which of them lays the informations we want. Once we determine that, xen initalization code is ready to be executed. This needs to run as early as possible, because all xen drivers will make use of it one way or another. The hypercall code is heavily inspired (aka mostly copied) from Avi's xen tentative patch, with the 5-argument hypercall removed (delayed until we need it) Signed-off-by:
Glauber Costa <glommer@cloudius-systems.com>
-
Glauber Costa authored
I am pretty sure kvmclock only sets the wall time when we write to the MSR, so there is no point in keep calculating it every time we call system_time(). I am not changing it to a const function because we *may* have to call it more than once in the future, if we ever suspend, or the likes. But for now, using a pre-computed value is enough. Signed-off-by:
Glauber Costa <glommer@cloudius-systems.com>
-
Glauber Costa authored
This is not a very serious issue, but goes like this: The very simple read method we are attempting right now in the loader, will keep reading from the disk until we reach a pre-determined max size. However, the disk is usually smaller than this. If this is the case, XEN dmesg logs are filled with messages indicated that we are trying to read from invalid LBAs, to the point of making the log useless for me. So although the annoyance is minor, the patch itself is minor too. If nobody opposes, I can apply it. Signed-off-by:
Glauber Costa <glommer@cloudius-systems.com>
-
Nadav Har'El authored
The "events", not "revents", field of the poll structure needs to be set before calling poll().
-
Nadav Har'El authored
Add tst-epoll.cc for testing the epoll_*() functions. This test finds a bug, which will be fixed in a separate patch.
-
- Jun 24, 2013
-
-
Christoph Hellwig authored
-
Christoph Hellwig authored
Not wired up yet due to the problems of creating a zfs fs on the host.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Nadav Har'El authored
This patch solves issue #11, where join() hangs were seen in tst-mutex, with threads remaining in "terminating" state. The problem was that complete() assumed that _cpu->terminating_thread was nullptr, so it could overwrite it with the current thread. This is usually true - when we switch to any thread, if terminating_thread!=0 it is handled. The problem is that when we switch to a *new* thread (in sched::init(), call switch_to_first()) this code does not run, and if this thread quickly terminates, _cpu->terminating_thread gets overwritten instead of being handled. The simplest workaround, in this patch is simply to handle (i.e., call unref()) the previous _cpu->terminating_thread before overwriting it. The downside with this approach is that the termination of a thread may be delayed by the run time of the first time-slice of a new thread. But we anyway plan to eventually replace this termination mechanism (see issue #10), so I think this solution is fine.
-
Guy Zana authored
-
Guy Zana authored
Starting the CLI and using the run command by specifying it as a run.py argument didn't work due to a cast problem (run expected NativeArray). previousely this didn't work: $ sudo ./scripts/run.py -n -e "java.so -jar /java/cli.jar run tools/netserver-osv -D -4 -f -N" -c2 -m1G
-
Dor Laor authored
VIRTIO_RING_F_EVENT_IDX and VIRTIO_RING_F_INDIRECT_DESC are defined in virtio.hh
-
Dor Laor authored
-
- Jun 23, 2013
-
-
Nadav Har'El authored
No need to assign the condvar initializer, this is C++ after all and objects are initialized by default anyway.
-
Guy Zana authored
When a callout is deleted, it is properly deleted from the set of callouts, but if it was the next-in-line to run, it was also saved in a local variable while waiting for its timer to expire, and could be run despite being deleted. The Shrew test HTTP server (see bug 7) exposed this bug - every once in a while (usually very quickly) when a socket was deleted had a crash when a callout referring to the deleted socket was run. Thanks to Guy for finding and fixing this bug. Signed-off-by:
Nadav Har'El <nyh@cloudius-systems.com>
-