From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: David Daney <ddaney@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Question about rdhwr emulation.
Date: Wed, 22 Oct 2008 02:35:21 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.1.10.0810220218310.29554@ftp.linux-mips.org> (raw)
In-Reply-To: <48FE7BEB.80906@caviumnetworks.com>
On Tue, 21 Oct 2008, David Daney wrote:
> I was looking at the rdhwr emulation code in genex.S and wondering about the
> following:
>
> If cpu_has_vtag_icache is true we run handle_ri_rdhwr_vivt() instead of
> handle_ri_rdhwr().
>
> And handle_ri_rdhwr_vivt() probes the tlb to see if the faulting instruction
> can be reached through the TLB, if it can the 'fast path' is taken, otherwise
> the 'slow path'.
>
> Why is this probe of the TLB necessary? Or perhaps more concisely under which
> conditions can I set cpu_has_vtag_icache to false (noting that for our cpu
> this is the only place cpu_has_vtag_icache is tested)?
Hmm, if the I-cache is physically tagged?
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.
I hope this helps.
Maciej
next prev parent reply other threads:[~2008-10-22 1:35 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 [this message]
2008-10-24 21:59 ` Ralf Baechle
2008-10-24 22:22 ` David Daney
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=alpine.LFD.1.10.0810220218310.29554@ftp.linux-mips.org \
--to=macro@linux-mips.org \
--cc=ddaney@caviumnetworks.com \
--cc=linux-mips@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.