Re: [Qemu-devel] [PATCH v3 0/3] Add HAX support

2016-12-08 Thread Yu Ning 
As a HAXM developer at Intel, I just want to come out and show our 
support for Vincent's upstreaming effort. We'd love to see HAXM support 
code land in upstream QEMU, and will do what is necessary to make that 
happen.


We've been working on the issues that Vincent raised and have made some 
progress - see below.


Regards,
Yu

On 11/17/2016 7:13 PM, Vincent Palatin wrote:

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/3, I have forward-ported the core HAX code from there.
It has been modified to build and run along with the current code base.
It has been simplifying by removing non-UG hardware support / Darwin support /
Android-specific leftovers.

CAVEAT: this patchset is still RFC because in addition of potentially containing
a few outdated constructs and a questionable mess in qemu_cpu_kick_thread(),
there are 2 unsolved issues:
- in rare cases, the HAX kernel module asks us to emulate a MMIO access rather
   than just using the 'fast MMIO' path. This path is still not implemented (as
   it was in the original patch). It's unclear why/when this is happening
   (eg you can run a full linux image without hitting it but the default iPXE
   option ROM is hitting it in the Intel network driver).


This is now resolved, thanks to Vincent's help with debugging. The next 
HAXM driver release will include the fix.



- the MemoryListener implementation cannot remove a memory mapping (e.g. for
   digging the VGA 'hole' in the lowmem). This shortcoming breaks the std vga
   implementation but in the current HAX module API, I don't see any 
(documented)
   way of implementing this.


The current HAXM driver does not support removing a memory mapping. We 
just got that implemented this week, but testing has revealed another 
MMIO bug, which we are trying to fix.




In patch 3/3, 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 |  4 +++
  vl.c  | 15 ++--
  10 files changed, 164 insertions(+), 5 deletions(-)

The patch 1/3 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.
Just running 'qemu-system-x86_64 -enable-hax' is broken due to the caveats
described above.

Changes from v2 to v3:
- fix saving/restoring FPU registers as suggested by Paolo.
- fix Windows build on all targets as contributed by Stefan Weil.
- clean-up IO / MMIO emulation.
- more clean-up of emulation leftovers.

Changes from v1 to v2:
- fix all style issues in the original code to get it through checkpatch.pl.
- remove Darwin support, it was barely tested and not fully functional.
- remove the support for CPU without UG mode.
- fix most review comments

Vincent Palatin (3):
   kvm: move cpu synchronization code
   target-i386: Add Intel HAX files
   Plumb the HAXM-based hardware acceleration support

  Makefile.target |1 +
  configure   |   18 +
  cpus.c  |   88 ++-
  exec.c  |   16 +
  gdbstub.c   |1 +
  hax-stub.c  |   39 ++
  hw/i386/kvm/apic.c  |1 +
  hw/i386/kvmvapic.c  |1 +
  hw/intc/apic_common.c   |3 +-
  hw/misc/vmport.c|2 +-
  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 +
  include/qom/cpu.h   |5 +
  include/sysemu/hax.h|   56 ++
  include/sysemu/hw_accel.h   |   48 ++
  include/sysemu/kvm.h|   23 -
  monitor.c   |2 +-
  qemu-options.hx |   11 +
  qom/cpu.c   |2 +-
  target-arm/cpu.c|2 +-
  target-i386/Makefile.objs   |4 +
  target-i386/hax-all.c   | 1250 +++
  target-i386/hax-i386.h  |   85 +++
  target-i386/hax-interface.h |  357 
  target-i386/hax-slot.c  |

Re: [Qemu-devel] HAXM is now open source

2017-11-15 Thread Yu Ning 



On 11/15/2017 3:13, John Snow wrote:


On 11/14/2017 06:09 AM, Thomas Huth wrote:


That's great news! I hope this all will help to promote QEMU on Windows
and macOS quite a bit!

However, during the past months, I noticed a couple of times that users
ask on IRC or the qemu-discuss mailing list how they could accelerate
their QEMU on Windows - and they are running only in TCG mode when you
ask how they start QEMU. So it seems like there is not much knowledge
about "--accel hax" in the public yet. Maybe you could write a nice blog
post for the QEMU blog or something similar that explains how to use
HAXM with QEMU on Windows for the normal users? Or maybe make it more
prominent in the QEMU wiki? (e.g. the main page only mentions KVM and
Xen, but not HAXM)

A blog post advertising this new development would be an absolute
miracle for linking to people who are just getting started with QEMU on
Windows.

(It would also be really good for idiots like me, who do not use Windows
for anything other than playing video games and sometimes forget that it
is capable of doing other things.)


Thanks for the encouragement.

I think I can start by writing a small section that can be added to an 
existing document, and later expanded to a blog article. But I haven't 
found a suitable place for it on the QEMU wiki.


Does it make sense to add the proposed piece to the QEMU user manual 
(qemu-doc.texi), under the Quick Start section (2.2)? The user manual is 
published on Stefan's website and referred to by qemu.org:


https://qemu.weilnetz.de/doc/qemu-doc.html

so I think it's a popular resource among users.

BTW, I assume most Windows users begin their QEMU journey from this page 
(also credit to Stefan):


https://qemu.weilnetz.de/

