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
