Re: [PATCH 14/15] mips: panic if vector register partitioning is implemented

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 27, 2014 at 11:56:07AM -0800, David Daney wrote:
> ....
> On 01/27/2014 11:39 AM, Paul Burton wrote:
> >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@xxxxxxxxxx>
> >>>---
> >>>  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. [...]
> 
> The CPU probing things are called so early that any panic() or BUG() here
> will result in absolutely no console output as this code is called before
> any console drivers are enabled.

Fair point, I'd overlooked that. v2 on its way.

Paul

> 
> So the choice is really:
> 
> panic(): No output on console and system is frozen/locked-up.
> 
> WARN(): Nice stack trace on console, theoretical lockup once userspace code
> starts executing.
> 
> You can probably guess which I think is the better option.
> 
> >
> >Thanks,
> >     Paul
> >
> >>>+	}
> >>>+
> >>>  	cpu_probe_vmbits(c);
> >>>
> >>>  #ifdef CONFIG_64BIT
> >>>
> >>
> >>
> >>To report this email as SPAM, please forward it to spam@xxxxxxxxxxxx
> >
> >
> >
> 
> 
> To report this email as SPAM, please forward it to spam@xxxxxxxxxxxx



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux