Re: [Milkymist port] virtual memory management

[Matt Thomas <matt%3am-software.com@localhost>]

On Feb 10, 2014, at 2:00 PM, Yann Sionneau <yann.sionneau%gmail.com@localhost> 
wrote:

> So if I understand correctly I could implement the following scheme:
> 
> Let my linker put the kernel ELF virtual addresses to 0xc000.0000. Load the 
> kernel at base of RAM (0x4000.0000)
> Then reserve this memory region as a "window" over physical ram : 
> 0xc000.0000-0xc800.0000 (ram size is 128 MB) by doing something like 
> "physseg[0].avail_start = 0xc800.0000;" in pmap_bootstrap()
> 
> Then in my tlb miss handlers I could do:
> 
> if (fault happened in kernel mode) /* we don't want user space to access all 
> ram through the kernel window */
> {
>    if ( (miss_vaddr <  0xc8000000) && (miss_vaddr >= 0xc0000000) ) /* <= this 
> would be kind of like your test of the high bit of the faulty vaddr */
>    {
>        reload_tlb_with(atop(miss_vaddr), atop(miss_vaddr - 0xc0000000 + 
> 0x40000000) | some_flags); /* <= create the mapping for accessing the window 
> */

atop(miss_vaddr ^ 0x8000000) :)

>        return_from_exception;
>    }
> } else {
>    - access the page table to reload tlb
>    - page table contains only physical addresses
>    - but I can dereference those using the 0xc000.0000-0xc800.0000 window 
> knowing that a nested tlb miss can happen
> }

I'd leave the page_table using virtual addresses but since they will all
be direct mapped, simply convert to them to physical before using them.

That way, when the kernel is running with the TLB enabled (which is most
of the time), it can traverse the page tables normally.

> Does this sound reasonable ?
> 
>> 
>> The cache aliasing issues in VIPT caches only occur if the cache way size
>> is larger than the page size.  If you're designing your own hardware,
>> don't do that.  Otherwise, remember to only access a page through a single
>> mapping and you won't have aliasing issues.  And flush the page from the
>> cache wenever establishing a new mapping.
> Well, lm32 caches are configurable but for the Milkymist SoC they are not 
> configured too big such that there is no alias problem.
> In order to handle all cases of lm32 cache sizes I guess I need to add a 
> macro that the machine headers will define if there are cache alias issues 
> possible.
> But then if I am using the 0xc000.0000-0xc800.0000 window during my tlb miss 
> handler I guess I will have no choice but to invalidate the cache because any 
> fault while reading this window will then add a tlb entry to this window 
> which would possibly cause a physical page to be mapped twice and then could 
> cause alias issues (in the scenario where caches are too big).

Hopefully, if they make the caches larger they increase the number of ways.
I wouldn't add code to flush.  Just add a panic if you detect you can have
aliases and deal with it if it ever happens.