Scott Wood wrote on 13/11/2009 20:25:48:
>
> Joakim Tjernlund wrote:
> > Anyhow, lets start simple and just do the pinned ITLB so the
> > new TLB code can be applied. Can you confirm this works for you?
>
> It works (after changing #ifdef 1 to #if 1).
OK, new series sent.
BTW, one can probably a
Joakim Tjernlund wrote:
Anyhow, lets start simple and just do the pinned ITLB so the
new TLB code can be applied. Can you confirm this works for you?
It works (after changing #ifdef 1 to #if 1).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists
Scott Wood wrote on 12/11/2009 22:57:59:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 12/11/2009 20:45:59:
> >> One other concern with pinning on 8xx -- could it cause problems with
> >> uncached DMA mappings? What happens if a speculative load pulls in a
> >> cache line in an area that'
Joakim Tjernlund wrote:
Scott Wood wrote on 12/11/2009 20:45:59:
One other concern with pinning on 8xx -- could it cause problems with
uncached DMA mappings? What happens if a speculative load pulls in a
cache line in an area that's supposed to be uncached?
hmm, why should this be a problem?
Scott Wood wrote on 12/11/2009 20:45:59:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 11/11/2009 16:26:53:
> >> On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
> >>> Scott Wood wrote on 11/11/2009 00:21:18:
> Where would you put the dcbi? How do you regain control
Joakim Tjernlund wrote:
Scott Wood wrote on 11/11/2009 16:26:53:
On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
Scott Wood wrote on 11/11/2009 00:21:18:
Where would you put the dcbi? How do you regain control after that
cache line has been refilled, but before code flows
Scott Wood wrote on 11/11/2009 16:26:53:
>
> On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
> > Scott Wood wrote on 11/11/2009 00:21:18:
> > > Where would you put the dcbi? How do you regain control after that
> > > cache line has been refilled, but before code flows back to t
On Wed, Nov 11, 2009 at 01:06:10AM +0100, Joakim Tjernlund wrote:
> Scott Wood wrote on 11/11/2009 00:21:18:
> > Where would you put the dcbi? How do you regain control after that
> > cache line has been refilled, but before code flows back to the bad branch?
>
> The dcbi would replace the curre
Scott Wood wrote:
Joakim Tjernlund wrote:
Why does not pinning interact well with CPU15? If pinned, you never get
a TLB miss for kernel text so that should mitigate the CPU15 problem.
The nature of the workaround for CPU15 is that we can't keep it pinned
-- we have to take an ITLB miss on eve
Scott Wood wrote on 11/11/2009 00:21:18:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 10/11/2009 23:02:10:
> >> Joakim Tjernlund wrote:
> >> It wasn't the CPU15 workaround that I was worried about taking down the
> >> pinning -- but rather the CPU15 bug itself causing bad code to be
> >>
Joakim Tjernlund wrote:
Scott Wood wrote on 10/11/2009 23:02:10:
Joakim Tjernlund wrote:
It wasn't the CPU15 workaround that I was worried about taking down the
pinning -- but rather the CPU15 bug itself causing bad code to be
executed inside the pinned kernel mapping.
Oh, but then one is scr
Scott Wood wrote on 10/11/2009 23:02:10:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 10/11/2009 22:36:32:
> >> Joakim Tjernlund wrote:
> >>> yes, maybe there is a way around that. Perhaps by using one of the
> >>> pinned entries for loaded modules, i.e avoid ITLB misses for kernel space?
Scott Wood wrote on 10/11/2009 17:55:28:
>
> Scott Wood wrote:
> > Joakim Tjernlund wrote:
> >> Why does not pinning interact well with CPU15? If pinned, you never get
> >> a TLB miss for kernel text so that should mitigate the CPU15 problem.
> >
> > The nature of the workaround for CPU15 is that
Scott Wood wrote on 10/11/2009 00:00:04:
>
> On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote:
> > On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote:
> > > > > With this, the kernel hangs after "Mount-cache hash table entries:
> > > > > 512".
> > > >
> > > > Somewhat su
Scott Wood wrote on 10/11/2009 21:00:07:
>
> Joakim Tjernlund wrote:
> > I think I have misunderstood, its is not CPU15 or 8xx problem per se, it
> > is a general problem that could happen to any ppc CPU, right?
> > 8xx just happen to be the first CPU that hits this case due to my
> > DAR fixing
>
Scott Wood wrote on 10/11/2009 21:27:05:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 10/11/2009 17:55:28:
> >> Except that the invalidation only happens when you take an ITLB miss on
> >> an adjacent page, which means we'd likely never get CPU15 protection for
> >> kernel code if pinning
Joakim Tjernlund wrote:
Scott Wood wrote on 10/11/2009 22:36:32:
Joakim Tjernlund wrote:
yes, maybe there is a way around that. Perhaps by using one of the
pinned entries for loaded modules, i.e avoid ITLB misses for kernel space?
Not sure what you mean... loaded modules won't be pinned, and
Scott Wood wrote on 10/11/2009 22:36:32:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 10/11/2009 21:27:05:
> >> Joakim Tjernlund wrote:
> >>> Scott Wood wrote on 10/11/2009 17:55:28:
> Except that the invalidation only happens when you take an ITLB miss on
> an adjacent page, wh
Joakim Tjernlund wrote:
Scott Wood wrote on 10/11/2009 00:00:04:
syscall_exit_cont, SRR0/SRR1 were being loaded immediately prior to a page
boundary, with the rfi after the page boundary. On crossing the boundary,
we take an ITLB miss (which goes from possibility to certainty with the
CPU15 wo
Scott Wood wrote on 10/11/2009 00:00:04:
>
> On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote:
> > On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote:
> > > > > With this, the kernel hangs after "Mount-cache hash table entries:
> > > > > 512".
> > > >
> > > > Somewhat surp
On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote:
> On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote:
> > > > With this, the kernel hangs after "Mount-cache hash table entries: 512".
> > >
> > > Somewhat surprising result. I didn't expect you would even hit this
> > > cond
>
> Scott Wood wrote on 06/11/2009 01:33:05:
> >
> > On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> > > Here is the latest(last?) round of this series. I
> > > hope I got everything right now.
> > > Scott and Rex, please test and send ACK/NACK.
> > >
> > > Jocke
> > >
> > >
Scott Wood wrote on 06/11/2009 01:33:05:
>
> On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> > Here is the latest(last?) round of this series. I
> > hope I got everything right now.
> > Scott and Rex, please test and send ACK/NACK.
> >
> > Jocke
> >
> > Joakim Tjernlund (8):
On Wed, Nov 04, 2009 at 02:38:32PM +0100, Joakim Tjernlund wrote:
> Here is the latest(last?) round of this series. I
> hope I got everything right now.
> Scott and Rex, please test and send ACK/NACK.
>
> Jocke
>
> Joakim Tjernlund (8):
> 8xx: invalidate non present TLBs
This works, and is a
24 matches
Mail list logo