[PATCH v2 1/3] KVM: arm64: Print warning when cpu erratum can cause guests to deadlock

[Will Deacon]

On Thu, Jul 02, 2020 at 08:04:43AM -0600, Rob Herring wrote:
> On Thu, Jul 2, 2020 at 5:45 AM Will Deacon <will at kernel.org> wrote:
> >
> > On Wed, Jul 01, 2020 at 03:53:06PM -0600, Rob Herring wrote:
> > > If guests don't have certain CPU erratum work-arounds implemented, then
> > > there is a possibility a guest can deadlock the system. IOW, only trusted
> > > guests should be used on systems with the erratum.
> > >
> > > This is the case for Cortex-A57 erratum 832075.
> > >
> > > Cc: Marc Zyngier <maz at kernel.org>
> > > Cc: James Morse <james.morse at arm.com>
> > > Cc: Julien Thierry <julien.thierry.kdev at gmail.com>
> > > Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > Cc: Will Deacon <will at kernel.org>
> > > Cc: kvmarm at lists.cs.columbia.edu
> > > Signed-off-by: Rob Herring <robh at kernel.org>
> > > ---
> > >  arch/arm64/kvm/arm.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index 90cb90561446..e2f50fa4d825 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -1653,6 +1653,10 @@ int kvm_arch_init(void *opaque)
> > >               return -ENODEV;
> > >       }
> > >
> > > +     if (cpus_have_const_cap(ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE))
> > > +             kvm_info("Guests without required CPU erratum work-arounds can deadlock system!\n" \
> >
> > work-arounds => workarounds
> >
> > (mainly for consistency, I have no clue if this is a real word or not!).
> >
> > I'd also probably do erratum => errata given that you're about to add a
> > second one.
> 
> Humm, the plural is on workarounds. If I use a more standard singular
> vs. plural form like "CPU feature workarounds" vs "CPU features
> workarounds", the former seems more correct to me. (working around
> features may be a bit nonsensical, but big.LITTLE ;) )

Ok, "erratum" it is then!

One other thing on the actual workaround... Case B in the document says:

  | In Program Order,
  | 1. The core executes any load with device memory attributes.
  | 2. The core executes a store-exclusive or register read of PAR_EL1.

and the patch register sequence says:

  | Use the following write sequence to several IMPLEMENTATION DEFINED
  | registers to have the hardware insert a DMB SY after all load-exclusive and
  | store-exclusive instructions.

but that would mean that the sequence is effectively:

	LDR	Xa, [device address]
	STXR	Wb, Xc, [Xd]
	DMB	SY

Does that really prevent the deadlock?

Will