On 9/18/25 23:40, Peter Xu wrote:
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.
So it seems it is not that useful anymore for upstream kernels
and downstream should have done the required backports.
Any blockers on this?
No.
If we could remove the workaround in QEMU, we would be able to
refactor some of the code unmapping DMAs to make it common
between the VFIO IOMMU Type1 and IOMMUFD backends.
Thanks,
C.
