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 9E973C433F5 for ; Wed, 8 Dec 2021 08:07:13 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BvkcecEPMQbx/CokC5OKaBQpL2dA1SDNuRrWcoCBM78=; b=XjKwLUx8ljQu4CLyaVL1lfb2G3 PsRb+1usNrkXivXecbMN1Z+bwpRSceTu2fHtC7gzn3kCDn9bLMzPZo5DRkDL/t9iDMkiAwxHrqAy7 FzaY2129+3mcjF/r/z41fOMfgBuL5ExdDQkd7shk5XZuyqQMBlDd6AanuVkk1X9qSDKwIgtkgppOU 5JE0ExQI3csmh72EbWWqsQies5DP56717i41E9je5u4OLcgROKi2paHGuZST1m2/rHhXo4b0DH3fy B4+By3dSsNmfbO3XuUgG7XVTh4LgTu0icpWA2fnxpoBRLAIGOBKHoTl30zTLKUXP0OaOnRevyqsZp JbK3+kew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1murx5-00BekR-9C; Wed, 08 Dec 2021 08:05:23 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1murx1-00Bek6-4b for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 08:05:20 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id C865DB81FDB; Wed, 8 Dec 2021 08:05:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96C26C00446; Wed, 8 Dec 2021 08:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638950716; bh=KiAE85J9E4RUuyics28Az+nBcidehxYeo/Lbw+wpMQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ObTiW/Vz3YU9qpZmKY/k1mWzpvBI5obIV7BpJjWxDrGUTLpu2T7uPxOJDOrKQwOa4 tnbDOPwipMkj/0NJu6iKdUlQtW6QU+UkQftQsaCulBsbB0NVcVQH5iz8AtqMkO4s3C Fp3s4Fd1ukqWEahHrvBJ8gZ9l5Uzg2Bd+vAr/N6u/kFr8mn+ndy+zfed/bbI2IKoh4 eoafLHuTBkbaIcFmuNoww57QAcvX//nC/h2lbkHLHrr+DZeS7mKQs2TTn006OJQygL ZIm6bTdyjYmoPlnSabfELxY9TyO5fq9wBAyN1JMHt6DFktdWQOQKfVTMfDdzLkyDfU mLScl4bVfhjMw== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) 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 1murww-00AiF1-Mq; Wed, 08 Dec 2021 08:05:14 +0000 MIME-Version: 1.0 Date: Wed, 08 Dec 2021 08:05:14 +0000 From: Marc Zyngier To: Reiji Watanabe Cc: Alexandru Elisei , 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 Subject: Re: [PATCH v2 0/4] KVM: arm64: Improve PMU support on heterogeneous systems In-Reply-To: References: <20211206170223.309789-1-alexandru.elisei@arm.com> User-Agent: Roundcube Webmail/1.4.12 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: reijiw@google.com, 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_000519_510023_A6ED6AA5 X-CRM114-Status: GOOD ( 27.31 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Reji, On 2021-12-08 02:36, Reiji Watanabe wrote: > Hi Alex, > > On Mon, Dec 6, 2021 at 9:02 AM 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 brief 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. > > Just to confirm, this series provides an API for userspace to request > KVM to detect a wrong affinity setting due to a userspace bug so that > userspace can get an error at KVM_RUN instead of leading to events > suddenly stopping, correct ? More than that, it allows userspace to select which PMU will be used for their guest. The affinity setting is a byproduct of the PMU's own affinity. > >> The default behaviour stays the same - without userspace setting the >> PMU, >> events will stop counting if the VCPU is scheduled on the wrong CPU. > > Can't we fix the default behavior (in addition to the current fix) ? > (Do we need to maintain the default behavior ??) Of course we do. This is a behaviour that has been exposed to userspace for years, and *we don't break userspace*. > IMHO I feel it is better to prevent userspace from configuring PMU > for guests on such heterogeneous systems rather than leading to > events suddenly stopping even as the default behavior. People running KVM on asymmetric systems *strongly* disagree with you. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel