On Tue, 11 Apr 2023 at 04:48, John Hubbard <jhubbard@xxxxxxxxxx> wrote: > > On 4/10/23 00:39, John Hubbard wrote: > >> pfn_to_page(x) for values 0xc00_0000 < x < 0x1000_0000 will produce a > >> kernel VA that points outside the region set aside for the vmemmap. > >> This region is currently unused, but that will likely change soon. > >> > > > > I tentatively think I'm in this case right now. Because there is no wrap > > around happening in my particular config, which is CONFIG_ARM64_VA_BITS > > == 48, and PAGE_SIZE == 4KB and sizeof(struct page) == 64 (details > > below). > > > > Correction, actually it *is* wrapping around, and ending up as a bogus > user space address, as you said it would when being above the range: > > page_to_pfn(0xffffffffaee00000): 0x0000000ffec38000 > Interesting. > > > It occurs to me that ZONE_DEVICE and (within that category) device > > private page support need only support rather large setups. On x86, it > > requires 64-bit. And on arm64, from what I'm learning after a day or so > > of looking around and comparing, I think we must require at least 48 bit > > VA support. Otherwise there's just no room for things. > > I'm still not sure of how to make room, but working on it. > The assumption that only the linear map needs to be covered by struct pages is rather fundamental to the arm64 mm code, as far as I am aware. Given that these device memory regions have no direct correspondence with the linear map at all, couldn't we simply vmalloc() a range of memory for struct pages for such a region and wire that up in the existing code? That seems far more maintainable to me than reorganizing the entire kernel VA space, and only for some choices for the dimensions.
