I was having a look at the issue and realized there would need to be quite a lot of changes:
The current implementation relies on walk_mut to traverse the page table hierarchy and calls on_leaf at level 0. As we want to map superpages we would need to call this function earlier. If we are only performing translation we can get away by checking if the attributes of the PTE match Mode::ENTRY_FLAGS_LEAF. This is not going to work when we first map the page and we would need to pass additional context to force walk_mut to call on_leaf early. This could be fixed by either passing a level at which we want to stop our walk or not use the walk function at all. The latter would probably have better performance as it doesn't require us to walk the page tables every time.

Just wanted to have your opinion before hacking away.

First off: heya ✌️
second: yeah what you're saying sounds about right. Thinking ahead we'll definitely benefit from being able the explicitly specify the level to map at (e.g. for wasm linear memories we'll always map 6gib slots)
if you can find a way to do this without having to recursively walk the page table every time even better!

also: the current mapping code is a bit overengineered bc I thought we'd need to support mutating the page table tree which turns out we don't really, so dont hesitate to do bigger sweeping changes if thats needed for faster mapping, no one is emotionally attached to that code :)

Finally managed to work on superpage support.
I implemented the algorithm that splits a memory region into a region that is mappable with a superpage (in this case a 1GiB or 2MiB page) and 2 optional padding regions as part of the map_range function.

Unfortunately the virtual and physical memory regions used to call map_range from map_physical_memory are not at the same offset from a superpage, meaning they can only be mapped with 4K pages. This is because both the physical and virtual addresses have to be correctly aligned.
A (stupid) example could be physical memory 0x0..0x1000000 (which is aligned on 2MiB boundary) and virtual memory 0x1000..0x1001000 (0x1000 offset from 2MiB boundary).

This could be fixed in map_physical_memory by breaking up the physical memory and having multiple mappings. Continuing the example above we would map virtual 0x1000...0x1000000 to physical 0x1000..0x1000000 and virtual 0x1000000..0x1001000 to physical 0x0..0x1000.

Is there any other way to make this work? If not, are there any downsides to this approach?

Hey @alegnani that seems like a totally suitable solution to me, but tbh I don't fully grasp the nuances from just a description so feel free to open a pull request and we could discuss there further ;) at the same time, I have been working on a different implementation in the meantime (bc it was blocking more useful higher level virtmem features) and came up with this #158 (specifically this