Question about rdhwr emulation.

Question about rdhwr emulation.

[David Daney]

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)?

Thanks in advance for enlightening me,
David Daney

Re: Question about rdhwr emulation.

[Maciej W. Rozycki]

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

Re: Question about rdhwr emulation.

[Ralf Baechle]

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.

  Ralf

Re: Question about rdhwr emulation.

[David Daney]

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