ANBZ: #4688
According to commit bf4ff7699135 ("anolis: sw64: iommu: work around iova
range check after resv_region"), the current map/unmap strategy will
directly return success, without doing real map when application
trying to use IOVA in 3.5G~4G.
This solved the problem of passing IOVA check on initiating certain
application, but what we do not expect is that VFIO will still pin
the physical memory pages for these IOVA (in 3.5~4G). It seems to work
fine during normal using. But when it comes to unmap/unpin, as VFIO
cannot find the related physical pfns through mapping tables, (because
we did not actually map them!), it will cause a 512M physical memory
leak after application exits.
The current strategy is to do real mappings for these IOVA. As for
possible collisions, we rely on OS to not initiate access requests
in this range.
Fixes: bf4ff7699135 ("anolis: sw64: iommu: work around iova range check after
resv_region")
Signed-off-by: Xu Yiwei <xuyiwei@wxiat.com>
Reviewed-by: He Sheng <hesheng@wxiat.com>
Signed-off-by: Gu Zitao <guzitao@wxiat.com>
Reviewed-by: Min Li <gumi@linux.alibaba.com>
Link: https://gitee.com/anolis/cloud-kernel/pulls/5372
f32648b9f7