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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B903BEB64DD for ; Mon, 14 Aug 2023 10:02:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=0BkJBzlo49g+447EiYBZtN1Sb/yKxIO+U63kdmchC5c=; b=s0DT59TJ5fXgDX ySDRm509pr/TzV2J5Mf7xxUGUmf9f+83s9P8J23jVuIEqjjgJB+YH75GQCvyxqOxPy+MGAEK2zrwr 4IpGLcF+5jtHplRfNty5P8If2NbAdzkT3blWJdEIgZ7DUOjVav+XRP1g+Ioglv2q1uM3Jx/rOq0ia peiSLsOqzzfOzD6pajrPOkoe6TD9gDGl++vPKwIyh3enCxmbPrwv53yVDA3+2i22QNP11o0IH3u45 Yhu0EtI3yHcaaxwj17y5d1LoM5sW0dxrSdXFNjz7XQQdv5slKoALmrF48QPql24hlJ49CQc5hPXVf pGq/ezrpDaon6UGyJWHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qVUOu-00GfQ6-0r; Mon, 14 Aug 2023 10:02:16 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qVUOl-00GfO8-0N for linux-arm-kernel@lists.infradead.org; Mon, 14 Aug 2023 10:02:08 +0000 Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-686e0213c0bso2557246b3a.1 for ; Mon, 14 Aug 2023 03:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692007324; x=1692612124; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=VEHQ1GcXOq53Dab+zMuzQTvtwyYcdquVeUtbNvaHWOU=; b=J8n1LwD7YQqqD+OMXwLUxYtQhyW8IbVjSZ6b92hvJKOpz6HTHWoZxRbb18TUNodwvZ J37PVrJf1TAiLPoaoGOJRI6QZkmlgB/zILlYxuyUABWsn8ZwEgGtfOoYm2KO/5vLMP/J oX80WVe/CaU87udWpAzqbBCUzb5cKrIOludcsxPs/SC8agwXd0oPDMzyiFuD1mmQ2oxA HOZzMEwPb5KMbhPOvcBDqhAXuC+Q/pqVqSDLdQhAi8orN8Rpbyz+ZwKTbmEmlw8ODcRj 4bgSZ22GwL0QBhXitxApnZi9aU3P1CaccvhVo6bGW+w2JkYLR9drKaE0q5BXJ8SUK2rK r9Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692007324; x=1692612124; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VEHQ1GcXOq53Dab+zMuzQTvtwyYcdquVeUtbNvaHWOU=; b=Cgq+Azx0YqRSciyr8HONwb8I2RJahMEKDN+JHNzod0SpYm8ZapizFOg7VEagB/Th/V H+d29dKmX0CcpXs98ZDAADI7ihnfMGQCDMPuUXJF4gNLibNlalydtB/3yZiNvkd83Bbj Cd4YhL5LEH+TPiBQCvyGOF0JlGWXTfNslu5QUONNKgZaTbrvTcMhwzhbFdBceTYwQ7vu 2F78TDPSW+/VessREpV+rDR0fKIhA1PblHbAWylJ8svLotmP8nuHwNKpDoB9yEgrnWVG yfyxzPWx3POqglfxBM0HJxZwnIRet6q7AX3HNiCPINqLRQmWcII/XGjkvfGARYWfawdE aelw== X-Gm-Message-State: AOJu0Yw7rHlQE98rf6xIeqTlOJIR9yMPaLNaWTmCOZJ4wGoex8TTyj77 oOV4cKCxxYV0/VWHl4/wH6O5Wg== X-Google-Smtp-Source: AGHT+IFtXQ+JjRdMcJ2DIlnBVrUvtOTbNWEKxiMz2Ldb8N2R3N3PRBqrFH/d1/DDuZN8TPtJOtYJ1Q== X-Received: by 2002:a05:6a00:2e84:b0:687:1c2c:7cf7 with SMTP id fd4-20020a056a002e8400b006871c2c7cf7mr8235847pfb.19.1692007323946; Mon, 14 Aug 2023 03:02:03 -0700 (PDT) Received: from leoy-huanghe.lan ([150.230.248.162]) by smtp.gmail.com with ESMTPSA id v8-20020aa78088000000b0068790c41ca2sm7592840pff.27.2023.08.14.03.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Aug 2023 03:02:03 -0700 (PDT) Date: Mon, 14 Aug 2023 18:01:54 +0800 From: Leo Yan To: Shijie Huang Cc: Marc Zyngier , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Huang Shijie , Mark Rutland , Will Deacon Subject: Re: [PATCH] KVM: arm64: pmu: Resync EL0 state on counter rotation Message-ID: <20230814100154.GB69080@leoy-huanghe.lan> References: <20230811180520.131727-1-maz@kernel.org> <20230814071627.GA3963214@leoy-huanghe> <5608d22d-47c3-2a03-a3d9-ba8ec51679a3@amperemail.onmicrosoft.com> <20230814084710.GA69080@leoy-huanghe.lan> <8640c3c7-b117-5754-6ac4-910988e5374f@amperemail.onmicrosoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8640c3c7-b117-5754-6ac4-910988e5374f@amperemail.onmicrosoft.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230814_030207_156327_2C8DC716 X-CRM114-Status: GOOD ( 19.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Shijie, On Mon, Aug 14, 2023 at 05:29:54PM +0800, Shijie Huang wrote: [...] > > Seems to me, based on Marc's patch, we need to apply below change. In > > below code, we don't need to change the perf core code and we can > > resolve it as a common issue for Arm PMU drivers. > > = > > = > > diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c > > index 121f1a14c829..8f9673cdadec 100644 > > --- a/arch/arm64/kvm/pmu.c > > +++ b/arch/arm64/kvm/pmu.c > > @@ -38,14 +38,20 @@ struct kvm_pmu_events *kvm_get_pmu_events(void) > > void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) > > { > > struct kvm_pmu_events *pmu =3D kvm_get_pmu_events(); > > + int resync; > > if (!kvm_arm_support_pmu_v3() || !pmu || !kvm_pmu_switch_needed(attr= )) > > return; > > + resync =3D pmu->events_guest !=3D set; > = > If we set two events in guest, the resync will set > = > For example: > = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 perf stat -e cycles:Gu, cycles:Gk > = > = > If so, this is not reasonble... You mean if set two guest events, the kvm_vcpu_pmu_resync_el0() will be invoked twice, and the second calling is not reasonable, right? I can accept this since I personally think this should not introduce much performance penalty. I understand your preference to call kvm_vcpu_pmu_resync_el0() from perf core layer, but this is not a common issue for all PMU events and crossing arches. Furthermore, even perf core rotates events, it's not necessarily mean we must restore events for guest in the case there have no event is enabled for guest. Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel