Add HAX support

Signed-off-by Vincent Palatin <[email protected]>

---
 hax-stub.c                  |   74 +++
 include/sysemu/hax.h        |   66 ++
 target-i386/hax-all.c       | 1490 +++++++++++++++++++++++++++++++++++++++++++

Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
[...]

Quoted 6 lines

Signed-off-by Vincent Palatin <[email protected]>

---
 hax-stub.c                  |   74 +++
 include/sysemu/hax.h        |   66 ++
 target-i386/hax-all.c       | 1490 +++++++++++++++++++++++++++++++++++++++++++

Git warns about a whitespace issue:
The empty last line of target-i386/hax-all.c should be removed.

target-i386/hax-all.c new file +6 -0

+
+static int hax_handle_fastmmio(CPUArchState *env, struct hax_fastmmio *hft)
+{
+    uint64_t buf = 0;
+    /*
+     * With fast MMIO, QEMU need not sync vCPU state with HAXM

target-i386/hax-all.c new file +30 -0

+    return 0;
+}
+
+static int hax_handle_io(CPUArchState *env, uint32_t df, uint16_t port,
+                         int direction, int size, int count, void *buffer)
+{
+    uint8_t *ptr;
+    int i;
+
+    if (!df) {
+        ptr = (uint8_t *) buffer;
+    } else {
+        ptr = buffer + size * count - size;
+    }
+    for (i = 0; i < count; i++) {
+        if (direction == HAX_EXIT_IO_IN) {
+            switch (size) {
+            case 1:
+                stb_p(ptr, cpu_inb(port));
+                break;
+            case 2:
+                stw_p(ptr, cpu_inw(port));
+                break;
+            case 4:
+                stl_p(ptr, cpu_inl(port));
+                break;
+            }
+        } else {
+            switch (size) {
+            case 1:

target-i386/hax-all.c new file +10 -0

+        if (!df) {
+            ptr += size;
+        } else {
+            ptr -= size;
+        }
+    }
+
+    return 0;
+}
+

target-i386/hax-all.c line 1345

Quoted 3 lines · Vincent Palatin

target-i386/hax-all.c new file +3 -0

+
+    memcpy(env->xmm_regs, fpu.mmx_1, sizeof(fpu.mmx_1));
+    memcpy((ZMMReg *) (env->xmm_regs) + 8, fpu.mmx_2, sizeof(fpu.mmx_2));

HAX will only support SSE (128-bit) registers, while env->xmm_regs supports AVX512 (512-bit) so you have to copy registers one by one.

Is there documentation for HAX?

In particular I'm curious as to what
the CPUID information looks like in the guest, and whether there are ioctls to change it.

In particular I would expect XSAVE to be disabled.

Quoted 12 lines

target-i386/hax-all.c new file +11 -0

+
+static int hax_handle_fastmmio(CPUArchState *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

target-i386/hax-all.c line 646

Quoted 5 lines

target-i386/hax-all.c new file +5 -0

+     */
+    env->cr[0] = hft->_cr0;
+    env->cr[2] = hft->_cr2;
+    env->cr[3] = hft->_cr3;
+    env->cr[4] = hft->_cr4;

These seem to apply only to some parts of the Android emulator that are not upstream, so you can remove them.

target-i386/hax-all.c line 654

Quoted 8 lines

target-i386/hax-all.c new file +7 -0

+    buf = hft->value;
+
+    cpu_physical_memory_rw(hft->gpa, (uint8_t *) &buf, hft->size,
+                           hft->direction);
+    if (hft->direction == 0) {
+        hft->value = buf;
+    }

No need to use "buf", you can use &hft->value directly.

Quoted 31 lines

target-i386/hax-all.c new file +30 -0

+    return 0;
+}
+
+static int hax_handle_io(CPUArchState *env, uint32_t df, uint16_t port,
+                         int direction, int size, int count, void *buffer)
+{
+    uint8_t *ptr;
+    int i;
+
+    if (!df) {
+        ptr = (uint8_t *) buffer;
+    } else {
+        ptr = buffer + size * count - size;
+    }
+    for (i = 0; i < count; i++) {
+        if (direction == HAX_EXIT_IO_IN) {
+            switch (size) {
+            case 1:
+                stb_p(ptr, cpu_inb(port));
+                break;
+            case 2:
+                stw_p(ptr, cpu_inw(port));
+                break;
+            case 4:
+                stl_p(ptr, cpu_inl(port));
+                break;
+            }
+        } else {
+            switch (size) {
+            case 1:

target-i386/hax-all.c line 695

Quoted 10 lines

target-i386/hax-all.c new file +10 -0

+                cpu_outb(port, ldub_p(ptr));
+                break;
+            case 2:
+                cpu_outw(port, lduw_p(ptr));
+                break;
+            case 4:
+                cpu_outl(port, ldl_p(ptr));
+                break;
+            }
+        }

The whole "if" can be replaced by

    MemTxAttrs = { 0 };
    ...

        address_space_rw(&address_space_io, port, attrs,
                         ptr, size, direction == HAX_EXIT_IO_OUT);

Quoted 11 lines

target-i386/hax-all.c new file +10 -0

+        if (!df) {
+            ptr += size;
+        } else {
+            ptr -= size;
+        }
+    }
+
+    return 0;
+}
+

