On Tue, Jan 14, 2025 at 11:13:48PM +0000, Ankit Agrawal wrote: > > Do we really want another weirdly defined VMA flag? I'd really like to > > avoid this.. > > I'd let Catalin chime in on this. My take of the reason for his suggestion is > that we want to reduce the affected configs to only the NVIDIA grace based > systems. The nvgrace-gpu module would be setting the flag and the > new codepath will only be applicable there. Or am I missing something here? We cannot add VMA flags that are not clearly defined. The rules for when the VMA creater should set the flag need to be extermely clear and well defined. > > Can't we do a "this is a weird VM_PFNMAP thing, let's consult the VMA > > prot + whatever PFN information to find out if it is weird-device and > > how we could safely map it?" > > My understanding was that the new suggested flag VM_FORCE_CACHED > was essentially to represent "whatever PFN information to find out if it is > weird-device". Is there an alternate reliable check to figure this out? For instance FORCE_CACHED makes no sense, how will the VMA creator know it should set this flag? > Currently in the patch we check the following. So Jason, is the suggestion that > we simply return error to forbid such condition if VM_PFNMAP is set? > + else if (!mte_allowed && kvm_has_mte(kvm)) I really don't know enought about mte, but I would take the position that VM_PFNMAP does not support MTE, and maybe it is even any VMA without VM_MTE/_ALLOWED does not support MTE? At least it makes alost more sense for the VMA creator to indicate positively that the underlying HW supports MTE. Jason
