<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>At 2016-04-05 07:01:04, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:<br>>> <br>>> 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).<br>><br>>Ok, looks like a good idea to me and I think it should work.<br>>What happens when user programs access the second GB?<br>>And which programs, moe, or later ones?<br>><br>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 (c<span id="result_box" lang="en" class="short_text" closure_uid_793217792="184"><span closure_uid_793217792="322">onverting the addr into 0x40000000 ~ 0x7ffffff</span></span>). Now, the method can works well, thank you for your help.</div></div><br><br><span title="neteasefooter"><p> </p></span>