and I've verified the hax accelerator module is built into the latest 
binaries there (at least the W64 ones).


-Yu

[Qemu-devel] [PATCH] hax-interface: Add BSD license

2017-11-15 Thread yu . ning 
From: Yu Ning 

hax-interface.h defines the interface between the HAXM kernel
module and the HAXM QEMU accelerator. The same code can be found in
the following files of the HAXM kernel module:

 include/hax_interface.h
 include/vcpu_state.h
 core/include/vm.h

These files are now open source under the 3-clause BSD license,
whereas hax-interface.h in QEMU uses GPLv2.

Address this inconsistency by adding the BSD license to the QEMU
file, per Stefan Weil's comment on this HAXM pull request:

 https://github.com/intel/haxm/pull/2

Signed-off-by: Yu Ning 
---
 target/i386/hax-interface.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/target/i386/hax-interface.h b/target/i386/hax-interface.h
index d141308..9a36c9a 100644
--- a/target/i386/hax-interface.h
+++ b/target/i386/hax-interface.h
@@ -1,4 +1,33 @@
 /*
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ *   1. Redistributions of source code must retain the above copyright notice,
+ *  this list of conditions and the following disclaimer.
+ *
+ *   2. Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ *
+ *   3. Neither the name of the copyright holder nor the names of its
+ *  contributors may be used to endorse or promote products derived from
+ *  this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+/*
  * QEMU HAXM support
  *
  * Copyright (c) 2011 Intel Corporation
-- 
2.7.4

Re: [Qemu-devel] HAXM is now open source

2017-11-17 Thread Yu Ning 



On 11/15/2017 22:18, Paolo Bonzini wrote:

On 15/11/2017 09:25, Yu Ning wrote:


On 11/15/2017 3:13, John Snow wrote:

On 11/14/2017 06:09 AM, Thomas Huth wrote:

That's great news! I hope this all will help to promote QEMU on Windows
and macOS quite a bit!

However, during the past months, I noticed a couple of times that users
ask on IRC or the qemu-discuss mailing list how they could accelerate
their QEMU on Windows - and they are running only in TCG mode when you
ask how they start QEMU. So it seems like there is not much knowledge
about "--accel hax" in the public yet. Maybe you could write a nice blog
post for the QEMU blog or something similar that explains how to use
HAXM with QEMU on Windows for the normal users? Or maybe make it more
prominent in the QEMU wiki? (e.g. the main page only mentions KVM and
Xen, but not HAXM)

A blog post advertising this new development would be an absolute
miracle for linking to people who are just getting started with QEMU on
Windows.

(It would also be really good for idiots like me, who do not use Windows
for anything other than playing video games and sometimes forget that it
is capable of doing other things.)

Thanks for the encouragement.

I think I can start by writing a small section that can be added to an
existing document, and later expanded to a blog article. But I haven't
found a suitable place for it on the QEMU wiki.

Does it make sense to add the proposed piece to the QEMU user manual
(qemu-doc.texi), under the Quick Start section (2.2)? The user manual is
published on Stefan's website and referred to by qemu.org:

https://qemu.weilnetz.de/doc/qemu-doc.html

Unfortunately the "Quick Start" section is quite out of date (it doesn't
even mention KVM!) and is basically a huge list of options.  We are in
the process of improving QEMU documentation, so I think a blog post is
preferrable at this stage.



I see. I'll take the advice.

Is there a preferred document format for the QEMU blog, e.g. Markdown? 
I'll get the content ready by early next week, and then I'll need 
someone to help me post it.

Re: [Qemu-devel] HAXM is now open source

2017-11-17 Thread Yu Ning 



On 11/17/2017 16:30, Thomas Huth wrote:

On 17.11.2017 09:17, Yu Ning wrote:
[...]

Is there a preferred document format for the QEMU blog, e.g. Markdown?

Yes, we're using markdown of Jekyll (https://jekyllrb.com/docs/posts/).
Please clone the qemu-web repository (see
https://git.qemu.org/?p=qemu-web.git), and have a look in the "_posts"
directory to see how the files should look like.


I'll get the content ready by early next week, and then I'll need
someone to help me post it.

Sure, Paolo and I should be able to help. The preferred way is to create
a patch against the qemu-web repository and send that patch to
qemu-devel, with CC: to Paolo and myself. We then can give feedback, do
sanity checking (in case you don't want to install Jekyll on your HD),
and push the patch to the website if everything is fine.


Got it, thanks!

Re: [Qemu-devel] [PATCH] hax-interface: Add BSD license

2017-11-17 Thread Yu Ning 



On 11/17/2017 2:00, Eduardo Habkost wrote:

On Thu, Nov 16, 2017 at 07:47:44AM +0100, Stefan Weil wrote:

Am 16.11.2017 um 07:50 schrieb yu.n...@linux.intel.com:

From: Yu Ning 

hax-interface.h defines the interface between the HAXM kernel
module and the HAXM QEMU accelerator. The same code can be found in
the following files of the HAXM kernel module:

  include/hax_interface.h
  include/vcpu_state.h
  core/include/vm.h

These files are now open source under the 3-clause BSD license,
whereas hax-interface.h in QEMU uses GPLv2.

Why is this a problem?


I know very little about licenses.  If this is not a problem, I'm happy 
to just abandon this patch.



Address this inconsistency by adding the BSD license to the QEMU
file, per Stefan Weil's comment on this HAXM pull request:

  https://github.com/intel/haxm/pull/2

The existing code on qemu.git don't match the code on the GitHub
repository above exactly, and its copyright history looks hard to
track[1].


Right. I don't know when the QEMU header (hax-interface.h) first 
appeared, but I think it's probably a derivative of the HAXM ones, which 
date back to no later than June 2011.



If we really care about consistency between the two
projects, shouldn't we just delete the existing file and copy the
headers from github.com/intel/haxm directly?


That's a good solution, but not feasible at the moment, because in the 
HAXM kernel module, a small piece of the interface code currently 
resides in an internal header (core/include/vm.h). Probably we should 
clean up the interface headers on the HAXM side, and then push the 
change to QEMU.



Also, does it even make sense to keep the two licenses in the
file?


I don't know the answer.  If it doesn't make sense, I can either remove 
the original GPLv2 license, or abandon this patch and later come back 
with another one implementing the above solution.

Re: [Qemu-devel] HAXM is now open source

2017-11-17 Thread Yu Ning 



On 11/17/2017 16:53, Kamil Rytarowski wrote:

On 14.11.2017 09:54, Yu Ning wrote:

Hello,

As some of you may have noticed, since QEMU 2.9.0, an accelerator known
as “hax” has been available for Windows and macOS builds of QEMU, thanks
to the hard work of Vincent Palatin and help from this community (Paolo
Bonzini, Stefan Weil, et al.).

The accelerator requires a host kernel module (driver) known as Intel
Hardware Accelerated Execution Manager (HAXM), i.e. intelhaxm.sys on
Windows or intelhaxm.kext on macOS, similar to how the KVM accelerator
depends on kvm.ko on Linux.

Today, we released the source code of the HAXM kernel module under the
BSD 3-clause license:

https://github.com/intel/haxm

We look forward to working with the community to improve HAXM (both the
kernel module and the accelerator). The code is accompanied by some
basic documentation (README.md and API.md), which is incomplete, but
hopefully helps people get started. If you have any questions or
suggestions, please create an issue or post a comment on GitHub.

Thanks,
Yu


Please make it clear whether this module can be ported (as host) to
other OSes


It was designed with only Windows and Mac hosts in mind, and we don't 
plan to support more host OSes. But porting HAXM to another host OS is 
possible.  If you take a look at the HAXM source tree, there are pretty 
clear boundaries between host-independent code (core/, include/*.h), 
Windows-specific code (windows/, include/windows/) and Mac-specific code 
(darwin/, include/darwin/).

  and whether it can support arbitrary guests OSes (for the
same CPU).


Unfortunately not, but again it can be done.  Initially HAXM was 
designed to support only two guest OSes, namely Android and Tizen. When 
we upstreamed the HAXM accelerator module to QEMU, we verified it using 
various desktop OS images, mostly Linux-based (Chrome OS, Debian, 
Ubuntu, CentOS, etc.), although there were a few others (FreeDOS, etc.).


Nevertheless, you may run into issues when you boot a completely 
different guest OS (e.g. Windows, which we have never tested), or even 
with one that is similar to what I've mentioned (e.g. Fedora, which IIRC 
will boot to a kernel panic).  In such cases, the culprit is usually 
bug(s) in the HAXM kernel module, causing incorrect behavior when the 
guest executes certain x86 instructions.  Once all the bugs exposed by a 
specific guest OS are fixed, that guest OS will work correctly.

Re: [Qemu-devel] [PATCH] hax-interface: Add BSD license

2017-11-19 Thread Yu Ning 



On 11/20/2017 5:31, Eduardo Habkost wrote:

On Fri, Nov 17, 2017 at 05:03:27PM +0800, Yu Ning wrote:

On 11/17/2017 2:00, Eduardo Habkost wrote:

On Thu, Nov 16, 2017 at 07:47:44AM +0100, Stefan Weil wrote:

Am 16.11.2017 um 07:50 schrieb yu.n...@linux.intel.com:

From: Yu Ning 

hax-interface.h defines the interface between the HAXM kernel
module and the HAXM QEMU accelerator. The same code can be found in
the following files of the HAXM kernel module:

   include/hax_interface.h
   include/vcpu_state.h
   core/include/vm.h

These files are now open source under the 3-clause BSD license,
whereas hax-interface.h in QEMU uses GPLv2.

Why is this a problem?

I know very little about licenses.  If this is not a problem, I'm happy to
just abandon this patch.

As far as I can see, this is not a problem for the QEMU project
at all, as QEMU as a whole is GPLv2.

It would make sense to update the license if we wanted to keep
our header file in sync with some other source tree (e.g. the one
from Intel), but this doesn't seem to be the case here (yet?).


I see, that makes sense.






If we really care about consistency between the two
projects, shouldn't we just delete the existing file and copy the
headers from github.com/intel/haxm directly?

That's a good solution, but not feasible at the moment, because in the HAXM
kernel module, a small piece of the interface code currently resides in an
internal header (core/include/vm.h). Probably we should clean up the
interface headers on the HAXM side, and then push the change to QEMU.

This would be nice, so we wouldn't need to maintain a different
header file in QEMU.  Should we open an issue at
https://github.com/intel/haxm?


Here: https://github.com/intel/haxm/issues/9

The API headers in the HAXM tree depend on another header, i.e. either 
hax_types_windows.h or hax_types_mac.h, which defines some basic data 
types (uint64_t, etc.) and macros (PACKED, ALIGNED, etc.).  If we want 
to use the same files for QEMU, we'll need to figure out an elegant way 
to provide those definitions.  Any suggestions?

Re: [Qemu-devel] [PATCH] Add a blog post about HAXM acceleration on Windows

2017-11-22 Thread Yu Ning 



On 11/22/2017 20:25, Thomas Huth wrote:

On 22.11.2017 09:10, Yu Ning wrote:

From: Yu Ning 

Following my announcement of the open source release of HAXM,
I was asked to write a blog post for normal Windows users to
advertise the use of "-accel hax":

https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02822.html

Thanks a lot, that blog post looks very good to me!


Thanks!


... just the width of the qemu-debian-wheezy-gui-with-haxm.png image
seems to cause some rendering ugliness in my webbrowser, causing the
text to overflow into the right menu:

http://people.redhat.com/~thuth/screenshot-haxm-blog.png

Would it be OK to remove the qemu-debian-wheezy-gui-with-haxm.png from
the blog post?


Yes, I'm fine with removing it.  Sorry I haven't installed Jekyll and 
didn't test the rendering.


Would you confirm whether that's the only change I need to make in v2?

Re: [Qemu-devel] [PATCH] Add a blog post about HAXM acceleration on Windows

2017-11-22 Thread Yu Ning 



On 11/23/2017 1:03, Thomas Huth wrote:

On 22.11.2017 15:52, Yu Ning wrote:

On 11/22/2017 20:25, Thomas Huth wrote:

[...]

Would it be OK to remove the qemu-debian-wheezy-gui-with-haxm.png from
the blog post?

Yes, I'm fine with removing it.  Sorry I haven't installed Jekyll and
didn't test the rendering.

Would you confirm whether that's the only change I need to make in v2?

No need to respin, since this was just a one-line change, I was able to
do it on my own (I still removed the screenshot, even if it seemed to be
working with Paolo's patch to the CSS, since the screenshot looked just
a bit too big for the blog - I hope that's OK for you).


Yes, absolutely :)


So the blog post is now online:

  https://www.qemu.org/2017/11/22/haxm-usage-windows/


Looks nice, thanks!

Re: [Qemu-devel] [PATCH] Add a blog post about HAXM acceleration on Windows

2017-11-28 Thread Yu Ning 



On 11/29/2017 9:25, Fam Zheng wrote:

On Tue, 11/28 13:57, Eric Blake wrote:

On 11/22/2017 04:43 AM, no-re...@patchew.org wrote:

Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] [PATCH] Add a blog post about HAXM acceleration on Windows
Type: series
Message-id: 1511338200-20417-1-git-send-email-yu.n...@linux.intel.com

Just now noticing this, but it's impressive that:


Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
73987e06df Add a blog post about HAXM acceleration on Windows

the patch even applied, even though it wasn't against qemu.git!  Is it
possible to teach patchew to ignore patches against the website, as that is
maintained in a separate repository?

This patch was supposed to have "[qemu-web PATCH]" or "[PATCH web]" in the
subject. That way it wouldn't be processed by patchew. (I think that is in
general a good way to state which repo the series is targeting at.)


I see.  Sorry I didn't know about that and used the wrong prefix. Is it 
documented on the wiki?


Thanks,
Yu

Re: [Qemu-devel] [PATCH] hax: Support guest RAM sizes of 4GB or more

2018-01-22 Thread Yu Ning 

A gentle ping. Patchwork link: http://patchwork.ozlabs.org/patch/859715/



On 1/12/2018 18:22, Yu Ning wrote:

From: Yu Ning 

Since HAX_VM_IOCTL_ALLOC_RAM takes a 32-bit size, it cannot handle
RAM blocks of 4GB or larger, which is why HAXM can only run guests
with less than 4GB of RAM. Solve this problem by utilizing the new
HAXM API, HAX_VM_IOCTL_ADD_RAMBLOCK, which takes a 64-bit size, to
register RAM blocks with the HAXM kernel module. The new API is
first added in HAXM 7.0.0, and its availablility and be confirmed
by the presence of the HAX_CAP_64BIT_RAMBLOCK capability flag.

When the guest RAM size reaches 7GB, QEMU will ask HAXM to set up a
memory mapping that covers a 4GB region, which will fail, because
HAX_VM_IOCTL_SET_RAM also takes a 32-bit size. Work around this
limitation by splitting the large mapping into small ones and
calling HAX_VM_IOCTL_SET_RAM multiple times.

Bug: https://bugs.launchpad.net/qemu/+bug/1735576

Signed-off-by: Yu Ning 
---
  include/sysemu/hax.h|  2 +-
  target/i386/hax-all.c   |  2 ++
  target/i386/hax-darwin.c| 27 +--
  target/i386/hax-darwin.h|  1 +
  target/i386/hax-i386.h  |  1 +
  target/i386/hax-interface.h |  8 
  target/i386/hax-mem.c   | 34 ++
  target/i386/hax-windows.c   | 38 +++---
  target/i386/hax-windows.h   |  2 ++
  9 files changed, 89 insertions(+), 26 deletions(-)

diff --git a/include/sysemu/hax.h b/include/sysemu/hax.h
index f252399..1f6c461 100644
--- a/include/sysemu/hax.h
+++ b/include/sysemu/hax.h
@@ -27,7 +27,7 @@
  int hax_sync_vcpus(void);
  int hax_init_vcpu(CPUState *cpu);
  int hax_smp_cpu_exec(CPUState *cpu);
-int hax_populate_ram(uint64_t va, uint32_t size);
+int hax_populate_ram(uint64_t va, uint64_t size);
  
  void hax_cpu_synchronize_state(CPUState *cpu);

  void hax_cpu_synchronize_post_reset(CPUState *cpu);
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index 3ce6950..57921e7 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -104,6 +104,8 @@ static int hax_get_capability(struct hax_state *hax)
  return -ENOTSUP;
  }
  
+hax->supports_64bit_ramblock = !!(cap->winfo & HAX_CAP_64BIT_RAMBLOCK);

+
  if (cap->wstatus & HAX_CAP_MEMQUOTA) {
  if (cap->mem_quota < hax->mem_quota) {
  fprintf(stderr, "The VM memory needed exceeds the driver 
limit.\n");
diff --git a/target/i386/hax-darwin.c b/target/i386/hax-darwin.c
index ee94174..acdde47 100644
--- a/target/i386/hax-darwin.c
+++ b/target/i386/hax-darwin.c
@@ -28,21 +28,36 @@ hax_fd hax_mod_open(void)
  return fd;
  }
  
-int hax_populate_ram(uint64_t va, uint32_t size)

+int hax_populate_ram(uint64_t va, uint64_t size)
  {
  int ret;
-struct hax_alloc_ram_info info;
  
  if (!hax_global.vm || !hax_global.vm->fd) {

  fprintf(stderr, "Allocate memory before vm create?\n");
  return -EINVAL;
  }
  
-info.size = size;

-info.va = va;
-ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ALLOC_RAM, &info);
+if (hax_global.supports_64bit_ramblock) {
+struct hax_ramblock_info ramblock = {
+.start_va = va,
+.size = size,
+.reserved = 0
+};
+
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ADD_RAMBLOCK, &ramblock);
+} else {
+struct hax_alloc_ram_info info = {
+.size = (uint32_t)size,
+.pad = 0,
+.va = va
+};
+
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ALLOC_RAM, &info);
+}
  if (ret < 0) {
-fprintf(stderr, "Failed to allocate %x memory\n", size);
+fprintf(stderr, "Failed to register RAM block: ret=%d, va=0x%" PRIx64
+", size=0x%" PRIx64 ", method=%s\n", ret, va, size,
+hax_global.supports_64bit_ramblock ? "new" : "legacy");
  return ret;
  }
  return 0;
diff --git a/target/i386/hax-darwin.h b/target/i386/hax-darwin.h
index fb8e25a..51af0e8 100644
--- a/target/i386/hax-darwin.h
+++ b/target/i386/hax-darwin.h
@@ -44,6 +44,7 @@ static inline void hax_close_fd(hax_fd fd)
  #define HAX_VM_IOCTL_SET_RAM _IOWR(0, 0x82, struct hax_set_ram_info)
  #define HAX_VM_IOCTL_VCPU_DESTROY _IOW(0, 0x83, uint32_t)
  #define HAX_VM_IOCTL_NOTIFY_QEMU_VERSION _IOW(0, 0x84, struct 
hax_qemu_version)
+#define HAX_VM_IOCTL_ADD_RAMBLOCK _IOW(0, 0x85, struct hax_ramblock_info)
  
  #define HAX_VCPU_IOCTL_RUN  _IO(0, 0xc0)

  #define HAX_VCPU_IOCTL_SET_MSRS _IOWR(0, 0xc1, struct hax_msr_data)
diff --git a/target/i386/hax-i386.h b/target/i386/hax-i386.h
index 8ffe91f..6abc156 100644
--- a/target/i386/hax-i386.h
+++ b/target/i386/hax-i386.h
@@ -37,6 +37,7 @@ struct hax_state {
  uint32_t version;
  struct hax_vm *vm;
  uint64_t mem_quota;
+bool suppo

[Qemu-devel] [PATCH] hax: Fix memory mapping de-duplication logic

2017-04-28 Thread Yu Ning 
hax_update_mapping() avoids unnecessary and potentially expensive
calls to HAX_VM_IOCTL_SET_RAM by computing the net result (i.e.
effective mapping changes) of each MemoryRegion transaction, with
the help of a linked list of HAXMapping objects.

However, when processing a new mapping that overlaps with an
existing mapping in the list, it fails to handle the case where the
start address of the new mapping is above that of the existing
mapping in the guest physical address space. This happens when QEMU
is launched with "-machine q35 -enable-hax", which involves the
following MemoryRegion transaction for digging the VGA hole:

 region_del: 0x->0x0800 VA 05fa ('pc.ram')
 region_add: 0x->0x000a VA 05fa ('pc.ram')
 region_add: 0x000a->0x000c VA  ('vga-lowmem')
 region_add: 0x000c->0x0800 VA 0606 ('pc.ram')

where the third MemoryRegion is MMIO and is ignored. The current
de-duplication logic handles the last MemoryRegion incorrectly and
produces the following result:

 hax_mapping_dump_list updates:
 + 0x000c->0x0800 VA 0x0606
 - 0x07fe->0x0800 VA 0x0df8

which is why VGA emulation does not work for Q35.

With this patch, one can see VGA output as Q35 boots up. Note that
Q35 support also requires a change to HAXM kernel module, which is
not available in the current HAXM release (6.1.2).

+ Add a warning if the input MemoryRegion is a ROM device, which is
  not supported by HAXM kernel module at this time.

Signed-off-by: Yu Ning 
---
 target/i386/hax-mem.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/target/i386/hax-mem.c b/target/i386/hax-mem.c
index 2884040..af09034 100644
--- a/target/i386/hax-mem.c
+++ b/target/i386/hax-mem.c
@@ -106,10 +106,10 @@ static void hax_update_mapping(uint64_t start_pa, 
uint32_t size,
uint64_t host_va, uint8_t flags)
 {
 uint64_t end_pa = start_pa + size;
-uint32_t chunk_sz;
 HAXMapping *entry, *next;
 
 QTAILQ_FOREACH_SAFE(entry, &mappings, entry, next) {
+uint32_t chunk_sz;
 if (start_pa >= entry->start_pa + entry->size) {
 continue;
 }
@@ -121,7 +121,16 @@ static void hax_update_mapping(uint64_t start_pa, uint32_t 
size,
 start_pa += chunk_sz;
 host_va += chunk_sz;
 size -= chunk_sz;
+} else if (start_pa > entry->start_pa) {
+/* split the existing chunk at start_pa */
+chunk_sz = start_pa - entry->start_pa;
+hax_insert_mapping_before(entry, entry->start_pa, chunk_sz,
+  entry->host_va, entry->flags);
+entry->start_pa += chunk_sz;
+entry->host_va += chunk_sz;
+entry->size -= chunk_sz;
 }
