From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: qwandor@google.com, tabba@google.com,
Steven Price <steven.price@arm.com>,
wedsonaf@google.com, dbrazdil@google.com,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Sat, 28 Mar 2020 11:23:51 +0000 [thread overview]
Message-ID: <20200328112351.53f800ed@why> (raw)
In-Reply-To: <20200327180913.GA10454@willie-the-truck>
On Fri, 27 Mar 2020 18:09:14 +0000
Will Deacon <will@kernel.org> wrote:
> On Fri, Mar 27, 2020 at 05:52:59PM +0000, Marc Zyngier wrote:
> > On 2020-03-27 17:48, Andrew Scull wrote:
> > > Thanks, Steven. Could we look into the EPD* caching microarch details
> > > Marc was referring to for these A55 and A76 cores?
> >
> > Only the folks that have access to the RTL can tell you, unfortunately.
> >
> > Thankfully, there is a bunch of people on Cc that should be able to ping
> > the relevant teams and report back...
>
> Yup, otherwise I guess we can throw in the TLB invalidation after setting
> the EPDx bits until we have clarity from Arm. We wouldn't need to broadcast
> it, so it might not be too bad on performance. If it is, I suppose we could
> switch to a reserved VMID?
I'd like to avoid the reserved VMID if at all possible -- we already
have one for the host on nVHE, and I bet your patches are going to
create some interesting havoc^Wchanges in that area, as the host is now
a guest from the mm perspective. It isn't clear either whether a
reserved VMID really solves the problem either, as you could still
end-up with speculative PTWs. Can it be harmful to create conflicting
TLB entries if you never hit them?
But if we bring in TLB invalidation, I wonder whether the problem can
be mitigated solely with just that on the affected CPUs, and what the
impact would be.
/me eyes the D05 running its 32 guests...
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: qwandor@google.com, qperret@google.com,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
tabba@google.com, Steven Price <steven.price@arm.com>,
wedsonaf@google.com, Andrew Scull <ascull@google.com>,
James Morse <James.Morse@arm.com>,
dbrazdil@google.com, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Sat, 28 Mar 2020 11:23:51 +0000 [thread overview]
Message-ID: <20200328112351.53f800ed@why> (raw)
In-Reply-To: <20200327180913.GA10454@willie-the-truck>
On Fri, 27 Mar 2020 18:09:14 +0000
Will Deacon <will@kernel.org> wrote:
> On Fri, Mar 27, 2020 at 05:52:59PM +0000, Marc Zyngier wrote:
> > On 2020-03-27 17:48, Andrew Scull wrote:
> > > Thanks, Steven. Could we look into the EPD* caching microarch details
> > > Marc was referring to for these A55 and A76 cores?
> >
> > Only the folks that have access to the RTL can tell you, unfortunately.
> >
> > Thankfully, there is a bunch of people on Cc that should be able to ping
> > the relevant teams and report back...
>
> Yup, otherwise I guess we can throw in the TLB invalidation after setting
> the EPDx bits until we have clarity from Arm. We wouldn't need to broadcast
> it, so it might not be too bad on performance. If it is, I suppose we could
> switch to a reserved VMID?
I'd like to avoid the reserved VMID if at all possible -- we already
have one for the host on nVHE, and I bet your patches are going to
create some interesting havoc^Wchanges in that area, as the host is now
a guest from the mm perspective. It isn't clear either whether a
reserved VMID really solves the problem either, as you could still
end-up with speculative PTWs. Can it be harmful to create conflicting
TLB entries if you never hit them?
But if we bring in TLB invalidation, I wonder whether the problem can
be mitigated solely with just that on the affected CPUs, and what the
impact would be.
/me eyes the D05 running its 32 guests...
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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-03-28 11:24 UTC|newest]
Thread overview: 24+ 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:39 ` Andrew Scull
2020-03-27 14:59 ` Steven Price
2020-03-27 14:59 ` Steven Price
2020-03-27 17:48 ` Andrew Scull
2020-03-27 17:48 ` Andrew Scull
2020-03-27 17:52 ` Marc Zyngier
2020-03-27 17:52 ` Marc Zyngier
2020-03-27 18:09 ` Will Deacon
2020-03-27 18:09 ` Will Deacon
2020-03-28 11:23 ` Marc Zyngier [this message]
2020-03-28 11:23 ` Marc Zyngier
2020-03-30 10:06 ` Will Deacon
2020-03-30 10:06 ` Will Deacon
2020-04-03 12:57 ` Andrew Scull
2020-04-03 12:57 ` Andrew Scull
2020-04-17 16:41 ` Will Deacon
2020-04-17 16:41 ` Will Deacon
2020-04-20 13:46 ` Steven Price
2020-04-20 13:46 ` Steven Price
2020-03-27 16:11 ` James Morse
2020-03-27 16:11 ` James Morse
2020-03-27 16:59 ` Will Deacon
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=20200328112351.53f800ed@why \
--to=maz@kernel.org \
--cc=dbrazdil@google.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.