| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following changes are crucial for GPU H/W acceleration because
some graphics applications like games perform very frequent QEMU pipe
operations to send GLES commands to the host translator.
For each read/write buffer operation, currently QEMU pipe requires five
MMIO operations.
This causes significant overhead when running with hardware virtualization
enabled (e.g. HAXM) because each MMIO causes expensive transition from
the guest kernel to the kernel driver, and to the QEMU user space in the end.
Among such five MMIO accesses, four of them are required to just set up the
parameters for the access, like the buffer address, length etc. By passing
a buffer containing such parameters, we need only one MMIO operation to
send a GLES command to the host translator.
Update the qemu_pipe save version for pipe struct changes.
Change-Id: Idf6400f3c4c9c8473311312bb1d8f3ea92d68797
Signed-off-by: Xin, Xiaohui <xiaohui.xin@intel.com>
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Nakajima, Jun <jun.nakajima@intel.com>
|
|
|
|
|
|
|
|
|
| |
The emulator crashes when loading a goldfish pipe from snapshot if it
was still in PipeConnection state when saved, since there is no
service associated with the pipe. Check for service existence before
dereferencing the service pointer.
Change-Id: I9093bdf403fd3532e9fb6584b98994d9d4dc686c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add snapshot load/save support to QEMU Pipes
This adds the ability to save and load QEMU Pipe connections
with snapshots. Note that by default, all loaded pipe client
connections are force-fully closed on load.
We don't have a good way to save the state of network
connections to persistent storage.
Properly implements snapshot save / load for qemu pipe clients.
Change-Id: Ie5767f8ce40c8341b958cc5844e724dd4fc1ed2b
|
|
|
|
| |
Change-Id: I62a2d54562ac043a5513585a2e86aa01038fdc29
|
|
|
|
|
|
|
|
|
| |
The issue was that CPU registers (CR3 in particular) in QEMU were out of sync with KVM
at the time when virtual address to physical address translation was performed. This
caused translation failure, and the subsequent crash. The fix was to explicitly sync
QEMU registers with KVM registers just before calling VA->PA translation.
Change-Id: I1ff4ed2cfddd77e6889bb645f08db442f119049a
|
|
|
|
|
|
|
|
|
| |
Throughout emulator's code pipe's 'poll' callback was returning PIPE_WAKE_XXX,
instead of PIPE_POLL_XXX flags. This created whole sort of issues with the
qemu pipe service <-> client communications.
This is also a fix for http://b/issue?id=5196348
Change-Id: I92202cf4ef4554559eb022c4410ee93923edec1b
|
|
|
|
| |
Change-Id: I7130b7f82dec493fb893acf2527755398104cde3
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of qemu_timer_new() implementation, and update all
callers to use qemu_timer_new_ms() or qemu_timer_new_ns()
instead.
Rename qemu_new_timer_scale() to qemu_new_timer() to follow
upstream conventions.
Change-Id: Id2c04f8597ec5026e02f87b3e2c5507920eb688e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new virtual hardware device named "goldfish_pipe"
used to implement a very fast communication channel between the
guest system and the emulator.
IMPORTANT: This depends on a special kernel driver, see:
https://review.source.android.com/#change,22496
Usage from the guest is simply the following:
fd = open("/dev/qemu_pipe", O_RDWR);
const char* pipename = "pipe:<name>";
ret = write(fd, pipename, strlen(pipename)+1);
if (ret < 0) {
/* could not connect to service named <name> */
}
/* now you can read()/write()/close() as a normal
* file descriptor to exchange data with the service.
*/
In addition, this implements the following pipe services in the
emulator:
tcp:<port>
tcp:<hostname>:<port>
unix:<path>
opengles
The 'tcp:' and 'unix:' services simply redirect to a TCP or Unix
socket on the host with minimal
The 'opengles' service simply connects to tcp:locahost:22468 for now.
We may change this to be more configurable in the future, but that's
the port number used by the current experimental OpenGL ES hardware
emulation host libraries / programs.
Benchmarking with a simple ping-pong program shows that the
guest <-> emulator can achieve a roundtrip bandwidth of 192 MB/s
(on a 2.7 Ghz Xeon PC).
Using the tcp: service to talk to a ping-pong server listening
on localhost reaches 102 MB/s on the same machine, using a Unix
socket reaches 140 MB/s.
By contrast, using standard sockets in the guest reaches only
3.8 MB/s on the same machine (and requires special privileges
from the application anyway).
|
|
Change-Id: I338334d53fa9bc52c87e9da18341d0cb94fd4269
|