KVM ARM Archive on lore.kernel.org
 help / color / Atom feed
From: Will Deacon <will@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
	Jose.Marinho@arm.com, Catalin Marinas <catalin.marinas@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412
Date: Tue, 30 Jun 2020 09:36:19 +0100
Message-ID: <20200630083618.GA13574@willie-the-truck> (raw)
In-Reply-To: <bfe3f27495152e4888f2ab2c02dd13a4@kernel.org>

[+Jose]

On Tue, Jun 30, 2020 at 09:15:15AM +0100, Marc Zyngier wrote:
> On 2020-06-29 22:33, Rob Herring wrote:
> > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device
> > load
> > and a store exclusive or PAR_EL1 read can cause a deadlock.
> > 
> > The workaround requires a DMB SY before and after a PAR_EL1 register
> > read
> > and the disabling of KVM. KVM must be disabled to prevent the
> > problematic
> > sequence in guests' EL1. This workaround also depends on a firmware
> > counterpart to enable the h/w to insert DMB SY after load and store
> > exclusive instructions. See the errata document SDEN-1152370 v10 [1] for
> > more information.

Jose -- having an SMC interface to see if the firmware is holding up its
side of the bargian would be really helpful here. There's been one in
development for _months_ now; any update?

> This seems a bit extreme. Given that this CPU is most likely
> used in big-little systems, there is still a bunch of CPUs
> on which we could reliably execute guests. It is also likely
> that people could run trusted guests.
> 
> I would suggest printing a big fat warning and taining the
> kernel with TAINT_CPU_OUT_OF_SPEC, together with the required
> DSBs in the KVM code.

Honestly, I think a TAINT is pointless here and we shouldn't be in the
business of trying to police what people do with their systems when there's
absolutely nothing we can do to help them. After all, they can always
disable KVM themselves if they want to. The only sensible action you can
take on seeing the taint is to disable the workaround to get rid of it,
which is also the worst thing you can do! As another example, imagine if
we had the ability to detect whether or not firmware was setting the patch
registers. If we knew that it wasn't applying the workaround, would we
TAINT on entering userspace? I don't think so. We'd probably just print a
message when trying to apply the workaround, indicating that it was
incomplete and the system may deadlock.

Finally, we have another erratum that allows guests to deadlock the system
(Cortex-A57 832075) so ultimately it's up to the person deploying the system
to decide whether or not they can tolerate the risk of deadlock. In many
cases, it won't be an issue, but if it is and they require KVM, then the
part is dead in the water and Linux can't help with that.

Will
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 21:33 [PATCH 1/2] arm64: Add part number for Arm Cortex-A77 Rob Herring
2020-06-29 21:33 ` [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412 Rob Herring
2020-06-30  8:15   ` Marc Zyngier
2020-06-30  8:36     ` Will Deacon [this message]
2020-07-01 12:00       ` James Morse

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=20200630083618.GA13574@willie-the-truck \
    --to=will@kernel.org \
    --cc=Jose.Marinho@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=robh@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

KVM ARM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvmarm/0 kvmarm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvmarm kvmarm/ https://lore.kernel.org/kvmarm \
		kvmarm@lists.cs.columbia.edu
	public-inbox-index kvmarm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/edu.columbia.cs.lists.kvmarm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git