Received: by 10.223.185.116 with SMTP id b49csp3943556wrg; Tue, 6 Mar 2018 07:27:08 -0800 (PST) X-Google-Smtp-Source: AG47ELuR1uTtXJ8A43II3t8AuRhVwq6jzNT0zowMJX8SiIL5Ql3fyAT7KqYyCT//CAwTNec0TDQ8 X-Received: by 10.101.92.6 with SMTP id u6mr15435484pgr.440.1520350028325; Tue, 06 Mar 2018 07:27:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520350028; cv=none; d=google.com; s=arc-20160816; b=wiWWxgGuszzX/S4z1FU1D4IZQXCal5b+UtVR7qFMva8eMzyQXmcu+o0571RX9z6FMK EhLBRz/9VJhYucdpdUGw9ljQ7UVogpmai0kDv7+ht22Z7hQm92p150TnFVAJecJz5Vht JOmDglN6ax8nbZ8VkN1JTnFNxpZFktyw6wxJZjq+71INUgKyQn3G39xLr8Xz/+crUrMt ErzHb4w4oREednWfJ+09xBoGe8fjMOOspFcXwmacKKqmRl8a974ECOTHMQ4hbsuPshoy 9Lj0U37RGBz2qPTtHvsvgPCepctpmP8OQ7uniTxA7iVOi6AF8QHw2IFD7Z6oMsWm5YZi I6SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=lBcnLNRflqHEzBWub95qsDQZDx+dMBqnAhCjVyCG7pA=; b=dSPWc2NobipxMCyxm+441MvkYpC0iIW/kDb6bXzfCl4BfWUKjdO1fHPJinmIqbHb1i FQ0HJ0FUJpS4jF4uZDLVn4FnGvPnZrXQQGGklRi3BTAnLtUwUEpjZVI8D+ZIBDiCG6Le rEtTqkuaffTCQKehyoFyjzwWqLkIVYzQv3s6ORnDtpISE2Ne+IDOqyf6T+dst4bP7zQt uztthTObMlN35ruva6o+ACSSo1tWXicvk4ADYU9DqC7kMLuI/pnm2Ag/UVv+aNhQOeHP RAJ0pdS+Jb0TGD/M/3SwnAhF6YwPa5X3tW8ojfzttOWFvSLxD1Uy7U1iAwS+Ti3kDkNX wvNA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si9946509pgf.90.2018.03.06.07.26.54; Tue, 06 Mar 2018 07:27:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753873AbeCFPZj (ORCPT + 99 others); Tue, 6 Mar 2018 10:25:39 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:40102 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753792AbeCFPZh (ORCPT ); Tue, 6 Mar 2018 10:25:37 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3BA6314; Tue, 6 Mar 2018 07:25:37 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0D5483F53D; Tue, 6 Mar 2018 07:25:37 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 47CC81AE52A2; Tue, 6 Mar 2018 15:25:41 +0000 (GMT) Date: Tue, 6 Mar 2018 15:25:41 +0000 From: Will Deacon To: Shanker Donthineni Cc: Thomas Speier , Vikram Sethi , Sean Campbell , Marc Zyngier , Catalin Marinas , linux-kernel , linux-arm-kernel , kvmarm , Christoffer Dall Subject: Re: [PATCH] arm64: KVM: Use SMCCC_ARCH_WORKAROUND_1 for Falkor BP hardening Message-ID: <20180306152540.GC18477@arm.com> References: <1520027418-10646-1-git-send-email-shankerd@codeaurora.org> <20180305155614.GG6618@arm.com> <05c25982-4939-593f-ad30-bf496e879885@codeaurora.org> <20180305171529.GA12869@arm.com> <770bb422-7a53-06b9-a136-4e38a0a4bed2@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <770bb422-7a53-06b9-a136-4e38a0a4bed2@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 05, 2018 at 12:03:33PM -0600, Shanker Donthineni wrote: > On 03/05/2018 11:15 AM, Will Deacon wrote: > > On Mon, Mar 05, 2018 at 10:57:58AM -0600, Shanker Donthineni wrote: > >> On 03/05/2018 09:56 AM, Will Deacon wrote: > >>> On Fri, Mar 02, 2018 at 03:50:18PM -0600, Shanker Donthineni wrote: > >>>> @@ -199,33 +208,15 @@ static int enable_smccc_arch_workaround_1(void *data) > >>>> return 0; > >>>> } > >>>> > >>>> + if (((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR) || > >>>> + ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1)) > >>>> + cb = qcom_link_stack_sanitization; > >>> > >>> Is this just a performance thing? Do you actually see an advantage over > >>> always making the firmware call? We've seen minimal impact in our testing. > >>> > >> > >> Yes, we've couple of advantages using the standard SMCCC_ARCH_WOKAROUND_1 framework. > >> - Improves the code readability. > >> - Avoid the unnecessary MIDR checks on each vCPU exit. > >> - Validates ID_AA64PFR0_CVS2 feature for Falkor chips. > >> - Avoids the 2nd link stack sanitization workaround in firmware. > > > > What I mean is, can we drop qcom_link_stack_sanitization altogether and > > use the SMCCC interface for everything? > > > > No, We would like to keep it qcom_link_stack_sanitization for host kernel > since it takes a few CPU cycles instead of heavyweight SMCCC call. Is that something that you can actually measure in the workloads and benchmarks that you care about? If so, fine, but that doesn't seem to be the case for the Cortex cores we've looked at internally and it would be nice to avoid having different workarounds in the kernel just because the SMCCC interface wasn't baked in time, rather than because there's a meaningful performance difference. Will