From f2e7dde5a79fd1778c9049d2fc7864621df703b9 Mon Sep 17 00:00:00 2001 From: David Gibson Date: Wed, 30 Sep 2015 06:43:13 +0200 Subject: [PATCH 05/10] memory: Allow replay of IOMMU mapping notifications Message-id: <1443595398-20898-6-git-send-email-dgibson@redhat.com> Patchwork-id: 67989 O-Subject: [RHEL7.2 qemu-kvm-rhev PATCHv4 05/10] memory: Allow replay of IOMMU mapping notifications Bugzilla: 1259556 RH-Acked-by: Alex Williamson RH-Acked-by: Laurent Vivier RH-Acked-by: Thomas Huth When we have guest visible IOMMUs, we allow notifiers to be registered which will be informed of all changes to IOMMU mappings. This is used by vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings. However, unlike with a memory region listener, an iommu notifier won't be told about any mappings which already exist in the (guest) IOMMU at the time it is registered. This can cause problems if hotplugging a VFIO device onto a guest bus which had existing guest IOMMU mappings, but didn't previously have an VFIO devices (and hence no host IOMMU mappings). This adds a memory_region_iommu_replay() function to handle this case. It replays any existing mappings in an IOMMU memory region to a specified notifier. Because the IOMMU memory region doesn't internally remember the granularity of the guest IOMMU it has a small hack where the caller must specify a granularity at which to replay mappings. If there are finer mappings in the guest IOMMU these will be reported in the iotlb structures passed to the notifier which it must handle (probably causing it to flag an error). This isn't new - the VFIO iommu notifier must already handle notifications about guest IOMMU mappings too short for it to represent in the host IOMMU. Signed-off-by: David Gibson Upstream: a788f227ef7bd2912fcaacdfe13d13ece2998149 Signed-off-by: David Gibson Signed-off-by: Miroslav Rezanina --- include/exec/memory.h | 13 +++++++++++++ memory.c | 20 ++++++++++++++++++++ 2 files changed, 33 insertions(+) diff --git a/include/exec/memory.h b/include/exec/memory.h index 0ccfd3b..b037abb 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -572,6 +572,19 @@ void memory_region_notify_iommu(MemoryRegion *mr, void memory_region_register_iommu_notifier(MemoryRegion *mr, Notifier *n); /** + * memory_region_iommu_replay: replay existing IOMMU translations to + * a notifier + * + * @mr: the memory region to observe + * @n: the notifier to which to replay iommu mappings + * @granularity: Minimum page granularity to replay notifications for + * @is_write: Whether to treat the replay as a translate "write" + * through the iommu + */ +void memory_region_iommu_replay(MemoryRegion *mr, Notifier *n, + hwaddr granularity, bool is_write); + +/** * memory_region_unregister_iommu_notifier: unregister a notifier for * changes to IOMMU translation entries. * diff --git a/memory.c b/memory.c index 0717005..7de38a5 100644 --- a/memory.c +++ b/memory.c @@ -1402,6 +1402,26 @@ void memory_region_register_iommu_notifier(MemoryRegion *mr, Notifier *n) notifier_list_add(&mr->iommu_notify, n); } +void memory_region_iommu_replay(MemoryRegion *mr, Notifier *n, + hwaddr granularity, bool is_write) +{ + hwaddr addr; + IOMMUTLBEntry iotlb; + + for (addr = 0; addr < memory_region_size(mr); addr += granularity) { + iotlb = mr->iommu_ops->translate(mr, addr, is_write); + if (iotlb.perm != IOMMU_NONE) { + n->notify(n, &iotlb); + } + + /* if (2^64 - MR size) < granularity, it's possible to get an + * infinite loop here. This should catch such a wraparound */ + if ((addr + granularity) < addr) { + break; + } + } +} + void memory_region_unregister_iommu_notifier(Notifier *n) { notifier_remove(n); -- 1.8.3.1