On Fri, Jan 17, 2025 at 06:52:39PM +0000, Catalin Marinas wrote: > On Fri, Jan 17, 2025 at 10:00:50AM -0400, Jason Gunthorpe wrote: > > On Thu, Jan 16, 2025 at 10:28:48PM +0000, Catalin Marinas wrote: > > > with FEAT_MTE_PERM (patches from Aneesh on the list). Or, a bigger > > > happen, disable MTE in guests (well, not that big, not many platforms > > > supporting MTE, especially in the enterprise space). > > > > As above, it seems we already effectively disable MTE in guests to use > > VFIO. > > That's fine. Once the NoTagAccess feature gets in, we could allow MTE > here as well. Yes, we can eventually mark these pages as NoTagAccess and maybe someday consume a VMA flag from VFIO indicating that MTE works and NoTagAccess is not required. > I agree this is safe. My point was more generic about not allowing > cacheable mappings without some sanity check. Ankit's patch relies on > the pgprot used on the S1 mapping to make this decision. Presumably the > pgprot is set by the host driver. Yes, pgprot is set only by vfio, and pgprot == Normal is the sanity check for KVM. > > For this series it is only about mapping VMAs. Some future FD based > > mapping for CC is going to also need similar metadata.. I have another > > thread about that :) > > How soon would you need that and if you come up with a different > mechanism, shouldn't we unify them early rather than having two methods? Looks to me like a year and half or more to negotiate this and complete the required preperation patches. It is big and complex and consensus is not obviously converging.. If we had a FD flow now I'd prefer to use it than going through the VMA :( I have a vauge hope that perhaps KVM could see the VMA when it creates the memslot and then transparently pick up the FD under the VMA and switch to a singular FD based mode inside KVM. Jason
