public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: ARM: do not handle Spectre V2 on Vexpress CA9
Date: Thu, 1 Nov 2018 14:01:43 +0000	[thread overview]
Message-ID: <20181101140143.GA27913@e107155-lin> (raw)
In-Reply-To: <42704270-8d9f-3f7a-9af1-4bd87f413815@arm.com>

On Thu, Nov 01, 2018 at 01:56:41PM +0000, Robin Murphy wrote:
> Hi Linus,
> 
> On 01/11/2018 12:54, Linus Walleij wrote:
> > Since the introduction of the Spectre V2 fixes for ARMv7,
> > especially the BPIALL workaround, the Versatile Express CA9
> > with its fragile CA9 core tile simply doesn't boot for me
> > anymore.
> > 
> > If I turn on low level debugging the boot log stops short
> > at:
> > 
> > smp: Bringing up secondary CPUs ...
> > GIC: PPI13 is secure or misconfigured
> > CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> > CPU1: Spectre v2: using BPIALL workaround
> > GIC: PPI13 is secure or misconfigured
> > CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> > CPU1: Spectre v2: using BPIALL workaround
> > 
> > This is pretty much consistent behaviour, I think it managed
> > to boot at one point but these fixes are definately rubbing
> > this CPU the wrong way.
> > 
> > This (not elegant) workaround tries to work around it by
> > simply not applying any Spectre v2 fixes on the ARM
> > Vexpress CA9. My other A9 platforms seem to work fine
> > with the fixes, so this appears to be related to the
> > fragility of the core tile on this one reference design,
> > so maybe it would be acceptable to mitigate it like this.
> > 
> > I don't know how much this could be related to my particular
> > specimen, it would be great if others with this machine
> > could verify the problem.
> 
> As far as I remember, the usual V2P_CA9 problem where the L2 cache locks up
> for unfathomable reasons can come and go reasonably consistently depending
> on the exact kernel configuration/version, and ultimately seems like it
> might be more sensitive to the general shape and timing of the early boot
> code than any particular feature. As such I'd be wary that there might still
> be some other combinations of options which would manage to boot with the
> mitigation left enabled, and others which won't even if (or at worst
> *because*) we do skip it.

Indeed, I was about ask if disabling L2 makes it any consistent.
We did try increasing the read/write/tag latencies in the past but never
got it fully consistent to push the change.

--
Regards,
Sudeep

  reply	other threads:[~2018-11-01 14:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 12:54 [PATCH] RFC: ARM: do not handle Spectre V2 on Vexpress CA9 Linus Walleij
2018-11-01 13:56 ` Robin Murphy
2018-11-01 14:01   ` Sudeep Holla [this message]
2018-11-01 15:11     ` Linus Walleij
2018-11-01 17:25   ` Russell King - ARM Linux
2018-11-01 21:36     ` Linus Walleij

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=20181101140143.GA27913@e107155-lin \
    --to=sudeep.holla@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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