On 27/2/26 02:04, Jason Gunthorpe wrote:
On Thu, Feb 26, 2026 at 10:11:56AM +1100, Alexey Kardashevskiy wrote:
The flow would be some thing like..
1) Create an IOAS
2) Create a HWPT. If there is some known upper bound on RMP/etc page
size then limit the HWPT page size to the upper bound
3) Map stuff into the ioas
4) Build the RMP/etc and map ranges of page granularity
5) Call iommufd to adjust the page size within ranges
I am about to try this approach now. 5) means splitting bigger pages
to smaller and I remember you working on that hitless IO PDEs
smashing, do you have something to play with? I could not spot
anything on github but do not want to reinvent. Thanks,
I thought this thread had concluded you needed to use the HW engines
The HW engine has to be used for smashing while DMAing to 2M page being smashed.
It is not needed when the insecure->trusted switch happens and IOMMU now needs
to match already configured RMP.
for this and if so then KVM should maintain the IOMMU S2 where it can
synchronize things and access the HW engines?
I want to explore the idea of using the gmemfd->iommufd notification mechanism
for smashing too (as these smashes are always the result of page state changes and
this requires a notification on its own as we figured out) and plumb that HW
engine to the IOMMU side, somewhere in the AMD IOMMU driver. Hard to imagine KVM
learning about IOMMU.
My draft for cut is here:
https://github.com/jgunthorpe/linux/commits/iommu_pt_all/
iommupt: Add cut_mapping op
Thanks!
--
Alexey
