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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, 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 A1B60C64E7B for ; Thu, 3 Dec 2020 09:20:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18DE822245 for ; Thu, 3 Dec 2020 09:20:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729939AbgLCJUK (ORCPT ); Thu, 3 Dec 2020 04:20:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:50974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726003AbgLCJUK (ORCPT ); Thu, 3 Dec 2020 04:20:10 -0500 Date: Thu, 3 Dec 2020 09:19:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1606987168; bh=g4ZTxyDoJc2ofiLEywA7CSH7BT199Th4IfgPacy3FN8=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=ql0QhUGhdAJl7TpjBdm2ozOMwP7frnOPgrdvJQsFGtfROn++9HOOSD403Xj2DCuRP RjILnJ2mFMEhnhM9TWoaINr/w5kLWK/vcZ8AOherzLmqEOvJLhJLJPEADm01yYswRA d4GKnr0vXXcGQooxPydiYdBHVgohYVHIavNyH4GRvaHXMx43AOb8uEFCiva+5OucsL Rw1wr2LfwYhvfb8jrqmWHlnS1lnoeAZoZEXrI42OlcrBmkOHBX3Q6hT1SSN0iPMHQg XMXMVT4ra/Ae1GERYkbVVbbLkFgLC/Aqb4t1cRubyF9HZhLP3CA7fuN52bI9wKQhpb 8y+Px29AjV2FA== From: Will Deacon To: "liwei (GF)" Cc: Catalin Marinas , Mark Rutland , Suzuki K Poulose , Anshuman Khandual , Vincenzo Frascino , Marc Zyngier , Ionela Voinescu , Ard Biesheuvel , Amit Daniel Kachhap , Vladimir Murzin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, guohanjun@huawei.com Subject: Re: [PATCH v3] drivers/perf: Add support for ARMv8.3-SPE Message-ID: <20201203091922.GA30817@willie-the-truck> References: <20201127060322.29025-1-liwei391@huawei.com> <20201130100628.GB24098@willie-the-truck> <47201e85-7cf3-7c94-d1be-9c83ef8c3416@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47201e85-7cf3-7c94-d1be-9c83ef8c3416@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Dec 03, 2020 at 04:42:20PM +0800, liwei (GF) wrote: > On 2020/11/30 18:06, Will Deacon wrote: > > On Fri, Nov 27, 2020 at 02:03:22PM +0800, Wei Li wrote: > >> /* Perf callbacks */ > >> static int arm_spe_pmu_event_init(struct perf_event *event) > >> { > >> @@ -670,7 +686,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) > >> !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus)) > >> return -ENOENT; > >> > >> - if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0) > >> + if (arm_spe_event_to_pmsevfr(event) & arm_spe_pmsevfr_res0(spe_pmu->pmsver)) > >> return -EOPNOTSUPP; > >> > >> if (attr->exclude_idle) > >> @@ -937,6 +953,7 @@ static void __arm_spe_pmu_dev_probe(void *info) > >> fld, smp_processor_id()); > >> return; > >> } > >> + spe_pmu->pmsver = (u16)fld; > > > > ... which also means we should clamp this value now that we expose it to > > userspace. Otherwise, userspace can't rely on this field for anything. > > > > That said -- please can you tell me what userspace intends to do with > > this version number? > > > > In fact, it is only used in our testcase for now, which needs to know the real version the > chip has implemented, as these is no other way to get the info now. So i added it in the > probe message in v1 at first. If it's not needed, then let's not expose it yet. ABIs aren't cheap! > Especially we use the of_device_id "arm,statistical-profiling-extension-v1" and the > platform_device_id "arm,spe-v1". It's a little weird to ARMv8.3-SPE. > What exactly breaks? It looks like it should work fine to me, but I don't have any SPE systems to test on. The "v1" in the compatible string doesn't really do anything at the moment because we can probe everything other than the interrupt topology at runtime, so I wouldn't get hung up on that. > Further more i am wondering if we need to add the 'spe-v2' device_id. If > not, i think it's broken on a big.LITTLE system [1] as we can register > only one device and the driver will work incorrectly if the big and LITTLE > cores have different version of SPE. This is only an issue for ACPI, right? I don't think that was ever intended to work with big.LITTLE. See: pr_warn("ACPI: SPE must be homogeneous\n"); DT should handle it though. Anyway, please can you post a new version of this patch without the ABI changes? In other words, just including the RES0 part. Thanks, Will 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=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 9D178C63777 for ; Thu, 3 Dec 2020 09:20:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 330C2206A4 for ; Thu, 3 Dec 2020 09:20:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 330C2206A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MXItW6F3fnnkVq019RV4b/uXRxmA0zn1yXri93bgOyo=; b=Ok4eNjAFcvhqtpFm7ZzT6jQUZ lJNuKfGEdDogAsvHDwY/Vp+eustv9OUx56iE1XD0Cf6yTJKxTM3OxBqblJPPcEyVTH4Jh3JjDq+50 XlzHLwa1C3+fkN7mW+llTLHEmTzgIVXw5DbByrqH9eHX1ZU/6Dh1oFaGPnm60XWkOt9lGkxhjQKX1 0IUXDs/NSLrZlyfD2Tm8+ON/D/RHAY1lTQHz8QYr3ZuxUrl0ekPGtwzQy925xBeFbFaBUb1Bzs0eP UYuk8IVaexvK6A5wm1aZ1dhqqo800lNWe0XhgAVyXGUbTgw0p34IutwNzr255BtE6C+q6Sya2fEU6 91xv13Taw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkklw-0003aR-R9; Thu, 03 Dec 2020 09:19:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkklt-0003ZD-VC for linux-arm-kernel@lists.infradead.org; Thu, 03 Dec 2020 09:19:31 +0000 Date: Thu, 3 Dec 2020 09:19:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1606987168; bh=g4ZTxyDoJc2ofiLEywA7CSH7BT199Th4IfgPacy3FN8=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=ql0QhUGhdAJl7TpjBdm2ozOMwP7frnOPgrdvJQsFGtfROn++9HOOSD403Xj2DCuRP RjILnJ2mFMEhnhM9TWoaINr/w5kLWK/vcZ8AOherzLmqEOvJLhJLJPEADm01yYswRA d4GKnr0vXXcGQooxPydiYdBHVgohYVHIavNyH4GRvaHXMx43AOb8uEFCiva+5OucsL Rw1wr2LfwYhvfb8jrqmWHlnS1lnoeAZoZEXrI42OlcrBmkOHBX3Q6hT1SSN0iPMHQg XMXMVT4ra/Ae1GERYkbVVbbLkFgLC/Aqb4t1cRubyF9HZhLP3CA7fuN52bI9wKQhpb 8y+Px29AjV2FA== From: Will Deacon To: "liwei (GF)" Subject: Re: [PATCH v3] drivers/perf: Add support for ARMv8.3-SPE Message-ID: <20201203091922.GA30817@willie-the-truck> References: <20201127060322.29025-1-liwei391@huawei.com> <20201130100628.GB24098@willie-the-truck> <47201e85-7cf3-7c94-d1be-9c83ef8c3416@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <47201e85-7cf3-7c94-d1be-9c83ef8c3416@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201203_041930_191098_EC726757 X-CRM114-Status: GOOD ( 26.33 ) 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 , Vladimir Murzin , Anshuman Khandual , Catalin Marinas , Suzuki K Poulose , guohanjun@huawei.com, linux-kernel@vger.kernel.org, Marc Zyngier , Amit Daniel Kachhap , Vincenzo Frascino , Ionela Voinescu , Ard Biesheuvel , 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+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Dec 03, 2020 at 04:42:20PM +0800, liwei (GF) wrote: > On 2020/11/30 18:06, Will Deacon wrote: > > On Fri, Nov 27, 2020 at 02:03:22PM +0800, Wei Li wrote: > >> /* Perf callbacks */ > >> static int arm_spe_pmu_event_init(struct perf_event *event) > >> { > >> @@ -670,7 +686,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) > >> !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus)) > >> return -ENOENT; > >> > >> - if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0) > >> + if (arm_spe_event_to_pmsevfr(event) & arm_spe_pmsevfr_res0(spe_pmu->pmsver)) > >> return -EOPNOTSUPP; > >> > >> if (attr->exclude_idle) > >> @@ -937,6 +953,7 @@ static void __arm_spe_pmu_dev_probe(void *info) > >> fld, smp_processor_id()); > >> return; > >> } > >> + spe_pmu->pmsver = (u16)fld; > > > > ... which also means we should clamp this value now that we expose it to > > userspace. Otherwise, userspace can't rely on this field for anything. > > > > That said -- please can you tell me what userspace intends to do with > > this version number? > > > > In fact, it is only used in our testcase for now, which needs to know the real version the > chip has implemented, as these is no other way to get the info now. So i added it in the > probe message in v1 at first. If it's not needed, then let's not expose it yet. ABIs aren't cheap! > Especially we use the of_device_id "arm,statistical-profiling-extension-v1" and the > platform_device_id "arm,spe-v1". It's a little weird to ARMv8.3-SPE. > What exactly breaks? It looks like it should work fine to me, but I don't have any SPE systems to test on. The "v1" in the compatible string doesn't really do anything at the moment because we can probe everything other than the interrupt topology at runtime, so I wouldn't get hung up on that. > Further more i am wondering if we need to add the 'spe-v2' device_id. If > not, i think it's broken on a big.LITTLE system [1] as we can register > only one device and the driver will work incorrectly if the big and LITTLE > cores have different version of SPE. This is only an issue for ACPI, right? I don't think that was ever intended to work with big.LITTLE. See: pr_warn("ACPI: SPE must be homogeneous\n"); DT should handle it though. Anyway, please can you post a new version of this patch without the ABI changes? In other words, just including the RES0 part. Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel