On Tue, Jun 30, 2020 at 10:23:43PM +0100, Matthew Wilcox wrote: > On Tue, Jun 30, 2020 at 12:57:34PM -0700, Ralph Campbell wrote: > > hmm_range_fault() returns an array of page frame numbers and flags for > > how the pages are mapped in the requested process' page tables. The PFN > > can be used to get the struct page with hmm_pfn_to_page() and the page > > size order can be determined with compound_order(page) but if the page > > is larger than order 0 (PAGE_SIZE), there is no indication that a > > compound page is mapped by the CPU using a larger page size. Without > > this information, the caller can't safely use a large device PTE to map > > the compound page because the CPU might be using smaller PTEs with > > different read/write permissions. > > > > Add two new output flags to indicate the mapping size (PMD or PUD sized) > > so that callers know the pages are being mapped with consistent permissions > > and a large device page table mapping can be used if one is available. > > The problem I have with this is that PTE/PMD/PUD are not the only choices > for how the CPU might choose to map something. For example, ARM has > the ability to map 64kB pages using 16 consecutive page table entries > (marked specially so the CPU knows to use a single TLB entry for the > 64kB range). Some other CPUs have similar capabilities. Sure, but at the moment this is the only thing hmm_range_fault() is able to detect and set.. > I'd rather you encoded the order of the mapping in the flags (eg a > number between 0 and 31) so that we have the flexibility in the future > to describe how memory is mapped. How about some hmm_get_mapping_order() API, we can keep the flags that match the implementation but the driver facing API will see something more general? Jason
