| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This is done to allow for future integration of the
upstream auto-generated "trace.h" header file.
Change-Id: I9d1bba3320d9e8acfd7359540d3ed6695773061e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
Note that this is also forces tracing support during machine
initialization. Measurements show that this doesn't have any
significant impact on emulation performance.
Change-Id: Ie32352659611531ce65ba2c95c5896e2421f509d
|
| |
|
|
|
|
|
| |
This forces -Wall during the build. Note that this patch doesn't
remove all warnings, but most of the remaining ones are from upstream anyway.
Change-Id: I8808d8495e99866e156ce5780d2e3c305eab491f
|
| | |
|
| |
|
|
| |
Change-id: Ibce845d0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change integrates many changes from the upstream QEMU sources.
Its main purpose is to enable correct ARMv6 and ARMv7 support to the
Android emulator. Due to the nature of the upstream code base, this
unfortunately also required changes to many other parts of the source.
Note that to ensure easier integrations in the future, some source files
and directories that have heavy Android-specific customization have been
renamed with an -android suffix. The original files are still there for
easier integration tracking, but *never* compiled. For example:
net.c net-android.c
qemu-char.c qemu-char-android.c
slirp/ slirp-android/
etc...
Tested on linux-x86, darwin-x86 and windows host machines.
|
| |
|
|
|
|
| |
This change adds new trace record types for entering (and exiting)
native code from Java code. There is a corresponding change in the
Dalvik interpreter to generate these trace records.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is part of a larger change to add support for tracing Java methods.
There is also a kernel change and a small change to the Dalvik interpreter
that will be checked in separately.
There used to be support for tracing Java methods but it relied on trapping
every store and checking if the store address matched a special "magic"
region (and that stopped working because we can no longer trap on loads
and stores). The new approach uses a memory-mapped page to catch stores to
just that page.
|
| | |
|
| | |
|
| | |
|
| |
|
