From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7gdE-0008Pf-Py for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:42:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7gdD-0006c1-KR for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:42:56 -0500 Received: from mail-it0-x22c.google.com ([2607:f8b0:4001:c0b::22c]:36128) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c7gdD-0006bT-B2 for qemu-devel@nongnu.org; Fri, 18 Nov 2016 05:42:55 -0500 Received: by mail-it0-x22c.google.com with SMTP id l8so20902627iti.1 for ; Fri, 18 Nov 2016 02:42:55 -0800 (PST) MIME-Version: 1.0 Sender: vpalatin@google.com In-Reply-To: References: <174f2d59-636d-9a25-eb46-47c30b7125e3@weilnetz.de> From: Vincent Palatin Date: Fri, 18 Nov 2016 11:42:33 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel On Thu, Nov 17, 2016 at 12:09 PM, Vincent Palatin wrote: > On Mon, Nov 14, 2016 at 2:09 PM, Vincent Palatin wrote: >> On Mon, Nov 14, 2016 at 1:36 PM, Stefan Weil wrote: >>> Am 11.11.2016 um 12:28 schrieb Vincent Palatin: >>> [...] >>>> 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 >> >> 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 It seems I mis-read my earlier traces, this is likely due to the fact that the option ROM is doing those MMIO in 'real 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. > >> >>> >>> 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 >>>