Hi,
At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@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).