From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a121420a0d-19355be9-4559-4183-b9c1-4caf1cae6311-000000@eu-central-1.amazonses.com> Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazon11021122.outbound.protection.outlook.com [52.101.65.122]) by lore.virtuozzo.com (Postfix) with ESMTPS id 5C20A8017D for ; Fri, 9 Oct 2026 15:22:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nlkY60ykDWPPPgZiPYCJofuuJ9FYhUYd1PVWPxpR1zMee2zOBzrSqsjogiryNLzlTFWLzEjojfRRXHVfnu50ARYmnHGNbgm79xTCb+iMTg037VURMEogIMrz6MqLLoE4zVs+9YP7d3uwUQUDNBBMVr/UJAcyBgQkctFrNdJVx6puHR02H4hWYzpAG0TAJHw4hHM776VL+UitVA28omV/VZWq7q1vEf646lAXN/HE0filsVbKQ1sxL3JcPtNbVO7V0MN6MBOPnj6+T6BkV3E7JIfZX/5Jzq09LybHtU0REq+IKtqHfsM5Uc/JKW1hKldiTr0fvZ4D55TgoWAxZsqXew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1kTRIHyQ2Y07jG4pJseP2l5cE540Z7F17ijn7Mxt0/Q=; b=MBpSu2qY0eKJqTHEytuYnpP/exGJtYFfhm+KIxcYErQmTkSRQzsjYoHM7MFiHmOnmABChpV375tFbVxqxmbEDLA+c0yZZ2ZwoB1e+Wq9nCxEhglbAvHg8MsDwIXuBqC7OGO41HFQ6vWV6Sce+h9VXlM1uxqilyH5g+6l9tAAVbaUQ2wVp/uGil+HgH5uiyDlG5iMrQa0b2GetxqGfB8/JWOE4Ghxv6dY1HCbKpeZXOH5ebfaRYH3zIRgWg/BVA+LphENjA+Qn2uUlPk+iBdZlZQ1IrmimUuiFnax4utcrKNeuKkV3BKdThK37iPPiHv9Ud273bPw88iCNRtXVcZeYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1kTRIHyQ2Y07jG4pJseP2l5cE540Z7F17ijn7Mxt0/Q=; b=PJFMp87k82MqJ6H0BMbOPcYFYBf3lciSgfkN3NBKLqTPCKD+5GX5Jg1LLkTe7ZMXmTOGQmAAdPb03WFCwUnscBVWg5yxWwyl9yN+/wF2upvQ48Sw+dXu999mGZcTD7T9B33VVPO+2F3+ucM8uMh3KdR9/Wz1TQ0hDf686FnYCvI= Received: from AS4PR09CA0002.eurprd09.prod.outlook.com (2603:10a6:20b:5e0::9) by VE1PR08MB5838.eurprd08.prod.outlook.com (2603:10a6:800:1a7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.5; Fri, 9 Oct 2026 15:22:19 +0000 Received: from AM2PEPF00070CF7.eurprd02.prod.outlook.com (2603:10a6:20b:5e0:cafe::ac) by AS4PR09CA0002.outlook.office365.com (2603:10a6:20b:5e0::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.20 via Frontend Transport; Fri, 9 Oct 2026 15:22:19 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by AM2PEPF00070CF7.mail.protection.outlook.com (10.167.242.9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 9 Oct 2026 15:22:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791559338; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=LDffNtrho8+urNQptA2SC/iCI+jTeda9DQG0V1F0K6I=; b=pPGDYKpqX/QiEdpD+cSCl46NhfBex05Xzd2VuMKh5yD2Al5DwN3cFTlhsifcTDXz 6tMZU2Qh9N6Hlke0MACf2ZBCemY+jWqlAIxgG1EZezBvk/j4mhKQHy1UGRvZeLJv/Ti tqKulcd5yzyQRhysnTWWYMUv6ZrxiGFShVxV6jYm3+2vxsNx4bQq/7O7MPsrxvOOb4C BJKHlFo86srHAYaPvSQHWVvkfyqOqtrMfAyYhq5xZGuNAV0vJcBbHIawo6UoQAjhwhT OHtNcKtxsoaC2Rj49EneZZU185gYb1LiyCjEZGoAgVShRbjIInV90kHwUfxiWxBfmDH c3Lm5aPlbg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791559338; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=LDffNtrho8+urNQptA2SC/iCI+jTeda9DQG0V1F0K6I=; b=jciKynk0hyj7MPoFjszA7m4n4CmT0pPiVfclnvkZ9N1i75iCpYP8bUHlJVhtoh7r Rhm+Da27mj1TbRbgT5pmtaz4BpCt1auABBKMDkHZMlBJz7MIDPxUKXPj+hokvRp8ciH 0hebSTcqY8xq/yw7a4im38DdzxEzqkJI9x/EhXHI= Message-ID: <010701a121420a0d-19355be9-4559-4183-b9c1-4caf1cae6311-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 14/21] kvm: tolerate ioctls after kvm_close() To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261009-vfio_v1-v1-14-2ae91d5b8048@virtuozzo.com> References: <20261009-vfio_v1-v1-0-2ae91d5b8048@virtuozzo.com> <20261009-vfio_v1-v1-14-2ae91d5b8048@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2026 15:22:18 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.09-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM2PEPF00070CF7:EE_|VE1PR08MB5838:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e210c9f5-20b9-4aee-4dd6-08df26191ba4 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|704160211799003|376014|48200799018|61400799027|32142699015|9140799003|5063699009|4143699003|5023799004|56012099006|10067099003|16102099003|18002099003|5113699003|22082099003|4113699003|6133799003|55112099003|13003099007; X-Microsoft-Antispam-Message-Info: U2KeMlLLfWY5+jwrN14kLOmTH3DjsqvRaEgHSYK47YiCV3FCYOaSsRI82NG2xQLA1vSl3mlHiIyToyjkAav6g8QKpZa4pREgqaxahB8dJCD2p4ZCI0zQwYQOh4g47duAhBrntAXkj/73b5GFyficO//3FmYXu/DCBNfQ3ji6IPxmLU9gWWy4esmuer7Yu2FsQXwXGa3UZwUs5kZsCTWXCcKj7BqE/TJFpPttEAmfJGaAsvoKrCrJQVcD+E4t1SpAWMvFE5TFOKO7jLjIIpucBIngvG68+AwpXi/oN1PeO/8zsAWa/CX1hwDxZ4Vfj6h+OrX7U1Hp11OzKnriO62YJk5Rg6Palao8iZUtnhhq8zsLSSNnhw5fImopHAvg3XygeFubpM69nRxF0ob1d4IVd5YNrt2SswkWZCux11wildIm+MhsaGjK2Ms1lu9Ar2vagyZdsSeMe/zQqIwk9+TVvHty8/aL+qmf44KVXTOW3zrH2uG2RxW+jSocFAa/xFn/lD0p1RtALEr2I2Tjw+KoaUN/tev7M8todNQZxSxLgVoxGcJQQ4HUORBNUlJlEk/L7TxXA4yV6HqwYHryQMi37z7h49u1p4cs5Sj3TC/HSMvw4LGnZD0bX7fRwgfKiasb7C251EG7VrEf4hfNbH8DmQl+Wk29D68iwDsbXEe96eDALuNFRWW3wgVsHSdAXjk7LWa/0bDXYl0DJbmSQxotLG5h5gkvHRqFUglUEnYT7/9qaN6dWMkVb/FsyH6CxKxZOErOXaapjmPdy+ZdVd7gPamyYmP9o/paBYmzEg1qYvcRH9dn31kX7HsrCbdBPEtNfA5HQ92V/mCuf8a61GW6A2uA64Q+zOZMGbnemcMMhzU= X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(704160211799003)(376014)(48200799018)(61400799027)(32142699015)(9140799003)(5063699009)(4143699003)(5023799004)(56012099006)(10067099003)(16102099003)(18002099003)(5113699003)(22082099003)(4113699003)(6133799003)(55112099003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: aB2+feGJIYKp+8L20ViuUnY6nvyLdGcYqhx/Yzb2+GbvH1VrAUSSuGm6ZY+YFDYcYmuHNS8XI3Bfui5VndCHQsqlIilVfVUg/PH0rdMmF35hdJv5fZ1D55dFtc1pjkoRn7g9fn7moLlIkK0SeM8r8HO18tPNf3Nr1lheMc4IIIvchk7AbMZ1rDkJRtQrbYFxUq3eggA8IJmzChAW6zzCeN/WKWAWDeD5KZJ16AsKMM9jhIst5OKBVm4SHE5HVEq5uquAvWBPdez9/omj5xt+Nkfn0KA3cDOR+1W4/yAWcKTzxrdaJ+drKgBg/pQamKhu5b9wgip0LyX8/R24dnVBJSIwp7UEfsZJmJJsdoqQF4JuHoJV2BefxmjfaIHR7F8tvx/pPNXhoveyGVWsFdX1gEsvalSvC77qA4U7Q16ENjA3AaRzD0XRBidCO6DU6/ZB X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:22:18.9072 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e210c9f5-20b9-4aee-4dd6-08df26191ba4 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF7.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5838 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] kvm: kvm_set_irq() still crashes or aborts after kvm_close() on = legacy IRQ paths - [Medium] kvm: irq-route and accessor helpers still deref NULL kvm_state a= fter kvm_close() - [Medium] kvm: early -ENODEV in kvm_vm_ioctl() leaves errno stale for call= ers that use errno -- commit a16b8da8a608436a2f83533cd5dc4b33bbf1644c Author: Andrey Drobyshev kvm: tolerate ioctls after kvm_close() This patch makes kvm_ioctl(), kvm_vm_ioctl() and kvm_vcpu_ioctl() return -ENODEV once kvm_close() has run. kvm_send_msi() is also changed so that -ENODEV does not print the "MSI lost" warning. The aim is to stop a retired cpr-transfer source from crashing on late interrupts. > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > --- a/accel/kvm/kvm-all.c > +++ b/accel/kvm/kvm-all.c [ ... ] > @@ -3389,6 +3394,11 @@ int kvm_vm_ioctl(KVMState *s, unsigned long type, = ...) > arg =3D va_arg(ap, void *); > va_end(ap); > =20 > + /* kvm_close() has been called: there is no VM to talk to any more */ > + if (!s || s->vmfd =3D=3D -1) { > + return -ENODEV; > + } > + > trace_kvm_vm_ioctl(type, arg); [Severity: Medium] The early return here, and the matching ones in kvm_ioctl() and kvm_vcpu_ioctl(), never call ioctl(), so errno is not set. Some callers look at errno after a negative return instead of using the returned value. kvm_set_ioeventfd_mmio() is one of them: ret =3D kvm_vm_ioctl(kvm_state, KVM_IOEVENTFD, &iofd); if (ret < 0) { return -errno; } return 0; After kvm_close(), can this return 0 (silent success) if errno happens to be 0, or an unrelated stale errno otherwise? Its callers kvm_mem_ioeventfd_add() and kvm_mem_ioeventfd_del() call abort() on any negative result: r =3D kvm_set_ioeventfd_mmio(fd, section->offset_within_address_space, data, false, int128_get64(section->size), match_data); if (r < 0) { fprintf(stderr, "%s: error deleting ioeventfd: %s (%d)\n", __func__, strerror(-r), -r); abort(); So a late ioeventfd removal on the retired source, for example from a memory region commit during device teardown, could still end in abort() instead of failing gracefully. kvm_create_guest_memfd() has the same pattern: fd =3D kvm_vm_ioctl(kvm_state, KVM_CREATE_GUEST_MEMFD, &guest_memfd); if (fd < 0) { error_setg_errno(errp, errno, "Error creating KVM guest_memfd"); This reports errno rather than -ENODEV. kvm_set_memory_attributes() uses strerror(errno) in the same way. The KVM_GET_STATS_FD callers test "=3D=3D -1", which -ENODEV does not match= , so they would carry on with stats_fd set to -19. Would setting errno =3D ENODEV before each early return, or changing these callers to use the returned value, be more robust? [Severity: Medium] Separately, the commit message says "any late interrupt or query on the retired source fails gracefully". Does that hold for the helpers that dereference kvm_state before any ioctl wrapper runs? kvm_close() sets kvm_state to NULL, but kvm_enabled() stays true: accel/accel-irq.c:accel_irqchip_release_virq() { if (kvm_enabled()) { kvm_irqchip_release_virq(kvm_state, virq); } ... } accel/kvm/kvm-all.c:kvm_irqchip_release_virq() { ... for (i =3D 0; i < s->irq_routes->nr; i++) { ... } With s =3D=3D NULL, this faults on s->irq_routes before the new "!s" check = can be reached. The only early return is kvm_gsi_direct_mapping(). The same applies to kvm_irqchip_commit_routes(), which writes s->irq_routes->flags. It is reached via accel_irqchip_commit_routes() from the virtio-pci unmask path and from the ioapic code. kvm_irqchip_update_msi_route() ends in kvm_update_routing_entry(s, ...), which reads s->irq_routes->nr. The plain accessors kvm_kernel_irqchip_split(), kvm_kernel_irqchip_allowed(= ), kvm_kernel_irqchip_required(), kvm_dirty_ring_size(), kvm_has_sync_mmu() and kvm_has_vcpu_events() read kvm_state->field with no NULL check. Only kvm_dirty_ring_enabled() has a "kvm_state &&" guard. One reachable caller is the virtio-pci teardown path: hw/virtio/virtio-pci.c:kvm_virtio_pci_vq_vector_release() { ... accel_irqchip_release_virq(irqfd->virq); ... } This could be reached through set_guest_notifiers(false), device reset or device_del on the retired source, since QMP is still served. I did not trace one specific exit or QMP sequence that reaches an unguarded helper. Nothing later in the series appears to guard these helpers. The follow-up patch "kvm: fix coalesced MMIO flush racing with kvm_close()" only adds "kvm_state->coalesced_mmio_ring =3D NULL; drain_call_rcu();" to kvm_close(). Should these helpers check for a closed kvm_state as well? [Severity: Medium] The commit message claim that any late interrupt fails gracefully also looks too broad for the legacy IRQ path. kvm_set_irq() evaluates s->irq_set_ioctl before kvm_vm_ioctl() is entered: accel/kvm/kvm-all.c:kvm_set_irq() { ... ret =3D kvm_vm_ioctl(s, s->irq_set_ioctl, &event); if (ret < 0) { perror("kvm_set_irq"); abort(); } return (s->irq_set_ioctl =3D=3D KVM_IRQ_LINE) ? 1 : event.status; } After kvm_close(), can a late level-IRQ change reach this through the callers below, all of which pass kvm_state? hw/i386/kvm/ioapic.c:kvm_ioapic_set_irq() delivered =3D kvm_set_irq(kvm_state, s->kvm_gsi_base + irq, level); hw/i386/kvm/i8259.c:kvm_pic_set_irq() delivered =3D kvm_set_irq(kvm_state, irq, level); hw/intc/ioapic.c:ioapic_update_kvm_routes() kvm_set_irq(kvm_state, i, 1); With s =3D=3D NULL, the s->irq_set_ioctl read faults before the new guard r= uns. If s were non-NULL, the new -ENODEV return would reach perror() followed by abort(). Either way the retired source would still die with SIGSEGV or SIGABRT and leave a core dump, as the commit message describes for the MSI path. I did not trace a concrete device that drives these legacy lines on a retired source. Could kvm_set_irq() and its callers be made to tolerate the closed state too? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261009-vfio= _v1-v1-0-2ae91d5b8048@virtuozzo.com?part=3D14