exec.c +8 -0

+            /*
+             * In Hax, the qemu allocate the virtual address, and HAX kernel
+             * populate the memory with physical memory. Currently we have no
+             * paging, so user should make sure enough free memory in advance
+             */
+            if (hax_enabled()) {
+                int ret;
+                ret = hax_populate_ram((uint64_t)(uintptr_t)new_block->host,

Quoted 8 lines · Vincent Palatin

exec.c +8 -0

+            /*
+             * In Hax, the qemu allocate the virtual address, and HAX kernel
+             * populate the memory with physical memory. Currently we have no
+             * paging, so user should make sure enough free memory in advance
+             */
+            if (hax_enabled()) {
+                int ret;
+                ret = hax_populate_ram((uint64_t)(uintptr_t)new_block->host,

exec.c static void ram_block_add(RAMBlock *new_block, Error **errp) · line 1638

Quoted 10 lines

exec.c +7 -0

+                                       new_block->max_length);
+                if (ret < 0) {
+                    error_setg(errp, "Hax failed to populate ram");
+                    return;
+                }
+            }
+
             if (!new_block->host) {
                 error_setg_errno(errp, errno,
                                  "cannot set up guest memory '%s'",

The hax_enabled() check should be after the "if (!new_block->host)" block.

Hi,

Your series seems to have some coding style problems. See output below for more information:

Type: series
Subject: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support
Message-id: [email protected]

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do

    echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))

done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test'
b9d801a Plumb the HAXM-based hardware acceleration support c855846 hax: simplify init
577d188 hax: remove non UG code
edf12f7 target-i386: Add Intel HAX files
cfebedf kvm: move cpu synchronization code

=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 2/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/5: ...
ERROR: spaces required around that '-' (ctx:WxV)
#158: FILE: cpus.c:1276:

+        if (SuspendThread(cpu->hThread) == (DWORD) -1) {
                                                    ^

ERROR: spaces required around that '-' (ctx:WxV)
#176: FILE: cpus.c:1294:

+        if (ResumeThread(cpu->hThread) == (DWORD) -1) {
                                                   ^

total: 2 errors, 0 warnings, 349 lines checked

Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1

---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to [email protected]

Quoted 55 lines · On Sun, Nov 13, 2016 at 4:20 AM, <[email protected]> wrote:

Hi,

Your series seems to have some coding style problems. See output below for more information:

Type: series
Subject: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support
Message-id: [email protected]

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do

    echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))

done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test'
b9d801a Plumb the HAXM-based hardware acceleration support c855846 hax: simplify init
577d188 hax: remove non UG code
edf12f7 target-i386: Add Intel HAX files
cfebedf kvm: move cpu synchronization code

=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 2/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/5: ...
ERROR: spaces required around that '-' (ctx:WxV)
#158: FILE: cpus.c:1276:

Quoted 8 lines

+        if (SuspendThread(cpu->hThread) == (DWORD) -1) {
                                                    ^

ERROR: spaces required around that '-' (ctx:WxV)
#176: FILE: cpus.c:1294:

+        if (ResumeThread(cpu->hThread) == (DWORD) -1) {
                                                   ^

Apparently I missed this couple of warnings when I did my final checkpatch pass. At the same time, I have no idea how to solve this one, can anybody enlighten me ?
Having a space on both sides of a unary minus doesn't seem what we want, so I imagine something else is wrong and confuse a bit checkpatch.pl.

Quoted 14 lines · On Sun, Nov 13, 2016 at 4:20 AM, <[email protected]> wrote:

=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 2/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/5: ...
ERROR: spaces required around that '-' (ctx:WxV)
#158: FILE: cpus.c:1276:

Quoted 8 lines

+        if (SuspendThread(cpu->hThread) == (DWORD) -1) {
                                                    ^

ERROR: spaces required around that '-' (ctx:WxV)
#176: FILE: cpus.c:1294:

+        if (ResumeThread(cpu->hThread) == (DWORD) -1) {
                                                   ^

Apparently I missed this couple of warnings when I did my final checkpatch pass. At the same time, I have no idea how to solve this one, can anybody enlighten me ?
Having a space on both sides of a unary minus doesn't seem what we want, so I imagine something else is wrong and confuse a bit checkpatch.pl.

Quoted 26 lines · Vincent Palatin

Quoted 15 lines · On Sun, Nov 13, 2016 at 4:20 AM, <[email protected]> wrote:

=== OUTPUT BEGIN ===
fatal: unrecognized argument: --no-patch
Checking PATCH 1/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 2/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 3/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 4/5: ...
fatal: unrecognized argument: --no-patch
Checking PATCH 5/5: ...
ERROR: spaces required around that '-' (ctx:WxV)
#158: FILE: cpus.c:1276:

Quoted 8 lines

+        if (SuspendThread(cpu->hThread) == (DWORD) -1) {
                                                    ^

ERROR: spaces required around that '-' (ctx:WxV)
#176: FILE: cpus.c:1294:

+        if (ResumeThread(cpu->hThread) == (DWORD) -1) {
                                                   ^

Quoted 6 lines

Apparently I missed this couple of warnings when I did my final checkpatch pass.
At the same time, I have no idea how to solve this one, can anybody enlighten me ?
Having a space on both sides of a unary minus doesn't seem what we want, so I imagine something else is wrong and confuse a bit checkpatch.pl.

(DWORK)(-1) works for checkpatch.pl.

I noticed a strange behaviour of checkpatch.pl:

If I run it on all of your five commits, it does not find any error. If I run it only on the 5th commit, it shows the two errors like above.

I took a stab at trying to rebase/upstream the support for Intel HAXM. (Hardware Accelerated Execution Manager).
Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.

I have based my work on the last version of the source code I found:
the emu-2.2-release branch in the external/qemu-android repository as used by the Android emulator.
In patch 2/5, I have forward-ported the core HAX code mostly unmodified from there, I just did some minor touch up to make it build and run properly, and fixed the style issues to go through checkpatch.pl.
I have not included the Darwin support.
It might contain some outdated constructs and probably requires more attention (thus the 'RFC' for this patchset).

In patch 3/5, I'm removing a good chunk of the support for CPUs without UG mode as advised by Paolo to simplify the initial version.

In patch 5/5, I have put the plumbing into the QEMU code base, I did some clean up there and it is reasonably intrusive: i.e.

 Makefile.target           |  1 +
 configure                 | 18 ++++++++++
 cpus.c                    | 87 ++++++++++++++++++++++++++++++++++++++++++++++-
 exec.c                    | 16 +++++++++
 hw/intc/apic_common.c     |  3 +-
 include/qom/cpu.h         |  5 +++
 include/sysemu/hw_accel.h |  9 +++++
 qemu-options.hx           | 11 ++++++
 target-i386/Makefile.objs |  7 ++++
 vl.c                      | 15 ++++++--
 10 files changed, 167 insertions(+), 5 deletions(-)

The qemu_cpu_kick_thread mess in cpus.c is probably still not perfact though.

The patch 1/5 just extracts from KVM specific header the cpu_synchronize_ functions that HAX is also using.

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

From 91481639a1005ed3278eb55c77c99bb1bcc135ce Mon Sep 17 00:00:00 2001

Am 11.11.2016 um 12:28 schrieb Vincent Palatin:

Quoted 33 lines

I took a stab at trying to rebase/upstream the support for Intel HAXM. (Hardware Accelerated Execution Manager).
Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.

I have based my work on the last version of the source code I found:
the emu-2.2-release branch in the external/qemu-android repository as used by the Android emulator.
In patch 2/5, I have forward-ported the core HAX code mostly unmodified from there, I just did some minor touch up to make it build and run properly, and fixed the style issues to go through checkpatch.pl.
I have not included the Darwin support.
It might contain some outdated constructs and probably requires more attention (thus the 'RFC' for this patchset).

In patch 3/5, I'm removing a good chunk of the support for CPUs without UG mode as advised by Paolo to simplify the initial version.

In patch 5/5, I have put the plumbing into the QEMU code base, I did some clean up there and it is reasonably intrusive: i.e.

 Makefile.target           |  1 +
 configure                 | 18 ++++++++++
 cpus.c                    | 87 ++++++++++++++++++++++++++++++++++++++++++++++-
 exec.c                    | 16 +++++++++
 hw/intc/apic_common.c     |  3 +-
 include/qom/cpu.h         |  5 +++
 include/sysemu/hw_accel.h |  9 +++++
 qemu-options.hx           | 11 ++++++
 target-i386/Makefile.objs |  7 ++++
 vl.c                      | 15 ++++++--
 10 files changed, 167 insertions(+), 5 deletions(-)

The qemu_cpu_kick_thread mess in cpus.c is probably still not perfact though.

Quoted 8 lines

The patch 1/5 just extracts from KVM specific header the cpu_synchronize_ functions that HAX is also using.

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

A full build for Windows needs the patch below to
fix missing declarations, otherwise it fails with
compiler warnings and linker errors.

From 91481639a1005ed3278eb55c77c99bb1bcc135ce Mon Sep 17 00:00:00 2001
From: Stefan Weil <[email protected]>
Date: Mon, 14 Nov 2016 13:09:53 +0100
Subject: [PATCH] Fix include statements for HAXM support

We need sysemu/hw_accel.h. As sysemu/hw_accel.h already includes sysemu/kvm.h, that one can be removed.

Signed-off-by Stefan Weil <[email protected]>

---
 hw/ppc/pnv_xscom.c          | 2 +-
 hw/ppc/ppce500_spin.c       | 4 ++--
 hw/ppc/spapr.c              | 2 +-
 hw/ppc/spapr_hcall.c        | 2 +-
 hw/s390x/s390-pci-inst.c    | 1 +
 target-ppc/mmu-hash64.c     | 2 +-
 target-ppc/translate_init.c | 2 +-
 target-s390x/gdbstub.c      | 1 +
 8 files changed, 9 insertions(+), 7 deletions(-)

hw/ppc/pnv_xscom.c +1 -1

index 5aaa264..abcb85d 100644
@@ -20,7 +20,7 @@
 #include "qapi/error.h"
 #include "hw/hw.h"
 #include "qemu/log.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "target-ppc/cpu.h"
 #include "hw/sysbus.h"
 

hw/ppc/ppce500_spin.c +2 -2

index cf958a9..eb219ab 100644
@@ -29,9 +29,9 @@
 
 #include "qemu/osdep.h"
 #include "hw/hw.h"
-#include "sysemu/sysemu.h"
 #include "hw/sysbus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
+#include "sysemu/sysemu.h"
 #include "e500.h"
 
 #define MAX_CPUS 32

hw/ppc/spapr.c +1 -1

index 0cbab24..174f4d3 100644
@@ -36,7 +36,7 @@
 #include "sysemu/device_tree.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/cpus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "kvm_ppc.h"
 #include "migration/migration.h"
 #include "mmu-hash64.h"

hw/ppc/spapr_hcall.c +1 -1

index 9a9bedf..b2a8e48 100644
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/sysemu.h"
 #include "qemu/log.h"
 #include "cpu.h"

@@ -9,7 +10,6 @@
 #include "mmu-hash64.h"
 #include "cpu-models.h"
 #include "trace.h"
-#include "sysemu/kvm.h"
 #include "kvm_ppc.h"
 #include "hw/ppc/spapr_ovec.h"
 

hw/s390x/s390-pci-inst.c +1 -0

index 0864d9b..4d0775c 100644
@@ -18,6 +18,7 @@
 #include "s390-pci-bus.h"
 #include "exec/memory-internal.h"
 #include "qemu/error-report.h"
+#include "sysemu/hw_accel.h"
 
 /* #define DEBUG_S390PCI_INST */
 #ifdef DEBUG_S390PCI_INST

target-ppc/mmu-hash64.c +1 -1

index fdb7a78..0efc8c6 100644
@@ -23,7 +23,7 @@
 #include "exec/exec-all.h"
 #include "exec/helper-proto.h"
 #include "qemu/error-report.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "kvm_ppc.h"
 #include "mmu-hash64.h"
 #include "exec/log.h"

target-ppc/translate_init.c +1 -1

index 208fa1e..1a049af 100644
@@ -21,10 +21,10 @@
 #include "qemu/osdep.h"
 #include "disas/bfd.h"
 #include "exec/gdbstub.h"
-#include "sysemu/kvm.h"
 #include "kvm_ppc.h"
 #include "sysemu/arch_init.h"
 #include "sysemu/cpus.h"
+#include "sysemu/hw_accel.h"
 #include "cpu-models.h"
 #include "mmu-hash32.h"
 #include "mmu-hash64.h"

target-s390x/gdbstub.c +1 -1

index 3d223de..3c652fb 100644
@@ -23,6 +23,7 @@
 #include "exec/exec-all.h"
 #include "exec/gdbstub.h"
 #include "qemu/bitops.h"
+#include "sysemu/hw_accel.h"
 
 int s390_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
 {
--

2.10.2

Quoted 4 lines

A full build for Windows needs the patch below to
fix missing declarations, otherwise it fails with
compiler warnings and linker errors.

Thanks for filing the gaps. That's very helpful !
Do you mind if I merge it with your SoB into Patch 1/5 where it belongs ? or do you prefer keeping it as a separate patch ?

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
[...]

Quoted 5 lines

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

My test on Windows 7 with HAXM 6.0.4 fails:

$ test/qemu-system-x86_64.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

$ test/qemu-system-i386.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I tested debug code (configure --enable-debug && make) based on latest QEMU from git, this patch series and my include fixes.

Stefan

Quoted 8 lines · Stefan Weil

Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
[...]

Quoted 5 lines

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

Quoted 5 lines

My test on Windows 7 with HAXM 6.0.4 fails:

$ test/qemu-system-x86_64.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

Sorry about this.
I did notice that just running the default Seabios/iPXE was triggering an issue and forgot to debug it (as I'm mostly running Chromium OS images).
I will have a look and try to sort this out..

Quoted 19 lines

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

$ test/qemu-system-i386.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I tested debug code (configure --enable-debug && make) based on latest QEMU from git, this patch series and my include fixes.

Stefan

Quoted 15 lines · Vincent Palatin

Quoted 8 lines · Stefan Weil

Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
[...]

Quoted 5 lines

I have tested the end result on a Windows 10 Pro machine (with UG support) with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux build with KVM enabled.

Quoted 5 lines

My test on Windows 7 with HAXM 6.0.4 fails:

$ test/qemu-system-x86_64.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

Quoted 5 lines

Sorry about this.
I did notice that just running the default Seabios/iPXE was triggering an issue and forgot to debug it (as I'm mostly running Chromium OS images).
I will have a look and try to sort this out..

I did more debugging on this and opened a whole new can of worms... The actual crash was the first MMIO access in the iPXE option ROM. The intel network driver there is triggering the MMIO emulation path (ie the HAX kernel module is asking us to emulate the MMIO instruction rather than using the 'fast MMIO' path as all other MMIOs), this path was never correctly plumbed for the UG case in the original Intel patchset, and still is not.... We can run a full linux image without triggering it showing how unlikely it is, but it is not documented why it is not using the normal fast MMIO in some rare case even in UG mode

Adding back a whole TCG emulation fall-back just for this is somewhat large and complex, I will try to find first why it's not using the normal path.
For what it worth '-net nic,model=pcnet' works as a workaround (by not triggering the MMIO of death)

In addition to this, as you might have noticed, there is no character on the (virtual) screen.
The VGA emulation is not triggered because the VGA hole is badly mapped. Digging into this, that's due to the fact that the .region_del() callback of the MemoryListener is missing a proper implementation, so the system cannot remove the initial large mapping of memory on top of those MMIO holes.
But there is a deeper issue to solve this: I'm not seeing in their current kernel module API (aka the hax-interface.h header) a (documented) way of removing a mapping...

So I will probably send the v3 patchset with those caveats still opened to be sure the other changes are not lost,
then I will work further on this and maybe try to get Intel inputs on those API behaviors.

Quoted 19 lines

Quoted 19 lines

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

$ test/qemu-system-i386.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I tested debug code (configure --enable-debug && make) based on latest QEMU from git, this patch series and my include fixes.

Stefan