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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 78BE7C2B9F4 for ; Tue, 22 Jun 2021 15:51:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5914E61040 for ; Tue, 22 Jun 2021 15:51:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231876AbhFVPx0 convert rfc822-to-8bit (ORCPT ); Tue, 22 Jun 2021 11:53:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:46760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232252AbhFVPx0 (ORCPT ); Tue, 22 Jun 2021 11:53:26 -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 29C9560233; Tue, 22 Jun 2021 15:51:10 +0000 (UTC) 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 1lvig6-009Cui-3O; Tue, 22 Jun 2021 16:51:06 +0100 Date: Tue, 22 Jun 2021 16:51:05 +0100 Message-ID: <871r8tdhjq.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 , Zenghui Yu , kernel-team@android.com Subject: Re: [PATCH v4 0/9] KVM: arm64: Initial host support for the Apple M1 In-Reply-To: <9bc0923c-5c3b-eeac-86ee-c3234c486955@arm.com> References: <20210601104005.81332-1-maz@kernel.org> <9bc0923c-5c3b-eeac-86ee-c3234c486955@arm.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/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=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 185.219.108.64 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, yuzenghui@huawei.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 Hi Alex, On Tue, 22 Jun 2021 16:39:11 +0100, Alexandru Elisei wrote: > > Hi Marc, > > On 6/1/21 11:39 AM, Marc Zyngier wrote: > > This is a new version of the series previously posted at [3], reworking > > the vGIC and timer code to cope with the M1 braindead^Wamusing nature. > > > > Hardly any change this time around, mostly rebased on top of upstream > > now that the dependencies have made it in. > > > > Tested with multiple concurrent VMs running from an initramfs. > > > > Until someone shouts loudly now, I'll take this into 5.14 (and in > > -next from tomorrow). > > I am not familiar with irqdomains or with the irqchip > infrastructure, so I can't really comment on patch #8. > > I tried testing this with a GICv3 by modifying the driver to set > no_hw_deactivation and no_maint_irq_mask: > > diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c > index 340c51d87677..d0c6f808d7f4 100644 > --- a/arch/arm64/kvm/vgic/vgic-init.c > +++ b/arch/arm64/kvm/vgic/vgic-init.c > @@ -565,8 +565,10 @@ int kvm_vgic_hyp_init(void) >         if (ret) >                 return ret; >   > +       /* >         if (!has_mask) >                 return 0; > +               */ >   >         ret = request_percpu_irq(kvm_vgic_global_state.maint_irq, >                                  vgic_maintenance_handler, > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 453fc425eede..9ce4dee20655 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -1850,6 +1850,12 @@ static void __init gic_of_setup_kvm_info(struct device_node > *node) >         if (!ret) >                 gic_v3_kvm_info.vcpu = r; >   > +       gic_v3_kvm_info.no_hw_deactivation = true; Blink... > +       gic_v3_kvm_info.no_maint_irq_mask = true; > + > +       vgic_set_kvm_info(&gic_v3_kvm_info); > +       return; > + >         gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis; >         gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid; >         vgic_set_kvm_info(&gic_v3_kvm_info); > > Kept the maintenance irq ID so the IRQ gets enabled at the > Redistributor level. I don't know if I managed to break something > with those changes, but when testing on the model and on a rockpro64 > (with the patches cherry-picked on top of v5.13-rc7) I kept seeing > rcu stalls. I assume I did something wrong. If you do that, the interrupts that are forwarded to the guest (timers) will never be deactivated, and will be left dangling after the first injection. This is bound to create havoc, as we will then use mask/unmask to control the timer delivery (remember that the Active state is just another form of auto-masking on top of the standard enable bit) On the contrary, the AIC only has a single bit to control the timer (used as a mask), which is what the irqdomain stuff implements to mimic the active state. Thanks, M. -- Without deviation from the norm, progress is not possible.