From: christophe leroy <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [v4,17/21] powerpc/8xx: set PTE bit 22 off TLBmiss
Date: Tue, 18 Nov 2014 21:07:15 +0100 [thread overview]
Message-ID: <546BA6F3.2070106@c-s.fr> (raw)
In-Reply-To: <1415405305.3805.45.camel@snotra.buserror.net>
Le 08/11/2014 01:08, Scott Wood a écrit :
>
> OK, so the _PAGE_KERNEL_RO(X) stuff is because initially setting the PTE
> doesn't go through pte_update().
>
> I'll apply this, though it'd be cleaner to just have 8xx versions of the
> relevant PTE accessor functions to maintain the PTE the way the hardware
> wants (this would also eliminate the _PAGE_RW inversion that's still in
> the TLB miss handler).
>
>
Yes, I've been looking at a simple way to also eliminate the _PAGE_RW
inversion, but i've not been able to find an easy solution up to now.
It seems that we have two functions that set PTE: set_pte_at() and
pte_update()
I could perform the bit 22 (0x200) stuff and the _PAGE_RW invertion in
both functions, but then there are functions that read the PTE to make
decision based on PAGE_RW for instance. Most (but not all it seems) do
it through pte_val()
But pte_val() is defined in page.h and doesn't seem to be intended to be
family specific. Should I change this ? if so, what is it cleanest way
to do so ?
Should I also change __pgprot() and __pte() to do the bit 22 and PAGE_RW
inversion stuffs ? But not all functions use those accessors.
So for the time being I don't see the best way to progress on this. Any
suggestion ?
Christophe
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
WARNING: multiple messages have this Message-ID (diff)
From: christophe leroy <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [v4,17/21] powerpc/8xx: set PTE bit 22 off TLBmiss
Date: Tue, 18 Nov 2014 21:07:15 +0100 [thread overview]
Message-ID: <546BA6F3.2070106@c-s.fr> (raw)
In-Reply-To: <1415405305.3805.45.camel@snotra.buserror.net>
Le 08/11/2014 01:08, Scott Wood a écrit :
>
> OK, so the _PAGE_KERNEL_RO(X) stuff is because initially setting the PTE
> doesn't go through pte_update().
>
> I'll apply this, though it'd be cleaner to just have 8xx versions of the
> relevant PTE accessor functions to maintain the PTE the way the hardware
> wants (this would also eliminate the _PAGE_RW inversion that's still in
> the TLB miss handler).
>
>
Yes, I've been looking at a simple way to also eliminate the _PAGE_RW
inversion, but i've not been able to find an easy solution up to now.
It seems that we have two functions that set PTE: set_pte_at() and
pte_update()
I could perform the bit 22 (0x200) stuff and the _PAGE_RW invertion in
both functions, but then there are functions that read the PTE to make
decision based on PAGE_RW for instance. Most (but not all it seems) do
it through pte_val()
But pte_val() is defined in page.h and doesn't seem to be intended to be
family specific. Should I change this ? if so, what is it cleanest way
to do so ?
Should I also change __pgprot() and __pte() to do the bit 22 and PAGE_RW
inversion stuffs ? But not all functions use those accessors.
So for the time being I don't see the best way to progress on this. Any
suggestion ?
Christophe
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
next prev parent reply other threads:[~2014-11-18 20:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 8:36 [PATCH v4 17/21] powerpc/8xx: set PTE bit 22 off TLBmiss Christophe Leroy
2014-09-19 8:36 ` Christophe Leroy
2014-11-07 3:37 ` [v4,17/21] " Scott Wood
2014-11-07 3:37 ` Scott Wood
2014-11-07 8:00 ` leroy christophe
2014-11-07 8:00 ` leroy christophe
2014-11-08 0:08 ` Scott Wood
2014-11-08 0:08 ` Scott Wood
2014-11-18 20:07 ` christophe leroy [this message]
2014-11-18 20:07 ` christophe leroy
2014-11-26 1:58 ` Scott Wood
2014-11-26 1:58 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546BA6F3.2070106@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.