Hello.
I want to map a single memory page twice to two different virtual addresses with different attributes within a single address space. In particular (for testing purposes) I want to have a piece of memory that is accessible as cacheable and non-cacheable region at different addresses.
How can I make this happen? Is this even possible with existing API?
Hello Dmitry,
thanks for your interest in Genode and welcome to the mailing list!
I want to map a single memory page twice to two different virtual addresses with different attributes within a single address space. In particular (for testing purposes) I want to have a piece of memory that is accessible as cacheable and non-cacheable region at different addresses.
That would open a nasty can of worms. The behavior of the cache is "undefined" when a same physical page is mapped with different caching attributes. This is exactly what we are observing right now. Since core receives physical memory from sigma0 always as cached memory, we implicitly create such an inconsistency when mapping memory as uncached outside of core (when creating a DMA buffer via 'Ram_session::alloc' with the 'cached' argument set to false). In theory, if core never touches the memory, this may be fine (actually this is the solution suggested by Adam Lackorzynski on the L4 hackers mailing list). However, core needs to touch the memory in order to clear it before handing it out. Consequently, we inevitably run into the problem.
Because we think that this inconsistency is the key problem for the weird cache behaviour that we see (i.e., with our OMAP4 HDMI driver with L2 cache enabled), we are currently trying to find a way to avoid this inconsistency altogether.
In short: Your idea is dangerous. I recommend to not even try that.
How can I make this happen? Is this even possible with existing API?
The Genode API has not such means. The Fiasco.OC kernel principally allows changing the caching attributes when mapping a page via a flexpage mapping (e.g., as map item supplied to the IPC mechanism). So in principle, you could use the kernel interface directly. But I would recommend not to go that route because of the dangers outlined above.
Cheers Norman