- Aug 05, 2013
-
-
Nadav Har'El authored
Christoph discovered a bug in our dynamic linker, where symbols which exist in the kernel cannot be used in a shared object, which can cause nasty bugs when trying to run existing programs. This test demonstrates this bug, and verifies its fix (in the previous commit).
-
Nadav Har'El authored
This patch fixes the bug in tst-resolve.so, where an OSV symbol (such as debug()) hides a symbol in the application (a shared object we are running). We look up symbols in load order - if tst-resolve.so needs libstdc++.so, we search for symbols in this order - first in tst-resolve.so and then libstdc++.so. This order is mostly fine. There is one problem though - that OSV itself is loaded first, so always gets searched first, which is not really what users expect: Users expect OSV to behave like the glibc library (searched last), not like the main executable (search first). So this patch keeps the first-loaded object (OSV itself) last on the search list.
-
Nadav Har'El authored
Pass -X* (and of course also -XX*) options to the JVM. The -Xmx option is the most useful example.
-
Nadav Har'El authored
The JVM options end with the first "-jar" *or* classname, not *and*. Fix the typo.
-
Pekka Enberg authored
Now that vn_stat() supports VOP_GETATTR, wire up the ZFS implementation.
-
Pekka Enberg authored
-
Glauber Costa authored
-
Christoph Hellwig authored
Without this we somehow get a non-zero value in it while running under OSv. This needs to be investigated as it would have a bad effect on user workloads.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
The off_t cast are just superflous, the int cast causes actual truncatation bugs.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
This currently causes an abort with out implementation, which looks ugly. Just let the return 0 from main do its work.
-
Christoph Hellwig authored
We don't support writing through shared mmaps yet.
-
Christoph Hellwig authored
Add fsx from xfstests to our test cases. Currently fails on the first OP due to our lacking truncate implemenation.
-
- Aug 04, 2013
-
-
Avi Kivity authored
gcc generates some functions in their own section. Have a wildcard that catches all of these sections so they can all be merged into the global .text section; this makes 'perf kvm top' format its output better. The catch-all wildcard is placed last since ld uses the first match.
-
Avi Kivity authored
Not all machines have Enhanced REP MOVSB/STOSB (ERMS); provide optimized fallbacks.
-
Avi Kivity authored
Cache uma initialized objects to avoid re-initializing them on each allocation.
-
Nadav Har'El authored
Convert poll.c to poll.cc, and add a few tracepoints.
-
Nadav Har'El authored
Before this patch, we ran init.js for every new shell. But init.js runs things that only need to be done once - like setting the IP address or runnig a DHCP or Telnet server - and we don't need to do this again when somebody telnets in. So this patch adds an "init" flag, which tells the shell if it should read init.js. This flag is true for the CLI's main(), but when run from TelnetCLI, the flag is false.
-
Nadav Har'El authored
Our CLI changes the console's tty mode to raw when doing its line editing, and back to the original (cooked) mode when running a command. Obviously, when we're running on a telnet connection we shouldn't touch the console's mode like the existing code did. OSV doesn't (at least for now) have ptys, so we can't handle the telnet connection exactly like we handled the console, and the kernel can't implement a "cooked" line discipline for us like it implemented on the console. But we can do a very similar thing in Java instead: This patch adds a new Java class, "TTY", which has an input and output stream and an "stty" interface. We have one implementation for the console (using System.in, System.out and the console's Stty), and a different implementation, TelnetTTY, for a telnet connection. This patch does not currently implement a line discipline ("cooked mode") for this TelnetTTY, so it will always stay in raw mode. This is fine for all our current uses of the CLI, but if in the future we have commands that read user input and expect cooked mode (echo, line editing), we'll need to implement this line discipline.
-
- Aug 01, 2013
-
-
Glauber Costa authored
There is no harm in leaving it mappend, and there is a potential harm in unmapping, since our mapping code does not keep reference counters. So if we map an already mapped area, the unmap code will just unmap it for good. Avi spotted this.
-
Glauber Costa authored
We are currently using PCI's brute force enumeration, which consists of scanning all possible combination of b,d,f. This makes us issue many inb operations, a lot more than we could do if we were using smarter enumeration. In my system, the inbs alone account for more than 5M cycles, which takes around 4s to run (remember this is xen, it is faster in KVM) We can do a lot better by using recursive discovery, and only scanning the buses we need to. In the case of virtual systems the difference is even bigger, since it is very unlikely that we will have any complex setup with more than one bridge. Boot for me feels instantaneous now (once we get to start OSV)
-
- Jul 31, 2013
-
-
Avi Kivity authored
The init and fini functions are fairly expensive (for networking). Cache initialized objects in percpu pools to save this cost. The implementation is imperfect since if we're allocating on one cpu and freeing on another, reuse is low. This can be improved in the future, or made unnecessary with VJ rings. Increases netperf from ~14.6Gbps to ~17.8Gbps on my machine.
-
Avi Kivity authored
M_ZERO requests zeroing of the object regardless of any constructor; honor it. It works now because we bzero() all objects unconditionally, but we soon won't.
-
Avi Kivity authored
We're going to make zones more expensive to allocate, so allocate only as many as we need.
-
Avi Kivity authored
Allows integrating with our mempools.
-
Avi Kivity authored
dynamic_percpu<some_large_struct> will exhaust our percpu pools very quickly. dynamic_percpu<unique_ptr<some_large_struct>> works, but is awkward to construct (need a cpu notifier so we allocate it for newly onlined cpus). Add dynamic_percpu_indirect<some_large_struct> which will allocate an object for each cpu automatically as it is brought up. It's not completely general as we can't pass any constructor arguments, but should work for now.
-
Avi Kivity authored
M_ZERO requests zeroing of the entire mbuf, which clears the fields initialized by the init function. It only works now because we don't honor M_ZERO. Remove M_ZERO and replace with bzero() for the packet data only.
-
Avi Kivity authored
The trace object contains a list link for the hash table, which needs to be initialized by the constructor. However, trace_alloc() did not call the constructor and returned uninitialized memory. Fix by calling the constructor. For simplicity, all of the object's initialization is moved to the constructor.
-
Glauber Costa authored
I have recently ran into an early init bug due that ended up being tracked down to a changeset in which the initialization priorities of the constructors were changed. One of the changed ones was kvmclock, but the change did not update kvmclock. I propose we use constants for that. To avoid things like this in the future, wherever priorities are used, I believe they should come from the same place so that the order is utterly obvious. To handle that, I am creating the prio.hh file, and sticking all priority definitions in there.
-
Glauber Costa authored
So after all the BSD code is not buggy, it is just their semantics that is slightly different from our version of mlock (Thanks Christoph). Whether or not we will drop the lock will be controlled by the value of the PDROP flag. Our msleep queues are protected by an internal lock which is not the same lock the user passed to the msleep call. Therefore, we can just a version of wait_until that does not take a lock argument, and do the locking manually ourselves. We may then lock it back or not, depending on the presence of the PDROP flag.
-
- Jul 30, 2013
-
-
Glauber Costa authored
Only those I plan to use for now. Wrap it into __*_DECLS
-
Glauber Costa authored
This provides a simple msleep implementation that simply calls our own, and an empty MTX_INIT macro
-
Glauber Costa authored
Most of those files are quasi-empty (just with the usual .h ifdef in case we need to add things later). When relevant, we also add code to those files, sometimes including our own files, and providing extra definitions. Providing those stubs make importing BSD files a lot easier.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Avi Kivity authored
This allows gcc to infer that asserts usually do not trigger, and move all that code out-of-line.
-
Nadav Har'El authored
This patch adds a simple telnet server to OSV, implemented in Java. One can telnet to the VM's IP address (default port 23) and get a CLI shell. Multiple concurrent telnet sessions are supported (and the shells are independent, as expected). To start the telnet server, simply run the com.cloudius.cli.util.TelnetCLI class. For example, in the CLI to start a telnet server in the background use: java com.cloudius.cli.util.TelnetCLI & To start OSV with only a telnet server, try sudo scripts/run.py -c1 -nv -m2G -e "java.so -jar /java/cli.jar java com.cloudius.cli.util.TelnetCLI" (The "cli.jar" in the last example is only needed to set the IP address...) In the future we can turn the telnet server on by default - but let's add a password feature first :-) Right now, there's no password requested when someone telnets in.
-
Nadav Har'El authored
The CLI used to assume it was using System.in, System.out (which point to the console). Now make these parameters. We need this so we can run the CLI on a telnet connection, and it doesn't send output to the console or try to read from it.
-
Dor Laor authored
-