On Mon, 5 Oct 2020 14:57:15 +0200 Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > On 2020-10-05 14:35, Claudio Imbrenda wrote: > > On Mon, 5 Oct 2020 13:54:42 +0200 > > Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > > > > [...] > > > >> While doing a page allocator, the topology is not the only > >> characteristic we may need to specify. > >> Specific page characteristics like rights, access flags, cache > >> behavior may be useful when testing I/O for some architectures. > >> This obviously will need some connection to the MMU handling. > >> > >> Wouldn't it be interesting to use a bitmap flag as argument to > >> page_alloc() to define separate regions, even if the connection > >> with the MMU is done in a future series? > > > > the physical allocator is only concerned with the physical pages. if > > you need special MMU flags to be set, then you should enable the MMU > > and fiddle with the flags and settings yourself. > > > > AFAIU the page_allocator() works on virtual addresses if the MMU has > been initialized. no, it still works on physical addresses, which happen to be identity mapped by the MMU. don't forget that the page tables are themselves allocated with the page allocator. > Considering that more and more tests will enable the MMU by default, > eventually with a simple logical mapping, it seems to me that having > the possibility to give the page allocator more information about the > page access configuration could be interesting. I disagree. I think we should not violate the layering here. > I find that using two different interfaces, both related to memory > handling, to have a proper memory configuration for an I/O page may > be complicated without some way to link page allocator and MMU tables > together. If you want to allocate an identity mapped page and also change its properties at the same time, you can always write a wrapper. keep the page allocator working only on physical addresses, add a function to change the properties of the mapping, and add a wrapper for the two.
