From: James Hogan <james.hogan@imgtec.com> To: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Matt Redfearn <matt.redfearn@imgtec.com>, Ralf Baechle <ralf@linux-mips.org>, <linux-mips@linux-mips.org> Subject: Re: [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit Date: Thu, 6 Oct 2016 19:05:25 +0100 [thread overview] Message-ID: <20161006180525.GG19354@jhogan-linux.le.imgtec.org> (raw) In-Reply-To: <alpine.LFD.2.20.1610061709400.1794@eddie.linux-mips.org> [-- Attachment #1: Type: text/plain, Size: 1314 bytes --] On Thu, Oct 06, 2016 at 05:18:26PM +0100, Maciej W. Rozycki wrote: > Hi James, > > > > This does look wrong to me, as I noted above EBase is 64-bit with MIPS64 > > > processors as from architecture revision 3.50. Also I don't think we want > > > > MIPS64 PRA (I'm looking at r5 and r6) seems to allow for write-gate not > > to be implemented, in which case the register is only 32-bits. > > Indeed, but we need to be prepared to handle the width of 64 bits and > `cpu_has_mips64r6' does not seem to me to be the right condition. The relevance of r6 is the assurance that reading a 32-bit COP0 register with dmfc0 is no longer UNDEFINED (like r5 and before), but reads the top 32-bits as reserved, i.e. read zero (may need manual sign extension) and writes ignored. > > ISTR a while ago we had a rather lengthy discussion as to how to detect > the presence of the upper 32 bits without triggering undefined behaviour > implied by 64-bit CP0 accesses to 32-bit CP0 registers. As I believe we > set EBase ourselves I think we are able to make the necessary checks and > have an accurate condition here, still remembering however that it may go > back as far as MIPSr3. We only set ebase under certain circumstances, otherwise leaving it as already set. Cheers James [-- Attachment #2: 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: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Matt Redfearn <matt.redfearn@imgtec.com>, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org Subject: Re: [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit Date: Thu, 6 Oct 2016 19:05:25 +0100 [thread overview] Message-ID: <20161006180525.GG19354@jhogan-linux.le.imgtec.org> (raw) Message-ID: <20161006180525.HMsEUfVc2uoBx8pmbidlEBlJdFjoFtYtpw8cFTs1ioo@z> (raw) In-Reply-To: <alpine.LFD.2.20.1610061709400.1794@eddie.linux-mips.org> [-- Attachment #1: Type: text/plain, Size: 1314 bytes --] On Thu, Oct 06, 2016 at 05:18:26PM +0100, Maciej W. Rozycki wrote: > Hi James, > > > > This does look wrong to me, as I noted above EBase is 64-bit with MIPS64 > > > processors as from architecture revision 3.50. Also I don't think we want > > > > MIPS64 PRA (I'm looking at r5 and r6) seems to allow for write-gate not > > to be implemented, in which case the register is only 32-bits. > > Indeed, but we need to be prepared to handle the width of 64 bits and > `cpu_has_mips64r6' does not seem to me to be the right condition. The relevance of r6 is the assurance that reading a 32-bit COP0 register with dmfc0 is no longer UNDEFINED (like r5 and before), but reads the top 32-bits as reserved, i.e. read zero (may need manual sign extension) and writes ignored. > > ISTR a while ago we had a rather lengthy discussion as to how to detect > the presence of the upper 32 bits without triggering undefined behaviour > implied by 64-bit CP0 accesses to 32-bit CP0 registers. As I believe we > set EBase ourselves I think we are able to make the necessary checks and > have an accurate condition here, still remembering however that it may go > back as far as MIPSr3. We only set ebase under certain circumstances, otherwise leaving it as already set. Cheers James [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-10-06 18:05 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-01 16:30 [PATCH 0/9] MIPS: General EVA fixes & cleanups James Hogan 2016-09-01 16:30 ` [PATCH 1/9] MIPS: traps: 64bit kernels should read CP0_EBase 64bit James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-21 13:08 ` Ralf Baechle 2016-09-21 15:01 ` Matt Redfearn 2016-09-21 15:01 ` Matt Redfearn 2016-10-02 10:30 ` Maciej W. Rozycki 2016-10-05 15:56 ` James Hogan 2016-10-05 15:56 ` James Hogan 2016-10-06 16:18 ` Maciej W. Rozycki 2016-10-06 18:05 ` James Hogan [this message] 2016-10-06 18:05 ` James Hogan 2016-10-06 19:56 ` Maciej W. Rozycki 2016-10-06 20:19 ` James Hogan 2016-10-06 20:19 ` James Hogan 2016-10-06 22:41 ` Maciej W. Rozycki 2016-10-06 22:50 ` James Hogan 2016-10-06 22:50 ` James Hogan 2016-10-06 23:07 ` Maciej W. Rozycki 2016-10-07 15:35 ` David Daney 2016-10-07 15:41 ` David Daney 2016-10-07 17:39 ` Maciej W. Rozycki 2016-09-01 16:30 ` [PATCH 2/9] MIPS: traps: Convert ebase to KSeg0 James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-01 16:30 ` [PATCH 3/9] MIPS: traps: Ensure full EBase is written James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-21 13:19 ` Ralf Baechle 2016-09-01 16:30 ` [PATCH 4/9] MIPS: c-r4k: Drop bc_wback_inv() from icache flush James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-01 16:30 ` [PATCH 5/9] MIPS: c-r4k: Split user/kernel flush_icache_range() James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-01 16:30 ` [PATCH 6/9] MIPS: cacheflush: Use __flush_icache_user_range() James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-01 16:30 ` [PATCH 7/9] MIPS: uprobes: Flush icache via kernel address James Hogan 2016-09-01 16:30 ` James Hogan 2016-09-21 13:26 ` Ralf Baechle 2016-09-21 18:15 ` Leonid Yegoshin 2016-09-21 18:15 ` Leonid Yegoshin 2016-09-22 21:15 ` James Hogan 2016-09-22 21:15 ` James Hogan 2016-09-22 21:38 ` Leonid Yegoshin 2016-09-22 21:38 ` Leonid Yegoshin 2016-09-22 21:42 ` Leonid Yegoshin 2016-09-22 21:42 ` Leonid Yegoshin 2016-09-22 22:13 ` James Hogan 2016-09-22 22:27 ` Leonid Yegoshin 2016-09-22 22:27 ` Leonid Yegoshin 2016-09-23 7:10 ` James Hogan 2016-09-01 16:30 ` [PATCH 8/9] MIPS: KVM: Use __local_flush_icache_user_range() James Hogan 2016-09-01 16:30 ` [PATCH 9/9] MIPS: c-r4k: Fix flush_icache_range() for EVA James Hogan 2016-09-01 16:30 ` 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=20161006180525.GG19354@jhogan-linux.le.imgtec.org \ --to=james.hogan@imgtec.com \ --cc=linux-mips@linux-mips.org \ --cc=macro@linux-mips.org \ --cc=matt.redfearn@imgtec.com \ --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: linkBe 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.