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 229EAEB64DD for ; Thu, 13 Jul 2023 06:58:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234130AbjGMG6Z (ORCPT ); Thu, 13 Jul 2023 02:58:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234133AbjGMG6W (ORCPT ); Thu, 13 Jul 2023 02:58:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 498502683 for ; Wed, 12 Jul 2023 23:58:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D435661A32 for ; Thu, 13 Jul 2023 06:58:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EB0AC433C8; Thu, 13 Jul 2023 06:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689231499; bh=WeGq7pJ/lWaD/x1KtAFolxdHoYgIyeiaxVaJh7F/tU8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JxeQtPreIFIXZ2/mGVJB6eFOkTHgD0bwWcE8D/WX1POIOY3BWu5bxv9CeRVajCf6D 5EHqR0Rmu32zefWrWOPvGM57PhH6zpNDx/FEst4qf91MND8dgTYNFsqTEqvDP3FCqE 1IHXRo3axY1EwwPPiwTbeTTb75MJf5PgvY4fAxETIicldpwtarNOAh7JIv4c52Tuqf Dka8CUth0Aa0KSeAkmfTZnmSOIqZjHURFFhBKG2Tu2F47AI2AGzxwffUz+soq9+pqA uVVOZJ35gVESBegA+SdiqECh4iowQd8VKgWJk7PQ0hrS6lxC4vB1g7qvR3rAqrK5z0 HSwsfUXUIWTYQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qJqHI-00ChRC-RB; Thu, 13 Jul 2023 07:58:17 +0100 Date: Thu, 13 Jul 2023 07:56:39 +0100 Message-ID: <87bkgg9u54.wl-maz@kernel.org> From: Marc Zyngier To: "chenxiang (M)" Cc: , , , , Subject: Re: [PATCH] KVM: arm64: Fix the name of sys_reg_desc related to PMU In-Reply-To: <5c513a72-9ae9-22ca-a9a6-8b3c481e0921@hisilicon.com> References: <1689148505-13914-1-git-send-email-chenxiang66@hisilicon.com> <868rblwmpn.wl-maz@kernel.org> <5c513a72-9ae9-22ca-a9a6-8b3c481e0921@hisilicon.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: chenxiang66@hisilicon.com, oliver.upton@linux.dev, james.morse@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linuxarm@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 13 Jul 2023 03:35:39 +0100, "chenxiang (M)" wrote: >=20 > Hi Marc, >=20 >=20 > =E5=9C=A8 2023/7/12 =E6=98=9F=E6=9C=9F=E4=B8=89 16:36, Marc Zyngier =E5= =86=99=E9=81=93: > > On Wed, 12 Jul 2023 08:55:05 +0100, > > chenxiang wrote: > >> From: Xiang Chen > >>=20 > >> For those PMU system registers defined in sys_reg_descs[], use macro > >> PMU_SYS_REG() / PMU_PMEVCNTR_EL0 / PMU_PMEVTYPER_EL0 to define them, a= nd > >> later two macros call macro PMU_SYS_REG() actually. > >> Currently the input parameter of PMU_SYS_REG() is other macro which is > >> calculation formula of the value of system registers, so for example, = if > >> we want to "SYS_PMINTENSET_EL1" as the name of sys register, actually > >> the name will be as following: > >> (((3) << 19) | ((0) << 16) | ((9) << 12) | ((14) << 8) | ((1) << 5)) > >>=20 > >> To fix the issue, use the name as a input parameter of PMU_SYS_REG like > >> MTE_REG or EL2_REG. > > Why is the name relevant? Is this related to tracing? > I think It is not related to tracing. I find the issue when i want to > know which system reigsters are set > when on live migration and printk the name of sys_reg_desc in function > kvm_sys_reg_set_user, > find the name of some registers are abnormal as followings: >=20 > [ 227.145540] kvm_sys_reg_set_user 3427:SYS_FAR_EL1 > [ 227.158057] kvm_sys_reg_set_user 3427:SYS_PAR_EL1 > [ 227.170574] kvm_sys_reg_set_user 3427:(((3) << 19) | ((0) << 16) | > ((9) << 12) | ((14) << 8) | ((1) << 5)) > [ 227.188037] kvm_sys_reg_set_user 3427:(((3) << 19) | ((0) << 16) | > ((9) << 12) | ((14) << 8) | ((2) << 5)) > [ 227.205511] kvm_sys_reg_set_user 3427:SYS_MAIR_EL1 > [ 227.218117] kvm_sys_reg_set_user 3427:SYS_PIRE0_EL1 So what is this if not some form of tracing? I agree that it would be good to fix it, at least because the register name is smaller than the encoding, but the commit message should at least mention what this is used for. Thanks, M. --=20 Without deviation from the norm, progress is not possible.