Stuck during invalidate local TLB in Tx2
Hi seL4 Dev team, Can someone explain the reason (share the reference) to invalidate the local TLB during kernel vspace activation as part CPU initialisation. The Tx2 board stuck while performing this operation. As per my understanding both Tx1 and Tx2 are using same A57 core. so the TLB initialisation and invalidation remain same for Tx2 and should not stuck during invalidation.Please correct me if anything wrong here. I understand from that instruction (tlbi vmalle1) which is invalidating stage 1 entries associated to the current VMID. Also from arm mmu code the seL4 setting up (TCR_EL1) TCR register addressing space as 48bit, ASID as 16bit and page table setup 4k granular size. I am using MRS macro to dump the spsr_el1 and dspsr_el0 register to see the state of processor but its throwing synchronous exception. Do we have any other option to dump all the register content to see the state of processor like we have one in 'sel4debug_dump_registers' which is used in sel4test code. Regards, Muneeswaran R
Hey Munees, Sorry, could you please link to the line in source that you're referring to? Ideally, you could navigate to the source file (or files) you're referring to in our github repository (https://github.com/seL4/seL4) and link to the source lines you're talking about -- would really help a lot :) -- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
Hi Kofi, Please find the source file link below (vspace.c) and the api name is 'invalidateLocalTLB()'. <goog_70420332> https://github.com/seL4/seL4/blob/master/src/arch/arm/64/kernel/vspace.c#L46... <https://github.com/seL4/seL4/blob/master/src/arch/arm/64/kernel/vspace.c#L469> Regards, Munees On Tue, Nov 21, 2017 at 5:10 AM, <Kofidoku.Atuah@data61.csiro.au> wrote:
Hey Munees, So if you trace from try_init_kernel() (https://github.com/seL4/seL4/blob/master/src/arch/arm/kernel/boot.c#L375), you'll see that on line 375, we do map_kernel_window(). Map_kernel_window() changes the mappings in the kernel's page tables in RAM. But the problem is that the cached TLB mappings in the processor will not be updated to reflect the changes we made, until we invalidate the processor's TLB. So we later on proceed to invalidate the TLB (https://github.com/seL4/seL4/blob/master/src/arch/arm/kernel/boot.c#L222) by calling activate_global_pd() shortly afterward inside of init_cpu(). Activate_global_pd() is a preprocessor macro which is #defined to just resolve down to activate_kernel_vspace (https://github.com/seL4/seL4/blob/master/src/arch/arm/64/kernel/vspace.c#L46...), which is the function in which you are now seeing problems. In short, we need to synchronize the processor's view of the page tables with its TLB caches so that we will be able to see the changes we made to the kernel window. If we don't force those changes to be seen, then we could potentially be accessing the wrong frames in RAM when we are trying to do things like initialize kernel objects and write to device MMIO registers in the kernel. -- Kofi Doku Atuah Kernel engineer DATA61 | CSIRO
Hi Kofi Doku Atuah, I am also facing the same problem: I am trying to port seL4 on new hardware platform based on arm64 cortex a53 Elfloader changes are done and i am able to boot the system till it reaches the try_kernel_init(). In the function "activate_kernel_vspace" when it tries to invalidateLocalTLB() the system gets hanged. What is the solution to this ? In your last post you have explained about the problem. @Rajendran, Did you managed to solve it ? Can you please share the detail. Regards, Misbah
participants (3)
-
khan.misbahullah＠in.bosch.com -
Kofidoku.Atuah＠data61.csiro.au -
Muneeswaran Rajendran