[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47bf8631-a214-4653-b098-5773a7d6ee83@csgroup.eu>
Date: Wed, 22 May 2024 08:37:01 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Oscar Salvador <osalvador@...e.de>
CC: Andrew Morton <akpm@...ux-foundation.org>, Jason Gunthorpe
<jgg@...dia.com>, Peter Xu <peterx@...hat.com>, Michael Ellerman
<mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linuxppc-dev@...ts.ozlabs.org"
<linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [RFC PATCH v2 01/20] mm: Provide pagesize to pmd_populate()
Le 21/05/2024 à 13:57, Oscar Salvador a écrit :
> On Mon, May 20, 2024 at 04:24:51PM +0000, Christophe Leroy wrote:
>> I had a quick look at that document and it seems to provide a good
>> summary of MMU features and principles. However there are some
>> theoritical information which is not fully right in practice. For
>> instance when they say "Segment attributes. These fields define
>> attributes common to all pages in this segment.". This is right in
>> theory if you consider it from Linux page table topology point of view,
>> hence what they call a segment is a PMD entry for Linux. However, in
>> practice each page has its own L1 and L2 attributes and there is not
>> requirement at HW level to have all L1 attributes of all pages of a
>> segment the same.
>
> Thanks for taking the time Christophe, highly appreciated.
>
>
>> rlwimi = Rotate Left Word Immediate then Mask Insert. Here it rotates
>> r10 by 23 bits to the left (or 9 to the right) then masks with
>> _PMD_PAGE_512K and inserts it into r11.
>>
>> It means _PAGE_HUGE bit is copied into lower bit of PS attribute.
>>
>> PS takes the following values:
>>
>> PS = 00 ==> Small page (4k or 16k)
>> PS = 01 ==> 512k page
>> PS = 10 ==> Undefined
>> PS = 11 ==> 8M page
>
> I see, thanks for the explanation.
>
>> That's a RFC, all ideas are welcome, I needed something to replace
>> hugepd_populate()
>
> The only user interested in pmd_populate() having a sz parameter
> is 8xx because it will toggle _PMD_PAGE_8M in case of a 8MB mapping.
>
> Would it be possible for 8xx to encode the 'sz' in the *pmd pointer
> prior to calling down the chain? (something like as we do for PTR_ERR()).
> Then pmd_populate_{kernel_}size() from 8xx, would extract it like:
>
> unsigned long sz = PTR_SIZE(pmd)
>
> Then we would not need all these 'sz' parameters scattered.
>
> Can that work?
Indeed _PMD_PAGE_8M can be set in set_huge_pte_at(), no need to do it
atomically as part of pmd_populate, so I'll drop patches 1 and 2.
>
>
> PD: Do you know a way to emulate a 8xx VM? qemu seems to not have
> support support.
>
I don't know any way. You are right that 8xx is not supported by QEMU
unfortunately. I don't know how difficult it would be to add it to QEMU.
Christophe
Powered by blists - more mailing lists