All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Marc Zyngier <Marc.Zyngier@arm.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523
Date: Mon, 14 Sep 2015 16:58:54 +0100	[thread overview]
Message-ID: <20150914155854.GF23878@arm.com> (raw)
In-Reply-To: <1442244988.3549.313.camel@citrix.com>

Hi Ian,

On Mon, Sep 14, 2015 at 04:36:28PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-14 at 16:06 +0100, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to the guest effectively running with junk in the DACR
> > and running into unexpected domain faults.
> 
> Thanks for the CC, dropping down to just the Xen folks/list and you guys.
> 
> The errata doc I've got doesn't yet cover this, so I've a few questions.

It should be updated in the next few days, but I wanted to get this out
ASAP since it's quite easy to hit under KVM (particularly with the new
domain-based PAN implementation for arch/arm/).

> > This patch works around the issue by re-ordering our restoration of the
> > AArch32 register aliases so that they happen before the AArch64 system
> > registers. Ensuring that the registers are restored in this order
> > guarantees that they will be correctly synchronised by the core.
> 
> Is it required that the AArch32 aliases are all restored strictly before
> the AArch64 sysregs, or just that at least one sysreg is restored after
> DACR32_EL2 (or a specific one?)?

Take your pick from: SCTLR_EL1, TCR_EL1, TTBR0_EL1, TTBR1_EL1, or
CONTEXTIDR_EL1. Writing any of those after DACR32_EL2 will avoid the
erratum.

> The Xen ctxt switch code[0] has DACR_EL2 in the midst of it all, and
> certainly followed by some sysregs, which I've got my fingers crossed
> happens to be sufficient (other than maybe adding a comment).

It looks like you restore CONTEXTIDR_EL1 fairly late, so you should be
ok.

Will

  reply	other threads:[~2015-09-14 15:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14 15:06 [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523 Will Deacon
2015-09-14 15:06 ` Will Deacon
2015-09-14 15:06 ` Will Deacon
2015-09-14 15:36 ` Ian Campbell
2015-09-14 15:58   ` Will Deacon [this message]
2015-09-14 23:08     ` Julien Grall
2015-09-15  8:40       ` Ian Campbell
2015-09-14 15:46 ` Marc Zyngier
2015-09-14 15:46   ` Marc Zyngier
2015-09-14 17:01   ` Will Deacon
2015-09-14 17:01   ` Will Deacon
2015-09-14 17:01     ` Will Deacon
2015-09-15 19:00   ` Christoffer Dall
2015-09-15 19:00     ` Christoffer Dall
2015-09-15 19:00   ` Christoffer Dall
2015-09-14 15:46 ` Marc Zyngier
  -- strict thread matches above, loose matches on Subject: below --
2015-09-14 15:06 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=20150914155854.GF23878@arm.com \
    --to=will.deacon@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=ian.campbell@citrix.com \
    --cc=xen-devel@lists.xenproject.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.