Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Dominic Sweetman" <dom@mips.com>, "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Mike Uhler" <uhler@mips.com>, "Jun Sun" <jsun@mvista.com>,
	<linux-mips@linux-mips.org>
Subject: Re: way selection bit for multi-way cache
Date: Fri, 11 Apr 2003 10:15:06 +0200	[thread overview]
Message-ID: <004a01c30002$b3b19480$10eca8c0@grendel> (raw)
In-Reply-To: 16022.24992.314581.716649@gladsmuir.mips.com

> Mike wrote:
> 
> > > I'm not sure what you mean by TLB translations required for hit
> > > cacheops.  If you mean the Index Writeback or Index Invalidate
> > > functions, note that you can (and should) use a kseg0 address to
> > > do this.
> 
> Mike was proposing a kseg0 address translating to the right physical
> address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
> are just assuming that's no good because it doesn't work if you have
> cacheable memory above 512Mbytes physical address.

More importantly, it doesn't work in the case of virtually tagged caches,
such as those in the SB-1 and MIPS 20K.

> I wonder whether anything really bad would happen if you temporarily
> changed the (machine) ASID to that of the address space you wanted to
> invalidate?

I looked at that when we were investigating the aforementioned
issues with virtually-tagged I-caches.  It looked to me as if exceptions
can occur during the invalidation, and that processing those exceptions
can cause signals to be raised to the current process in a manner that 
assumes that the TLB and ASID are coherent and in sync with 
the scheduler.  It may be that just changing the ASID temporarily
would work - most of the time.  It may even be that, with a bit
of lashing down of state, disabling of interrupts, setting of flags
to be read by traps.c/signal.c, etc, etc, it could be made bulletproof.
But I don't think that the simple, obvious hack is safe.

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Dominic Sweetman <dom@mips.com>, Ralf Baechle <ralf@linux-mips.org>
Cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
	linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Date: Fri, 11 Apr 2003 10:15:06 +0200	[thread overview]
Message-ID: <004a01c30002$b3b19480$10eca8c0@grendel> (raw)
Message-ID: <20030411081506.LSjd2gaAtvBcWyhgDuPK3BAHJxpsHsg7ScxcbzgVJUs@z> (raw)
In-Reply-To: 16022.24992.314581.716649@gladsmuir.mips.com

> Mike wrote:
> 
> > > I'm not sure what you mean by TLB translations required for hit
> > > cacheops.  If you mean the Index Writeback or Index Invalidate
> > > functions, note that you can (and should) use a kseg0 address to
> > > do this.
> 
> Mike was proposing a kseg0 address translating to the right physical
> address, and used with a hit-type cacheop.  I believe Ralf (and Linux)
> are just assuming that's no good because it doesn't work if you have
> cacheable memory above 512Mbytes physical address.

More importantly, it doesn't work in the case of virtually tagged caches,
such as those in the SB-1 and MIPS 20K.

> I wonder whether anything really bad would happen if you temporarily
> changed the (machine) ASID to that of the address space you wanted to
> invalidate?

I looked at that when we were investigating the aforementioned
issues with virtually-tagged I-caches.  It looked to me as if exceptions
can occur during the invalidation, and that processing those exceptions
can cause signals to be raised to the current process in a manner that 
assumes that the TLB and ASID are coherent and in sync with 
the scheduler.  It may be that just changing the ASID temporarily
would work - most of the time.  It may even be that, with a bit
of lashing down of state, disabling of interrupts, setting of flags
to be read by traps.c/signal.c, etc, etc, it could be made bulletproof.
But I don't think that the simple, obvious hack is safe.

            Kevin K.

  reply	other threads:[~2003-04-11  8:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-10 18:05 way selection bit for multi-way cache Jun Sun
2003-04-10 18:50 ` Mike Uhler
2003-04-10 18:55   ` Jun Sun
2003-04-10 19:24   ` Ralf Baechle
2003-04-10 19:37     ` Mike Uhler
2003-04-10 19:37       ` Mike Uhler
2003-04-10 20:09       ` Ralf Baechle
2003-04-10 20:28         ` Mike Uhler
2003-04-10 20:28           ` Mike Uhler
2003-04-10 20:52           ` Ralf Baechle
2003-04-11  6:33             ` Dominic Sweetman
2003-04-11  8:15               ` Kevin D. Kissell [this message]
2003-04-11  8:15                 ` Kevin D. Kissell
2003-04-11 12:10                 ` Ralf Baechle
2003-04-11 11:35               ` Ralf Baechle

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='004a01c30002$b3b19480$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=dom@mips.com \
    --cc=jsun@mvista.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=uhler@mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox