From: Paul Burton <paul.burton@imgtec.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: <linux-mips@linux-mips.org>
Subject: Re: [PATCH 14/15] mips: panic if vector register partitioning is implemented
Date: Mon, 27 Jan 2014 19:39:08 +0000 [thread overview]
Message-ID: <20140127193908.GL970@pburton-linux.le.imgtec.org> (raw)
In-Reply-To: <52E6A7B5.2040505@gmail.com>
On Mon, Jan 27, 2014 at 10:38:45AM -0800, David Daney wrote:
> ....
> On 01/27/2014 07:23 AM, Paul Burton wrote:
> >No current systems implementing MSA include support for vector register
> >partitioning which makes it somewhat difficult to implement support for
> >it in the kernel. Thus for the moment the kernel includes no such
> >support. However if the kernel were to be run on a system which
> >implemented register partitioning then it would not function correctly,
> >mishandling MSA disabled exceptions. Calling panic when run on a system
> >with vector register partitioning implemented ensures that we're not
> >caught out by this later but instead reminded to implement support once
> >such a system is available.
> >
> >Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> >---
> > arch/mips/kernel/cpu-probe.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> >index 852e085..003ba3c 100644
> >--- a/arch/mips/kernel/cpu-probe.c
> >+++ b/arch/mips/kernel/cpu-probe.c
> >@@ -1193,9 +1193,13 @@ void cpu_probe(void)
> > else
> > c->srsets = 1;
> >
> >- if (cpu_has_msa)
> >+ if (cpu_has_msa) {
> > c->msa_id = cpu_get_msa_id();
> >
> >+ if (c->msa_id & MSA_IR_WRPF)
> >+ panic("Vector register partitioning unimplemented!");
>
> You should probably use a WARN_ON() instead. There is no reason to crash
> the kernel for this condition is there?
>
Well mapping vector registers reuses the MSA disabled exception, so if
the kernel were to continue with my current code & userland were to
execute an MSA instruction I believe it would appear to hang. There
would be an initial MSA disabled exception which would lead the kernel
to enable MSA & return to userland to re-execute the MSA instruction.
Then another MSA disabled exception would occur because we'd need to
map a vector register, but the kernel doesn't understand so would
attempt to enable MSA & return again. Then another MSA disabled
exception, etc etc. So if the kernel were to continue then it would
probably want to disable MSA support entirely to avoid userland
appearing to just hang. Additionally since vector registers & FP
registers are aliased the same would apply to scalar FP (cop1)
instructions too, so we'd also need to disable the FPU. To me that all
seems like a lot of hassle to allow a crippled kernel to run on a system
that doesn't exist yet, so personally I'd rather the kernel just panics
as a safeguard. Then once some target system implements vector register
partitioning support for it can be implemented in the kernel.
Thanks,
Paul
> >+ }
> >+
> > cpu_probe_vmbits(c);
> >
> > #ifdef CONFIG_64BIT
> >
>
>
> To report this email as SPAM, please forward it to spam@websense.com
WARNING: multiple messages have this Message-ID (diff)
From: Paul Burton <paul.burton@imgtec.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 14/15] mips: panic if vector register partitioning is implemented
Date: Mon, 27 Jan 2014 19:39:08 +0000 [thread overview]
Message-ID: <20140127193908.GL970@pburton-linux.le.imgtec.org> (raw)
Message-ID: <20140127193908.5taduaDWXd1JuhdRiApJFvIww_hQEivgTNYCvO8xfSc@z> (raw)
In-Reply-To: <52E6A7B5.2040505@gmail.com>
On Mon, Jan 27, 2014 at 10:38:45AM -0800, David Daney wrote:
> ....
> On 01/27/2014 07:23 AM, Paul Burton wrote:
> >No current systems implementing MSA include support for vector register
> >partitioning which makes it somewhat difficult to implement support for
> >it in the kernel. Thus for the moment the kernel includes no such
> >support. However if the kernel were to be run on a system which
> >implemented register partitioning then it would not function correctly,
> >mishandling MSA disabled exceptions. Calling panic when run on a system
> >with vector register partitioning implemented ensures that we're not
> >caught out by this later but instead reminded to implement support once
> >such a system is available.
> >
> >Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> >---
> > arch/mips/kernel/cpu-probe.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> >index 852e085..003ba3c 100644
> >--- a/arch/mips/kernel/cpu-probe.c
> >+++ b/arch/mips/kernel/cpu-probe.c
> >@@ -1193,9 +1193,13 @@ void cpu_probe(void)
> > else
> > c->srsets = 1;
> >
> >- if (cpu_has_msa)
> >+ if (cpu_has_msa) {
> > c->msa_id = cpu_get_msa_id();
> >
> >+ if (c->msa_id & MSA_IR_WRPF)
> >+ panic("Vector register partitioning unimplemented!");
>
> You should probably use a WARN_ON() instead. There is no reason to crash
> the kernel for this condition is there?
>
Well mapping vector registers reuses the MSA disabled exception, so if
the kernel were to continue with my current code & userland were to
execute an MSA instruction I believe it would appear to hang. There
would be an initial MSA disabled exception which would lead the kernel
to enable MSA & return to userland to re-execute the MSA instruction.
Then another MSA disabled exception would occur because we'd need to
map a vector register, but the kernel doesn't understand so would
attempt to enable MSA & return again. Then another MSA disabled
exception, etc etc. So if the kernel were to continue then it would
probably want to disable MSA support entirely to avoid userland
appearing to just hang. Additionally since vector registers & FP
registers are aliased the same would apply to scalar FP (cop1)
instructions too, so we'd also need to disable the FPU. To me that all
seems like a lot of hassle to allow a crippled kernel to run on a system
that doesn't exist yet, so personally I'd rather the kernel just panics
as a safeguard. Then once some target system implements vector register
partitioning support for it can be implemented in the kernel.
Thanks,
Paul
> >+ }
> >+
> > cpu_probe_vmbits(c);
> >
> > #ifdef CONFIG_64BIT
> >
>
>
> To report this email as SPAM, please forward it to spam@websense.com
next prev parent reply other threads:[~2014-01-27 19:39 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 15:22 [PATCH 00/15] Initial MSA support Paul Burton
2014-01-27 15:22 ` Paul Burton
2014-01-27 15:23 ` [PATCH v2 01/15] mips: simplify FP context access Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-02-13 11:26 ` [PATCH v3 " Paul Burton
2014-02-13 11:26 ` Paul Burton
2014-01-27 15:23 ` [PATCH 02/15] mips: update outdated comment Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 03/15] mips: move & rename fpu_emulator_{save,restore}_context Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 04/15] mips: don't require FPU on sigcontext setup/restore Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 05/15] mips: replace hardcoded 32 with NUM_FPU_REGS in ptrace Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 06/15] mips: clear upper bits of FP registers on emulator writes Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 18:06 ` Sergei Shtylyov
2014-01-27 17:11 ` Paul Burton
2014-01-27 17:11 ` Paul Burton
2014-01-27 17:14 ` [PATCH v2 " Paul Burton
2014-01-27 17:14 ` Paul Burton
2014-01-27 15:23 ` [PATCH 07/15] mips: don't assume 64-bit FP registers for dump_{,task_}fpu Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 08/15] mips: don't assume 64-bit FP registers for FP regset Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 09/15] mips: don't assume 64-bit FP registers for context switch Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 10/15] mips: add MSA register definitions & access Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 11/15] mips: detect the MSA ASE Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 12/15] mips: basic MSA context switching support Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 13/15] mips: dumb MSA FP exception handler Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 15:23 ` [PATCH 14/15] mips: panic if vector register partitioning is implemented Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 18:38 ` David Daney
2014-01-27 19:39 ` Paul Burton [this message]
2014-01-27 19:39 ` Paul Burton
2014-01-27 19:56 ` David Daney
2014-01-28 14:20 ` Paul Burton
2014-01-28 14:20 ` Paul Burton
2014-01-28 14:28 ` [PATCH v2 14/15] mips: warn " Paul Burton
2014-01-28 14:28 ` Paul Burton
2014-01-27 15:23 ` [PATCH 15/15] mips: save/restore MSA context around signals Paul Burton
2014-01-27 15:23 ` Paul Burton
2014-01-27 19:50 ` David Daney
2014-01-27 20:06 ` Paul Burton
2014-01-27 20:06 ` Paul Burton
2014-02-13 11:27 ` [PATCH v2 " Paul Burton
2014-02-13 11:27 ` Paul Burton
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=20140127193908.GL970@pburton-linux.le.imgtec.org \
--to=paul.burton@imgtec.com \
--cc=ddaney.cavm@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox