All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Rob Herring <robh@kernel.org>, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 3/3] arm64: Add workaround for Arm Cortex-A77 erratum 1508412
Date: Fri, 21 Aug 2020 13:45:40 +0100	[thread overview]
Message-ID: <8c641833ff20d5a35981c456d4fe1d5a@kernel.org> (raw)
In-Reply-To: <20200821122633.GC6823@gaia>

On 2020-08-21 13:26, Catalin Marinas wrote:
> On Fri, Aug 21, 2020 at 01:12:10PM +0100, Will Deacon wrote:
>> On Fri, Aug 21, 2020 at 01:07:00PM +0100, Catalin Marinas wrote:
>> > On Mon, Aug 03, 2020 at 01:31:27PM -0600, Rob Herring wrote:
>> > > @@ -979,6 +980,14 @@
>> > >  		write_sysreg(__scs_new, sysreg);			\
>> > >  } while (0)
>> > >
>> > > +#define read_sysreg_par() ({						\
>> > > +	u64 par;							\
>> > > +	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
>> > > +	par = read_sysreg(par_el1);					\
>> > > +	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
>> > > +	par;								\
>> > > +})
>> >
>> > I was about to queue this up but one more point to clarify: can we get
>> > an interrupt at either side of the PAR_EL1 read and the handler do a
>> > device read, triggering the erratum? Do we need a DMB at exception
>> > entry/return?
>> 
>> Disabling irqs around the PAR access would be simpler, I think 
>> (assuming
>> this is needed).
> 
> This wouldn't work if it interrupts a guest.

If we take an interrupt either side of the PAR_EL1 read and that we
fully exit, the saving of PAR_EL1 on the way out solves the problem.

If we don't fully exit, but instead reenter the guest immediately
(fixup_guest_exit() returns true), we'd need a DMB at that point,
at least because of the GICv2 proxying code which performs device
accesses on the guest's behalf.

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: Catalin Marinas <catalin.marinas@arm.com>
Cc: Rob Herring <robh@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	James Morse <james.morse@arm.com>,
	Andrew Scull <ascull@google.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 v4 3/3] arm64: Add workaround for Arm Cortex-A77 erratum 1508412
Date: Fri, 21 Aug 2020 13:45:40 +0100	[thread overview]
Message-ID: <8c641833ff20d5a35981c456d4fe1d5a@kernel.org> (raw)
In-Reply-To: <20200821122633.GC6823@gaia>

On 2020-08-21 13:26, Catalin Marinas wrote:
> On Fri, Aug 21, 2020 at 01:12:10PM +0100, Will Deacon wrote:
>> On Fri, Aug 21, 2020 at 01:07:00PM +0100, Catalin Marinas wrote:
>> > On Mon, Aug 03, 2020 at 01:31:27PM -0600, Rob Herring wrote:
>> > > @@ -979,6 +980,14 @@
>> > >  		write_sysreg(__scs_new, sysreg);			\
>> > >  } while (0)
>> > >
>> > > +#define read_sysreg_par() ({						\
>> > > +	u64 par;							\
>> > > +	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
>> > > +	par = read_sysreg(par_el1);					\
>> > > +	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
>> > > +	par;								\
>> > > +})
>> >
>> > I was about to queue this up but one more point to clarify: can we get
>> > an interrupt at either side of the PAR_EL1 read and the handler do a
>> > device read, triggering the erratum? Do we need a DMB at exception
>> > entry/return?
>> 
>> Disabling irqs around the PAR access would be simpler, I think 
>> (assuming
>> this is needed).
> 
> This wouldn't work if it interrupts a guest.

If we take an interrupt either side of the PAR_EL1 read and that we
fully exit, the saving of PAR_EL1 on the way out solves the problem.

If we don't fully exit, but instead reenter the guest immediately
(fixup_guest_exit() returns true), we'd need a DMB at that point,
at least because of the GICv2 proxying code which performs device
accesses on the guest's behalf.

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-08-21 12:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 19:31 [PATCH v4 0/3] Cortex-A77 erratum 1508412 workaround Rob Herring
2020-08-03 19:31 ` Rob Herring
2020-08-03 19:31 ` [PATCH v4 1/3] KVM: arm64: Print warning when cpu erratum can cause guests to deadlock Rob Herring
2020-08-03 19:31   ` Rob Herring
2020-08-03 19:31 ` [PATCH v4 2/3] arm64: Add part number for Arm Cortex-A77 Rob Herring
2020-08-03 19:31   ` Rob Herring
2020-08-03 19:31 ` [PATCH v4 3/3] arm64: Add workaround for Arm Cortex-A77 erratum 1508412 Rob Herring
2020-08-03 19:31   ` Rob Herring
2020-08-21 12:07   ` Catalin Marinas
2020-08-21 12:07     ` Catalin Marinas
2020-08-21 12:12     ` Will Deacon
2020-08-21 12:12       ` Will Deacon
2020-08-21 12:26       ` Catalin Marinas
2020-08-21 12:26         ` Catalin Marinas
2020-08-21 12:45         ` Marc Zyngier [this message]
2020-08-21 12:45           ` Marc Zyngier
2020-08-21 14:05           ` Catalin Marinas
2020-08-21 14:05             ` Catalin Marinas
2020-08-21 17:02             ` Marc Zyngier
2020-08-21 17:02               ` Marc Zyngier
2020-08-21 17:51               ` Catalin Marinas
2020-08-21 17:51                 ` Catalin Marinas
2020-09-09 23:06                 ` Rob Herring
2020-09-09 23:06                   ` Rob Herring
2020-08-21 10:56 ` [PATCH v4 0/3] Cortex-A77 erratum 1508412 workaround Will Deacon
2020-08-21 10:56   ` Will Deacon
2020-08-21 18:15 ` Catalin Marinas

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=8c641833ff20d5a35981c456d4fe1d5a@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.