+/* now start_pa == entry->start_pa */
 chunk_sz = MIN(size, entry->size);
 if (chunk_sz) {
 bool nop = hax_mapping_is_opposite(entry, host_va, flags);
@@ -165,8 +174,14 @@ static void hax_process_section(MemoryRegionSection 
*section, uint8_t flags)
 unsigned int delta;
 uint64_t host_va;
 
-/* We only care about RAM pages */
+/* We only care about RAM and ROM regions */
 if (!memory_region_is_ram(mr)) {
+if (memory_region_is_romd(mr)) {
+/* HAXM kernel module does not support ROMD yet  */
+fprintf(stderr, "%s: Warning: Ignoring ROMD region 0x%016" PRIx64
+"->0x%016" PRIx64 "\n", __func__, start_pa,
+start_pa + size);
+}
 return;
 }
 
-- 
2.9.3

Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support

2017-01-08 Thread Yu Ning 



On 1/6/2017 5:38, Paolo Bonzini wrote:


On 05/01/2017 15:01, Paolo Bonzini wrote:


In fact there is a race anyway:

 if (cpu->exit_request) {
 ret = 1;
 break;
 }
cpu->exit_request
SuspendThread
ResumeThread
 hax_vcpu_interrupt(env);
 qemu_mutex_unlock_iothread();
 hax_ret = hax_vcpu_run(vcpu);

and the same race is true for QueueUserAPC.  It's rare enough that I
guess we can accept the patches with just a FIXME comment, but...  Yu
Ning, can you tell us what user_event_pending is for? :)  My hunch is
that we should call hax_raise_event after setting cpu->exit_request, like

hax_raise_event();
/* write user_event_pending before exit_request */
smp_wmb();
cpu->exit_request = 1;
SuspendThread/ResumeThread
(or QueueUserAPC)

and in the hax thread:

 if (cpu->exit_request) {
cpu->hax_vcpu->tunnel->user_event_pending = 0;
 ret = 1;
 break;
 }

 hax_vcpu_interrupt(env);
 qemu_mutex_unlock_iothread();

/* read exit_request before user_event_pending */
smp_rmb();
 hax_ret = hax_vcpu_run(vcpu);

but I would like some more official documentation than my own reverse
engineering of the brain of whoever wrote the interface (I have not
looked at the HAXM driver binary).


Unfortunately, user_event_pending was introduced in 2011 without proper 
documentation, so I guess even the original author might not have an 
answer now (even if I could find him).  I need more time to analyze the 
HAXM driver code to understand what it's about.  Please feel free to add 
a FIXME for now.


But one thing I've noticed is that the Darwin driver does not test or 
reset this flag properly - it will remain 1 after the first 
hax_raise_event() call.  So removing user_event_pending from the QEMU 
side should not affect Mac.

[Qemu-devel] HAXM is now open source

2017-11-14 Thread Yu Ning 

Hello,

As some of you may have noticed, since QEMU 2.9.0, an accelerator known 
as “hax” has been available for Windows and macOS builds of QEMU, thanks 
to the hard work of Vincent Palatin and help from this community (Paolo 
Bonzini, Stefan Weil, et al.).


