Received: by 2002:a05:7412:f584:b0:e2:908c:2ebd with SMTP id eh4csp1278252rdb; Mon, 4 Sep 2023 08:23:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEj9JeXdTgJG99dUFQSkDP3Mc2TbhV2cvhdJ5i2NmAqnvxEzuVom/WBGr0RHgfmpGnQAzAF X-Received: by 2002:a05:6512:3d90:b0:500:9dd4:2969 with SMTP id k16-20020a0565123d9000b005009dd42969mr8082767lfv.59.1693841026851; Mon, 04 Sep 2023 08:23:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693841026; cv=none; d=google.com; s=arc-20160816; b=XJcUe098rJrNhn+xfPAWLx0BrN0pexBRtX45Wn/hxSaHNxrtrPGtDVzfeYo69P+I0O 3q+RsAIf3JvNbdy0RZbRaM7ElmPZMj39P2KsmkxZwlp/NrAyi0gphpE+9KuJDNUz/63Q EoNb8UqYiSZokMhcZezEBETurN5tibVBARZYY8lDrDy8F9gQfZwYWrZuE4VdwgKnJUxD eP8HZoBjW10ziwgJV9k+JIja+aL+AeCHicD7or48/x97UIHnvSAIhpWu3iOj1ZkX5c4K dQhBxArRFlC0Gh64on/3iYnRjhxNWtBj9+QaMS0pYfoC9jHw8QaOr//9Z4U703FeehFe YzQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=fO6HnxsUWiCKDIFvMqaenEQcGfI5hCbL4CE6kLTnkcA=; fh=mwcmY4x0XPp/vSwB+tczj8nBJfLZFI9ef32Y8AdXv7g=; b=YR3o3bWTZ97YIAH1r4vcRTabTfW4M1U24zWhfL5BhWc1t+Utvgs/ocCBxBQLzJHQ+P 7djHothR5xhKYdwLTmVcS3JId1MR3RUlo8V01+brigjPZ3F7RsfhLgVDcylR4S9G/pdg gVW0KNlJeetJPGx+JXdgfflSLVFWLfyeYdFghkX9FkLGaAOHuoEfnX4r7dHrztTgnqqb lNvcFem3Y0SnLvFlJ+umDYhfUTycPtfFmT1/cwDwx29If1f9vUfVP+2lXfopHa9RsjSV VUfZLR9xmCZzhlbyaRmPMuqj7h6MhWFo1QBTDxRGAw8joyN3ZZWd5Ve3d66ni1iWRZBp 6+rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MpQRi+Ay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p7-20020a170906b20700b00992c195b499si6121502ejz.765.2023.09.04.08.23.13; Mon, 04 Sep 2023 08:23:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MpQRi+Ay; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239373AbjIDJ5p (ORCPT + 99 others); Mon, 4 Sep 2023 05:57:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243886AbjIDJ5o (ORCPT ); Mon, 4 Sep 2023 05:57:44 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 741C5E3; Mon, 4 Sep 2023 02:57:31 -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 ams.source.kernel.org (Postfix) with ESMTPS id B720BB80DE3; Mon, 4 Sep 2023 09:57:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F895C433C8; Mon, 4 Sep 2023 09:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693821448; bh=KCgrMSpReKkomAvjrgAyI+M74AruhN3j2aeC3Jx7Y+g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MpQRi+AyB0glohPHvUIs5L0PJBy56ywLS/W3DOBlGZczOTro6uLRuZXW19unGTcYD Tp4cFFCkpNKYDGLzLltFyVr2zlrSidWZKX6Jqo5OA9+0G9uNbKE8HTBm7V4QF+XZAZ FsQmWEAin7RKf/Se/pjD6v3Dj17PeDCTchxVwQaYjPJE6j4y+W+K1oM8xFi6VZQjT9 Qg4mHRo6TW7ULwrjc7A5lLZ+H3Q2BIdodMI++Tv30dspoBcLn03g9iKl+gQsYoPU2p Iju5S1r3VUsVfsYFQY/8rv22rkS4a4ekB77raDYFciJl30Rh3Ca2KZOEHJ1umIhBvF w+VvKYzOmRa4Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1qd6Kj-00ANAe-VB; Mon, 04 Sep 2023 10:57:26 +0100 Date: Mon, 04 Sep 2023 10:57:24 +0100 Message-ID: <86o7iidzwb.wl-maz@kernel.org> From: Marc Zyngier To: Xu Zhao Cc: oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [RFC v2] KVM: arm/arm64: optimize vSGI injection performance In-Reply-To: <20230825015811.5292-1-zhaoxu.35@bytedance.com> References: <20230825015811.5292-1-zhaoxu.35@bytedance.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 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: zhaoxu.35@bytedance.com, oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Aug 2023 02:58:11 +0100, Xu Zhao wrote: > > In a VM with more than 16 vCPUs (with multiple aff0 groups), if the target > vCPU of a vSGI exceeds 16th vCPU, kvm needs to iterate from vCPU0 until > the target vCPU is found. However, affinity routing information is provided > by the ICC_SGI* register, which allows kvm to bypass other aff0 groups, > iterating only on the aff0 group that the target vCPU located. It reduces > the maximum iteration times from the total number of vCPUs to 16, or even > 8 times. > > This patch aims to optimize the vSGI injecting performance of injecting > target exceeds 16th vCPU in vm with more than 16 vCPUs. The problem is that you optimise it for the default case, and break it for *everything* else. [...] > The performance of VM witch 32 cores improvement can be observed. When > injecting SGI into the first vCPU of the first aff0 group, the performance > remains the same as before (because the number of iteration is also 1), > but there is an improvement in performance when injecting interrupts into > the last vCPU. When injecting vSGI into the first and last vCPU of the > second aff0 group, the performance improvement is significant because > compared to the original algorithm, it skipped iterates the first aff0 > group. > > BTW, performance improvement can also be observed by microbench in > kvm-unit-test with little modification :add 32 cores initialization, > then change IPI target CPU in function ipi_exec. > > The more vcpu a VM has, the greater the performance improvement of injecting > vSGI into the vCPU in the last aff0 group. > > Signed-off-by: Xu Zhao > --- > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 152 ++++++++++++++--------------- > include/linux/kvm_host.h | 5 + > 2 files changed, 78 insertions(+), 79 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > index 188d2187eede..af8f2d6b18c3 100644 > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > @@ -1013,44 +1013,64 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr) > > return 0; > } > + > /* > - * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI > - * generation register ICC_SGI1R_EL1) with a given VCPU. > - * If the VCPU's MPIDR matches, return the level0 affinity, otherwise > - * return -1. > + * Get affinity routing index from ICC_SGI_* register > + * format: > + * aff3 aff2 aff1 aff0 > + * |- 8 bits -|- 8 bits -|- 8 bits -|- 4 bits -| > */ > -static int match_mpidr(u64 sgi_aff, u16 sgi_cpu_mask, struct kvm_vcpu *vcpu) > +static unsigned long sgi_to_affinity(unsigned long reg) > { > - unsigned long affinity; > - int level0; > + u64 aff; > > - /* > - * Split the current VCPU's MPIDR into affinity level 0 and the > - * rest as this is what we have to compare against. > - */ > - affinity = kvm_vcpu_get_mpidr_aff(vcpu); > - level0 = MPIDR_AFFINITY_LEVEL(affinity, 0); > - affinity &= ~MPIDR_LEVEL_MASK; > + /* aff3 - aff1 */ > + aff = (((reg) & ICC_SGI1R_AFFINITY_3_MASK) >> ICC_SGI1R_AFFINITY_3_SHIFT) << 16 | > + (((reg) & ICC_SGI1R_AFFINITY_2_MASK) >> ICC_SGI1R_AFFINITY_2_SHIFT) << 8 | > + (((reg) & ICC_SGI1R_AFFINITY_1_MASK) >> ICC_SGI1R_AFFINITY_1_SHIFT); Here, you assume that you can directly map a vcpu index to an affinity. It would be awesome if that was the case. However, this is only valid at reset time, and userspace is perfectly allowed to change this mapping by writing to the vcpu's MPIDR_EL1. So this won't work at all if userspace wants to set its own specific CPU numbering. M. -- Without deviation from the norm, progress is not possible.