Thread (28 messages) 28 messages, 7 authors, 2017-02-08

[PATCH v4 2/4] arm64: Work around Falkor erratum 1003

From: Will Deacon <hidden>
Date: 2017-02-01 17:59:51
Also in: kvm, kvmarm, lkml

On Wed, Feb 01, 2017 at 05:49:34PM +0000, Catalin Marinas wrote:
On Wed, Feb 01, 2017 at 05:41:05PM +0000, Will Deacon wrote:
quoted
On Wed, Feb 01, 2017 at 05:36:09PM +0000, Catalin Marinas wrote:
quoted
On Wed, Feb 01, 2017 at 04:33:58PM +0000, Will Deacon wrote:
quoted
On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote:
quoted
On 01/31/2017 12:56 PM, Marc Zyngier wrote:
quoted
Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be
enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in
that case too, and hope that people do enable the HW version.
Okay, I'll do my best to add support for the SW PAN case. I rebased and
submitted v6 of the E1009 patch [1] so that it no longer depends on this
patch landing first, if you all are inclined to pick it up while work on
this E1003 patch continues.
The alternative is not enabling SW_PAN (at runtime) if this errata is
present, along with a warning stating that hardware-PAN should be
enabled in kconfig instead. Not sure what distributions will make of that
though.
The problem with this patch is that when ARM64_SW_TTBR0_PAN is enabled
and in the absence of hardware PAN (or ARM64_PAN disabled),
cpu_do_switch_mm is no longer called for user process switching, so the
workaround is pretty much useless.
Oh, I see what you mean now.
quoted
I'm ok with adding the Kconfig dependency below to
QCOM_FALKOR_ERRATUM_1003:

	depends on !ARM64_SW_TTBR0_PAN || ARM64_PAN

together with a run-time warning if ARM64_SW_TTBR0_PAN is being used.
That makes it look like hardware-PAN is the cause of the erratum.
With the right Kconfig comment we could make this clearer.
It's not just a comment though, the kconfig option for the workaround
will disappear from menuconfig as long as the dependencies aren't met.
The dependency is really that SW_PAN depends on !ERRATUM_1003, but that
doesn't work for the distributions.
quoted
Maybe
just select ARM64_PAN if the erratum workaround is selected, then
runtime warning if we find that the h/w doesn't have PAN but does have
the erratum (which should never fire)?
You still need this workaround even if you don't want any PAN (both sw
and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
a dependency. It's more like if you do need a PAN, make sure you only
use the hw one.
True, in the case that all PAN options are disabled we still want this
to work. How about:

  select ARM64_PAN if ARM64_SW_TTBR0_PAN

?

In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
config combination? Why not just have "PAN" that enables them both and
uses the hardware feature if it's there?

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help