<ysionneau>
I am wondering how to handle a tlb miss (for NetBSD/lm32, but the question applies for any other OS I think)
<ysionneau>
I see at least two ways: 1°) handle the entire tlb miss with tlb off 2°) save current state somewhere in physical memory and re-enable tlb and handle the miss with tlb *on*
<ysionneau>
But I can see a problem for each of those ways
<ysionneau>
for 1°) it means I need to put physical addreses in the page tables (it's a 2 level page tables) since tlb is off
<ysionneau>
but then the code that manipulates the page table and runs with tlb *on*, will not be able to manipulate it
<ysionneau>
back to my tlb handler stuff: for the 2°) way, if I enable the tlb and therefore use only virtual addresses in the page table, then what happens if one of the page table is not in the TLB?
<lekernel>
Fox news attempts to explain what Github is
<xiangfu>
cannot found that build log. the build server is gone already.
<ysionneau>
xiangfu: for the builds you were taking the "head" of rtems master of the time, right? not one precise rtems commit which was always the same?
<ysionneau>
so between the releases, the rtems code evolved a bit I guess
<ysionneau>
about my 2°) problem, I think I might end up with endless tlb misses where a tlb miss handler wants to access to a page table page which generates a miss and etc .... recursively :/
<ysionneau>
I'm OK with both 1°) or 2°) so just one solution would make me happy :)
<xiangfu>
yes. I use "head" of rtems at that time.
<ysionneau>
ok
<ysionneau>
with the build date I think we can recover approximately which commit was used
<ysionneau>
thanks :)
<ysionneau>
one crappy solution for my tlb miss handler question would be to use "dual entries" (64 bits values) for the 1st level page table. the two entries being the virtual *and* physical address of 2nd level page table containing the PTE
<ysionneau>
but that would really be ugly :( and wastes memory
<ysionneau>
there must be another solution
<lekernel>
ysionneau, are you still trying to use ASID by the way?
<ysionneau>
lekernel: it's not fully debugged yet in the hw side so I will see how it goes
<ysionneau>
with the current sw implementation I can do both with or without asid
<ysionneau>
I can just say "I have only one ASID which is ASID0" and flush tlb at context switch
<ysionneau>
I'm taking inspiration from the code used for PPC book-e (e500), it's pretty well done :)
<ysionneau>
mpc85xx kind of SoC
<ysionneau>
ah I just remembered OpenRISC has hardware page tree walker, so they don't have this issue about tls miss handling
<ysionneau>
:(
<ysionneau>
well at least it means they put physical addresses in the Page table
<lekernel>
isn't the TLB disabled in the TLB miss handler?
<ysionneau>
which mean they must use some interesting trick for the management of the page table
<ysionneau>
lekernel: it is
<lekernel>
so there is no problem #2
<ysionneau>
then I have the choice of enabling it or not
<ysionneau>
if I don't enable it then I need to put physical addresses in the 1st level page table
<ysionneau>
then how do I manage the page table when in the kernel code which runs with TLB *on* in virtual memory ?
<ysionneau>
for instance how do I add the mapping (vaddr,paddr) to the kernel page table
<ysionneau>
I cannot dereference the pointer kernel_page_table[vaddr] because it's physical
<ysionneau>
the issue is to define soft_tlb_lookup()
<ysionneau>
for "kernel_page_table" it's ok because it's allocated in the kernel data at link time
<ysionneau>
so indeed I have a working macro "kern_phy_to_virt()"
<lekernel>
yes
<ysionneau>
which basically does x - 0x40000000 + 0xc0000000
<ysionneau>
but, let's say I can do p = v_kernel_page_table[vaddr]
<lekernel>
can't you just map the kernel that runs with TLB on at a fixed virtual address?
<ysionneau>
this p is then the physical address of another page, containing the PTEs
<ysionneau>
and this one may very well be dynamically allocated during the life of the kernel
<lekernel>
you can maybe have a one-to-one mapping even
<ysionneau>
or maybe I am making this problem up :o
<ysionneau>
maybe there is no need for adding pages to the kernel during its life ...
<ysionneau>
I think it needs to allocate stuff like mutex, network packets etc
<lekernel>
i.e. for the beginning of the 0x40000000 address range, physical address == virtual address
<ysionneau>
I am doing something a bit like that
<ysionneau>
from 0x40000000 to kernel_end I am mapping it statically to 0xc0000000
<ysionneau>
up to kernel_end - 0x40000000 + 0xc0000000
<ysionneau>
so for kernel text(code) there is no issue I think
<ysionneau>
and kernel initial data
<ysionneau>
16:44 < lekernel> can't you just map the kernel that runs with TLB on at a fixed virtual address? < all that's inside the kernel ELF binary is indeed mapped at a fixed known virtual address, my concern is for what the kernel will allocate during runtime
<lekernel>
is the page table dynamically allocated?
<ysionneau>
the first page tables (to map what's inside the kernel ELF file) I allocate them right after kernel_end and I use the same fixed mapping
<ysionneau>
but then the rest which is dynamically allocated ...
<ysionneau>
it will fetch new pages to act as page tables and map it wherever it likes
<ysionneau>
maybe I can try to force the virtual address of those pages to follow the same rule
<ysionneau>
to use my kern_phy_to_virt() and kern_virt_to_phy() macro
xiangfu has quit [Remote host closed the connection]
<ysionneau>
maybe I need to dig into how the kernel will allocate dynamically the new page tables
<ysionneau>
because I honestly don't know :)
lekernel has quit [Read error: Operation timed out]
lekernel has joined #m-labs
azonenberg has quit [Ping timeout: 264 seconds]
azonenberg has joined #m-labs
bentley` has joined #m-labs
Alarm has quit [Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140127194636]]
nicksydney has quit [Remote host closed the connection]
playthatbeat has quit [Read error: Connection reset by peer]
playthatbeat has joined #m-labs
mumptai has quit [Ping timeout: 245 seconds]
<GitHub177>
[misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/IDyE_g