On Mon, May 12, 2025 at 10:02:16AM +0200, David Hildenbrand wrote:
> 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 <[email protected]>
> 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 <[email protected]>
> Reviewed-by: Peter Xu <[email protected]>
> Reviewed-by: Juan Quintela <[email protected]>
> Acked-by: Jason Wang <[email protected]>
> Message-Id: <[email protected]>
> Reviewed-by: Michael S. Tsirkin <[email protected]>
> Signed-off-by: Michael S. Tsirkin <[email protected]>
>
>
> I think this change here is fine, but it would be good getting Pete Xu's
> opinion.
Agree, that could be an old sanity check only when it used to be guranteed.
>
> Acked-by: David Hildenbrand <[email protected]>
Acked-by: Peter Xu <[email protected]>
--
Peter Xu
