----- Original Message -----
Hi Dave,
At 07/11/2018 03:33 AM, Dave Anderson wrote:
>
> The final phase of support would be making this work:
>
> static int
> x86_64_task_uses_5level(struct task_context *tc)
> {
> return FALSE;
> }
>
> Have you had a chance to look at how that can be done?
>
I have no idea to check if 5level paging is used in User-space.
You gave me some methods, and I have try:
-The MAP_FIXED flag
-check if the contents of the page directory or p4d is 'flods'
It would be most helpful if you can compare two tasks, one with 5-level
and one without, and see if there's anything obviously different.
(I don't know what "flods" means)
The documentation in 5level-paging.txt is not very clear, but it does
state that MAP_FIXED is not required:
But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.
If hint address set above 47-bit, but MAP_FIXED is not specified, we try
to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather than
from 47-bit window.
That seems to imply that when the kernel is using 5-level page tables,
then the user-space tasks are also using them -- regardless whether
the task has requested an allocation or not. In other words, if a task
that is already running requests memory in the high address space, its
page tables have already been set up. I wouldn't think that an mmap()
request could change the top-level page table mappings on the fly,
correct?
Now, I found a rough way. As We all know, in x86_64_uvtop_level4(),
the user virtual address is either 4-level or 5-level paging. Can we
do like that:
if (machdep->flags & VM_5LEVEL)
1) Using 5-level parsing code...
2) Check if it is success
If failed, Using 4-level parsing code...
else
Always using 4-level parsing code...
3) go on...
Have you actually confirmed that a user task using 4-level page tables
will fail "vtop" or "vm -p" if the kernel is running with 5-level
page
tables?
Dave