On Fri, Sep 25, 2020 at 05:25:11PM +0200, Alexander Potapenko wrote: > Will, > > > Given that the pool is relatively small (i.e. when compared with our virtual > > address space), dedicating an area of virtual space sounds like it makes > > the most sense here. How early do you need it to be available? > > How do we assign struct pages to a fixed virtual space area (I'm > currently experimenting with 0xffff7f0000000000-0xffff7f0000200000)? You don't. There should be a struct page for each of the /physical/ pages, and these can be found: * via the physical address, using phyts_to_page() or pfn_to_page() * via the linear/direct map, using virt_to_page() * via the vmalloc page tables using vmalloc_to_page() If you need virt_to_page() to work, the address has to be part of the linear/direct map. If you need to find the struct page for something that's part of the kernel image you can use virt_to_page(lm_alias(x)). > Looks like filling page table entries (similarly to what's being done > in arch/arm64/mm/kasan_init.c) is not enough. > I thought maybe vmemmap_populate() would do the job, but it didn't > (virt_to_pfn() still returns invalid PFNs). As above, I think lm_alias() will solve the problem here. Please see that and CONFIG_DEBUG_VIRTUAL. Thanks, Mark.
