Hello Michael,
On Tue, Oct 25, 2022 at 03:24:01PM +0200, Michael Grunditz wrote:
Indeed, it would be good to instrument all occurrences of `throw` within the page-table implementation for ARMv8. It shares the implementation with ARMv7 Large Physical Address Extension support defined within the following header:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/include/h...
Regards Stefan
I also notice that alloc add
https://github.com/genodelabs/genode/blob/8ece2366354c941ad2206f3d511cd75a10... allways allocs a bigger amount out ram than I have in my ram declariation. If I increse my size it adds more. Why? Does it add image size to ram size?
Just an alignment problem .. if I align my mem ,, it stays. But it doesn't help for the insert of region for loading elf objects.
And then the switch to el1.. still trying to find out the difference in cpu core that maskes that to fail, if it isn't ram related.
Did you instrumented all occurrences of `throw` inside the page-table header, like I've suggested? Exception handling does not function at this very early time. At this early stage usage of the page-table API always needs to be cooperativly in the sense that you're not allowed to double-insert, insert mis-aligned mappings, nor exceed the page-table memory. I expect that a C++ exception is the reason for your stall here. To find out what is going on, you should instrument that first.
It doesn't make sense to try to step further, when the page-table isn't set up appropriatedly. A switch to another exception level is not constructive without a useful MMU setup. Before switching from EL2 to EL1, the MMU for EL2 gets enabled using the page-table that got set up formerly.
When looking at your insert_translation trace, I expect it contains all calls of insert_translation?! I recognized that there has no 1:1 mapping occurred, which is normaly the case before the core/kernel ELF is loaded. Without the 1:1 mapping it is clear that enabling the MMU will lead to a fault resp. stall of the machine.
Regards Stefan