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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > Cc: James Morse <james.morse@xxxxxxx>
> > > Cc: Julien Thierry <julien.thierry.kdev@xxxxxxxxx>
> > > Cc: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
> > > Cc: Will Deacon <will@xxxxxxxxxx>
> > > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx
> > > Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
> > > ---
> > > 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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
