When paging is enabled and an exception occurs does a translation table walk occur to access the exception vector table at address 0x00000000?
When paging is enabled and an exception occurs does a translation table walk occur to access the exception vector table at address 0x00000000?
Almost all ARM CPUs have a means to configure the exception table address. So in most systems, the exception vector table is not at address 0x00000000. However, the MMU is enabled when exceptions are taken. The TLB (an MMU/page table cache) will contain the vector table physical address.
In some SOCs the boot vector table maybe at 0x0, but this is usually reconfigured by the boot code.
- If paging is still enabled then how do user mode processes and the vector table both share address 0x00000000 - the TTBR (translation table base register) does not get updated on exception entry and the TTBR is not a banked register (we are not talking here about switching between secure and non-secure worlds).
If you want the vector table at address 0x00000000, then it is what user space will see unless you prohibit it. Prohibiting access to 0x0 maybe a desired design to prevent NULL pointer use. Many OSes do not have user space run from 0x0, but an address like 0x8000.
Having user space fault based on a parameter can be very useful as you can trap NULL pointer access while a process is being developed. I would recommend always leaving this on, but some people allow NULL access for production code.
- If no then we must enter exceptions using physical addressing in which case is paging now disabled?
No paging is enabled as the cache is probably on as well. The load/store unit of the CPU would be more complex if some accesses are physical and others are virtual; especially as caches are populated by a virtual address in traditional ARM CPUs.