From nobody Sun Feb 8 00:49:25 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9811E3939C5 for ; Tue, 13 Jan 2026 17:46:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768326373; cv=none; b=LeweWu/9QEWciYVuBu3T3Q7cpFEaKzTagHMIoZ9eLRyq2y6Ku1CeA3oqmqFKEnp+Xc3wVLkv8BdSAifwkFn3J7DEYgFs7FnTD6KH5URgSNkZqce+R7Y/UCNnA8A+nEOY2CPFmmOhrb/rBkaOVZn4TBAa+YDDkxrFcRv1/NY5hGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768326373; c=relaxed/simple; bh=4ZTtxbzTNmYnUM+MsSzb1wsDVYo0Qs03WvcCysD6+C8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=SaFUN7uf6bn8dfyvkz08iw2sfnP/eiAvyGYUa9rFCUKIJ4b9t8+6oUEpTQWLIsPFqvT5vXy9o54+hkkQlT59/DwxzbLMd0BbM6BTkjkvY9AhTeaHBCiKqvsFZSO8Zm4OK1off4FIHoACnIpGYCC0a9R1puxp0/eH8T/ICsVHEE0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ttdsE+eT; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ttdsE+eT" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-34cc88eca7eso7847098a91.2 for ; Tue, 13 Jan 2026 09:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768326371; x=1768931171; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=YNb2VF84dP46LgFx8kiI9WVhad6Rik0R6dM/dGioytE=; b=ttdsE+eTatJw14Afq144jOjFP5iT4YrjCaRRiGzpZLEfeXAO1+dh3/v1heUeySkCuy rtzjvslLEc8D+Zdye3a2CS1KUkz4zWNTnITjBTZXf30aZlvAT6x/13dWqdZlZzFhWTLw 3eSJIjR0DDF+xLSYrtGE7YVVJNEK3WmWQIODA1L1OVQLz2qJPHQoqfiQby2Him2blX7o snl7BKg0huTzbWA3OhW/icI5apwLE23MKPQP8GboEADs8Q24FC6GBhh419qpdXtq3/7p hSvkI9+uJZRahcdVy7C5v1d3v2eHsZv2d/fhvCbFELDC58zqUk7cYwFrCqM4tqyfBT6p rdKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768326371; x=1768931171; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YNb2VF84dP46LgFx8kiI9WVhad6Rik0R6dM/dGioytE=; b=BPH17a0MVv/N1J7n1LiWo+TUIF63xEiUgg+ecWrFmfn6gogD3jdFOql/yQcNxcvVe1 IUgsG7NIFz1OfXGVFpR9wojJhrXoV2jXnmCcKvJhj0h26u92WPGfVmxWjI6dBx6WqCyv lWhxeY2XMoCqxgNzyu0B1PT9nKXGtNTYHu4lOj9S1raWpM8dDdswx+BtMjtfe0ipOUoZ IOt5VxXeZtHX3Ahs7VUDWri8ryKHhNDN/CmSt2A/1Pm6l0/D3GLuPBGKJ3AsuH1F0HZv +f+HEQmPe7BAAOOGMbwCyn4jQTxquUEPx5W6aUltTFA5A+0w8McI2OlpRedXZDnlN9Hg ccEw== X-Forwarded-Encrypted: i=1; AJvYcCVvGK67VUjXaBp9ket5g9wvBqMDDo8XBnYZbW/d+Npbf1rcHoedKRj0faJ5XhZ/HqOPE0o/F/Ti7mcd6ig=@vger.kernel.org X-Gm-Message-State: AOJu0YxCUbGb1T6ma1yBeSgVh6H2Au7VvUct1wUVbk2VCp0i5EXcCWXj c01aJWBPwPBeU0LQwoDd9+jU+2kqc7wB789cfSnrUfRXNdxINDT7Of81UFIM/sCC4HxFxg6ON+4 cmmIXzg== X-Google-Smtp-Source: AGHT+IEKlBSoSv5shvkXPl9+9fw8Es6u45z4EYm65607JuzRtL7Cln0TrdLfZO0/fpXy5y1svjXiHFuAGOo= X-Received: from pjboo9.prod.google.com ([2002:a17:90b:1c89:b0:34c:2f52:23aa]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1b03:b0:343:e461:9022 with SMTP id 98e67ed59e1d1-34f68ca444bmr22112564a91.24.1768326370718; Tue, 13 Jan 2026 09:46:10 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 13 Jan 2026 09:46:05 -0800 In-Reply-To: <20260113174606.104978-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260113174606.104978-1-seanjc@google.com> X-Mailer: git-send-email 2.52.0.457.g6b5491de43-goog Message-ID: <20260113174606.104978-2-seanjc@google.com> Subject: [PATCH 1/2] KVM: Don't clobber irqfd routing type when deassigning irqfd From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marc Zyngier , Oliver Upton Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=3DUSER, [W]=3DWARN, [O]=3DOOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 0= 9/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=3Dffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=3DUSER, [W]=3DWARN, [O]=3DOOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 0= 9/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypass] kvm_irqfd+0x4c6/0x540 [kvm] kvm_vm_ioctl+0x118/0x5d0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- On Intel and arm64, the bug is less noisy, as the end result is that the device keeps posting IRQs to the vCPU even after it's been deassigned. Note, the worst of the breakage can be traced back to commit cb210737675e ("KVM: Pass new routing entries and irqfd when updating IRTEs"), as before that commit KVM would pull the routing information from the per-VM routing table. But as above, similar bugs have existed since support for IRQ bypass was added. E.g. if a routing change finished before irq_shutdown() invoked kvm_arch_irq_bypass_del_producer(), VMX and SVM would see stale routing information and potentially leave the irqfd in bypass mode. Alternatively, x86 could be fixed by explicitly checking irq_bypass_vcpu instead of irq_entry.type in kvm_arch_irq_bypass_del_producer(), and arm64 could be modified to utilize irq_bypass_vcpu in a similar manner. But (a) that wouldn't fix the routing updates bug, and (b) fixing core code doesn't preclude x86 (or arm64) from adding such code as a sanity check (spoiler alert). Fixes: f70c20aaf141 ("KVM: Add an arch specific hooks in 'struct kvm_kernel= _irqfd'") Fixes: cb210737675e ("KVM: Pass new routing entries and irqfd when updating= IRTEs") Fixes: a0d7e2fc61ab ("KVM: arm64: vgic-v4: Only attempt vLPI mapping for ac= tual MSIs") Cc: stable@vger.kernel.org Cc: Marc Zyngier Cc: Oliver Upton Signed-off-by: Sean Christopherson --- virt/kvm/eventfd.c | 44 ++++++++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c index 0e8b5277be3b..a369b20d47f0 100644 --- a/virt/kvm/eventfd.c +++ b/virt/kvm/eventfd.c @@ -157,21 +157,28 @@ irqfd_shutdown(struct work_struct *work) } =20 =20 -/* assumes kvm->irqfds.lock is held */ -static bool -irqfd_is_active(struct kvm_kernel_irqfd *irqfd) +static bool irqfd_is_active(struct kvm_kernel_irqfd *irqfd) { + /* + * Assert that either irqfds.lock or SRCU is held, as irqfds.lock must + * be held to prevent false positives (on the irqfd being active), and + * while false negatives are impossible as irqfds are never added back + * to the list once they're deactivated, the caller must at least hold + * SRCU to guard against routing changes if the irqfd is deactivated. + */ + lockdep_assert_once(lockdep_is_held(&irqfd->kvm->irqfds.lock) || + srcu_read_lock_held(&irqfd->kvm->irq_srcu)); + return list_empty(&irqfd->list) ? false : true; } =20 /* * Mark the irqfd as inactive and schedule it for removal - * - * assumes kvm->irqfds.lock is held */ -static void -irqfd_deactivate(struct kvm_kernel_irqfd *irqfd) +static void irqfd_deactivate(struct kvm_kernel_irqfd *irqfd) { + lockdep_assert_held(&irqfd->kvm->irqfds.lock); + BUG_ON(!irqfd_is_active(irqfd)); =20 list_del_init(&irqfd->list); @@ -217,8 +224,15 @@ irqfd_wakeup(wait_queue_entry_t *wait, unsigned mode, = int sync, void *key) seq =3D read_seqcount_begin(&irqfd->irq_entry_sc); irq =3D irqfd->irq_entry; } while (read_seqcount_retry(&irqfd->irq_entry_sc, seq)); - /* An event has been signaled, inject an interrupt */ - if (kvm_arch_set_irq_inatomic(&irq, kvm, + + /* + * An event has been signaled, inject an interrupt unless the + * irqfd is being deassigned (isn't active), in which case the + * routing information may be stale (once the irqfd is removed + * from the list, it will stop receiving routing updates). + */ + if (unlikely(!irqfd_is_active(irqfd)) || + kvm_arch_set_irq_inatomic(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID, 1, false) =3D=3D -EWOULDBLOCK) schedule_work(&irqfd->inject); @@ -585,18 +599,8 @@ kvm_irqfd_deassign(struct kvm *kvm, struct kvm_irqfd *= args) spin_lock_irq(&kvm->irqfds.lock); =20 list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds.items, list) { - if (irqfd->eventfd =3D=3D eventfd && irqfd->gsi =3D=3D args->gsi) { - /* - * This clearing of irq_entry.type is needed for when - * another thread calls kvm_irq_routing_update before - * we flush workqueue below (we synchronize with - * kvm_irq_routing_update using irqfds.lock). - */ - write_seqcount_begin(&irqfd->irq_entry_sc); - irqfd->irq_entry.type =3D 0; - write_seqcount_end(&irqfd->irq_entry_sc); + if (irqfd->eventfd =3D=3D eventfd && irqfd->gsi =3D=3D args->gsi) irqfd_deactivate(irqfd); - } } =20 spin_unlock_irq(&kvm->irqfds.lock); --=20 2.52.0.457.g6b5491de43-goog From nobody Sun Feb 8 00:49:25 2026 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CA4F21C16E for ; Tue, 13 Jan 2026 17:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768326378; cv=none; b=dZmrYdD/gAq7F+2YMvkuX8Y0EcoiUgV/VfGcOxOe/gS0v6wN9ux3TICw4OzoNAe4yyd/N9gtk8/KpW4Ohn1+VXRTGeej+sLwBeQcJFugGOISe4W5T0jVF2yb/h+O9JgByq41gGQvt0LH5xQNUsXGyzRkdcUIFvRLF4tjxlPLUjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768326378; c=relaxed/simple; bh=s5qcLLCVA2jY5aqc6PFjcFhBKKWoGxB3OeqfS/8L/6Y=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Vb/8KswMi1Keklku0qWH5656mXgXkf0muXOcVhxrvfZxQe53iD9rb7T9ZDFgye83QH/dqVTYRa7quEJKxdYZVn7rnAtZX0tS7QrnyC8zTMNQdgflsWUufuvZRaOrd8QAFF+UUCoLzJCjG84AHzKNdTWiXBVSfQxd2sfv8uMUH8U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=SpRKCRan; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SpRKCRan" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-34abd303b4aso15663379a91.1 for ; Tue, 13 Jan 2026 09:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768326373; x=1768931173; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=4CraqsN8zUJ5wBwG4fLZa6cryGuFuoNdJFyZA+YKRFU=; b=SpRKCRanEHotWFCcqHWl2eyBDcwEKGMSL6NQ3y6VlkwNt4Ax3J7rTKdEl8zTZpkbi9 beI5ieytXaJE7RNb7FJ7dlQvSdcUFK8+j2fJdAc+QVrs+qfqf9Rvm3pL61VcyXcqb1Vb fLg+bfJB0W7cS34VHf6sCVevMCBSGo5LmaKjxKnX8a5Y3wxt8nbEs0T6PVhOecN/p90m JQzOu+FKP9q/+wjcIBus08Sx/t9qd3GB5MafqNU8vb2EtktTJpuveIN7OqMCGZyP2ENf UyP644FMxiAMskUcYV6I5SJumqXtbTFeA3Yr42cNPnZASFpdVQsH421XWwzWZHgINpsC OIDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768326373; x=1768931173; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4CraqsN8zUJ5wBwG4fLZa6cryGuFuoNdJFyZA+YKRFU=; b=q/TAUdgbgNvnqd2Xt235I4Csr36VxRBKi4TO+1RnY2VN1B8fUgu9x0heT/DaaNGHvc xmmK5XNHWE0ZKW8b1VDF3IQKOg23o9LtYkDedawfMqFXA+JU52CyAg3FCLQyAKibpok1 8jmUux0+MHi9YLcu/vrgN6sytuzYBa6GIBabbblLacOcuCDvmem72fCa/0t/B3uzF17Q 4aF3SAqd7T5vpO+7Dkw9jOGk0MZEXbXDFo3WU+C2MCTW9NCe+y3gIBHV/l+RbMWf8dpZ Jbd5lq/HR0OM32RcIVA9J7g/AWXcgRkvGrLKCeUZpBEbEpHxLbD2L0sS25tOpNhK9D07 WdMQ== X-Forwarded-Encrypted: i=1; AJvYcCXimRFea8zqwhbMI+ZdmJBiE/vcgNX8xLreKy4/C1nd/uNZe8Sn7kh/4RIXTASuQROVc7wuxaVUllYuWrs=@vger.kernel.org X-Gm-Message-State: AOJu0YyH/TLxgZ0hO0xSplywrG+X646EbrtlcjPqpCOfjgbeR7fsHi/g YwYGCqZN5lBOhpVgtCOHdgZIIaVokD7MAYgJNUz6aaEoQVA4o4xMHRDQvMHGTJ2OrvMboUZJiuq ZpaBuDw== X-Google-Smtp-Source: AGHT+IEjY7ADT1ZxCtwPjnM/2bCNCF/Z7AnwYEw5eULnlRYie/qAccGeg6dWSK+Wosg2sEorAm0VWPbWFKQ= X-Received: from pjty24.prod.google.com ([2002:a17:90a:ca98:b0:34a:6f9f:4531]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:568d:b0:34a:a65e:e6ad with SMTP id 98e67ed59e1d1-34f68c32ae0mr19229737a91.1.1768326372671; Tue, 13 Jan 2026 09:46:12 -0800 (PST) Reply-To: Sean Christopherson Date: Tue, 13 Jan 2026 09:46:06 -0800 In-Reply-To: <20260113174606.104978-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260113174606.104978-1-seanjc@google.com> X-Mailer: git-send-email 2.52.0.457.g6b5491de43-goog Message-ID: <20260113174606.104978-3-seanjc@google.com> Subject: [PATCH 2/2] KVM: x86: Assert that non-MSI doesn't have bypass vCPU when deleting producer From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marc Zyngier , Oliver Upton Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When disconnecting a non-MSI irqfd from an IRQ bypass producer, WARN if the irqfd is configured for IRQ bypass and set its IRTE back to remapped mode to harden against kernel/KVM bugs (keeping the irqfd in bypass mode is often fatal to the host). Deactivating an irqfd (removing it from the list of irqfds), updating irqfd routes, and the code in question are all mutually exclusive (all run under irqfds.lock). If an irqfd is configured for bypass, and the irqfd is deassigned at the same time IRQ routing is updated (to change the routing to non-MSI), then either kvm_arch_update_irqfd_routing() should process the irqfd routing change and put the IRTE into remapped mode (routing update "wins"), or kvm_arch_irq_bypass_del_producer() should see the MSI routing info (deactivation "wins"). Signed-off-by: Sean Christopherson --- arch/x86/kvm/irq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c index a52115441c07..9519fec09ee6 100644 --- a/arch/x86/kvm/irq.c +++ b/arch/x86/kvm/irq.c @@ -514,7 +514,8 @@ void kvm_arch_irq_bypass_del_producer(struct irq_bypass= _consumer *cons, */ spin_lock_irq(&kvm->irqfds.lock); =20 - if (irqfd->irq_entry.type =3D=3D KVM_IRQ_ROUTING_MSI) { + if (irqfd->irq_entry.type =3D=3D KVM_IRQ_ROUTING_MSI || + WARN_ON_ONCE(irqfd->irq_bypass_vcpu)) { ret =3D kvm_pi_update_irte(irqfd, NULL); if (ret) pr_info("irq bypass consumer (eventfd %p) unregistration fails: %d\n", --=20 2.52.0.457.g6b5491de43-goog