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?
PD: Do you know a way to emulate a 8xx VM? qemu seems to not have
support support.
Thanks
--
Oscar Salvador
SUSE Labs
