First, if something has an MMIO address, then it's not an integrated part of the ARM CPU, rather a peripheral integrated in the SoC.
CPU uses system control registers (for example VBAR_ELx) and instructions only. This means you can trigger a software generated interrupt (SVC instruction) or an exception (abort in ARM terminology, see BRK instruction), once you have set up which function to execute, but that's all.
What you also need is a circuit which connects the peripherals to the CPU by converting their signals into the aformentioned CPU interrupts. This circuit is often called an IRQ controller (or IRQ routing circuit), and that's what the peripherals at 0x3F00B200 and 0x40000000 for (meaning the Broadcom SoC has one CPU and two IRQ controllers). The IO peripherals are often hardwired to the IRQ controllers, but you can choose which interrupt to be triggered on a specific IRQ by programming those IRQ controllers. ARM is very limited in this regard, an IRQ signal is either translated to an IRQ interrupt or an FIQ interrupt (which is good, because makes things simpler). In the interrupt handler code you can read a system register to figure out which peripheral signaled the CPU. As a contrast, the x86 architecture does not have such a system register, but has 224 CPU interrupts available for IRQs, therefore you have to tell the IRQ controller to fire a different interrupt for each peripheral. Imho ARM way is better, and all OS on x86 (that I know of) just sets a variable and calls a common interrupt handler anyway (to mimic ARM's which-IRQ-was-fired register). To complicate things even more, on multicore systems the IRQ controller also has to figure out on which core to trigger the interrupt, because one core is enough to execute the IRQ handler, the rest can do what they were doing uninterrupted.
Back to your original question, since the SoC has more controllers, I believe some peripherals are wired to one controller, while others are wired to the other controller. Things a little bit more complicated here, because the GPU can also receive and generate IRQs. According to Section 3.2 on page 4 of Qa7_rev3, the IRQ controllers are cascaded, meaning all the 64 IRQ lines of the first controller are translated into 2 IRQ lines of the second controller (which has several additional IRQ sources too, some are core related (so it's obvious which core to interrupt), some (like the 2 IRQ lines originated from the GPU) are not).
Example: let's say the UART received a byte, and therefore triggers one of the 64 IRQ lines of GPU's ARM Controller (MMIO 0x3F00...). That will be translated to a FIQ signal, recevied by the second IRQ controller (MMIO 0x4000...) on it's GPU FIQ line, and would trigger a CPU interrupt on the 2nd core for example, which in turn will execute the function FIQ interrupt handler from memory pointed by the VBAR_ELx system register.