2

What are the steps to update entries in the translation table?

I use the MMU of an ARM920T to get some memory protection. When I switch between processes I need to change some of the entries to protect the memory of the other processes. After updating the table (in memory) I issue a full TLB invalidation (just to be sure, also there are no locked entries) but the new process still has access to the data of the previous one.

When I traverse the table everything looks like it should (meaning the other process areas are set to "not accessible in USR mode").

Edit I also do a full cache clean and invalidation (on both caches) before the TLB invalidation, but this does not change anything.

Nobody moving away from SE
  • 9,347
  • 3
  • 45
  • 92

2 Answers2

1

TLB is not the only thing that needs to be maintained after page changes, particularly those containing executable code. First, you need to make sure that your changes propagated to physical memory (i.e., clean the cached area pointing to the page tables that you modified). You will need to invalidate your instruction cache, as it may contain lines from the old code area. Depending on your cache type, you may need to clean your data caches prior to updating your page tables and invalidate your data caches after the change. Finally, you will need to make sure that you have sufficient barriers in place to enforce that operations complete in the order you specify.

Variable Length Coder
  • 7,958
  • 2
  • 25
  • 29
1

You should map the area where your pagetables are as strongly ordered for some good reasons, it will hurt your performance a bit but should still be better than flushing complete cache after writing to the table or issuing a memory barrier.

I don't really understand what you're trying to ask, or where you have problem exactly, but this is what I'm using in one of my softwares:

.align
arch_mmu_map_section:
#if ARM_WITH_MMU
    ldr     r3, =MMU_TLB          @ r3 = &table
    add     r1, r3, r1, lsr #18   @ r1 = &table + offset(entry)
    ldr     r3, =0xFFFFF          @ r3 = (1<<20) - 1
    bic     r0, r0, r3            @ Align r0 to 1 MB
    orr     r0, r0, r2            @ ORR the flags
    str     r0, [r1]              @ Write entry to r1, pointer to entry
    @ Invalidate UTLB
    mov     r3, #0
    mcr     p15, 0, r3, c8, c7, 0
#endif
    bx      lr

MMU_TLB is pointer to the table and is mapped as strongly ordered during mmu_init. The prototype for this function would be

void arch_mmu_map_section(addr_t paddr, addr_t vaddr, uint flags);
sgupta
  • 1,214
  • 2
  • 15
  • 29
  • The question is: What are the required steps to do for updates in the translation table to take effect. The performance is not a criterion right now. And as I stated in my question: The problem is, that I update the table but it seems the changes are not taken into account by the mmu. Also note that for now I do not use real mapping (meaning everything is just mapped flat). – Nobody moving away from SE Jul 06 '12 at 08:53
  • I know, flat mapping does not affect memory model, when you map memory, you must be supplying some flags with it, the flags and the TX, CB and other bits in it decide the memory model for the part of the memory being mapped to in the table for that entry. There are multiple memory models in ARM, you should give it a read in your processor's Manual. Strongly ordered is the easiest to handle since all cache is flushed automatically on any write operation and operations are not executed out of order. Just use Strongly ordered memory and flush UTLB for now. – sgupta Jul 06 '12 at 19:42