Domain in arm architecture means what

Question

When I debug MMU in Cortex-A9 MPCore, I always see Domain Access Control Register, but, what does domain means ? up to 16 domains ? Anyone can give me a link to explain this ?

Equanimity

it is how you keep program A from stomping on program B, you can assign them different domains and when one is running it can only access things it has permission to access. When switching tasks you dont have to change as many things, you dont have to sweep the entire mmu table and change what the next task can access. – Numb

at least that is loosely how it was in the older arm mmus. there were places where you specified the permission directly and places where you indexed into a register that contained 16 definitions. – Numb

Answer 1

TL;DR The DACR not only decreases the context switch code path, but can also speed execution after the context switch occurs.

---

There are several links which explain the specifics of Domain Access Control Register or DACR. For example ARM's Memory access permissions and domains. However, this page and many others don't explain why you might need this feature; especially for people use to embedded applications.

A prior ARM feature (ARM architecture V5) was the PID. The reason for this feature is the same as the DACR and domains. What is an MMU used for?

• Privilege separation - or giving some entities (task, thread, etc) access to memory and other limited (read-only) or none.
• Memory remapping - a virtual to physical translation allows sparse/separated memory to become continuous.
• Paging - a fault handler can swap in/out memory on access by less privileged code.
• Access behaviour - the MMU can specify whether memory is cacheable, read/write, should be buffered, etc.

The DACR (and PID) are only concerned with the first (Privilege separation). On a context switch an OS must manage this separation. With most MMUs (historically on the ARM), there are only two privileges being user and super. In order to accommodate multiple tasks, the super MMU code must alter the MMU table. This is complex as the ARM has a TLB and cache, both of which have virtual addresses and depend on the MMU table.

The DACR (and PID) allow the MMU mappings to change with a single register write. Moreover, the TLB and cache also have domain information (and modified address for PID). This means these entries do not need to be flushed (and repopulated) on a context switch. The domains are advantageous to the PID as multiple access profiles can exist. For instance, shared library code may remain accessible on a context switch while the main task/thread binary is switched out.

Compare work with the DACR versus updating the MMU tables.

1. Change at least the L1 page tables to map correct profile.
2. clean/invalidate the L1 table and others in page table update (see below).
3. invalidate the TLB entries (most likely the whole thing for simplicity).
4. invalidate the cache entries in MMU table; probably the whole thing again.

This is versus changing a single register. Moreover, you will probably invalidate the entire cache and TLB. With the DACR and a brief context switch, code/data can remain in the cache and MMU page table entries in the TLB. For example, a system with a check email task and a movie player.

The decoding of audio/video is highly CPU and memory intensive. Occasionally, the email client will poll a network server for information. Usually there is nothing. During this brief transition only a small (1-4k) of check email code may be needed; a single TLB entry. Cache is typically 32k+, so much of the audio/video cache and TLB entries can remain valid.

So the DACR not only decreases the context switch code path, but can also speed execution after the context switch occurs.

Cinerary

For a custom (ARM only) RT-embedded OS, you could structure things with static domains. To support >16 tasks, most OSs will still fall back to the traditional page table update method. However, for the majority of task switches in a running system, the DACR write is used. This optimizes the common case, but has a worst case path (probably not what real time people want to hear). – Cinerary

A fact that is taken for granted in my mind, the ARM is/was typically VIVT caches. That is virtually indexed and virtually tagged. This allows 'domains' and a 'pid' or ASID to be used to compare a current register to values during a page walk. However, when a cache is hit the indexes need to include 'pid/asid'. With physical index or tag, this is not possible (maybe 'pseudo-physcial', like a modified address, but not a pure physical address). – Cinerary