ARM Context ID Register & Process Context Switch

Yes, it is the OS which is responsible for assigning ASIDs to processes.

It depends on what you mean by essential.  ASIDs allow TLB entries to be tagged as belonging to a specific process.  This means you don't need to invalidate the TLBs when context switching between different processes (as each has it's own ASID, and thus their TLB entries can be told apart).  This not only saves you from an unnecessary invalidate, but means that you can potentially pick up the TLB entries when next the process is context switched back in.

It's not strictly essential that you use ASIDs.  You could just invalidate the TLB on each context switch instead.  However, this would be less efficient.

The Context ID register is present on all ARMv7-A processors, including the Cortex-A8.  It works in the same way on the Cortex-A8 and Cortex-A9.

LPAE (implement on Cortex-A7, Cortex-A15 and Cortex-A17 + all ARMv8-A processors) changes where the ASID is stored.  But the basic mechanism stays the same.

The corresponding identifier for x86 is called PCID - process context id, so that's the thing to look for in the x86 Minix code as implementing the business isn't entirely straightforward. I get the feeling it will be much more worthwhile on Minix 3 than it ever has been with Linux because of it switching processes for every little service or driver interrupt, so yeah go for it.

thank you for your advice. At present I am trying to port Minix 3 to Zynq-7000 All Programmable SoC Zedboard, but when the system switches to VM service, after it writes the physical address of page directory again, the operation of refresh_tlb() hangs the CPU. Before this execution point, the same operation of writing TTBR and refreshing TLB is performed smoothly? I don't find the reason why invalidating the TLB at this point will hang the CPU.

Just to expand on Martin's post:

• For pre-LPAE processors and later processors using "Short-descriptors", the ASID is stored in the least-significant byte of the CONTEXTIDR register. The rest of the register is not used by the MMU.
• For processors using LPAE's "Long-descriptors", the ASID is stored elsewhere, and the CONTEXTIDR is not used by the MMU.

ASIDs allow virtual addresses to be tagged to a process, as Martin describes.

The (portion of the) CONTEXTIDR not used by the MMU is used for debug. E.g. you can tag hardware breakpoints/watchpoints to match on CONTEXTIDR, and ETM trace outputs CONTEXTIDR. The value in the register has no other meaning to the hardware. It is up to the OS to assign a useful value to this for debugging.

I suspect that it's not the TLB invalidate that is causing the problem, but rather the table walk(s) that have to happen after the invalidate.  Could you give an outline of the steps you are performing?  Also, when you say "hang" what exactly do you mean (e.g. recursive abort, or the processor can't enter debug state)?

EDIT: Forgot an important "not"

Just to establish a base point.

I see that Minix 3 has been ported to some ARM systems..

So basically I guess Minix 3 works on ARM at the moment by flushing on context switch and I believed you wanted to use ASID to cut down on the overheads.

However it sounds to me from what you are saying that you are porting to this board and Minix 3 is failing to run and the ASID stuff was just an idea you had about why it wasn't running.

Is that right?

My first guess would be that if it has been running on a different ARM system and is having problems on this one there is very possibly a memory barrier problem, for instance you need to ensure new page table entries are written away from the cache before loading the translation table base. Have you the Cortex-A Series Programmer's Guide for ARMv7-A from the ARM site? It talks a bit about this sort of thing.

yes, it is right. I failed to run Minix on the Zedboard. I have downloaded the Cortex-A Series Programmer's Guide. I will read that again. Thanks.

The ASID on the ARM is by my opinion badly designed. It should be possible to store it also in the page-table. On PowerPC E200 cores, one can directly write the TLB and set the ASID. Why ARM did not extend the page-table entries to hold also an ASID is still a big mystery to me.

I wonder, is there really no way (hidden bit) to disable hardware table walk and write TLB entries directly?

It would be good if you gave reasons for what you say and for what you want to do. It would probably be better to start up a a separate discussion as it seems to not be closely related to this one.