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 49C95C433F5 for ; Wed, 16 Mar 2022 05:27:30 +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=H4Z+5iGfuo/czr6VqZsOwcMAdeqpt0arzB09MSgcxvE=; b=zU4NnRorAHPKtt BgyXiYxtkN4TLTqlyEwfBAJlyOcNPn4d40N/WVyh6zkUiMwVR4t330aR8UYstPxrcb21uL+H0bD2W VFpbRYnIRvmqCl/k03OLTlisaAw7BprgdVctiDgWLm6dunfLpgsmWJ/IPJ+Z2fczuGHrC3YIw3qB9 o5743swKop6KA16gC5oaV6bEdxaMk1ZqtOndKPeeg/nQgx10b+DQg91S7DJMt7k7LV29xw7BlbnDY k5TdLpmKcgMJsNgt70dKXos7BfF86AHYuZPkbDPLtp+D93Ng1/eKLN31uvMbrk272aH/uHTJ3/aDi uiQIEmraKGHFBxak2QcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUMAp-00BUOl-I0; Wed, 16 Mar 2022 05:26:15 +0000 Received: from mail-io1-xd30.google.com ([2607:f8b0:4864:20::d30]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUMAm-00BUOL-56 for linux-arm-kernel@lists.infradead.org; Wed, 16 Mar 2022 05:26:14 +0000 Received: by mail-io1-xd30.google.com with SMTP id w7so1187024ioj.5 for ; Tue, 15 Mar 2022 22:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=MDmfm0yq5QKaDGuWZ2WJN7inSGu4ilYlUPUq2PHc548=; b=hHmsqzpGvsS9Y1ZB5I42lsFXIKnQQyu25GTdr7JTz2IX4sIM4v1uC/a3/wypnsUwFG Qr38t8WeJE2gHlcSCv1OJ/5nNHmLsCPx1n3pmb2sqH9O3PsGNg9LcM0QZfInPkO5YPaC OGNBVqFQlA1k6BmXkyFQRxEh6+u/WrJUMrIap09cPLCJTHe/6odByfDCS8zdp8g6PxFZ NxhYQiDVlU5pYF8vc6GQUxKikjB8QupM1ZKIHBWIjjNPrTD6FH46Wv93MFYE5YzWIXmA MukHBRZaCbdiypc/pDPeeWwcX6cKvv9JMfojWsGCVqSfUh/VbYSWHPdtpCg3/VA7j3fA jlqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MDmfm0yq5QKaDGuWZ2WJN7inSGu4ilYlUPUq2PHc548=; b=Pb2DrZWqBlj9wQf+Si39hUAZSsm1rKOK23wnLkt6AIiEPzv90uowmWmIzdfVEu3vSH IgIURF+z0G6jqDhIdmNPHpW4kdOcozExxkCWOnoBIIk8xGyd0zrKeclGbrYm0ek65lab RYzf3kPFHKTGAKjuIKdPn+RBgiNZcZxQw26Pp40AhByZ9tSILZAaluC24whD8koXgvIF 7reFEAxB8CTCnri06X5iy0Nab5Nkvk16hobvMgJm5wHUgdqjJCo+f5XgHDOujVYmPNTR YQaPp/SFd3FdAXtaDJ+qknQQNq2KnI6WSc3XPWt539BuW5gXenkrcvLhP7HbKVcLIctg fw+w== X-Gm-Message-State: AOAM530KrflyGDAXTyElTVB0D32Rw2hgpCBAbQe4x82JU5ZYf0IhVyZV Kq1uuXXA1Q3lvIwu1WdEwRHdeQ== X-Google-Smtp-Source: ABdhPJwCyzug0+FN/43Z6CGII1/g9j/8aDBetLwF31/ychamqjfYJ3Tp9QN56BXbl0azt5JLkjVlmQ== X-Received: by 2002:a05:6602:2c0c:b0:5f0:793f:cb9e with SMTP id w12-20020a0566022c0c00b005f0793fcb9emr23184429iov.122.1647408370619; Tue, 15 Mar 2022 22:26:10 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id y74-20020a6bc84d000000b00645dfdd8a4csm532962iof.38.2022.03.15.22.26.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Mar 2022 22:26:09 -0700 (PDT) Date: Wed, 16 Mar 2022 05:26:06 +0000 From: Oliver Upton To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, Andre Przywara Subject: Re: [PATCH 2/4] KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation Message-ID: References: <20220314164044.772709-1-maz@kernel.org> <20220314164044.772709-3-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220314164044.772709-3-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220315_222612_237605_3E7F059E X-CRM114-Status: GOOD ( 35.34 ) 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 Hi Marc, On Mon, Mar 14, 2022 at 04:40:42PM +0000, Marc Zyngier wrote: > Since GICv4.1, it has become legal for an implementation to advertise > GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more > efficient invalidation scheme (no guest command queue contention when > multiple CPUs are generating invalidations). > > Provide the invalidation registers as a primitive to their ITS > counterpart. Note that we don't advertise them to the guest yet > (the architecture allows an implementation to do this). > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/vgic/vgic-its.c | 62 ++++++++++++++++++++---------- > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 62 ++++++++++++++++++++++++++++++ > arch/arm64/kvm/vgic/vgic.h | 4 ++ > include/kvm/arm_vgic.h | 1 + > 4 files changed, 108 insertions(+), 21 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c > index 089fc2ffcb43..cc62d8a8180f 100644 > --- a/arch/arm64/kvm/vgic/vgic-its.c > +++ b/arch/arm64/kvm/vgic/vgic-its.c > @@ -1272,6 +1272,11 @@ static int vgic_its_cmd_handle_clear(struct kvm *kvm, struct vgic_its *its, > return 0; > } > > +int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq) > +{ > + return update_lpi_config(kvm, irq, NULL, true); > +} > + > /* > * The INV command syncs the configuration bits from the memory table. > * Must be called with the its_lock mutex held. > @@ -1288,7 +1293,41 @@ static int vgic_its_cmd_handle_inv(struct kvm *kvm, struct vgic_its *its, > if (!ite) > return E_ITS_INV_UNMAPPED_INTERRUPT; > > - return update_lpi_config(kvm, ite->irq, NULL, true); > + return vgic_its_inv_lpi(kvm, ite->irq); > +} > + > +/** > + * vgic_its_invall - invalidate all LPIs targetting a given vcpu > + * @vcpu: the vcpu for which the RD is targetted by an invalidation > + * > + * Contrary to the INVALL command, this targets a RD instead of a > + * collection, and we don't need to hold the its_lock, since no ITS is > + * involved here. > + */ > +int vgic_its_invall(struct kvm_vcpu *vcpu) > +{ > + struct kvm *kvm = vcpu->kvm; > + int irq_count, i = 0; > + u32 *intids; > + > + irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids); > + if (irq_count < 0) > + return irq_count; > + > + for (i = 0; i < irq_count; i++) { > + struct vgic_irq *irq = vgic_get_irq(kvm, NULL, intids[i]); > + if (!irq) > + continue; > + update_lpi_config(kvm, irq, vcpu, false); > + vgic_put_irq(kvm, irq); > + } > + > + kfree(intids); > + > + if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm) > + its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe); > + > + return 0; > } nit: the refactoring happening at the same time as the functional change is a bit distracting. Looks fine though. > /* > @@ -1305,32 +1344,13 @@ static int vgic_its_cmd_handle_invall(struct kvm *kvm, struct vgic_its *its, > u32 coll_id = its_cmd_get_collection(its_cmd); > struct its_collection *collection; > struct kvm_vcpu *vcpu; > - struct vgic_irq *irq; > - u32 *intids; > - int irq_count, i; > > collection = find_collection(its, coll_id); > if (!its_is_collection_mapped(collection)) > return E_ITS_INVALL_UNMAPPED_COLLECTION; > > vcpu = kvm_get_vcpu(kvm, collection->target_addr); > - > - irq_count = vgic_copy_lpi_list(kvm, vcpu, &intids); > - if (irq_count < 0) > - return irq_count; > - > - for (i = 0; i < irq_count; i++) { > - irq = vgic_get_irq(kvm, NULL, intids[i]); > - if (!irq) > - continue; > - update_lpi_config(kvm, irq, vcpu, false); > - vgic_put_irq(kvm, irq); > - } > - > - kfree(intids); > - > - if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.its_vm) > - its_invall_vpe(&vcpu->arch.vgic_cpu.vgic_v3.its_vpe); > + vgic_its_invall(vcpu); > > return 0; > } > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > index 58e40b4874f8..186bf35078bf 100644 > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > @@ -525,6 +525,59 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu, > pendbaser) != old_pendbaser); > } > > +static unsigned long vgic_mmio_read_sync(struct kvm_vcpu *vcpu, > + gpa_t addr, unsigned int len) > +{ > + return !!atomic_read(&vcpu->arch.vgic_cpu.syncr_busy); > +} > + > +static void vgic_make_rdist_busy(struct kvm_vcpu *vcpu, bool busy) nit: s/make/set, since you use this helper to decrement the counter too. > +{ > + if (busy) { > + atomic_inc(&vcpu->arch.vgic_cpu.syncr_busy); > + smp_mb__after_atomic(); > + } else { > + smp_mb__before_atomic(); > + atomic_dec(&vcpu->arch.vgic_cpu.syncr_busy); > + } > +} > + > +static void vgic_mmio_write_invlpi(struct kvm_vcpu *vcpu, > + gpa_t addr, unsigned int len, > + unsigned long val) > +{ > + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; > + struct vgic_irq *irq; > + > + if (!vgic_cpu->lpis_enabled) > + return; > + > + vgic_make_rdist_busy(vcpu, true); > + > + irq = vgic_get_irq(vcpu->kvm, NULL, val); > + if (!irq) > + return; Isn't the busy counter unbalanced if you return early? -- Thanks, Oliver > + > + vgic_its_inv_lpi(vcpu->kvm, irq); > + vgic_put_irq(vcpu->kvm, irq); > + > + vgic_make_rdist_busy(vcpu, false); > +} > + > +static void vgic_mmio_write_invall(struct kvm_vcpu *vcpu, > + gpa_t addr, unsigned int len, > + unsigned long val) > +{ > + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; > + > + if (!vgic_cpu->lpis_enabled) > + return; > + > + vgic_make_rdist_busy(vcpu, true); > + vgic_its_invall(vcpu); > + vgic_make_rdist_busy(vcpu, false); > +} > + > /* > * The GICv3 per-IRQ registers are split to control PPIs and SGIs in the > * redistributors, while SPIs are covered by registers in the distributor > @@ -630,6 +683,15 @@ static const struct vgic_register_region vgic_v3_rd_registers[] = { > REGISTER_DESC_WITH_LENGTH(GICR_PENDBASER, > vgic_mmio_read_pendbase, vgic_mmio_write_pendbase, 8, > VGIC_ACCESS_64bit | VGIC_ACCESS_32bit), > + REGISTER_DESC_WITH_LENGTH(GICR_INVLPIR, > + vgic_mmio_read_raz, vgic_mmio_write_invlpi, 8, > + VGIC_ACCESS_64bit | VGIC_ACCESS_32bit), > + REGISTER_DESC_WITH_LENGTH(GICR_INVALLR, > + vgic_mmio_read_raz, vgic_mmio_write_invall, 8, > + VGIC_ACCESS_64bit | VGIC_ACCESS_32bit), > + REGISTER_DESC_WITH_LENGTH(GICR_SYNCR, > + vgic_mmio_read_sync, vgic_mmio_write_wi, 8, > + VGIC_ACCESS_64bit | VGIC_ACCESS_32bit), > REGISTER_DESC_WITH_LENGTH(GICR_IDREGS, > vgic_mmio_read_v3_idregs, vgic_mmio_write_wi, 48, > VGIC_ACCESS_32bit), > diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h > index 3fd6c86a7ef3..53581e11f7c8 100644 > --- a/arch/arm64/kvm/vgic/vgic.h > +++ b/arch/arm64/kvm/vgic/vgic.h > @@ -317,6 +317,10 @@ void vgic_lpi_translation_cache_init(struct kvm *kvm); > void vgic_lpi_translation_cache_destroy(struct kvm *kvm); > void vgic_its_invalidate_cache(struct kvm *kvm); > > +/* GICv4.1 MMIO interface */ > +int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq); > +int vgic_its_invall(struct kvm_vcpu *vcpu); > + > bool vgic_supports_direct_msis(struct kvm *kvm); > int vgic_v4_init(struct kvm *kvm); > void vgic_v4_teardown(struct kvm *kvm); > diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h > index bb30a6803d9f..d54bb44d6d98 100644 > --- a/include/kvm/arm_vgic.h > +++ b/include/kvm/arm_vgic.h > @@ -344,6 +344,7 @@ struct vgic_cpu { > struct vgic_io_device rd_iodev; > struct vgic_redist_region *rdreg; > u32 rdreg_index; > + atomic_t syncr_busy; > > /* Contains the attributes and gpa of the LPI pending tables. */ > u64 pendbaser; > -- > 2.34.1 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel