[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: A223 A223
Subject: Re: [Qemu-discuss] How to resolve "Failed to mmap" error?
Date: Wed, 19 Oct 2016 11:06:09 -0700

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]