On Thu, Sep 18, 2025 at 10:55:47PM +0200, Cédric Le Goater wrote: > Alex, Peter, > > On 1/10/19 00:10, Alex Williamson wrote: > > A kernel bug was introduced in v4.15 via commit 71a7d3d78e3c which > > adds a test for address space wrap-around in the vfio DMA unmap path. > > Unfortunately due to overflow, the kernel detects an unmap of the last > > page in the 64-bit address space as a wrap-around. In QEMU, a Q35 > > guest with VT-d emulation and guest IOMMU enabled will attempt to make > > such an unmap request during VM system reset, triggering an error: > > > > qemu-kvm: VFIO_UNMAP_DMA: -22 > > qemu-kvm: vfio_dma_unmap(0x561f059948f0, 0xfef00000, 0xffffffff01100000) > > = -22 (Invalid argument) > > > > Here the IOVA start address (0xfef00000) and the size parameter > > (0xffffffff01100000) add to exactly 2^64, triggering the bug. A > > kernel fix is queued for the Linux v5.0 release to address this. > > > > This patch implements a workaround to retry the unmap, excluding the > > final page of the range when we detect an unmap failing which matches > > the requirements for this issue. This is expected to be a safe and > > complete workaround as the VT-d address space does not extend to the > > full 64-bit space and therefore the last page should never be mapped. > > > > This workaround can be removed once all kernels with this bug are > > sufficiently deprecated. > > Have we waited long enough ? what does "sufficiently deprecated" mean ? > Is it related to the linux stable updates ?
Alex might be the best to define it. To me, it doesn't sound a major issue to have it even forever just in case someone was using a broken v4.15..v5.0 kernel. It's pretty small, limited and self contained workaround. Any blockers on this? Thanks, -- Peter Xu
