All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: Question about rdhwr emulation.
Date: Fri, 24 Oct 2008 15:22:48 -0700	[thread overview]
Message-ID: <49024AB8.4090301@caviumnetworks.com> (raw)
In-Reply-To: <20081024215904.GM25297@linux-mips.org>

Ralf Baechle wrote:
> On Wed, Oct 22, 2008 at 02:35:21AM +0100, Maciej W. Rozycki wrote:
> 
>>  This probe is necessary, because for a VIVT I-cache, code from there may 
>> be executed even if there is no mapping stored for the virtual address of 
>> the instruction in the TLB anymore.  However this trap handler wants to 
>> read the instruction word from the memory and obviously this goes through 
>> the D-cache which is not virtually tagged.  As such a TLB refill exception 
>> would happen if the mapping was indeed absent.
>>
>>  However, please note that this piece of code runs at the exception level 
>> and therefore such a scenario would qualify as a nested exception.  Which 
>> means the general exception vector would be used and the TLBL or TLBS 
>> handler invoked as appropriate.  Neither of which are currently prepared 
>> to do a refill.  Changing that would be rather trivial as it boils down to 
>> checking the value of cp0.index.p and executiong TLBWR rather than TLBWI 
>> as usual, but that is in the fast path, so we do not want to waste cycles 
>> for such a corner case as RDHWR emulation.
> 
> To clarify, this behaviour of hitting in an VIVT I-cache even though there
> is no address translation in the TLB is allowed but not required by the
> the MIPS architecture spec.  From a software perspective it's a bit
> quirky but it allows faster pipeline implementations.  The currently
> supported VIVT I-cache processors are the SB1, 20K and 25K.  The SB1
> has this behaviour; of the 20K and 25K I don't know.

And to perhaps clarify even more, the octeon too has this property, so 
the probe of the TLB is needed there.

David Daney

      reply	other threads:[~2008-10-24 22:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22  1:03 Question about rdhwr emulation David Daney
2008-10-22  1:35 ` Maciej W. Rozycki
2008-10-24 21:59   ` Ralf Baechle
2008-10-24 22:22     ` David Daney [this message]

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=49024AB8.4090301@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /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.