The accelerator requires a host kernel module (driver) known as Intel 
Hardware Accelerated Execution Manager (HAXM), i.e. intelhaxm.sys on 
Windows or intelhaxm.kext on macOS, similar to how the KVM accelerator 
depends on kvm.ko on Linux.


Today, we released the source code of the HAXM kernel module under the 
BSD 3-clause license:


https://github.com/intel/haxm

We look forward to working with the community to improve HAXM (both the 
kernel module and the accelerator). The code is accompanied by some 
basic documentation (README.md and API.md), which is incomplete, but 
hopefully helps people get started. If you have any questions or 
suggestions, please create an issue or post a comment on GitHub.


Thanks,
Yu

[Qemu-devel] [PATCH] hax: Support guest RAM sizes of 4GB or more

2018-01-12 Thread Yu Ning 
From: Yu Ning 

Since HAX_VM_IOCTL_ALLOC_RAM takes a 32-bit size, it cannot handle
RAM blocks of 4GB or larger, which is why HAXM can only run guests
with less than 4GB of RAM. Solve this problem by utilizing the new
HAXM API, HAX_VM_IOCTL_ADD_RAMBLOCK, which takes a 64-bit size, to
register RAM blocks with the HAXM kernel module. The new API is
first added in HAXM 7.0.0, and its availablility and be confirmed
by the presence of the HAX_CAP_64BIT_RAMBLOCK capability flag.

