diff options
author | Alex Williamson <alex.williamson@redhat.com> | 2016-10-31 09:53:03 -0600 |
---|---|---|
committer | Alex Williamson <alex.williamson@redhat.com> | 2016-10-31 09:53:03 -0600 |
commit | 24acf72b9a291cebfd05f2ecdf3a982ac01e6291 (patch) | |
tree | 5ea76fd6bcf3315aeaa58a4879158da32ffbad86 /tcg | |
parent | 4a2e242bbb306ef5c16ce9e7bb2da3bd8a4eb098 (diff) | |
download | qemu-24acf72b9a291cebfd05f2ecdf3a982ac01e6291.zip qemu-24acf72b9a291cebfd05f2ecdf3a982ac01e6291.tar.gz qemu-24acf72b9a291cebfd05f2ecdf3a982ac01e6291.tar.bz2 |
vfio: Handle zero-length sparse mmap ranges
As reported in the link below, user has a PCI device with a 4KB BAR
which contains the MSI-X table. This seems to hit a corner case in
the kernel where the region reports being mmap capable, but the sparse
mmap information reports a zero sized range. It's not entirely clear
that the kernel is incorrect in doing this, but regardless, we need
to handle it. To do this, fill our mmap array only with non-zero
sized sparse mmap entries and add an error return from the function
so we can tell the difference between nr_mmaps being zero based on
sparse mmap info vs lack of sparse mmap info.
NB, this doesn't actually change the behavior of the device, it only
removes the scary "Failed to mmap ... Performance may be slow" error
message. We cannot currently create an mmap over the MSI-X table.
Link: http://lists.nongnu.org/archive/html/qemu-discuss/2016-10/msg00009.html
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Diffstat (limited to 'tcg')
0 files changed, 0 insertions, 0 deletions