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 X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B52FC2B9F7 for ; Tue, 25 May 2021 00:40:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 52BB66128D for ; Tue, 25 May 2021 00:40:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52BB66128D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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=lzhE3XhGtiJP82jGVi8tsxrJg8Yy3MKa5irRsL797jA=; b=FJDJ76ymX5JEhq Yp/V2H6oxlmFOeL6JfpRvIJu4Wsdd9Etd7yx917PhJ1rm6Ntx1XTiHLLOQBcbfZj2HdKGTneIeffh 3Adl+QMoUmiMb027N5nyWuUCmupj6E3kU3b0yI/4MXTmc0nrrdHa5LAYsXtG+63cRE7VSaH3QCYwC dHGYcRaz/5Zh1ra1vK38srG2cCeDGwquCCr1XMd0bVkFCnbz79IVuoWnGAgL9hwXRcAMKJ3Horhdn 33bKHOvgICeexlGP1SaMG/WFFR0ASQ5u8icsZ36OKI45n84KI/8z85N69RG9LcoLvfzLs/f9uaIlq apeG0GJbOeUqlOJr19JQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1llL5q-002b6b-36; Tue, 25 May 2021 00:38:46 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1llEc3-001KIu-7i for linux-arm-kernel@lists.infradead.org; Mon, 24 May 2021 17:43:36 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 841AF601FC; Mon, 24 May 2021 17:43:34 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] 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 1llEc0-003Ivb-EB; Mon, 24 May 2021 18:43:32 +0100 Date: Mon, 24 May 2021 18:43:31 +0100 Message-ID: <87bl90vxh8.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, James Morse , Suzuki K Poulose , Eric Auger , Hector Martin , Mark Rutland , kernel-team@android.com Subject: Re: [PATCH v3 6/9] KVM: arm64: vgic: Implement SW-driven deactivation In-Reply-To: References: <20210510134824.1910399-1-maz@kernel.org> <20210510134824.1910399-7-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: 62.31.163.78 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, eric.auger@redhat.com, marcan@marcan.st, mark.rutland@arm.com, kernel-team@android.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-20210524_104335_382465_AA86ED61 X-CRM114-Status: GOOD ( 41.81 ) 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 Mon, 24 May 2021 17:53:04 +0100, Alexandru Elisei wrote: > > Hi Marc, > > Some questions regarding how this is supposed to work. > > On 5/10/21 2:48 PM, Marc Zyngier wrote: > > In order to deal with these systems that do not offer HW-based > > deactivation of interrupts, let implement a SW-based approach: > > > > - When the irq is queued into a LR, treat it as a pure virtual > > interrupt and set the EOI flag in the LR. > > > > - When the interrupt state is read back from the LR, force a > > deactivation when the state is invalid (neither active nor > > pending) > > > > Interrupts requiring such treatment get the VGIC_SW_RESAMPLE flag. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/vgic/vgic-v2.c | 19 +++++++++++++++---- > > arch/arm64/kvm/vgic/vgic-v3.c | 19 +++++++++++++++---- > > include/kvm/arm_vgic.h | 10 ++++++++++ > > 3 files changed, 40 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c > > index 11934c2af2f4..2c580204f1dc 100644 > > --- a/arch/arm64/kvm/vgic/vgic-v2.c > > +++ b/arch/arm64/kvm/vgic/vgic-v2.c > > @@ -108,11 +108,22 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu) > > * If this causes us to lower the level, we have to also clear > > * the physical active state, since we will otherwise never be > > * told when the interrupt becomes asserted again. > > + * > > + * Another case is when the interrupt requires a helping hand > > + * on deactivation (no HW deactivation, for example). > > */ > > - if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) { > > - irq->line_level = vgic_get_phys_line_level(irq); > > + if (vgic_irq_is_mapped_level(irq)) { > > + bool resample = false; > > + > > + if (val & GICH_LR_PENDING_BIT) { > > + irq->line_level = vgic_get_phys_line_level(irq); > > + resample = !irq->line_level; > > + } else if (vgic_irq_needs_resampling(irq) && > > + !(irq->active || irq->pending_latch)) { > > So this means that if the IRQ has the special flag, if it's not > pending in the LR or at the software level, and it's not active > either, then perform interrupt deactivation. Correct. > I don't see where the state of the interrupt is checked again, am I > correct in assuming that we rely on the CPU interface to assert the > interrupt to the host while we run with interrupts enabled in the > run loop, and the handler for the interrupt will mark it pending for > kvm_vgic_sync_hw_state->vgic_vx_fold_lr_state? See the vgic_get_phys_line_level() call. This is all about dealing with an interrupt that was made pending in the LR, that the guest didn't Ack, but instead decided to disable the timer. In this case, we need to clear the pending bit and deactivate the interrupt because nothing will perform the physical deactivation for us. What we add in the M1 case is that if the interrupt isn't pending anymore at the virtual level, we also need to deactivate it at the physical level, because there is no HW mechanism to enforce it. > > > + resample = true; > > + } > > > > - if (!irq->line_level) > > + if (resample) > > This name, "resample", is confusing to me, quite possibly because > I'm not familiar with the irqchip subsystem. It was my impression > that "resample" means that at some point, the physical interrupt > state will be checked again, yet I don't see that happening anywhere > when VGIC_IRQ_SW_RESAMPLE is set. Am I mistaken in my assumptions? The resample is at the HW level. We forcefully tell the interrupt controller to deliver a pending interrupt (this is implemented as an unmask under the hood). 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