From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4AR2-0006YG-S5 for qemu-devel@nongnu.org; Tue, 08 Nov 2016 12:43:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4AQz-0006D3-O5 for qemu-devel@nongnu.org; Tue, 08 Nov 2016 12:43:48 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:35478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4AQz-0006C0-HA for qemu-devel@nongnu.org; Tue, 08 Nov 2016 12:43:45 -0500 Received: by mail-wm0-x241.google.com with SMTP id a20so13331092wme.2 for ; Tue, 08 Nov 2016 09:43:45 -0800 (PST) Sender: Paolo Bonzini References: From: Paolo Bonzini Message-ID: <5a5399c5-a8bb-bfcb-8bc5-8aaad9749aa0@redhat.com> Date: Tue, 8 Nov 2016 18:43:42 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/3] [RFC] Add HAX support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vincent Palatin , qemu-devel On 08/11/2016 16:39, 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 mostly unmodified from > there, I just did some minor touch up to make it build and run properly. > So it might contain some outdated constructs and probably requires more > attention (thus the 'RFC' for this patchset). Does HAXM support the "unrestricted guest" feature in Westmere and more recent processors? If so, I think we should only support those processors and slash all the part related to HAX_EMULATE_STATE_INITIAL and HAX_EMULATE_STATE_REAL. This would probably let us make patch 3 much less intrusive. That said, patch 3's cpu-exec.c surgery is much nicer on the surface than if you look in depth, :) and since you don't look in depth if you steer clear of target-i386/hax*, I think it's okay to start with your patches and clean up progressively. Others may disagree... Also, we're now in soft freeze so the patches wouldn't be merged anyway for a few weeks. Paolo