On Wed, Feb 19, 2025 at 03:30:37PM -0600, Michael Roth wrote: > I think the documentation only mentioned 1G specifically since that's > the next level up in host/nested page table mappings, and that more > generally anything mapping at a higher granularity than 2MB would be > broken down into individual checks on each 2MB range within. But it's > quite possible things are handled differently for IOMMU so definitely > worth confirming. Hmm, well, I'd very much like it if we are all on the same page as to why the new kernel parameters were needed. Joerg was definitely seeing testing failures without them. IMHO we should not require parameters like that, I expect the kernel to fix this stuff on its own. > But regardless, we'll still end up dealing with 4K RMP entries since > we'll need to split 2MB RMP entries in response to private->conversions > that aren't 2MB aligned/sized. :( What is the point of even allowing < 2MP private/shared conversion? > > Then the HW will not see IOPTEs that exceed the shared/private > > granularity of the VM. > > That sounds very interesting. It would allow us to use larger IOMMU > mappings even for guest_memfd as it exists today, while still supporting > shared memory discard and avoiding the additional host memory usage > mentioned above. Are there patches available publicly? https://patch.msgid.link/r/0-v1-01fa10580981+1d-iommu_pt_jgg@xxxxxxxxxx I'm getting quite close to having something non-RFC that just does AMD and the bare minimum. I will add you two to the CC Jason
