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

From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Steven Price <steven.price@arm.com>,
	James Morse <james.morse@arm.com>,
	Andrew Scull <ascull@google.com>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm64: Unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Thu, 30 Apr 2020 10:16:03 +0100	[thread overview]
Message-ID: <5f391a75142a8ae2263e52d37d73526d@kernel.org> (raw)
In-Reply-To: <20200429212120.GC8604@willie-the-truck>

On 2020-04-29 22:21, Will Deacon wrote:
> Hi Andrew,
> 
> On Wed, Apr 22, 2020 at 05:13:46PM +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 v1 <20200327143941.195626-1-ascull@google.com>:
>>   - Restored registers in VHE path
> 
> This largely looks good to me, but I don't understand these bits:
> 
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 8a1e81a400e0..651820f537fb 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -138,7 +138,7 @@ static void __hyp_text 
>> __activate_traps_nvhe(struct kvm_vcpu *vcpu)
>> 
>>  	write_sysreg(val, cptr_el2);
>> 
>> -	if (cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT_NVHE)) {
>> +	if (cpus_have_const_cap(ARM64_WORKAROUND_SPECULATIVE_AT)) {
> 
> It seems like you consistently replace cpus_have_final_cap() with
> cpus_have_const_cap(), but I can't figure out why that's required.

Seems like a bad conflict resolution. We definitely want to keep the
final_cap checks for anything that will run at EL2, and probably
everywhere else (if capabilities are not final by the time we hit KVM,
we have bigger problems to solve).

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