On 22.07.24 08:43, Yan Zhao wrote:
On Fri, Jul 19, 2024 at 10:28:09AM +0200, David Hildenbrand wrote:
On 19.07.24 01:18, Yan Zhao wrote:
On Thu, Jul 18, 2024 at 10:03:01AM -0400, Peter Xu wrote:
On Thu, Jul 18, 2024 at 09:50:31AM +0800, Yan Zhao wrote:
Ok. Then if we have two sets of pfns, then we can
1. Call remap_pfn_range() in mmap() for pfn set 1.
I don't think this will work.. At least from the current implementation,
remap_pfn_range() will only reserve the memtype if the range covers the
whole vma.
Hmm, by referring to pfn set 1 and pfn set 2, I mean that they're both
covering the entire vma, but at different times.
To make it more accurately:
Consider this hypothetical scenario (not the same as what's implemented in
vfio-pci, but seems plausible):
Suppose we have a vma covering only one page, then
(1) Initially, the vma is mapped to pfn1, with remap_pfn_range().
(2) Subsequently, unmap_single_vma() is invoked to unmap the entire VMA.
(3) The driver then maps the entire vma to pfn2 in fault handler
Given this context, my questions are:
1. How can we reserve the memory type for pfn2? Should we call
track_pfn_remap() in mmap() in advance?
2. How do we untrack the memory type for pfn1 and pfn2, considering they
belong to the same VMA but mutual exclusively and not concurrently?
Do we really have to support such changing PFNs in a VMA? Are there existing
use cases that would rely on that?
I don't know. But it's not disallowed.
Okay, but we don't know of any such use case.
What we do have is a single VMA, whereby within that VMA we place
various different PFN ranges. (randomly looking at
drivers/video/fbdev/smscufx.c)
These wouldn't have triggered VM_PAT code.
--
Cheers,
David / dhildenb
