From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2014 20:39:40 +0100 (CET) Received: from multi.imgtec.com ([194.200.65.239]:40308 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6825397AbaA0TjiMX3Uo (ORCPT ); Mon, 27 Jan 2014 20:39:38 +0100 Date: Mon, 27 Jan 2014 19:39:08 +0000 From: Paul Burton To: David Daney CC: Subject: Re: [PATCH 14/15] mips: panic if vector register partitioning is implemented Message-ID: <20140127193908.GL970@pburton-linux.le.imgtec.org> References: <1390836194-26286-1-git-send-email-paul.burton@imgtec.com> <1390836194-26286-15-git-send-email-paul.burton@imgtec.com> <52E6A7B5.2040505@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <52E6A7B5.2040505@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Originating-IP: [192.168.154.79] X-SEF-Processed: 7_3_0_01192__2014_01_27_19_39_32 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 39114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: paul.burton@imgtec.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips 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 > >--- > > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from multi.imgtec.com ([194.200.65.239]:40308 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6825397AbaA0TjiMX3Uo (ORCPT ); Mon, 27 Jan 2014 20:39:38 +0100 Date: Mon, 27 Jan 2014 19:39:08 +0000 From: Paul Burton Subject: Re: [PATCH 14/15] mips: panic if vector register partitioning is implemented Message-ID: <20140127193908.GL970@pburton-linux.le.imgtec.org> References: <1390836194-26286-1-git-send-email-paul.burton@imgtec.com> <1390836194-26286-15-git-send-email-paul.burton@imgtec.com> <52E6A7B5.2040505@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <52E6A7B5.2040505@gmail.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: David Daney Cc: linux-mips@linux-mips.org Message-ID: <20140127193908.5taduaDWXd1JuhdRiApJFvIww_hQEivgTNYCvO8xfSc@z> 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 > >--- > > 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