Re: Question about ARM LPAE
li94575 <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, >> >> At 2016-03-25 06:41:45, "Adam Lackorzynski" <[email protected]> wrote: >> >> > >> >> >With the current 32bit setup the second part won't be accessible as it >> >> >goes beyond the 4GB space. Making this memory usable on 32bit could be >> >> >done with some (very hacky) changes but commonly thoughts are that such >> >> >an effort would be better spent for 64bit that does not have any such >> >> >limitations. >> >> Could you tell me where I need to change? I have modified the memory initialization in sigma0, and >> addeda new memory region (from 0x100000000 to 0x13fffffff) on the avl tree. However, it does >> not seem to work, because the page fault address is 32 bit (fpage also cann't hold 64-bit address), >> I wonder if I revise the wrong place. > >The size of an fpage is one thing to solve but far not the only one. >Maybe an fpage can be changed to describe larger addresses (with other >trade-offs) or sigma0 could use a different way/protocol to talk to the >kernel. With that one could get to the memory above 4G through sigma0 >(the sigma0 protocol for clients would probably also need some review >regarding larger addresses). Would that be enough for your use case? > I do not want to extend all of the physical address to 64 bit, including the fpage, this will involve too many places. So, we come up with a way to avoid using the 64-bit physical address, using 32-bit address (0x40000000 ~ 0x7fffffff) to replace the 33-bit physical address (0x100000000 ~ 0x13fffffff). When filling in the page table entry, we make judgments and fill the actual 33-bit physical address. Then, the address translation in MMU would be no problem, the kernel memory area(16MB) is still in the front 1G address. Is there a problem with this method? We test it in the kernel, it seems to work well, but processes in user space cannot use the address(0x40000000 ~ 0x7fffffff). _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers