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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6E0EC433F5 for ; Thu, 6 Jan 2022 18:21:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 21FF14B22A; Thu, 6 Jan 2022 13:21:36 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSYN66bpwZDn; Thu, 6 Jan 2022 13:21:35 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F0AFC4B1DD; Thu, 6 Jan 2022 13:21:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EC8E04B1DD for ; Thu, 6 Jan 2022 13:21:32 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCMmqHGoMbv5 for ; Thu, 6 Jan 2022 13:21:31 -0500 (EST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B6B834B1DC for ; Thu, 6 Jan 2022 13:21:31 -0500 (EST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5670461D17; Thu, 6 Jan 2022 18:21:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF3AEC36AEB; Thu, 6 Jan 2022 18:21:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641493289; bh=zBpZGxgznYG2e8AhlNYg7DgwP3l3ot1s/+PwBHU4MOw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X/FW69DHeO1CF320pQ0Xt7H/Gfk3AT7KZLQRnaSJ+1Jt33JNJxuDkUxAZZYG21Q9Y 0KrbZ56oHt2ES0aOT+OVc+AnkVZ2NkLHQ4bskislGf5vTcqSMBxRl/6d01DdWuTpOJ Rh1xrUrvS2CXJWP3pzJt4s8WQISJV0RV+UgScpqVWNsiBWHNZo2wOMIer7DXQApT7M AAK1GYivIU+JIYM/UzuGofDxgSVeF/ve0RbKUeW8y0C+Vjo0fQG1+cMXgOXt942rXP su8HRLq5gTOtsqWZYWl58TMlaqIjUfETXeygkf0SY3BDaXUSK8dmcv2F4ZIazVyx6Q XNQhJ9OK6W90A== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n5XOB-00GPJ3-Rl; Thu, 06 Jan 2022 18:21:27 +0000 Date: Thu, 06 Jan 2022 18:21:27 +0000 Message-ID: <871r1kvi6w.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Subject: Re: [PATCH v3 0/4] KVM: arm64: Improve PMU support on heterogeneous systems In-Reply-To: References: <20211213152309.158462-1-alexandru.elisei@arm.com> <87bl0xzwu1.wl-maz@kernel.org> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, tglx@linutronix.de, mingo@redhat.com, peter.maydell@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: mingo@redhat.com, tglx@linutronix.de, will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 06 Jan 2022 12:07:38 +0000, Alexandru Elisei wrote: > > Hi Marc, > > On Thu, Dec 30, 2021 at 08:01:10PM +0000, Marc Zyngier wrote: > > Alex, > > > > On Mon, 13 Dec 2021 15:23:05 +0000, > > Alexandru Elisei wrote: > > > > > > (CC'ing Peter Maydell in case this might be of interest to qemu) > > > > > > The series can be found on a branch at [1], and the kvmtool support at [2]. > > > The kvmtool patches are also on the mailing list [3] and haven't changed > > > since v1. > > > > > > Detailed explanation of the issue and symptoms that the patches attempt to > > > correct can be found in the cover letter for v1 [4]. > > > > > > A summary of the problem is that on heterogeneous systems KVM will always > > > use the same PMU for creating the VCPU events for *all* VCPUs regardless of > > > the physical CPU on which the VCPU is running, leading to events suddenly > > > stopping and resuming in the guest as the VCPU thread gets migrated across > > > different CPUs. > > > > > > This series proposes to fix this behaviour by allowing the user to specify > > > which physical PMU is used when creating the VCPU events needed for guest > > > PMU emulation. When the PMU is set, KVM will refuse to the VCPU on a > > > physical which is not part of the supported CPUs for the specified PMU. The > > > restriction is that all VCPUs must use the same PMU to avoid emulating an > > > asymmetric platform. > > > > > > The default behaviour stays the same - without userspace setting the PMU, > > > events will stop counting if the VCPU is scheduled on the wrong CPU. > > > > > > Tested with a hacked version of kvmtool that does the PMU initialization > > > from the VCPU thread as opposed to from the main thread. Tested on > > > rockpro64 by testing what happens when all VCPUs having the same PMU, one > > > random VCPU having a different PMU than the other VCPUs and one random VCPU > > > not having the PMU set (each test was run 1,000 times on the little cores > > > and 1,000 times on the big cores). > > > > > > Also tested on an Altra by testing all VCPUs having the same PMU, all VCPUs > > > not having a PMU set, and one random VCPU not having the PMU set; the VM > > > had 64 threads in each of the tests and each test was run 10,000 times. > > > > Came back to this series, and found more problems. On top of the > > remarks I had earlier (the per-CPU data structures that really should > > per VM, the disappearing attribute size), what happens when event > > filters are already registered and that you set a specific PMU? > > This is a good point. When I looked at how the PMU event filter works, I > saw that KVM doesn't attempt to check that the events are actually > implemented on the PMU, but somehow skipped over the fact that the PMU > affects the total number of events available. That, but also the meaning of the events. Switching PMU after programmed event filters is really odd, as you don't know what you are filtering anymore (unless you stick to purely architected events). Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm