Re: [Qemu-discuss] How to resolve "Failed to mmap" error?

[A223 A223]

Okay, I've enabled intremap=no_x2apic_optout on the host kernel and
didn't see much of a change in performance.
I feel I should mention that the qemu process on the host consumes
about 8-30% CPU (as shown in top) when the guest (Windows 10) task
manager shows <1.0% cpu utilization. More often than not, it is >15%.
Is this normal?
Presuming this is interrupt handling, I've tried:
Enabling hv_apic
Disabling hv_apic (No idea which is faster [hv_apic on or off] -- I've
read seemingly contradictory reports online)
Adding intremap=no_x2apic_optout to my host's kernel options (x2apic
is now enabled on the host according to my dmesg output).
CPU usage for the qemu process always hovers in that range on the host.

More details on what I'm trying to do, here:
I'm trying to see if qemu/kvm + passthrough is viable for low latency
/ high bandwidth USB applications such as cameras, sensors, etc.
Specifically I've been trying to get an Oculus Rift VR headset and
sensor working under this configuration. I can certainly see the CPU
utilization shoot right up to 60-80% on the host qemu process when I
plug the sensor into the USB port, and I get poor performance from the
device (they're reported as dropped / truncated USB frames in the
guest application). I just tried passing through an NEC / Renesas USB
controller and had the same issue. I've also tried passing through the
built-in Intel USB controller with similar results. Running
bare-metal, things work fine.

At this point, unless you or someone else has some bright ideas on how
I might decrease the load when the interrupt rate is very high, I will
probably throw in the towel on this effort until I can upgrade my
hardware to something that supports APICv or similar.

I'm going to attach my dmesg output in case it is of any use.

Thanks for all your help.


On Wed, Oct 19, 2016 at 12:35 PM, A223 A223 <address@hidden> wrote:
> On Wednesday, October 19, 2016, A223 A223 <address@hidden> wrote:
>>
>> On Mon, Oct 17, 2016 at 10:24 PM, Alex Williamson
>> <address@hidden> wrote:
>> > I picked up a card based on the same Fresco FL1100 (rev 10) chip, I
>> > don't think it needs the no-bus-reset quirk above, resets seem to work
>> > fine for me.  In fact the card works as expected with the previous
>> > patch I sent, no warning about mmaps.
>>
>> Thanks for giving that a shot.
>> Yeah, I had the same result -- no warnings about mmaps once I applied
>> your patch. I did encounter those lockups on the host, but it's still
>> too hard for me to say whether that was related to your patch, because
>> my sample size was way to small as I mentioned.
>>
>> > There's no performance loss due
>> > to the mapping of the MSI-X table BAR with or without that patch, that
>> > BAR seems to only be used for MSI-X and nothing changes once setup, at
>> > least with modern versions of Linux as the guest.  Tracing shows
>> > absolutely no traps through QEMU once it's setup.  The device does run
>> > at a high interrupt rate, which I expect is the primary source of
>> > performance loss when running in a VM.  Hardware solutions like APICv
>> > and Posted Interrupts should close that gap.
>>
>> Also, just to be clear, I'm using a Windows guest, so perhaps the
>> guest is doing something out-of-line?
>>
>> I also have a couple of other questions about this if you don't mind:
>> Will most USB 3.0 controllers run at a high interrupt rate, or is that
>> unique to certain controllers such as this one? I'm planning to try an
>> NEC chip soon as well, so I'm hoping that may be better.
>> It appears that APICv is only available on Ivy Bridge E* chips, is
>> that correct? I wasn't able to find which processors support posted
>> interrupts. If you know offhand, please let me know. I will have to
>> keep all of this in mind for my next hardware upgrade.
>>
>> > What you're seeing above still suggests to me that the device is not
>> > returning from a bus reset, all reads from the device are returning
>> > -1.  Since I'm unable to reproduce with my card, it would seem to imply
>> > that the problem is not an intrinsic issue with the controller chip
>> > itself.  Are you overclocking in any way?  Thanks,
>>
>> No overclocking, here. I'm going to give all of this another try this
>> week sometime and see if I can find any other clues. I'll let you know
>> what happens. Thanks, Andrew
>
>
> In doing some more research about apicv and related topics, I came to find
> this in my host's dmesg:
>
>  [    0.025739] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out
> bit.
> [    0.025749] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS
> setting.
> [    0.025957] x2apic: IRQ remapping doesn't support X2APIC mode
>
> I assume then that it's falling back to (slower?) xAPIC. Could this be a
> cause for my poor performance? Should I try overriding this with the kernel
> param? I'm running a Haswell chip on a Z97 chipset. I'm under the impression
> tha x2apic was broken on far older chipsets running nehalem and they got a
> little overzealous with the blacklisting... So I should probably be fine
> overriding? Thanks, Andrew

dmesg.txt
Description: Text document