When the guest RAM size reaches 7GB, QEMU will ask HAXM to set up a
memory mapping that covers a 4GB region, which will fail, because
HAX_VM_IOCTL_SET_RAM also takes a 32-bit size. Work around this
limitation by splitting the large mapping into small ones and
calling HAX_VM_IOCTL_SET_RAM multiple times.

Bug: https://bugs.launchpad.net/qemu/+bug/1735576

Signed-off-by: Yu Ning 
---
 include/sysemu/hax.h|  2 +-
 target/i386/hax-all.c   |  2 ++
 target/i386/hax-darwin.c| 27 +--
 target/i386/hax-darwin.h|  1 +
 target/i386/hax-i386.h  |  1 +
 target/i386/hax-interface.h |  8 
 target/i386/hax-mem.c   | 34 ++
 target/i386/hax-windows.c   | 38 +++---
 target/i386/hax-windows.h   |  2 ++
 9 files changed, 89 insertions(+), 26 deletions(-)

diff --git a/include/sysemu/hax.h b/include/sysemu/hax.h
index f252399..1f6c461 100644
--- a/include/sysemu/hax.h
+++ b/include/sysemu/hax.h
@@ -27,7 +27,7 @@
 int hax_sync_vcpus(void);
 int hax_init_vcpu(CPUState *cpu);
 int hax_smp_cpu_exec(CPUState *cpu);
