All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	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:15:15 +0100	[thread overview]
Message-ID: <bfe3f27495152e4888f2ab2c02dd13a4@kernel.org> (raw)
In-Reply-To: <20200629213321.2953022-2-robh@kernel.org>

Hi Rob,

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.
> 

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.

Thanks,

         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: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Will Deacon <will@kernel.org>,
	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:15:15 +0100	[thread overview]
Message-ID: <bfe3f27495152e4888f2ab2c02dd13a4@kernel.org> (raw)
In-Reply-To: <20200629213321.2953022-2-robh@kernel.org>

Hi Rob,

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.
> 

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.

Thanks,

         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

  reply	other threads:[~2020-06-30  8:15 UTC|newest]

Thread overview: 10+ 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 ` Rob Herring
2020-06-29 21:33 ` [PATCH 2/2] arm64: Add workaround for Arm Cortex-A77 erratum 1508412 Rob Herring
2020-06-29 21:33   ` Rob Herring
2020-06-30  8:15   ` Marc Zyngier [this message]
2020-06-30  8:15     ` Marc Zyngier
2020-06-30  8:36     ` Will Deacon
2020-06-30  8:36       ` Will Deacon
2020-07-01 12:00       ` James Morse
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=bfe3f27495152e4888f2ab2c02dd13a4@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robh@kernel.org \
    --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.