From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CD4722541F for ; Fri, 23 May 2025 18:14:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748024053; cv=none; b=JvWnQSxILo6owCTvMJtdK0RPPy1OeefNnaZvsDRafv59fv3X7VEjAcRlzVo/l1XABfuU27A1WlNSfs0AsQeyJ3Hkk6aHuaFDtyWLFqqfPX41zwx5SmSpTjKjExXd4WYqExL7JRFkM0i7WuOnAvzDoYOkFk7JDB/1j8Tr440tzts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748024053; c=relaxed/simple; bh=MzViEOFEdyZcTvsG/eQXecmI7LaClwqzL01TvixbJ9g=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=oGGLiVzvVHEXkdxVI4woT68ewH0yZpaD7Tw9W8d6GGOtOMJ24xisTIr3MNkFtsB2QknJ8loHVG4rjPvvxOhnSnYBBx6xWzwr3fb0LC4dQS7FwbG8JowGBX+77oOxU/XQ7/C9YKGfIaCmliyY9r/CCUPP2Pl0nqMvMbQfMTMNws0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R6dh/fRR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R6dh/fRR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81309C4CEE9; Fri, 23 May 2025 18:14:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748024052; bh=MzViEOFEdyZcTvsG/eQXecmI7LaClwqzL01TvixbJ9g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=R6dh/fRRhEY3rmNY7eahhxG68inXxTNezUNv996VuwcRaypPTtFVv4dTjlm0SxNDO mXA1qlI8QYiRijtb3UyoasxQLEK7DDlxu2XjeojfSYvQDxcllRfxmWZKt4zaqFgkN7 3QGOLeodiCVrN4rJmuwuT2AOXsLXPZZ2ogLFouF8SzztzqPS4WkV8UQdDBY4KK49dk nm82Izlp0eoaWTvkTUfZo5/UbqqCKCo5mYvM9iJ7oBk7IAlBsvCGkwdunR+Iin8H+v 7QJiH6qf/RwIBM+uvqrA0/9LKAj1Xt1KYKC7gxjGhjL3gSHz2Ac1Iy2dlpAzuQZxfM FdzDSPthp9cQQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1uIWuI-0004nw-JV; Fri, 23 May 2025 19:14:10 +0100 Date: Fri, 23 May 2025 19:14:01 +0100 Message-ID: <87zff3urdi.wl-maz@kernel.org> From: Marc Zyngier To: Sean Christopherson Cc: Oliver Upton , kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Zenghui Yu , Sweet Tea Dorminy Subject: Re: [PATCH 4/5] KVM: arm64: Unmap vLPIs affected by changes to GSI routing information In-Reply-To: References: <20250523160810.4049313-1-oliver.upton@linux.dev> <20250523160810.4049313-5-oliver.upton@linux.dev> <87tt5bdyqu.wl-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/30.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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: seanjc@google.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, sweettea@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 23 May 2025 18:48:02 +0100, Sean Christopherson wrote: > > On Fri, May 23, 2025, Marc Zyngier wrote: > > On Fri, 23 May 2025 17:08:09 +0100, > > Oliver Upton wrote: > > > > > > KVM's interrupt infrastructure is dodgy at best, allowing for some ugly > > > 'off label' usage of the various UAPIs. In one example, userspace can > > > change the routing entry of a particular "GSI" after configuring > > > irqbypass with KVM_IRQFD. KVM/arm64 is oblivious to this, and winds up > > > preserving the stale translation in cases where vLPIs are configured. > > > > > > Honor userspace's intentions and tear down the vLPI mapping if affected > > > by a "GSI" routing change. Make no attempt to reconstruct vLPIs if the > > > new target is an MSI and just fall back to software injection. > > > > > > Tested-by: Sweet Tea Dorminy > > > Signed-off-by: Oliver Upton > > > --- > > > arch/arm64/kvm/arm.c | 23 +++++++++++++++++++++++ > > > 1 file changed, 23 insertions(+) > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > > index 1de49b48e35e..505d504b52b5 100644 > > > --- a/arch/arm64/kvm/arm.c > > > +++ b/arch/arm64/kvm/arm.c > > > @@ -2790,6 +2790,7 @@ int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons, > > > return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq, > > > &irqfd->irq_entry); > > > } > > > + > > > void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons, > > > struct irq_bypass_producer *prod) > > > { > > > @@ -2803,6 +2804,28 @@ void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons, > > > kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq); > > > } > > > > > > +bool kvm_arch_irqfd_route_changed(struct kvm_kernel_irq_routing_entry *old, > > > + struct kvm_kernel_irq_routing_entry *new) > > > +{ > > > + if (new->type != KVM_IRQ_ROUTING_MSI) > > > + return true; > > > + > > > + return memcmp(&old->msi, &new->msi, sizeof(new->msi)); > > > +} > > > + > > > +int kvm_arch_update_irqfd_routing(struct kvm *kvm, unsigned int host_irq, > > > + uint32_t guest_irq, bool set) > > > > If we're adding this, can we take out the trash and get rid of this > > 'set' parameter? Its only purpose is to be set to '1' and fed to the > > x86-specific stuff. How about this: > > Can we hold off on any changes to the common APIs? Unless they're urgent and > need to land in 6.16, I've got a massive series that I've been slowing working > on for ~7 months that fixes this wart, and several more, e.g. gets rid of > kvm_arch_irqfd_route_changed() entirely, and make the above ugliness into: > > void kvm_arch_update_irqfd_routing(struct kvm_kernel_irqfd *irqfd, > struct kvm_kernel_irq_routing_entry *old, > struct kvm_kernel_irq_routing_entry *new) > > > I'm ~90% confident it'll land in 6.17: > https://lore.kernel.org/all/20250523010004.3240643-1-seanjc@google.com Sure, if you want to preserve this fossil for another round, I don't really care. But if you are planning your grand plan for 6.17, you could as well rebase on top of theses patches which are aimed at -rc1 (yes, they are bug fixes), and it would then be perfectly acceptable to have this cleanup early. Thanks, M. -- Without deviation from the norm, progress is not possible.