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 284E9C433F5 for ; Sat, 8 Jan 2022 13:28:46 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dkaJJkKu9+lj4yIsnccQosbOxduPVGlqgfOvRmo24q4=; b=3jYHffkE1tU1V6 27KFVh6FKxE+tNmuW/BF+qy9XuMysbsuJFahm3ZKTZgwQONwmq4f2jpEA+xXugVORbPce9GmFGeui LB0vtN9pUTIgwyz6/RMrq2mXIc4kHlfBbYPkqAaxDRS2h5Cy1hlqN55RKQGOid6t60CG22V66jOBH 99tn01VMzqDsRnEGC/GWSF/45SQ1dNwpVC1uhW2aIUGCCX46xz2ST2xkaz2sCXEztvdKQzHy+zSFV WJQwwVi1LdKStDVS9yuQXQ55PNvCjLIYciA/8uMGfpsY3cMApr5Swni1Waf+byFOWB50PV4obcmPA +0K+fVdSGD/jrVVmldSw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6Bkl-006Uf5-Lv; Sat, 08 Jan 2022 13:27:27 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6Bkh-006UeC-DK for linux-arm-kernel@lists.infradead.org; Sat, 08 Jan 2022 13:27:25 +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 1A122B80907; Sat, 8 Jan 2022 13:27:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68868C36AEF; Sat, 8 Jan 2022 13:27:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641648440; bh=uSM4Zj5JvNVoUBtc+QSOLU6cDQhWwDB13DxfW7mQOFY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZsNnALMF6sjcWCBLmXeD9VHpGhK+utsEIWCgKHQV8mbY88dQGBGsYjdLMu5+ezPzo bUtTu1OBYzrd3EdnqRsrBB7n1S1tEliEP6u/BVeBtRZgWv5JBaiNt+i8yY011d+K7P KmF+a9Xia4Lh/Ld46M1Sx77I0wUvxlbRSLKtQX9rRAdxGu4ITi7qLJdhigxm16sekN epn43rt/K8CKUMpdRy6WjVeAwykM2ttAe5BKEo0oYIr9RPM6SWS968o1juT2iPJ5AR YZfFMYpWw054hjCErecXDwoKD7U7Bgi/oAaMfBSpzbgwgVxR01Jb1lZ4LYFH0CpT1r u/kOs+V4l05/g== 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 1n6Bkc-00GlD7-7y; Sat, 08 Jan 2022 13:27:18 +0000 Date: Sat, 08 Jan 2022 13:27:17 +0000 Message-ID: <87o84mtl1m.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: will@kernel.org, julien.thierry.kdev@gmail.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, mark.rutland@arm.com Subject: Re: [PATCH kvmtool 9/9] arm64: Add support for KVM_ARM_VCPU_PMU_V3_SET_PMU In-Reply-To: References: <20211115165705.195736-1-alexandru.elisei@arm.com> <20211115165705.195736-10-alexandru.elisei@arm.com> <87h7ajva2o.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, will@kernel.org, julien.thierry.kdev@gmail.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, mark.rutland@arm.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-20220108_052723_765527_4B55C08F X-CRM114-Status: GOOD ( 32.66 ) 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="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 On Fri, 07 Jan 2022 12:10:05 +0000, Alexandru Elisei wrote: > > Hi Marc, > > On Tue, Jan 04, 2022 at 02:39:59PM +0000, Marc Zyngier wrote: > > On Mon, 15 Nov 2021 16:57:05 +0000, > > Alexandru Elisei wrote: > > > > > > The KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_V3_SET_PMU) VCPU ioctl is > > > used to assign a physical PMU to the events that KVM creates when emulating > > > the PMU for that VCPU. This is useful on heterogeneous systems, when there > > > is more than one hardware PMU present. > > > > > > The assumption that is made in the implementation is that the user will > > > pin the kvmtool process on a set of CPUs that share the same PMU. This > > > allows kvmtool to set the same PMU for all VCPUs from the main thread, > > > instead of in the individual VCPU threads. > > > > May I suggest a slightly different use model? Ideally, you'd be able > > to run the vcpu threads on the CPUs matching the PMU affinity, and > > leave all the other threads to roam on other CPUs. > > Right now, the only way for userspace to make kvmtool run on a particular > set of CPUs in a heterogeneous configuration is to use taskset, which means > the entire kvmtool process ends up being pinned on a subset of CPUs which > have the same PMU. I would like to keep this approach, as it's simple and > straightforward to implement in kvmtool, and it's easy to change in the > future if there's an incentive to do so. > > It's also not clear to me how your suggestion would work. Add a command > line argument to pin all the VCPUs to the specified cpumask? > > > > > With your implementation, the whole of kvmtool gets stuck to a given > > CPU type, which can be problematic. > > Do you have a specific use case in mind? Or is it more like a general > concern regarding, for example, the virtio-blk-io or virtio-net-* threads > competing with the VCPU threads if the VM is doing lots of I/O? Exactly that. The real requirement is that the vcpu thread affinities are that of the PMU, but not that of any other thread. Maybe that's just another parameter, independent of the PMU setup. Something like: lkvm run ... --vcpu-affinity $(< /sys/devices/armv8_pmuv3_0/cpus) for example. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel