[Crash-utility] [PATCH v2] x86_64: Make the conversion between 4level and 5level paging automatically
Dou Liyang
douly.fnst at cn.fujitsu.com
Thu Jul 12 12:02:10 UTC 2018
At 07/12/2018 02:23 AM, Dave Anderson wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- 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)
>
> Ah, sorry, you mean if the top-level page directory folds back into itself.
>
> So yes, I wonder if it would be obvious enough by checking whether the
> top-level pgd folds back into itself, and if so, 4-levels of page tables
> are in use? But if that were the case, it seems that the 5-level translation
> code would work on both types of user-space tasks. I just don't understand
> how it's supposed to work.
>
OK, let me try to clarify if the the 5-level translation code would work
on both types of user-space tasks at first. ;-)
Thank you so much for you kind explanation!
dou.
> Dave
>
>
>>
>> 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
>>
>>
>>
>
>
>
More information about the Crash-utility
mailing list