Question about ARM LPAE

[li94575]

At 2016-04-05 07:01:04, "Adam Lackorzynski" <adam at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20160407/dc3d1284/attachment.htm>