From: Andrew Scull <ascull@google.com>
To: Steven Price <steven.price@arm.com>
Cc: "qwandor@google.com" <qwandor@google.com>,
"qperret@google.com" <qperret@google.com>,
Marc Zyngier <maz@kernel.org>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
Will Deacon <will@kernel.org>,
"wedsonaf@google.com" <wedsonaf@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
James Morse <James.Morse@arm.com>,
"dbrazdil@google.com" <dbrazdil@google.com>,
"kernel-team@android.com" <kernel-team@android.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"tabba@google.com" <tabba@google.com>
Subject: Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Fri, 3 Apr 2020 13:57:26 +0100 [thread overview]
Message-ID: <20200403125726.GA33049@google.com> (raw)
In-Reply-To: <1705907b-234c-6f56-1360-f598c8047d1d@arm.com>
On Fri, Mar 27, 2020 at 02:59:47PM +0000, Steven Price wrote:
> I proposed something similar a while ago[1], but Marc was concerned about
> the microarch detail[2] and hence I split the workaround into VHE/non-VHE.
>
> That said I'm not saying this is necessarily wrong, just that we'd need some
> more information on whether the non-VHE workaround is suitable for the CPUs
> we're currently forcing VHE on.
We noticed that both the nVHE and VHE workarounds share the same
assumption that the EPDx bits are not being cached in the TLB.
`__tlb_switch_to_guest_vhe` and `__tlb_switch_to_guest_nvhe` are both
setting EPDx as part of the workaround. However, neither handles the
possibility of a speculative AT being able to make use of a cached EPD=0
value in the TLB in order to allocate bad TLB entries.
If this is correct, the microarch concern appears to have been solved
already. Otherwise, or if we are unsure, we should go ahead and add the
TLB flushes to keep this safe.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-03 12:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 14:39 [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE} Andrew Scull
2020-03-27 14:59 ` Steven Price
2020-03-27 17:48 ` Andrew Scull
2020-03-27 17:52 ` Marc Zyngier
2020-03-27 18:09 ` Will Deacon
2020-03-28 11:23 ` Marc Zyngier
2020-03-30 10:06 ` Will Deacon
2020-04-03 12:57 ` Andrew Scull [this message]
2020-04-17 16:41 ` Will Deacon
2020-04-20 13:46 ` Steven Price
2020-03-27 16:11 ` James Morse
2020-03-27 16:59 ` Will Deacon
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=20200403125726.GA33049@google.com \
--to=ascull@google.com \
--cc=James.Morse@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=dbrazdil@google.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=qperret@google.com \
--cc=qwandor@google.com \
--cc=steven.price@arm.com \
--cc=tabba@google.com \
--cc=wedsonaf@google.com \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).