Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp327963pxf; Thu, 1 Apr 2021 02:08:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyS8ckkefO9+3GFeLmdB36I1/ZvP+yLz/3hubxQ+HZmMch6lEqMG5z/UjcZozajfLL7R6RS X-Received: by 2002:a05:6402:158d:: with SMTP id c13mr8600295edv.297.1617268126989; Thu, 01 Apr 2021 02:08:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617268126; cv=none; d=google.com; s=arc-20160816; b=TRGuLiZRVyBWbJeOnWIHwfWAzbVMiOtIaTxPVqS1jF+uoAFB3v9NzS2LaZKpRw+Oh7 pXrrJHm7QZjEgKelUm6ZS/kcWlSinigL0/lQnOizFI8UU3UQf8IeTRwbrBlTlY4XmTWk 68jlucHpdrH9oO5iNlMGxpHLpM6THz86+N3myh45XwuhpN7HD6+Ys1xfafBwtexYzMjJ Qn3c5uaeGw2lw5XiL2Fynoo2bEPFs2a6g2xZZHOCJzrXu38PNiiM5uVYdorDK9oaUcVo 4zU3uEuO3TDa3xFedqxkR1SA9Ni92kQBsNBuMrwt+WPI6VaT1peno3HtVyYh9BNASKX/ z1Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=9ipvarUvXkxJLxLwuin9LTrAs2w+ctpHBIHuEhA8YB0=; b=UPkhOP3GAUErycCcnufPN1UEiTCmQYanzO7mHiX6abLZdr0XKOTG+749YkZzHBZuBq bgFKxSi5Zz8rn7b8rewmjMGibzkGNhUnyQURAAvFQKnpomdeL8AxjPaYGpBaDHlg9nJC N/bWOwx4Z6P0FgnqDPzII1F+jBYxJdmmlQAV5ZWvpL4x/w38cyBDIfKZc4DGud8hT9G1 eTfy9+1edVxSxqFs2ME5I1mM6gKGXQd6Pj8VH04GliNUjEVMnsRRF8GGDn1HMN+TEh9r fgdoD2UJi3x2YpM94O/wVwZ05BHE6byA4u8+X1xo/0Q4zX1cGBMjTuB1UkcOkzpbA5vc A8Bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jRRMVerE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oq7si3956532ejb.655.2021.04.01.02.08.25; Thu, 01 Apr 2021 02:08:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jRRMVerE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233527AbhDAJFD (ORCPT + 99 others); Thu, 1 Apr 2021 05:05:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:46362 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233383AbhDAJEe (ORCPT ); Thu, 1 Apr 2021 05:04:34 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C408610A5; Thu, 1 Apr 2021 09:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617267874; bh=muveIZy9ANXdY0khfktn7mV+Le3qqWgit/n0uDMsFok=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jRRMVerETfm1pofEK4SDc+PwF4vXH+mM6kDKa3yiEq6qjeWIcbz/812P6ebUyXTKe EmGgnmCCyfggYtjBeH+mkG77YN0ummtOhR/7wvYS44OIYLHtHBXOQ3DjS8mpfwHixN PkeihXAuLq2jfEoj2QPRqqm/jhlG40pAdZ4+NV81oFHi09g9ol2Zp5FZxsEaVZyGpq qtiSzk+18tbyH8LSo++b9bihBOWULevV4t74WKk5THWfvpe+Ya7W1hYzrsvP+Bdc67 D1QY+AAxov95hqjKE0GmIjcAfqCPwm4FFSIB0SvvCv8IiOVdVT0YU9NWseSYLMf6za yNTq0sBzhKFgg== Date: Thu, 1 Apr 2021 10:04:28 +0100 From: Will Deacon To: Rob Herring Cc: Catalin Marinas , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Jiri Olsa , Mark Rutland , Ian Rogers , Alexander Shishkin , Honnappa Nagarahalli , Zachary.Leaf@arm.com, Raphael Gault , Jonathan Cameron , Namhyung Kim , Itaru Kitayama , linux-arm-kernel , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event Message-ID: <20210401090427.GB8781@willie-the-truck> References: <20210311000837.3630499-1-robh@kernel.org> <20210311000837.3630499-3-robh@kernel.org> <20210330153125.GC6567@willie-the-truck> <20210331153845.GB7815@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 31, 2021 at 12:52:11PM -0500, Rob Herring wrote: > On Wed, Mar 31, 2021 at 10:38 AM Will Deacon wrote: > > > > On Tue, Mar 30, 2021 at 04:08:11PM -0500, Rob Herring wrote: > > > On Tue, Mar 30, 2021 at 12:09 PM Rob Herring wrote: > > > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon wrote: > > > > > The logic here feels like it > > > > > could with a bit of untangling. > > > > > > > > Yes, I don't love it, but couldn't come up with anything better. It is > > > > complicated by the fact that flags have to be set before we assign the > > > > counter and can't set/change them when we assign the counter. It would > > > > take a lot of refactoring with armpmu code to fix that. > > > > > > How's this instead?: > > > > > > if (armv8pmu_event_want_user_access(event) || !armv8pmu_event_is_64bit(event)) > > > event->hw.flags |= ARMPMU_EL0_RD_CNTR; > > > > > > /* > > > * At this point, the counter is not assigned. If a 64-bit counter is > > > * requested, we must make sure the h/w has 64-bit counters if we set > > > * the event size to 64-bit because chaining is not supported with > > > * userspace access. This may still fail later on if the CPU cycle > > > * counter is in use. > > > */ > > > if (armv8pmu_event_is_64bit(event) && > > > (!armv8pmu_event_want_user_access(event) || > > > armv8pmu_has_long_event(cpu_pmu) || (hw_event_id == > > > ARMV8_PMUV3_PERFCTR_CPU_CYCLES))) > > > event->hw.flags |= ARMPMU_EVT_64BIT; > > > > I thought there were some cases where we could assign cycles event to an > > event counter; does that not happen anymore? > > Yes, but if we hit that scenario when the user has asked for 64-bit > user access, then we return an error later when assigning the counter. > I think we can assume if users have gone to the trouble of requesting > 64-bit counters, then they can deal with ensuring they don't have > multiple users. > > Otherwise, the only way I see to simplify this is we only support > 64-bit counters in userspace when we have v8.5 PMU. I'm happy to start from that position, and then we can extend it later if there's a need. Will