| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Ib3891704ece2cea0c5a80b468b2514e6c4d13216
|
| |
|
|
| |
Change-Id: I49e96e2d5ae571849b0b6fef0a30b41ecdee8d23
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: I7f7f46b6e9526d207f53ad6a9e6baa315bd6af7b
|
| |
|
|
|
|
|
|
| |
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 large patch upgrades the block support code to the upstream
version available in ba5e7f82169f32ab8163c707d97c799ca09f8924
dated 2010-08-08
Change-Id: I8b24df0c287e72f6620650a4d6a62e1bb315453e
|
| |
|
|
|
|
| |
+ new document under docs/DISPLAY-STATE.TXT to explain what's happening.
Change-Id: Ia0d233377266212da49af932c7528f46f5feb92d
|
| |
|
|
|
|
|
|
|
|
|
| |
The previous patch modifies SD Card hardware emulation in a way that is
not backwards compatible with previous SDK platform releases. This has
the unfortunate effect of making SD Card emulation not work properly
when running existing AVDs.
Reverting the patch until we get a better one.
Change-Id: I82dac87709d88aa3bd292bf2ed0008ae74d95853
|
| | |
|
| |
|
|
| |
Change-id: Ibce845d0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add commandline support for an additional SD card, and plumb support to
the MMC emulation layer. This patch also reworks the way the hw emulation
layer registers devices. Previously, the mmc virtual hardware was only
created if the sdcard image existed. Now, two virtual MMC controllers are
*always* created as on real hardware. When a request is made to one
of our controllers which has no image file bound to it, a new interrupt
status indicating a command timeout is sent to the guest driver, as
is standard with MMC controllers. This patch also sets the stage for
supporting hot-add / hot-remove.
Signed-off-by: San Mehat <san@google.com>
qemu: android: Integrate card detect into the virtual mmc hardware and
wire it up to the STATE_CHANGE irq status
Signed-off-by: San Mehat <san@google.com>
fixups from review - mmc now works with legacy
drivers
Signed-off-by: San Mehat <san@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
