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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38093C433FE for ; Thu, 29 Sep 2022 18:54:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229801AbiI2Sya (ORCPT ); Thu, 29 Sep 2022 14:54:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229658AbiI2Sy1 (ORCPT ); Thu, 29 Sep 2022 14:54:27 -0400 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 989E71449DB; Thu, 29 Sep 2022 11:54:26 -0700 (PDT) Received: by mail-oi1-f176.google.com with SMTP id o64so2502737oib.12; Thu, 29 Sep 2022 11:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=u/LkYHvYR+btps55yDhNvqai2AlFnIqwkDLQGyvkZiA=; b=AfJZK4b1xSewAt0LhAIiWgbqxzQjkPUHV26A7sEprPbceGLdKN9euewPkxLjINbcmK x+JXuD1u+sD0jrQskrTGH0Gn1TJzv7pYyzdjwtDrYD9MhLouitHhw5Bqsftyx1Ra6954 6jDs2mCvf2h5wAugVipioDsCB6EzGEVujPoO2gCBm0cEYj825NgQgdZlpmVRqmQfiGf9 nawCi1YjtrPj2pbwhePTlAuoZNGQnKJ6noSyM5Cc729Nf9W80KM4H5GPGtfuSv+9aAym How3peOn10d/TwsFGTian3NoPPmPCTIH7EzGORxidOg7gAYbVFOq5YEoYjTXGVjpFU// QnUg== X-Gm-Message-State: ACrzQf0u0JPoS//BA1EITY85oDRnFETlS8Lbp6HtJbEIGb9S1LNJKz3B E2aetq8hjeq+SKms0dT6l6hdWch9HeXvv0V7TOI= X-Google-Smtp-Source: AMsMyM6erVnoONuNBkVi0YaF3+arwnhUw2NtLkwVkJQzfYCn/k3LhVGeCu1QBDwIlsKqQ8y2j9XEOPMrFFR8qp7zWhk= X-Received: by 2002:a05:6808:181e:b0:350:e92a:9ab1 with SMTP id bh30-20020a056808181e00b00350e92a9ab1mr2195276oib.209.1664477665895; Thu, 29 Sep 2022 11:54:25 -0700 (PDT) MIME-Version: 1.0 References: <20220914-arm-perf-tool-spe1-2-v2-v3-0-8189fc04dcc6@kernel.org> <20220914-arm-perf-tool-spe1-2-v2-v3-1-8189fc04dcc6@kernel.org> In-Reply-To: From: Namhyung Kim Date: Thu, 29 Sep 2022 11:54:14 -0700 Message-ID: Subject: Re: [PATCH v3 1/3] perf: Skip and warn on unknown format 'configN' attrs To: Rob Herring Cc: Peter Zijlstra , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Mark Rutland , Jiri Olsa , Leo Yan , linux-perf-users , James Clark , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 26, 2022 at 6:32 AM Rob Herring wrote: > > On Fri, Sep 16, 2022 at 1:12 PM Namhyung Kim wrote: > > > > On Wed, Sep 14, 2022 at 1:09 PM Rob Herring wrote: > > > > > > If the kernel exposes a new perf_event_attr field in a format attr, perf > > > will return an error stating the specified PMU can't be found. For > > > example, a format attr with 'config3:0-63' causes an error as config3 is > > > unknown to perf. This causes a compatibility issue between a newer > > > kernel with older perf tool. > > > > > > Before this change with a kernel adding 'config3' I get: > > > > > > $ perf record -e arm_spe// -- true > > > event syntax error: 'arm_spe//' > > > \___ Cannot find PMU `arm_spe'. Missing kernel support? > > > Run 'perf list' for a list of valid events > > > > > > Usage: perf record [] [] > > > or: perf record [] -- [] > > > > > > -e, --event event selector. use 'perf list' to list > > > available events > > > > > > After this change, I get: > > > > > > $ perf record -e arm_spe// -- true > > > WARNING: 'arm_spe_0' format 'inv_event_filter' requires 'perf_event_attr::config3' which is not supported by this version of perf! > > > [ perf record: Woken up 2 times to write data ] > > > [ perf record: Captured and wrote 0.091 MB perf.data ] > > > > > > To support unknown configN formats, rework the YACC implementation to > > > pass any config[0-9]+ format to perf_pmu__new_format() to handle with a > > > warning. > > > > It only handles configN formats but it might add a completely different > > name later, right? > > Right. An unknown configN is a warning. An unknown name is still an > error as before. Given that sysfs format attrs are for mapping fields > which could be anything to "generic" perf_event_attr fields, how would > we ever have anything other than configN? I'm not sure I'm following. It could be anything other than configN. But I don't object to this particular change as it's needed for current work. Later, we can fix the issue if another name comes in. Thanks, Namhyung