From: Fredrik Noring <noring@nocrew.org> To: "Maciej W. Rozycki" <macro@imgtec.com> Cc: linux-mips@linux-mips.org Subject: Re: [PATCH v2] MIPS: Add basic R5900 support Date: Fri, 22 Sep 2017 18:37:54 +0200 [thread overview] Message-ID: <20170922163753.GA2415@localhost.localdomain> (raw) In-Reply-To: <alpine.DEB.2.00.1709201604400.16752@tp.orcam.me.uk> Hi Maciej, > The operation is only defined for bits 63:0 AFAICS. IIUC bits 127:64 > remain unchanged (which is why I think that at the initial stage of R5900 > support they have to be explicitly set to a fixed value on a context > switch, to prevent leaking information), but I have no means to verify it. > > In the interim to fix the value of bits 127:64 while keeping disruption > to existing code at the minimum you could AFAICT use a sequence like: > > pcpyld $1, $0, $1 > pcpyld $2, $0, $2 > # ... > pcpyld $31, $0, $31 > > in RESTORE_SOME, preferably via an auxiliary macro. Once we have switched > to saving/restoring full 128-bit registers, possibly with SQ/LQ, we can > remove this temporary measure. Sounds reasonable! > This would verify whether the original contents of $17 were a properly > sign-extended 32-bit value. Although for predictable operation I would > advise to use: > > sll k1, $17, 0 > sw k1, PT_R17(sp) > lw k1, PT_R17(sp) > tne k1, $17, 12 > > or simply: > > sll k1, $17, 0 > tne k1, $17, 12 > sw $17, PT_R17(sp) There is a slight complication: the trap appears to be taken before the console is ready, hence nothing is displayed. Is there a practical way to postpone or recover from a trap? The issue becomes somewhat involved since the trap needs to save/restore registers for itself to recover, and so might evoke boundless recursion. From a practical point of view it would be great if backtraces could be rate limited, recoverable and possible to copy over network (I don't have e.g. a serial port soldered). I will look into other alternatives to try to capture this. > Previously you wrote that the problem is with resetting the upper 96 bits > (how did you notice that BTW?) rather than bits 63:32 only, so you need a > different check. I suspect 63:32 are the critical bits of the upper 96 bits since SD/LD is sufficient. Summery of observations thus far: save/restore works with SQ/LQ and SD/LD, but not SW/LW, in a 32-bit kernel ceteris paribus. > Also I see no reason why LW would set bits 63:32 to anything different > from what was there before SW as long as the original value was 32-bit > (hence the second check sequence proposed). Yes, SLL seems sufficient for testing this. > > A question is whether registers are clobbered within the kernel itself > > (via interrupts or some such) or for user programs. > > Well, you do need to verify your patches for such a possibility, right. > I would advise double-checking exception handling indeed, including > run-time generated exception handler code in particular. The extremely early trap indicates a kernel issue, or perhaps register garbage during kernel initialisation, that wouldn't be an error? Is the run-time code related to genex.S? The R5900 patch sprinkles NOP and SYNC.P instructions on it, for various workarounds, but not much else apart from reverting db8466c581c "MIPS: IRQ Stack: Unwind IRQ stack onto task stack" that otherwise crashes for an unknown reason. Fredrik
WARNING: multiple messages have this Message-ID (diff)
From: Fredrik Noring <noring@nocrew.org> To: "Maciej W. Rozycki" <macro@imgtec.com> Cc: linux-mips@linux-mips.org Subject: Re: [PATCH v2] MIPS: Add basic R5900 support Date: Fri, 22 Sep 2017 18:37:54 +0200 [thread overview] Message-ID: <20170922163753.GA2415@localhost.localdomain> (raw) Message-ID: <20170922163754.ffqtWX89Tva3MvEfGTf89rbq_Cik41DLma9eLJgpOFk@z> (raw) In-Reply-To: <alpine.DEB.2.00.1709201604400.16752@tp.orcam.me.uk> Hi Maciej, > The operation is only defined for bits 63:0 AFAICS. IIUC bits 127:64 > remain unchanged (which is why I think that at the initial stage of R5900 > support they have to be explicitly set to a fixed value on a context > switch, to prevent leaking information), but I have no means to verify it. > > In the interim to fix the value of bits 127:64 while keeping disruption > to existing code at the minimum you could AFAICT use a sequence like: > > pcpyld $1, $0, $1 > pcpyld $2, $0, $2 > # ... > pcpyld $31, $0, $31 > > in RESTORE_SOME, preferably via an auxiliary macro. Once we have switched > to saving/restoring full 128-bit registers, possibly with SQ/LQ, we can > remove this temporary measure. Sounds reasonable! > This would verify whether the original contents of $17 were a properly > sign-extended 32-bit value. Although for predictable operation I would > advise to use: > > sll k1, $17, 0 > sw k1, PT_R17(sp) > lw k1, PT_R17(sp) > tne k1, $17, 12 > > or simply: > > sll k1, $17, 0 > tne k1, $17, 12 > sw $17, PT_R17(sp) There is a slight complication: the trap appears to be taken before the console is ready, hence nothing is displayed. Is there a practical way to postpone or recover from a trap? The issue becomes somewhat involved since the trap needs to save/restore registers for itself to recover, and so might evoke boundless recursion.
next prev parent reply other threads:[~2017-09-22 16:38 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-27 13:23 [PATCH] MIPS: Add basic R5900 support Fredrik Noring 2017-08-28 13:53 ` Ralf Baechle 2017-08-28 17:11 ` Maciej W. Rozycki 2017-08-29 17:33 ` Fredrik Noring 2017-08-29 17:24 ` Maciej W. Rozycki 2017-08-29 17:24 ` Maciej W. Rozycki 2017-08-30 13:23 ` Fredrik Noring 2017-08-31 15:11 ` Maciej W. Rozycki 2017-08-31 15:11 ` Maciej W. Rozycki 2017-09-02 10:28 ` Fredrik Noring 2017-09-09 10:13 ` Maciej W. Rozycki 2017-09-09 10:13 ` Maciej W. Rozycki 2017-09-11 5:21 ` Maciej W. Rozycki 2017-09-11 5:21 ` Maciej W. Rozycki 2017-09-12 17:59 ` Fredrik Noring 2017-09-15 11:12 ` Maciej W. Rozycki 2017-09-15 11:12 ` Maciej W. Rozycki 2017-09-15 13:19 ` Fredrik Noring 2017-09-15 18:28 ` Maciej W. Rozycki 2017-09-15 18:28 ` Maciej W. Rozycki 2017-09-02 14:10 ` [PATCH v2] " Fredrik Noring 2017-09-11 5:18 ` Maciej W. Rozycki 2017-09-11 5:18 ` Maciej W. Rozycki 2017-09-11 15:17 ` Fredrik Noring 2017-09-14 13:50 ` Maciej W. Rozycki 2017-09-14 13:50 ` Maciej W. Rozycki 2017-09-16 13:34 ` Fredrik Noring 2017-09-18 17:05 ` Maciej W. Rozycki 2017-09-18 17:05 ` Maciej W. Rozycki 2017-09-18 19:24 ` Fredrik Noring 2017-09-19 12:44 ` Maciej W. Rozycki 2017-09-19 12:44 ` Maciej W. Rozycki 2017-09-20 14:54 ` Fredrik Noring 2017-09-26 11:50 ` Maciej W. Rozycki 2017-09-26 11:50 ` Maciej W. Rozycki 2017-09-27 17:21 ` Fredrik Noring 2017-09-28 12:13 ` Maciej W. Rozycki 2017-09-28 12:13 ` Maciej W. Rozycki 2017-09-30 6:56 ` Fredrik Noring 2017-10-02 9:05 ` Maciej W. Rozycki 2017-10-02 9:05 ` Maciej W. Rozycki 2017-10-02 16:33 ` Fredrik Noring 2017-10-29 17:20 ` Fredrik Noring 2017-11-10 23:34 ` Maciej W. Rozycki 2017-11-10 23:34 ` Maciej W. Rozycki 2017-11-11 16:04 ` Fredrik Noring 2018-01-29 20:27 ` Fredrik Noring 2018-01-31 23:01 ` Maciej W. Rozycki 2018-02-11 7:29 ` [RFC] MIPS: R5900: Workaround for the short loop bug Fredrik Noring 2018-02-12 9:25 ` Maciej W. Rozycki 2018-02-12 15:22 ` Fredrik Noring 2018-02-11 7:46 ` [RFC] MIPS: R5900: Use SYNC.L for data cache and SYNC.P for instruction cache Fredrik Noring 2018-02-11 7:56 ` [RFC] MIPS: R5900: Workaround exception NOP execution bug (FLX05) Fredrik Noring 2018-02-12 9:28 ` Maciej W. Rozycki 2018-02-15 19:15 ` [RFC v2] " Fredrik Noring 2018-02-15 20:49 ` Maciej W. Rozycki 2018-02-17 11:16 ` Fredrik Noring 2018-02-17 11:57 ` Maciej W. Rozycki 2018-02-17 13:38 ` Fredrik Noring 2018-02-17 15:03 ` Maciej W. Rozycki 2018-02-17 20:04 ` Fredrik Noring 2018-02-20 14:09 ` Maciej W. Rozycki 2018-02-22 17:04 ` Fredrik Noring 2018-02-18 8:47 ` Fredrik Noring 2018-02-20 14:41 ` Maciej W. Rozycki 2018-02-22 17:27 ` Fredrik Noring 2018-02-11 8:01 ` [RFC] MIPS: R5900: Workaround for CACHE instruction near branch delay slot Fredrik Noring 2018-02-11 11:16 ` Aw: " "Jürgen Urban" 2018-02-11 8:09 ` [RFC] MIPS: R5900: The ERET instruction has issues with delay slot and CACHE Fredrik Noring 2018-02-11 11:07 ` Aw: " "Jürgen Urban" 2018-02-11 8:29 ` [RFC] MIPS: R5900: Use mandatory SYNC.L in exception handlers Fredrik Noring 2018-02-11 10:33 ` Aw: " "Jürgen Urban" 2018-02-12 9:22 ` Maciej W. Rozycki 2018-02-12 9:22 ` Maciej W. Rozycki 2018-02-18 10:30 ` Fredrik Noring 2018-02-17 14:43 ` [RFC] MIPS: R5900: Workaround for saving and restoring FPU registers Fredrik Noring 2018-02-17 15:18 ` Maciej W. Rozycki 2018-02-17 17:47 ` Fredrik Noring 2018-02-17 19:33 ` Maciej W. Rozycki 2018-02-18 9:26 ` [RFC] MIPS: R5900: Workaround where MSB must be 0 for the instruction cache Fredrik Noring 2018-02-18 11:08 ` [RFC] MIPS: R5900: Add mandatory SYNC.P to all M[FT]C0 instructions Fredrik Noring 2018-03-03 12:26 ` [RFC] MIPS: PS2: Interrupt request (IRQ) support Fredrik Noring 2018-03-03 13:09 ` Maciej W. Rozycki 2018-03-03 14:14 ` Fredrik Noring 2018-04-09 15:51 ` Fredrik Noring 2018-03-18 10:45 ` Fredrik Noring 2018-03-19 19:15 ` Thomas Gleixner 2018-06-18 18:52 ` [RFC v2] " Fredrik Noring 2017-10-30 17:55 ` [PATCH v2] MIPS: Add basic R5900 support Fredrik Noring 2017-11-24 10:26 ` Maciej W. Rozycki 2017-11-24 10:26 ` Maciej W. Rozycki 2017-11-24 10:39 ` Maciej W. Rozycki 2017-11-24 10:39 ` Maciej W. Rozycki 2017-09-20 14:07 ` Fredrik Noring 2017-09-21 21:07 ` Maciej W. Rozycki 2017-09-21 21:07 ` Maciej W. Rozycki 2017-09-22 16:37 ` Fredrik Noring [this message] 2017-09-22 16:37 ` Fredrik Noring 2017-09-29 23:55 ` Maciej W. Rozycki 2017-09-29 23:55 ` Maciej W. Rozycki 2017-09-30 18:26 ` Fredrik Noring 2017-10-02 9:11 ` Maciej W. Rozycki 2017-10-02 9:11 ` Maciej W. Rozycki 2017-10-03 19:49 ` Fredrik Noring 2017-10-05 19:04 ` Fredrik Noring 2017-10-06 20:28 ` Fredrik Noring 2017-10-15 16:39 ` Fredrik Noring 2017-10-17 12:23 ` Maciej W. Rozycki 2017-10-17 12:23 ` Maciej W. Rozycki 2017-10-21 18:00 ` Fredrik Noring 2017-10-23 16:10 ` Maciej W. Rozycki 2017-10-23 16:10 ` Maciej W. Rozycki 2017-09-21 18:11 ` Paul Burton 2017-09-21 18:11 ` Paul Burton 2017-09-21 19:48 ` Maciej W. Rozycki 2017-09-21 19:48 ` Maciej W. Rozycki 2017-10-29 18:42 ` Fredrik Noring
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=20170922163753.GA2415@localhost.localdomain \ --to=noring@nocrew.org \ --cc=linux-mips@linux-mips.org \ --cc=macro@imgtec.com \ /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.