Add fast mmio support

In HAXM 1.0, HAXM driver utilizes QEMU to decode and emulate MMIO accesses.
This simplified the HAXM driver implementation. However, decoding in QEMU is
slow because QEMU needs to sync with the HAXM driver regarding the vCPU state,
guest page tables, etc.

Newer HAXM driver will decode some MMIO instructions, and QEMU
will get the decoded instruction information like the physical address,
access direction etc, and then invoke the MMIO handler directly.

This boosts MMIO handling performance significantly, thus performance of 2D/3D
games because they performance very frequent MMIO access for GLES commands to
the host translator.

Change-Id: Ida308b2e6da3697ee37a1b28a9645916e104d9ff
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>

2 files changed, 54 insertions, 1 deletions

diff --git a/target-i386/hax-all.c b/target-i386/hax-all.c
index 2c13250..2540f54 100644
--- a/target-i386/hax-all.c
+++ b/target-i386/hax-all.c
@@ -120,7 +120,7 @@ hax_fd hax_vcpu_get_fd(CPUState *env)
 }
 
 /* Current version */
-uint32_t hax_cur_version = 0x1;
+uint32_t hax_cur_version = 0x2;
 /* Least HAX kernel version */
 uint32_t hax_lest_version = 0x1;
 
@@ -395,6 +395,31 @@ error:
     return ret;
 }
 
+int  hax_handle_fastmmio(CPUState *env, struct hax_fastmmio *hft)
+{
+    uint64_t buf = 0;
+
+    /*
+     * With fast MMIO, QEMU need not sync vCPU state with HAXM
+     * driver because it will only invoke MMIO handler
+     * However, some MMIO operations utilize virtual address like qemu_pipe
+     * Thus we need to sync the CR0, CR3 and CR4 so that QEMU
+     * can translate the guest virtual address to guest physical
+     * address
+     */
+    env->cr[0] = hft->_cr0;
+    env->cr[2] = hft->_cr2;
+    env->cr[3] = hft->_cr3;
+    env->cr[4] = hft->_cr4;
+
+    buf = hft->value;
+    cpu_physical_memory_rw(hft->gpa, &buf, hft->size, hft->direction);
+    if (hft->direction == 0)
+        hft->value = buf;
+
+    return 0;
+}
+
 int hax_handle_io(CPUState *env, uint32_t df, uint16_t port, int direction,
   int size, int count, void *buffer)
 {
@@ -542,6 +567,10 @@ static int hax_vcpu_hax_exec(CPUState *env)
             case HAX_EXIT_MMIO:
                 ret = HAX_EMUL_ONE;
                 break;
+            case HAX_EXIT_FAST_MMIO:
+                ret = hax_handle_fastmmio(env,
+                        (struct hax_fastmmio *)vcpu->iobuf);
+                break;
             case HAX_EXIT_REAL:
                 ret = HAX_EMUL_REAL;
                 break;
diff --git a/target-i386/hax-interface.h b/target-i386/hax-interface.h
index cb6d7c8..22d4acc 100644
--- a/target-i386/hax-interface.h
+++ b/target-i386/hax-interface.h
@@ -316,6 +316,14 @@ enum exit_status {
      * Now the vcpu is only paused when to be destroid, so simply return to hax
      */
     HAX_EXIT_PAUSED,
+    /* from API 2.0 */
+    /*
+     * In API 1.0, HAXM driver utilizes QEMU to decode and emulate MMIO
+     * operations.
+     * From 2.0, HAXM driver will decode some MMIO instructions to improve
+     * MMIO handling performance, especially for GLES hardware acceleration
+     */
+    HAX_EXIT_FAST_MMIO,
 };
 
 /*
@@ -391,4 +399,20 @@ struct hax_capabilityinfo
     uint64_t mem_quota;
 };
 
+/* API 2.0 */
+
+struct hax_fastmmio
+{
+    uint64_t gpa;
+    uint64_t value;
+    uint8_t size;
+    uint8_t direction;
+    uint16_t reg_index;
+    uint32_t pad0;
+    uint64_t _cr0;
+    uint64_t _cr2;
+    uint64_t _cr3;
+    uint64_t _cr4;
+};
+
 #endif