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

[Andrew Jones]

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 :-)

Thanks,
drew