On Tue, 11 Apr 2023 at 04:48, John Hubbard [off-list ref] wrote:

On 4/10/23 00:39, John Hubbard wrote:

quoted

quoted

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.

quoted

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.