summaryrefslogtreecommitdiff
path: root/hw/misc
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2014-01-16 09:22:07 -0700
committerAlex Williamson <alex.williamson@redhat.com>2014-01-16 09:22:07 -0700
commitd3a2fd9b29e43e202315d5e99399b99622469c4a (patch)
tree290b0c3d589f75a8dff793688bd715b9e1b00352 /hw/misc
parente638073c569e801ce9def2016a84f955cbbca779 (diff)
downloadqemu-d3a2fd9b29e43e202315d5e99399b99622469c4a.zip
vfio: Filter out bogus mappings
Since 57271d63 we now see spurious mappings with the upper bits set if 64bit PCI BARs are sized while enabled. The guest writes a mask of 0xffffffff to the lower BAR to size it, then restores it, then writes the same mask to the upper BAR resulting in a spurious BAR mapping into the last 4G of the 64bit address space. Most architectures do not support or make use of the full 64bits address space for PCI BARs, so we filter out mappings with the high bit set. Long term, we probably need to think about vfio telling us the address width limitations of the IOMMU. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'hw/misc')
-rw-r--r--hw/misc/vfio.c9
1 files changed, 8 insertions, 1 deletions
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 30b1a78f9c..d304213bf1 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -2156,7 +2156,14 @@ static int vfio_dma_map(VFIOContainer *container, hwaddr iova,
static bool vfio_listener_skipped_section(MemoryRegionSection *section)
{
- return !memory_region_is_ram(section->mr);
+ return !memory_region_is_ram(section->mr) ||
+ /*
+ * Sizing an enabled 64-bit BAR can cause spurious mappings to
+ * addresses in the upper part of the 64-bit address space. These
+ * are never accessed by the CPU and beyond the address width of
+ * some IOMMU hardware. TODO: VFIO should tell us the IOMMU width.
+ */
+ section->offset_within_address_space & (1ULL << 63);
}
static void vfio_listener_region_add(MemoryListener *listener,