-int hax_populate_ram(uint64_t va, uint32_t size);
+int hax_populate_ram(uint64_t va, uint64_t size);
 
 void hax_cpu_synchronize_state(CPUState *cpu);
 void hax_cpu_synchronize_post_reset(CPUState *cpu);
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index 3ce6950..57921e7 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -104,6 +104,8 @@ static int hax_get_capability(struct hax_state *hax)
 return -ENOTSUP;
 }
 
+hax->supports_64bit_ramblock = !!(cap->winfo & HAX_CAP_64BIT_RAMBLOCK);
+
 if (cap->wstatus & HAX_CAP_MEMQUOTA) {
 if (cap->mem_quota < hax->mem_quota) {
 fprintf(stderr, "The VM memory needed exceeds the driver 
limit.\n");
diff --git a/target/i386/hax-darwin.c b/target/i386/hax-darwin.c
index ee94174..acdde47 100644
--- a/target/i386/hax-darwin.c
+++ b/target/i386/hax-darwin.c
@@ -28,21 +28,36 @@ hax_fd hax_mod_open(void)
 return fd;
 }
 
-int hax_populate_ram(uint64_t va, uint32_t size)
+int hax_populate_ram(uint64_t va, uint64_t size)
 {
 int ret;
-struct hax_alloc_ram_info info;
 
 if (!hax_global.vm || !hax_global.vm->fd) {
 fprintf(stderr, "Allocate memory before vm create?\n");
 return -EINVAL;
 }
 
-info.size = size;
-info.va = va;
-ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ALLOC_RAM, &info);
+if (hax_global.supports_64bit_ramblock) {
+struct hax_ramblock_info ramblock = {
+.start_va = va,
+.size = size,
+.reserved = 0
+};
+
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ADD_RAMBLOCK, &ramblock);
+} else {
+struct hax_alloc_ram_info info = {
+.size = (uint32_t)size,
+.pad = 0,
+.va = va
+};
+
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ALLOC_RAM, &info);
+}
 if (ret < 0) {
-fprintf(stderr, "Failed to allocate %x memory\n", size);
+fprintf(stderr, "Failed to register RAM block: ret=%d, va=0x%" PRIx64
+", size=0x%" PRIx64 ", method=%s\n", ret, va, size,
+hax_global.supports_64bit_ramblock ? "new" : "legacy");
 return ret;
 }
 return 0;
