On Tue, Nov 8, 2016 at 6:43 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > 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?
Yes it does, as mentioned in the last paragraph of my message, I have actually done a fair chunk of my testing in UG mode. > > 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. Sure the whole patchset would be lighter, not sure which proportion of user have VT machines without UG support though. > > 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
