Question about ARM LPAE

[li94575]

Hi,
>> >> At 2016-03-25 06:41:45, "Adam Lackorzynski" <adam at os.inf.tu-dresden.de> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20160403/037072af/attachment.html>