All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2/9] MIPS: hazards: Add hazard macros for tlb read
Date: Mon, 18 May 2015 14:30:42 +0100	[thread overview]
Message-ID: <5559E982.2050704@imgtec.com> (raw)
In-Reply-To: <20150515150845.GB2322@linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Hi Ralf,

On 15/05/15 16:08, Ralf Baechle wrote:
> On Wed, May 13, 2015 at 11:50:48AM +0100, James Hogan wrote:
> 
>> Add hazard macros to <asm/hazards.h> for the following hazards around
>> tlbr (TLB read) instructions, which are used in TLB dumping code and
>> some KVM TLB management code:
>>
>> - mtc0_tlbr_hazard
>>   Between mtc0 (Index) and tlbr. This is copied from mtc0_tlbw_hazard in
>>   all cases on the assumption that tlbr always has similar data user
>>   timings to tlbw.
>>
>> - tlb_read_hazard
>>   Between tlbr and mfc0 (various TLB registers). This is copied from
>>   tlbw_use_hazard in all cases on the assumption that tlbr has similar
>>   data writer characteristics to tlbw, and mfc0 has similar data user
>>   characteristics to loads and stores.
>>
>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: linux-mips@linux-mips.org
>> ---
>> Looking at r4000 manual, its tlbr had similar data user timings to tlbw,
>> and mfc0 had similar data writer timings to loads and stores. Are there
>> particular other cores that should be checked too?
> 
> The R4600 and R5000 CPUs are important.  The R4600 also covers the
> R4700 and the R5000 the R52xx embedded cores.
> 
> For most cases the R4000/R4400 due to their long pipeline represent the
> worst case but there are exceptions.

Okay. For mtc0-tlbw/tlbr on r4000:
mtc0	CPR written stage 7
tlbwi/r	CPR read stage 5-8 (5-7 for tlbr)
delay = 7-5-1 = 1 nop
but linux has 2 nops for __mtc0_tlbw_hazard. Is that one of the exceptions?

(
For r4600, mtc0-tlbw/tlbr = 4-2-1 = 1 nop too

For tlbr-mfc0, r4000:
tlbr	CPR written stage 8
mfc0	CPR read state 4
delay = 8-4-1 = 3 nops (that's what I have)

r4600:
tlbr	CPR written stage 4
mfc0	CPR read stage 2
delay = 4-2-1 = 1 nop
)

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2/9] MIPS: hazards: Add hazard macros for tlb read
Date: Mon, 18 May 2015 14:30:42 +0100	[thread overview]
Message-ID: <5559E982.2050704@imgtec.com> (raw)
Message-ID: <20150518133042.XSrk54hSRAnr7ZyuBRQR1AM-DAgmTv7hMyeL92TYOsA@z> (raw)
In-Reply-To: <20150515150845.GB2322@linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Hi Ralf,

On 15/05/15 16:08, Ralf Baechle wrote:
> On Wed, May 13, 2015 at 11:50:48AM +0100, James Hogan wrote:
> 
>> Add hazard macros to <asm/hazards.h> for the following hazards around
>> tlbr (TLB read) instructions, which are used in TLB dumping code and
>> some KVM TLB management code:
>>
>> - mtc0_tlbr_hazard
>>   Between mtc0 (Index) and tlbr. This is copied from mtc0_tlbw_hazard in
>>   all cases on the assumption that tlbr always has similar data user
>>   timings to tlbw.
>>
>> - tlb_read_hazard
>>   Between tlbr and mfc0 (various TLB registers). This is copied from
>>   tlbw_use_hazard in all cases on the assumption that tlbr has similar
>>   data writer characteristics to tlbw, and mfc0 has similar data user
>>   characteristics to loads and stores.
>>
>> Signed-off-by: James Hogan <james.hogan@imgtec.com>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: linux-mips@linux-mips.org
>> ---
>> Looking at r4000 manual, its tlbr had similar data user timings to tlbw,
>> and mfc0 had similar data writer timings to loads and stores. Are there
>> particular other cores that should be checked too?
> 
> The R4600 and R5000 CPUs are important.  The R4600 also covers the
> R4700 and the R5000 the R52xx embedded cores.
> 
> For most cases the R4000/R4400 due to their long pipeline represent the
> worst case but there are exceptions.

Okay. For mtc0-tlbw/tlbr on r4000:
mtc0	CPR written stage 7
tlbwi/r	CPR read stage 5-8 (5-7 for tlbr)
delay = 7-5-1 = 1 nop
but linux has 2 nops for __mtc0_tlbw_hazard. Is that one of the exceptions?

(
For r4600, mtc0-tlbw/tlbr = 4-2-1 = 1 nop too

For tlbr-mfc0, r4000:
tlbr	CPR written stage 8
mfc0	CPR read state 4
delay = 8-4-1 = 3 nops (that's what I have)

r4600:
tlbr	CPR written stage 4
mfc0	CPR read stage 2
delay = 4-2-1 = 1 nop
)

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-05-18 13:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 10:50 [PATCH 0/9] MIPS: dump_tlb improvements James Hogan
2015-05-13 10:50 ` James Hogan
2015-05-13 10:50 ` [PATCH RFC 1/9] MIPS: Add SysRq operation to dump TLBs on all CPUs James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-13 10:50 ` [PATCH 2/9] MIPS: hazards: Add hazard macros for tlb read James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-15 15:08   ` Ralf Baechle
2015-05-18 13:30     ` James Hogan [this message]
2015-05-18 13:30       ` James Hogan
2015-05-13 10:50 ` [PATCH 3/9] MIPS: dump_tlb: Use tlbr hazard macros James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-15 15:17   ` Ralf Baechle
2015-05-16  0:32     ` Maciej W. Rozycki
2015-05-13 10:50 ` [PATCH 4/9] MIPS: dump_tlb: Refactor TLB matching James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-13 10:50 ` [PATCH 5/9] MIPS: dump_tlb: Take global bit into account James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-15 15:38   ` Ralf Baechle
2015-05-18 13:37     ` James Hogan
2015-05-18 13:37       ` James Hogan
2015-05-16  0:44   ` Maciej W. Rozycki
2015-05-16  1:02     ` Maciej W. Rozycki
2015-05-18 13:50     ` James Hogan
2015-05-18 13:50       ` James Hogan
2015-05-18 14:19       ` Maciej W. Rozycki
2015-05-13 10:50 ` [PATCH 6/9] MIPS: dump_tlb: Take EHINV " James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-13 10:50 ` [PATCH 7/9] MIPS: dump_tlb: Take RI/XI bits " James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-13 10:50 ` [PATCH 8/9] MIPS: dump_tlb: Take XPA " James Hogan
2015-05-13 10:50   ` James Hogan
2015-05-13 10:50 ` [PATCH 9/9] MIPS: tlb-r4k: Fix PG_ELPA comment James Hogan
2015-05-13 10:50   ` James Hogan

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=5559E982.2050704@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=linux-mips@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.