At 2016-04-05 07:01:04, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
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).
Ok, looks like a good idea to me and I think it should work. What happens when user programs access the second GB? And which programs, moe, or later ones?
We use Genode as the runtime environment, and already find the reasion why we cannot access the second GB. when thread receives a fpage (mem), It goes wrong while doing the fpage mapping, because we get a wrong physical address through calling 'v_lookup' function. So, we shuld also make judgment when lookup the page table, if the phys addr is 33bit, then minus 0xc0000000 (converting the addr into 0x40000000 ~ 0x7ffffff). Now, the method can works well, thank you for your help.