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

[A223 A223]

On Wed, Oct 19, 2016 at 9:21 PM, A223 A223 <address@hidden> wrote:
> 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
> 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.

I just found your suggestions here:
https://www.redhat.com/archives/vfio-users/2016-May/msg00072.html
I will try these. I first need to get libvirt working -- it gave me a
lot of trouble last time I tried.
Thanks, Andrew