Re: [PATCH v3] arm64: Unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}

From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Steven Price <steven.price@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3] arm64: Unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Mon, 04 May 2020 12:13:02 +0100	[thread overview]
Message-ID: <7b3cc0b0a3fa6d08d8c8413e4498d485@kernel.org> (raw)
In-Reply-To: <20200504105539.GA4879@willie-the-truck>

On 2020-05-04 11:55, Will Deacon wrote:
> On Mon, May 04, 2020 at 10:48:58AM +0100, Andrew Scull wrote:
>> Errata 1165522, 1319367 and 1530923 each allow TLB entries to be
>> allocated as a result of a speculative AT instruction. In order to
>> avoid mandating VHE on certain affected CPUs, apply the workaround to
>> both the nVHE and the VHE case for all affected CPUs.
>> 
>> Signed-off-by: Andrew Scull <ascull@google.com>
>> CC: Marc Zyngier <maz@kernel.org>
>> CC: James Morse <james.morse@arm.com>
>> CC: Suzuki K Poulose <suzuki.poulose@arm.com>
>> CC: Will Deacon <will@kernel.org>
>> CC: Steven Price <steven.price@arm.com>
>> ---
>> From v2 <20200422161346.67325-1-ascull@google.com>:
>>  - const_cap -> final_cap merge correction
>>  - based on 5.7 rc4
>> ---
>>  arch/arm64/Kconfig                | 39 
>> ++++++++++++++-----------------
>>  arch/arm64/include/asm/cpucaps.h  | 15 ++++++------
>>  arch/arm64/include/asm/kvm_host.h |  4 ----
>>  arch/arm64/include/asm/kvm_hyp.h  |  2 +-
>>  arch/arm64/kernel/cpu_errata.c    | 25 +++++++++-----------
>>  arch/arm64/kvm/hyp/switch.c       |  6 ++---
>>  arch/arm64/kvm/hyp/sysreg-sr.c    |  6 +++--
>>  arch/arm64/kvm/hyp/tlb.c          | 11 +++++----
>>  8 files changed, 50 insertions(+), 58 deletions(-)
> 
> Acked-by: Will Deacon <will@kernel.org>
> 
> We'll probably run into some trivial conflicts with the arm64 tree, but
> I'm happy to put this on a branch if it helps. Marc?

I'd rather we avoid the conflicts by not repainting all the capabilities
and just leave a capability unused until the next one fills in the slot.
But otherwise, I'll take a stable branch.

Also the current state of the KVM/arm tree is a bit crap as none of the
fixes have made it into Linus' tree yet, and I don't have a good base
for the current queue (the welcome-home branch could create havoc).

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