On 02.05.25 04:15, Alejandro Jimenez wrote:
Invalidating the entire address space (i.e. range of [0, ~0ULL]) is a
valid and required operation by vIOMMU implementations. However, such
invalidations currently trigger an assertion unless they originate from
device IOTLB invalidations.
Although in recent Linux guests this case is not exercised by the VTD
implementation due to various optimizations, the assertion will be hit
by upcoming AMD vIOMMU changes to support DMA address translation. More
specifically, when running a Linux guest with VFIO passthrough device,
and a kernel that does not contain commmit 3f2571fed2fa ("iommu/amd:
Remove redundant domain flush from attach_device()").
Remove the assertion altogether and adjust the range to ensure it does
not cross notifier boundaries.
Looking at the history, we used to have the assert unconditionally, and
made it specific to IOMMU_NOTIFIER_DEVIOTLB_UNMAP in
commit 1804857f19f612f6907832e35599cdb51d4ec764
Author: Eugenio Pérez <epere...@redhat.com>
Date: Mon Nov 16 17:55:06 2020 +0100
memory: Skip bad range assertion if notifier is DEVIOTLB_UNMAP type
Device IOTLB invalidations can unmap arbitrary ranges, eiter outside of
the memory region or even [0, ~0ULL] for all the space. The assertion
could be hit by a guest, and rhel7 guest effectively hit it.
Signed-off-by: Eugenio Pérez <epere...@redhat.com>
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Juan Quintela <quint...@redhat.com>
Acked-by: Jason Wang <jasow...@redhat.com>
Message-Id: <20201116165506.31315-6-epere...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
I think this change here is fine, but it would be good getting Pete Xu's
opinion.
Acked-by: David Hildenbrand <da...@redhat.com>
--
Cheers,
David / dhildenb
