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=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 C330CC433E0 for ; Wed, 29 Jul 2020 07:44:20 +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 8F51620838 for ; Wed, 29 Jul 2020 07:44:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lGOdrvRO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F51620838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com 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: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=V4cJwpOEHtr8XnU0Gzmuv9YSsaRyXO9vpbcu2oVDGco=; b=lGOdrvROH7/2IFKza/0tb4bzt Ehs/w2MpejxZrwFO+wDXGzVQl6yCp0scpSXSw5Km65esjUbotfev5KdtHFC4cf3toeYAf2oYJz2Xc +eG4bUGAdX0OL7FmEzBev3ZNJJ2M2vuojml19NT0LhRw5rLpgAsPv8k13KCTaRwEoRXMX3jrC16n+ I1vs+nASo92ZHRW3E0wgaVWspsP9pD0Sb+8G+ysbjccQRCPoI635UjGkrz70xuyrkuxkqDRs9Y0yv g6gK+/W9/j4U57Z6+7kIG+Cpz1aiTd9tRAzwwTRF+GKKX5XX97/k362BeG0L/0R5ryx0nR7Mi0o63 JpP2B8clg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0gk3-00027W-SQ; Wed, 29 Jul 2020 07:43:11 +0000 Received: from szxga07-in.huawei.com ([45.249.212.35] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0gjv-00023P-4Y for linux-arm-kernel@lists.infradead.org; Wed, 29 Jul 2020 07:43:04 +0000 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 7C583CB271A10AF009FB; Wed, 29 Jul 2020 15:42:57 +0800 (CST) Received: from [10.174.178.63] (10.174.178.63) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.487.0; Wed, 29 Jul 2020 15:42:46 +0800 Subject: Re: [PATCH 2/4] perf: arm-spe: Add support for ARMv8.3-SPE To: Leo Yan References: <20200724091607.41903-1-liwei391@huawei.com> <20200724091607.41903-3-liwei391@huawei.com> <20200729062951.GE4343@leoy-ThinkPad-X240s> <20200729072844.GH4343@leoy-ThinkPad-X240s> From: "liwei (GF)" Message-ID: Date: Wed, 29 Jul 2020 15:42:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.0 MIME-Version: 1.0 In-Reply-To: <20200729072844.GH4343@leoy-ThinkPad-X240s> X-Originating-IP: [10.174.178.63] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200729_034303_484040_0116C73A X-CRM114-Status: GOOD ( 14.90 ) 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 , Will Deacon , Suzuki K Poulose , Alexander Shishkin , Catalin Marinas , Adrian Hunter , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, zhangshaokun@hisilicon.com, Peter Zijlstra , Ingo Molnar , James Clark , guohanjun@huawei.com, Namhyung Kim , Jiri Olsa , 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 Leo, On 2020/7/29 15:28, Leo Yan wrote: > On Wed, Jul 29, 2020 at 03:21:20PM +0800, liwei (GF) wrote: > > [...] > >>>> @@ -354,8 +372,38 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet, char *buf, >>>> } >>>> case ARM_SPE_OP_TYPE: >>>> switch (idx) { >>>> - case 0: return snprintf(buf, buf_len, "%s", payload & 0x1 ? >>>> - "COND-SELECT" : "INSN-OTHER"); >>>> + case 0: { >>>> + if (payload & 0x8) { >>> >>> Some nitpicks for packet format checking ... >>> >>> For SVE operation, the payload partten is: 0b0xxx1xx0. >>> >>> So it's good to check the partten like: >>> >>> /* SVE operation subclass is: 0b0xxx1xx0 */ >>> if ((payload & 0x8081) == 0x80) { >>> .... >>> } >>> >>> If later the packet format is extended, this will not introduce any >>> confliction. >> >> Get it, but i think what you are really meaning is: >> if ((payload & 0x89) == 0x80) { >> ... >> } > > Yes. > >>> >>>> + size_t blen = buf_len; >>>> + >>>> + ret = snprintf(buf, buf_len, "SVE-OTHER"); >>>> + buf += ret; >>>> + blen -= ret; >>>> + if (payload & 0x2) { >>> >>> Here should express as binary results: " FP" or " INT". >> >> I think this is a style choice, i add these just like the current code where >> processing "AT", "EXCL", "AR", "COND" and so on. So should we modify all the corresponding code together? > > Okay, understood. Let's just follow the existed style and later can > enhance the output log with more readable format. > > [...] > >>> >>>> + ret = snprintf(buf, buf_len, " FP"); >>>> + buf += ret; >>>> + blen -= ret; >>>> + } >>>> + if (payload & 0x4) { >>>> + ret = snprintf(buf, buf_len, " PRED"); >>> >>> Here should express as binary results: " PRED" or " NOT-PRED". >> >> Ditto. >> >>> >>>> + buf += ret; >>>> + blen -= ret; >>>> + } >>>> + if (payload & 0x70) { >>> >>> This is incorrect. If bits[6:4] is zero, it presents vector length is 32 bits. >>> >> >> I am a little confused here. >> Refer to the ARM DDI 0487F.b (ID040120), page D10-2830, if bits[6:4] is zero, >> it presents vector length is 32 bits indeed. > > Yes, if bits[6:4] is zero, your current code will not output any info. > Yes, thanks for spotting this. And thanks for you review. Thanks, Wei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel