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.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 4CBBFC04FF3 for ; Mon, 24 May 2021 17:43:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DD36613F5 for ; Mon, 24 May 2021 17:43:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233299AbhEXRpF (ORCPT ); Mon, 24 May 2021 13:45:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:36072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233192AbhEXRpE (ORCPT ); Mon, 24 May 2021 13:45:04 -0400 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") Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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.