1
votes

In most of ARM dual or multi core systems, the exception/vector table seems to be ONE and ONE ONLY -- @the typical 0x0000 or 0xffff0000 addresses. One exception(no pun intended :-) seems to be the cortex-M3, where there is a register VTOR ( for each core presumably) to have a variable/dynamic exception/vector table base address.

Whereas, the intel x86 multicore architecture supports multiple IDTs ( multiple IDTR registers for each individual core ).

So if we were to design a new OS(interrupt handling scheme), I find it a bit limiting that we cannot have different ISRs, for different cores, for a single exception ( say FIQ ) when the GIC interrupts the any one of the logical ARM cores

Of course, it can be argued that one can chain and/or share interrupts, use synchronization mechanisms like spinlocks, but again...seems like a limitation to me.

Why not ARM make this a standard feature ( like cortex-M3 VTOR ) on all the latest ARM multicores/versions ?

Any thoughts?

1
Do note that the normal operation of the GIC is to distribute your interrupt handling across the different cores in your system. This is a separate issue from vector tables. Nothing prevents the operating system from simultaneously processing different interrupts on different cores.unixsmurf
Also, the newer ARMV7 have support to map the vector tables to any address for secure and normal worlds. I think that monitor mode must use the CP15 values to set the vector table address (which is virtual). Some other aspects of this question are speculative.artless noise

1 Answers

2
votes

The vector's addresses, as any executable code location, are subject to MMU translation so you can put them anywhere in physical memory. Probably you can even have different vectors for different cores (via different MMU tables). Linux uses "high vectors" bit which puts them at 0xFFFF0000, but it's unlikely that a simple ARM machine would have over 3GB of RAM.

See also Relocate the ARM exception vectors?