diff --git a/target/i386/hax-darwin.h b/target/i386/hax-darwin.h
index fb8e25a..51af0e8 100644
--- a/target/i386/hax-darwin.h
+++ b/target/i386/hax-darwin.h
@@ -44,6 +44,7 @@ static inline void hax_close_fd(hax_fd fd)
 #define HAX_VM_IOCTL_SET_RAM _IOWR(0, 0x82, struct hax_set_ram_info)
 #define HAX_VM_IOCTL_VCPU_DESTROY _IOW(0, 0x83, uint32_t)
 #define HAX_VM_IOCTL_NOTIFY_QEMU_VERSION _IOW(0, 0x84, struct hax_qemu_version)
+#define HAX_VM_IOCTL_ADD_RAMBLOCK _IOW(0, 0x85, struct hax_ramblock_info)
 
 #define HAX_VCPU_IOCTL_RUN  _IO(0, 0xc0)
 #define HAX_VCPU_IOCTL_SET_MSRS _IOWR(0, 0xc1, struct hax_msr_data)
diff --git a/target/i386/hax-i386.h b/target/i386/hax-i386.h
index 8ffe91f..6abc156 100644
--- a/target/i386/hax-i386.h
+++ b/target/i386/hax-i386.h
@@ -37,6 +37,7 @@ struct hax_state {
 uint32_t version;
 struct hax_vm *vm;
 uint64_t mem_quota;
+bool supports_64bit_ramblock;
 };
 
 #define HAX_MAX_VCPU 0x10
diff --git a/target/i386/hax-interface.h b/target/i386/hax-interface.h
index d141308..93d5fcb 100644
-

Re: [Qemu-devel] Debugging on HAXM

2018-04-12 Thread Yu Ning 
Sorry for the very late response.  I completely forgot to check this 
mailbox...  Adding my usual corporate email to the cc.


On 4/2/2018 10:20, Paolo Bonzini wrote:

On 01/04/2018 17:35, Alexandro Sanchez Bach wrote:

I've noticed that `gdb_breakpoint_insert` only considers KVM so far. My
question is: Has anyone planned adding debugging support to HAXM? Or is
anyone actively working on QEMU's HAXM frontend at all? If not, I would like
to work on it myself. Are there any guidelines or things I should take into
consideration to work on this accelerator (pinging Anthony and Glauber)?

The main person working on HAXM is Yu Ning.  Anthony and Glauber are
only listed because they are the authors of the KVM support (and HAXM
support in turn is based on KVM).


That is correct, and thanks Paolo for the introduction.  In fact I just 
reviewed a HAXM pull request from Alexandro on GitHub, so we know each 
other already.





Would it be more reasonable to add debugging support to HAXM [1] directly
instead of trying to use the existing APIs from QEMU to achieve the same
thing  (I was thinking in patching memory, e.g. with `hlt` instructions, to
trigger VM exits)?

That would probably be less "hackish", but harder too.  It would also
let you support singlestep and hardware breakpoints---they are often
better than software breakpoints for debugging if you can live with the
limit of four breakpoints.

Yu Ning, what do you think?


First of all, I think adding debugging support to HAXM is a great idea, 
and I really look forward to Alexandro's contribution.  But I only know 
the very basics of how breakpoints work, and I'm a little confused after 
reading your discussion.


I guess the "less hackish and harder" approach Paolo referred to is the 
KVM approach, not the patching-with-HLT approach.  If so, I'd agree.  It 
seems KVM implements software breakpoints with memory patching too, 
using the INT 3 instruction, which I think requires the hypervisor to 
handle breakpoint exceptions (#BP).  Is this the sole reason to patch 
with HLT instead of INT 3, to avoid handling #BP in HAXM or perhaps 
avoid modifying the HAXM kernel module at all?


Alexandro, I'm not sure what you mean by not using existing QEMU APIs.  
Surely you still need to add HAXM-specific logic to 
gdb_breakpoint_insert(), etc., otherwise you wouldn't be able to debug 
your guest using the QEMU gdbserver?  Finally, in case you need to add 
any new HAXM APIs, please feel free to propose a design on GitHub, and 
we can continue our discussion there.  Thanks.


-Yu

Re: [Qemu-devel] [PATCH] hax: Support guest RAM sizes of 4GB or more

2018-02-07 Thread Yu Ning 


On 2/7/2018 7:36, Paolo Bonzini wrote:


Queued, thanks.  Sorry for the delay!


That's okay, thanks!

Yu



Paolo

[Qemu-devel] New HAXM maintainer

2019-05-27 Thread Yu Ning 

Hello,

I am leaving Intel, and will soon lose access to my Intel email 
accounts. Effective today, I am no longer maintainer of the HAXM open 
source project (https://github.com/intel/haxm). Colin Xu (colin DOT xu 
AT intel DOT com) will take my place, and he will be helped by Henry 
Yuan (hang DOT yuan AT intel DOT com) as well as the rest of the HAXM 
team at Intel (team email: haxm DASH team AT intel DOT com).


I am grateful for all the support this community has given to HAXM and 
myself over the past few years. I would appreciate your continued 
support for the project and the Intel HAXM team.


Thanks,
Yu