summaryrefslogtreecommitdiffstats
path: root/include/hw/vfio
diff options
context:
space:
mode:
authorDavid Gibson2015-09-30 04:13:53 +0200
committerAlex Williamson2015-10-05 20:38:13 +0200
commit3898aad323475cf19127d9fc0846954d591d8e11 (patch)
treebe2a263e3a51f1bf162996c4427d36e3ad81fb77 /include/hw/vfio
parentvfio: Generalize vfio_listener_region_add failure path (diff)
downloadqemu-3898aad323475cf19127d9fc0846954d591d8e11.tar.gz
qemu-3898aad323475cf19127d9fc0846954d591d8e11.tar.xz
qemu-3898aad323475cf19127d9fc0846954d591d8e11.zip
vfio: Check guest IOVA ranges against host IOMMU capabilities
The current vfio core code assumes that the host IOMMU is capable of mapping any IOVA the guest wants to use to where we need. However, real IOMMUs generally only support translating a certain range of IOVAs (the "DMA window") not a full 64-bit address space. The common x86 IOMMUs support a wide enough range that guests are very unlikely to go beyond it in practice, however the IOMMU used on IBM Power machines - in the default configuration - supports only a much more limited IOVA range, usually 0..2GiB. If the guest attempts to set up an IOVA range that the host IOMMU can't map, qemu won't report an error until it actually attempts to map a bad IOVA. If guest RAM is being mapped directly into the IOMMU (i.e. no guest visible IOMMU) then this will show up very quickly. If there is a guest visible IOMMU, however, the problem might not show up until much later when the guest actually attempt to DMA with an IOVA the host can't handle. This patch adds a test so that we will detect earlier if the guest is attempting to use IOVA ranges that the host IOMMU won't be able to deal with. For now, we assume that "Type1" (x86) IOMMUs can support any IOVA, this is incorrect, but no worse than what we have already. We can't do better for now because the Type1 kernel interface doesn't tell us what IOVA range the IOMMU actually supports. For the Power "sPAPR TCE" IOMMU, however, we can retrieve the supported IOVA range and validate guest IOVA ranges against it, and this patch does so. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Diffstat (limited to 'include/hw/vfio')
-rw-r--r--include/hw/vfio/vfio-common.h6
1 files changed, 6 insertions, 0 deletions
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index fbbe6de9b3..27a14c0fd1 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -65,6 +65,12 @@ typedef struct VFIOContainer {
MemoryListener listener;
int error;
bool initialized;
+ /*
+ * This assumes the host IOMMU can support only a single
+ * contiguous IOVA window. We may need to generalize that in
+ * future
+ */
+ hwaddr min_iova, max_iova;
QLIST_HEAD(, VFIOGuestIOMMU) giommu_list;
QLIST_HEAD(, VFIOGroup) group_list;
QLIST_ENTRY(VFIOContainer) next;