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

[Vincent Palatin <vpalatin@chromium.org>]

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