From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FE14C47247 for ; Fri, 8 May 2020 04:26:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 169C9206B8 for ; Fri, 8 May 2020 04:26:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726009AbgEHE00 (ORCPT ); Fri, 8 May 2020 00:26:26 -0400 Received: from foss.arm.com ([217.140.110.172]:43296 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725550AbgEHE0Z (ORCPT ); Fri, 8 May 2020 00:26:25 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 06A7530E; Thu, 7 May 2020 21:26:25 -0700 (PDT) Received: from [10.163.73.155] (unknown [10.163.73.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8DAA3F68F; Thu, 7 May 2020 21:26:22 -0700 (PDT) Subject: Re: [PATCH V3 02/16] arm64/cpufeature: Drop TraceFilt feature exposure from ID_DFR0 register To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Marc Zyngier , Mark Rutland , James Morse , Suzuki K Poulose , linux-kernel@vger.kernel.org References: <1588426445-24344-1-git-send-email-anshuman.khandual@arm.com> <1588426445-24344-3-git-send-email-anshuman.khandual@arm.com> <20200504202453.GA5012@willie-the-truck> <56cd3062-a0c2-6cdf-b7c6-c2b7bf56d23b@arm.com> <20200505104250.GA19710@willie-the-truck> From: Anshuman Khandual Message-ID: <26002f7f-865c-bcdb-8394-c8565bebeb5c@arm.com> Date: Fri, 8 May 2020 09:55:52 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200505104250.GA19710@willie-the-truck> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/2020 04:12 PM, Will Deacon wrote: > On Tue, May 05, 2020 at 12:20:41PM +0530, Anshuman Khandual wrote: >> On 05/05/2020 01:54 AM, Will Deacon wrote: >>> On Sat, May 02, 2020 at 07:03:51PM +0530, Anshuman Khandual wrote: >>>> ID_DFR0 based TraceFilt feature should not be exposed to guests. Hence lets >>>> drop it. >>>> >>>> Cc: Catalin Marinas >>>> Cc: Will Deacon >>>> Cc: Marc Zyngier >>>> Cc: Mark Rutland >>>> Cc: James Morse >>>> Cc: Suzuki K Poulose >>>> Cc: linux-arm-kernel@lists.infradead.org >>>> Cc: linux-kernel@vger.kernel.org >>>> >>>> Suggested-by: Mark Rutland >>>> Reviewed-by: Suzuki K Poulose >>>> Signed-off-by: Anshuman Khandual >>>> --- >>>> arch/arm64/kernel/cpufeature.c | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c >>>> index 6d032fbe416f..51386dade423 100644 >>>> --- a/arch/arm64/kernel/cpufeature.c >>>> +++ b/arch/arm64/kernel/cpufeature.c >>>> @@ -435,7 +435,6 @@ static const struct arm64_ftr_bits ftr_id_pfr1[] = { >>>> }; >>>> >>>> static const struct arm64_ftr_bits ftr_id_dfr0[] = { >>>> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0), >>> >>> Hmm, this still confuses me. Is this not now FTR_NONSTRICT? Why is that ok? >> >> Mark had mentioned about it earlier (https://patchwork.kernel.org/patch/11287805/) >> Did I misinterpret the first part ? Could not figure "capping the emulated debug >> features" part. Probably, Mark could give some more details. >> >> From the earlier discussion: >> >> * ID_DFR0 fields need more thought; we should limit what we expose here. >> I don't think it's valid for us to expose TraceFilt, and I suspect we >> need to add capping for debug features we currently emulate. > > Sorry, I for confused (again) by the cpufeature code :) I'm going to add > the following to my comment: > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index c1d44d127baa..9b05843d67af 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -53,6 +53,11 @@ > * arbitrary physical CPUs, but some features not present on the host are > * also advertised and emulated. Look at sys_reg_descs[] for the gory > * details. > + * > + * - If the arm64_ftr_bits[] for a register has a missing field, then this > + * field is treated as STRICT RES0, including for read_sanitised_ftr_reg(). > + * This is stronger than FTR_HIDDEN and can be used to hide features from > + * KVM guests. > */ > > #define pr_fmt(fmt) "CPU features: " fmt > Wondering if you will take this comment via a separate patch/branch or should I fold it here instead. > > However, I think we really want to get rid of ftr_generic_32bits[] entirely > and spell out all of the register fields, even just using comments for the > fields we're omitting: Should we do that later or in this series itself ? > > > @@ -425,7 +430,7 @@ static const struct arm64_ftr_bits ftr_id_pfr1[] = { > }; > > static const struct arm64_ftr_bits ftr_id_dfr0[] = { > - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0), > + /* 31:28 TraceFilt */ > S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0xf), /* PerfMon */ > ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), > ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0), > > > Longer term, I think we'll probably want to handle these within > ARM64_FTR_BITS, as we may end up with features that we want to hide from > KVM guests but not from the host kernel. Sure, but for now will fold the above changes here. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2D5BC47254 for ; Fri, 8 May 2020 04:26:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F9F0206B8 for ; Fri, 8 May 2020 04:26:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rQERv5pe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F9F0206B8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5cgu4L5yUka9N+MM3i4QpxikXbNcswEuEeTjXJpf79c=; b=rQERv5peJLRE0g ERj6KHayo14VbKOkv1dwwjKTWjrX0hyfvt4ooVoN6EXo5+poL+zhu7W2YtZdGjYFe4utiqpApgYRz qG+fYpkpSL5ekln+I0HpRMhHQoleSudHI3al/sEhX0jH6BZwSq8xA5Jabq1a4mPmWxWQ5jpyWAnjm 22TRAj4V/01kKAUlIw8Aed/qY+tdp/jFJOnxkxt4zoletW2aUp3xZBHX1i4xzfdUOUvGmjv1BBO8r g32pAWdxZAKfv80/C7aESpFwa5sSwt/hBoTDXM7JtGxxD2fyFQRTE+/qvtTwIbmWS4Z1ny0Xpp7y3 zLzN3g0l60EEJplgV8aQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jWuak-0007it-0k; Fri, 08 May 2020 04:26:30 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jWuag-0007iM-3l for linux-arm-kernel@lists.infradead.org; Fri, 08 May 2020 04:26:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 06A7530E; Thu, 7 May 2020 21:26:25 -0700 (PDT) Received: from [10.163.73.155] (unknown [10.163.73.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8DAA3F68F; Thu, 7 May 2020 21:26:22 -0700 (PDT) Subject: Re: [PATCH V3 02/16] arm64/cpufeature: Drop TraceFilt feature exposure from ID_DFR0 register To: Will Deacon References: <1588426445-24344-1-git-send-email-anshuman.khandual@arm.com> <1588426445-24344-3-git-send-email-anshuman.khandual@arm.com> <20200504202453.GA5012@willie-the-truck> <56cd3062-a0c2-6cdf-b7c6-c2b7bf56d23b@arm.com> <20200505104250.GA19710@willie-the-truck> From: Anshuman Khandual Message-ID: <26002f7f-865c-bcdb-8394-c8565bebeb5c@arm.com> Date: Fri, 8 May 2020 09:55:52 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200505104250.GA19710@willie-the-truck> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200507_212626_241882_971E8833 X-CRM114-Status: GOOD ( 27.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Suzuki K Poulose , Catalin Marinas , linux-kernel@vger.kernel.org, James Morse , Marc Zyngier , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 05/05/2020 04:12 PM, Will Deacon wrote: > On Tue, May 05, 2020 at 12:20:41PM +0530, Anshuman Khandual wrote: >> On 05/05/2020 01:54 AM, Will Deacon wrote: >>> On Sat, May 02, 2020 at 07:03:51PM +0530, Anshuman Khandual wrote: >>>> ID_DFR0 based TraceFilt feature should not be exposed to guests. Hence lets >>>> drop it. >>>> >>>> Cc: Catalin Marinas >>>> Cc: Will Deacon >>>> Cc: Marc Zyngier >>>> Cc: Mark Rutland >>>> Cc: James Morse >>>> Cc: Suzuki K Poulose >>>> Cc: linux-arm-kernel@lists.infradead.org >>>> Cc: linux-kernel@vger.kernel.org >>>> >>>> Suggested-by: Mark Rutland >>>> Reviewed-by: Suzuki K Poulose >>>> Signed-off-by: Anshuman Khandual >>>> --- >>>> arch/arm64/kernel/cpufeature.c | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c >>>> index 6d032fbe416f..51386dade423 100644 >>>> --- a/arch/arm64/kernel/cpufeature.c >>>> +++ b/arch/arm64/kernel/cpufeature.c >>>> @@ -435,7 +435,6 @@ static const struct arm64_ftr_bits ftr_id_pfr1[] = { >>>> }; >>>> >>>> static const struct arm64_ftr_bits ftr_id_dfr0[] = { >>>> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0), >>> >>> Hmm, this still confuses me. Is this not now FTR_NONSTRICT? Why is that ok? >> >> Mark had mentioned about it earlier (https://patchwork.kernel.org/patch/11287805/) >> Did I misinterpret the first part ? Could not figure "capping the emulated debug >> features" part. Probably, Mark could give some more details. >> >> From the earlier discussion: >> >> * ID_DFR0 fields need more thought; we should limit what we expose here. >> I don't think it's valid for us to expose TraceFilt, and I suspect we >> need to add capping for debug features we currently emulate. > > Sorry, I for confused (again) by the cpufeature code :) I'm going to add > the following to my comment: > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index c1d44d127baa..9b05843d67af 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -53,6 +53,11 @@ > * arbitrary physical CPUs, but some features not present on the host are > * also advertised and emulated. Look at sys_reg_descs[] for the gory > * details. > + * > + * - If the arm64_ftr_bits[] for a register has a missing field, then this > + * field is treated as STRICT RES0, including for read_sanitised_ftr_reg(). > + * This is stronger than FTR_HIDDEN and can be used to hide features from > + * KVM guests. > */ > > #define pr_fmt(fmt) "CPU features: " fmt > Wondering if you will take this comment via a separate patch/branch or should I fold it here instead. > > However, I think we really want to get rid of ftr_generic_32bits[] entirely > and spell out all of the register fields, even just using comments for the > fields we're omitting: Should we do that later or in this series itself ? > > > @@ -425,7 +430,7 @@ static const struct arm64_ftr_bits ftr_id_pfr1[] = { > }; > > static const struct arm64_ftr_bits ftr_id_dfr0[] = { > - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0), > + /* 31:28 TraceFilt */ > S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0xf), /* PerfMon */ > ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), > ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0), > > > Longer term, I think we'll probably want to handle these within > ARM64_FTR_BITS, as we may end up with features that we want to hide from > KVM guests but not from the host kernel. Sure, but for now will fold the above changes here. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel