On Thu, Nov 17, 2016 at 12:09 PM, Vincent Palatin <vpala...@chromium.org> wrote: > On Mon, Nov 14, 2016 at 2:09 PM, Vincent Palatin <vpala...@chromium.org> > wrote: >> On Mon, Nov 14, 2016 at 1:36 PM, Stefan Weil <s...@weilnetz.de> 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 >>>
