On 12.06.25 06:34, Dan Williams wrote:
David Hildenbrand wrote:
We setup the cache mode but ... don't forward the updated pgprot to
insert_pfn_pud().
Only a problem on x86-64 PAT when mapping PFNs using PUDs that
require a special cachemode.
This is only a problem if the kernel mapped the pud in advance of userspace
mapping it, right?
Good question, PAT code is confusing.
What I understood is that drivers like vfio will register the range with
the expected cachemode, and then rely on vm_insert_* to fill out the
cachemode for them.
Peter explained it in the dicussion here [1] how e.g., vfio triggers
that early registration.
Regarding vfio, I can see that we do in vfio_pci_core_mmap()
unconditionally:
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
and probably rely on us querying the actual cachemode to be used later.
vfio can map all kinds of different memory types ...
[1] https://lkml.kernel.org/r/aBDXr-Qp4z0tS50P@x1.local
The change looks good.
Reviewed-by: Dan Williams <dan.j.willi...@intel.com>
...but I am struggling with the scenario where this causes problems in
practice, where vm_page_prot is the wrong cachemode.
Yeah, it's all confusing.
But as long as we don't conclude that pfnmap_setup_cachemode_pfn() can
be removed entirely (esp. also from pte / pmd case), this seems to be
the right thing to do and was accidental change in the introducing commit.
Is it actually stable material? I don't know, but possibly getting
cachemodes wrongs sounds ... bad?
--
Cheers,
David / dhildenb
