Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support

[Vincent Palatin]

On Mon, Nov 14, 2016 at 2:09 PM, Vincent Palatin <address@hidden> wrote:
> On Mon, Nov 14, 2016 at 1:36 PM, Stefan Weil <address@hidden> 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 (and I don't have much clues, maybe related to the
second bug described below ?).
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
>>