[PATCH v5 1/4] mm: modify pte format for Svnapot

[Qinglin Pan]

On 10/5/22 9:25 PM, Andrew Jones wrote:
> On Wed, Oct 05, 2022 at 08:41:02PM +0800, Qinglin Pan wrote:
>> On 10/5/22 3:15 PM, Andrew Jones wrote:
>>> On Wed, Oct 05, 2022 at 12:43:01PM +0800, Qinglin Pan wrote:
>>>> Hi Conor and Andrew,
>>>>
>>>> On 10/5/22 2:33 AM, Conor Dooley wrote:
>>>>> On Tue, Oct 04, 2022 at 07:00:27PM +0200, Andrew Jones wrote:
>>>>>> On Mon, Oct 03, 2022 at 09:47:18PM +0800, panqinglin2020 at iscas.ac.cn wrote:
>>>
>>>>>>> +#define ALT_SVNAPOT_PTE_PFN(_val, _napot_shift, _pfn_mask, _pfn_shift)	\
>>>>>>> +asm(ALTERNATIVE("and %0, %0, %1\n\t"					\
>>>>>>> +		"srli %0, %0, %2\n\t"					\
>>>>>>> +		__nops(3),						\
>>>>>>> +		"srli t3, %0, %3\n\t"					\
>>>>>>> +		"and %0, %0, %1\n\t"					\
>>>>>>> +		"srli %0, %0, %2\n\t"					\
>>>>>>> +		"sub  t4, %0, t3\n\t"					\
>>>>>>> +		"and  %0, %0, t4",					\
>>>>>>
>>>>>> This implements
>>>>>>
>>>>>>      temp = ((pte & _PAGE_PFN_MASK) >> _PAGE_PFN_SHIFT);
>>>>>>      pfn = temp & (temp - (pte >> _PAGE_NAPOT_SHIFT));
>>>>>>
>>>>>> which for a non-napot pte just returns the same as the non-napot
>>>>>> case would, but for a napot pte we return the same as the non-napot
>>>>>> case but with its first set bit cleared, wherever that first set
>>>>>> bit was. Can you explain to me why that's what we want to do?
>>>>>>
>>>>
>>>> For 64KB napot pte, (pte >> _PAGE_NAPOT_SHIFT) will get 1, and temp will be
>>>> something like 0xabcdabcdab8, but the correct pfn we expect should be
>>>> 0xabcdabcdab0. We can get it by calculating (temp & (temp - 1)).
>>>> So temp & (temp - (pte >> _PAGE_NAPOT_SHIFT)) will give correct pfn
>>>> both in non-napot and napot case:)
>>>
>>> I understood that and it makes sense to me for your example, where
>>> temp = 0xabcdabcdab8, as we effectively clear the lower four bits as
>>> expected (I think) for napot-order = 4. But, what if temp = 0xabcdabcdab0,
>>> then we'll get 0xabcdabcdaa0 for the napot case. Is that still correct?
>>> With the (temp & (temp - 1)) approach we'll always clear the first set
>>> bit, wherever it is, e.g. 0xabcd0000800 would be 0xabcd0000000.  Am I
>>> missing something about the expectations of the lower PPN bits of the PTE?
>>
>> According to spec, when napot-order=4, the last 3 bit of temp will be 0, and
>> the fourth bit from the bottom must be 1. All 16 PTEs will be the same.
>> We'll always need to clear the first set bit of napot PTE's pfn.
>> The first set bit is used by MMU to determine this PTE's napot-order.
> 
> Thank you for the clarification. My first reading of the spec left me
> confused, so I was hoping your answer would help me understand it and
> it did. The assembly you've pulled together is indeed a clever way to
> handle this :-)
> 

You are welcome :-)

Yours,
Qinglin

> Thanks,
> drew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv