- Feb 06, 2014
-
-
Takuya ASADA authored
Signed-off-by:
Takuya ASADA <syuu@cloudius-systems.com> Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
- Jan 27, 2014
-
-
Nadav Har'El authored
Drop the nanotime() function. Change the few remaining callers to use the appropriate osv::clock or std::chrono replacements. We already got rid in previous patches of most references to nanotime() by switching from absolute times to relative times. The direct equivalent of the old nanotime() function, where we actually need the number of nanoseconds since the UNIX epoch, is the rather verbose expression osv::clock::wall::now().time_since_epoch().count(), or the shorter clock::get()->time(). Reviewed-by:
Glauber Costa <glommer@cloudius-systems.com> Signed-off-by:
Nadav Har'El <nyh@cloudius-systems.com> Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
Nadav Har'El authored
Drop the s64 literals _ms, _ns, etc., from <drivers/clock.hh>. Fix a few places which still use the old literals. The std:chrono::duration version from <osv/clock.hh> remains - but remember you need to "using namespace osv::clock::literals" to use them. Reviewed-by:
Glauber Costa <glommer@cloudius-systems.com> Signed-off-by:
Nadav Har'El <nyh@cloudius-systems.com> Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
- Jan 22, 2014
-
-
Pekka Enberg authored
Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
Pekka Enberg authored
Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
Pekka Enberg authored
Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
- Dec 24, 2013
-
-
Avi Kivity authored
Helps making bsd header changes that xen includes. Signed-off-by:
Avi Kivity <avi@cloudius-systems.com>
-
- Nov 06, 2013
-
-
Pekka Enberg authored
condvar_wait() expects an absolute time, not a duration. Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
- Oct 28, 2013
-
-
Pekka Enberg authored
Spotted by GCC with '-Wformat=1': ../../drivers/xenfront-xenbus.cc: In function ‘XenbusState xenbus_get_state(device_t)’: ../../drivers/xenfront-xenbus.cc:219:80: warning: format ‘%d’ expects argument of type ‘int*’, but argument 6 has type ‘XenbusState* {aka xenbus_state*}’ [-Wformat=] xs_scanf(XST_NIL, dev->get_node_path().c_str(), "state", NULL, "%d", &state); Signed-off-by:
Pekka Enberg <penberg@cloudius-systems.com>
-
- Sep 15, 2013
-
-
Nadav Har'El authored
Add Cloudius copyright and license statement to drivers/*. A couple of header files were based on Linux's BSD-licensed header files (e.g., include/uapi/linux/virtio_net.h) so they included the BSD license, but not any copyright statement, so we can just replace that by our own statement of the BSD license.
-
- Sep 12, 2013
-
-
Dmitry Fleytman authored
This patch implements GSI interrupt support for Xen bus. Needed in Xen environments w/o vector callbacks for HVM. One example of such an environment is Amazon EC2.
-
- Aug 13, 2013
-
-
Glauber Costa authored
This commit includes the basic translation layer so we can support BSD devices for Xen as is. I believe there is room for improvement, but that provides a very good starting point. I would like to provide you guys with a smaller commit, but it is quite cumbersome to separate the device implementation from the bus implementation per se. Part of it is due to the way Xen does things. For instance: when we are talking virtio devices, each of them will have its own pci device. For xen, only one pci device will be exposed, with its own interrupt, and that will be the xenbus. The xenbus is then responsible for querying the xenstore and figuring out which devices are there. Maybe there is a different way of doing things (I believe for instance that there is no reason to have shared interrupts between all devices) but that is the way BSD does things. And about the bus-is-the-device, even Linux as far as I know. Another thing to note, is that BSD devices registered with a device_method_t seem to be fully hierarchical. I am not doing it this way here (I am mostly ignoring the xenbus device_method_t definitions), which means there are a lot of assumptions that probably won't hold with other kinds of drivers. But it should not be hard to extend, and that simplifies things.
-