Le 01/02/2021 à 11:22, PLATTNER Christoph a écrit :
Hello to all, and thank you very much for first and second fast response.

I do not have a long history on PowerPC MMU environment, I hacked into this 
topic
for about 3 months for analyzing that problem- so, sorry, if I am wrong in some 
points ...

Yes you are wrong on some points, sorry, see below.



What I learn so far from this MPC5121e (variant of e300c4 core):
- It uses book3s32 hash-code, but it DOES NOT provide KEY hash method, so 
always the
    branch  "if (! Hash) ...." is taken, so, I assume that "key 0" and "key 1" 
setups are not
    used on this CPU (not supporting MMU_FTR_HPTE_TABLE)

hash method is not used, this is SW TLB loading that is used, but still, all the PP and Ks/Kp keys defined in the segment register are used, see e300 core reference manual §6.4.2 Page Memory Protection

- The PP bits are NOT checked by the CPU in HW, even if set to 00, the CPU does 
not react.
    As far I have understood, the TLB miss routines are responsible for 
checking permissions.
    The TLB miss routines check the Linux PTE styled entries and generates the 
PP bits
    for the TLB entry. The PowerPC PP bits are never check elsewhere on that 
CPU models ...

PP bits ARE checked hoppefully. If it was not the case, then the TLB miss routines would install a TLB on a read, then the user could do a write without any verification being done ?

Refer to e300 Core reference Manual, §6.1.4 Memory Protection Facilities

As I explained in the patch, the problem is not that the HW doesn't check the permission. It is that user accessed been done with key 0 as programmed in the segment registers, PP 00 means RW access.

- The PTE entries in Linux are fully "void" in sense of this CPU type, as this 
CPU does not
    read any PTEs from RAM (no HW support in contrast to x86 or ARM or later 
ppc...).

No, the PTE are read by the TLB miss exception handlers and writen into TLB 
entries.


In summary - as far as I understand it now - we have to handle the PTE bits 
differently
(Linux style) for PROT_NONE permissions - OR - we have to expand the permission
checking like my proposed experimental patch. (PROT_NONE is not NUMA related 
only,
but may not used very often ...).

Yes, expanding the permission checking is the easiest solution, hence the patch I sent out based on your proposal.


Another related point:
According e300 RM (manual) the ACCESSED bit in the PTE shall be set on TLB 
miss, as
it is an indication, that page is used. In 4.4 kernel this write back of the 
_PAGE_ACCESSED
bit was performed after successful permission check:

         bne-    DataAddressInvalid      /* return if access not permitted */
         ori     r0,r0,_PAGE_ACCESSED    /* set _PAGE_ACCESSED in pte */
         /*
          * NOTE! We are assuming this is not an SMP system, otherwise
          * we would need to update the pte atomically with lwarx/stwcx.
          */
         stw     r0,0(r2)                /* update PTE (accessed bit) */
         /* Convert linux-style PTE to low word of PPC-style PTE */

Bit is set (ori ...) and written back (stw ...) to Linux PTE. May be, this is 
not needed, as the
PTE is never seen by the PPC chip. But I do not understand, WHY the 
PAGE_ACCCESSED
is used for permission check in the late 5.4 kernel (not used in 4.4 kernel):

        cmplw   0,r1,r3
        mfspr   r2, SPRN_SDR1
        li      r1, _PAGE_PRESENT | _PAGE_ACCESSED
        rlwinm  r2, r2, 28, 0xfffff000
        bgt-    112f

What is the reason or relevance for checking this here ?
Was not checked in 4.4, bit or-ed afterwards, as it is accessed now.
Do you know the reason of change on this point ?

PAGE_ACCESSED is important for memory management, linux kernel need it.

But instead of spending time at every miss to perform a write which will be a no-op in 99% of cases, we prefer bailing out to the page_fault logic when the accessed bit is not set. Then the page_fault logic will set the bit. This also allowed to simplify the handling in __set_pte()_at function by avoiding races in the update of PTEs.


Another remark to Core manual relevant for this:
There is the reference manual for e300 core available (e300 RM). It includes
many remarks in range of Memory Management section, that many features
are optional or variable for dedicated implementations. On the other hand,
the MPC5121e reference manual refers to the e300 core RM, but DOES NOT
information, which of the optional points are there or nor. According my
analysis, MPC5121e does not include any of the optional features.


Not sure what you mean. As far as I understand, that chapter tells you that some functionnalities are optional for the powerpc architectecture, and provided (or not) by the e300 core. The MPC5121 supports all the things that are defined by e300 core.



Thanks a lot for first reactions

You are welcome, don't hesitate if you have additional questions.

Christophe

Reply via email to