From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a14562a9c8-9cf64716-e63e-4c1a-83f5-e3405985689d-000000@eu-central-1.amazonses.com> Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazon11021076.outbound.protection.outlook.com [52.101.70.76]) by lore.virtuozzo.com (Postfix) with ESMTPS id 95BE2802A5 for ; Fri, 16 Oct 2026 15:44:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zFrf1pYQ93GXN3iheEEK0W9DrJbuqncG9TQigqTncynlrP/LXpK8Bgpr/kw6rP/6hbk7S6DAskOgutQ9hbbrQekJmx8JsmgkNj26yD/RRuXJbkARUE2LsY7SwERo03MhxZLJOgrVf9cKTPTeuKvrdR4eNihh8wTATNw76Hl8IGJ25/pMSZ5wyNT78i+P7wexxXHBMpckxA0G9A/YVf3bT8JT4fSZeUaGKZG6zFYtJBFfBPcxl9Jul2KFmAUOgR5wAUrgMHtH/70RCtjCfbUFD2L3ALfEvX4NezctUYN3i5fSa7jNOk2AuqOXddC/HH6HIh3/Thzsxqz4vkXpGlp+Jw== 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=pE/yL6IVcGL3XmxwsOD8cMsXGUcbBUvHPcpY8d1gXcs=; b=NjZ/FJHy4N/edF7icm1u4ypV1W/VWB9rruqcmoNXEc7xZpj5TcTV7pZXk7B2hjtK+Uvn+fjmbZlMfSCY4AJuBSrgIrvGM9Jff/mhC5bMz4zqz1A7yUK9w7YWpctLGNcIbp+TP2iByN/E6Uq3u//3/lIPVZYoxhFZ5exOpwpy5+mokTDDE0X132xi+oB2PPY2BDdxhgR/qX1yq3fBH6PUcKhC0sgXytzYPvgLutJD1FrtY48l0g6EjBn4UM9H3Vo5wjOALrHhd6MiJduYC+SCIKPWM45sdXyqjoz/17d9qzNspOnuTte/j/TdoqA3OtEp3W6pqlNTP64qrCTdujEf8Q== 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=pE/yL6IVcGL3XmxwsOD8cMsXGUcbBUvHPcpY8d1gXcs=; b=p/RC6GRJXIwpG7oG8htrRriNpmxTo5Thppob8lP7JkjevCiCEowhbPK8jdyvxix9swgkWl45XOMYj3wWil69sbUQt5bMOQ8KAwUkzca5b1mAkf1ayT0oYwNw3Dg5CEtR5puBZDu/jmUOkdoryGRuukrUkPUzZJlF48qUchlNKrI= Received: from MM0P280CA0061.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:8::21) by VI0PR08MB10655.eurprd08.prod.outlook.com (2603:10a6:800:209::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.7; Fri, 16 Oct 2026 15:44:17 +0000 Received: from CPH1EPF0000052F.eurprd05.prod.outlook.com (2603:10a6:190:8:cafe::24) by MM0P280CA0061.outlook.office365.com (2603:10a6:190:8::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Fri, 16 Oct 2026 15:44:17 +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 CPH1EPF0000052F.mail.protection.outlook.com (10.167.241.170) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 16 Oct 2026 15:44:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792165456; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=jy2+YyA/oBpy7Cz+Ur+SLSlrs4My/8EZ9LfxuYcZxcE=; b=gP+JpHFaOMg/rnq70d5zXL7xbJ62HaoZV83JhtAMubKgVDRoQeyg5w2va1ZiclyH fyH7GZJPROrUzlo4Bbe6dDf3gA7VfkPD2es8wk677eCeUYbYzdvNr+WULzs8jSgucKt bmgeBnZJL2qaamuwYrIZkBUAbwW4OLgvVf/ZLnSVSQMMd6DfbEB53HGA+yL1+1mk0e3 AI+YIspaU+JEQmOIJNlQFNAm2EIyH2VLXoBmlv1jK7mb+79lc1RJGhgrSrAY0aT9gZL pM/x9qck9RZEGHMTK9uW2IbMMh6nfgP+oIjNaCppVG1iyXZu9bHuyrAn+KNzDahvV+B cCFMpv3Qtw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792165456; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=jy2+YyA/oBpy7Cz+Ur+SLSlrs4My/8EZ9LfxuYcZxcE=; b=ZzMIWPTkzgYeQYz0Oe64W/P1dVUGbuMgoGyVVsPN7x6aAe2XpjgXxTipbjAl3bGF jWJ6pj8SZ3ztQGXdwZfEjk6XNqjjhrn7MAMPQSwESZsw6ff1sg9vtIPkmcBAf4VfTtb FxykE67g5yr8dZT1eMfdMBF8rGLH63ruNhuBFSyk= Message-ID: <010701a14562a9c8-9cf64716-e63e-4c1a-83f5-e3405985689d-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v3 18/28] kvm: tolerate ioctls after kvm_close() To: Andrey Drobyshev , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261016-vfio_v1-v3-18-47487cb5a8e5@virtuozzo.com> References: <20261016-vfio_v1-v3-0-47487cb5a8e5@virtuozzo.com> <20261016-vfio_v1-v3-18-47487cb5a8e5@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2026 15:44:16 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.16-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CPH1EPF0000052F:EE_|VI0PR08MB10655:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 46cbdac8-fb7e-4c1f-71ff-08df2b9c5620 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|48200799018|376014|61400799027|32142699015|9140799003|5063699009|56012099006|4143699003|5023799004|261009223027099003|10067099003|18002099003|16102099003|22082099003|55112099003|6133799003|4113699003|5113699003|13003099007; X-Microsoft-Antispam-Message-Info: wogMnKXvgp2VgVulsrs8kTLB83kBqZ1cMwvXyQFuQDSTzeyPGS2ADSTt80kMWudyZf10vciViXfD445yjSJD4XLWIbSH4Mz0kheJRIj8WyNT7wgpDyKq8nvdPHKFCK07RLT85C5OpfjyMv+wlzJWUf4WnbE+krOKSjI77BNbb7VMcUYo74FWa3NCUD2zkephhU9P0rEnaAe60q/WUwZAOhLusdiUMnRLwQx9JuBXrVYYWhSfFAdGmwf8pRWb8xME3kbTaeI6wYS9NSv8uyz6RyxPtelxXOlcSMiSVSjiIXdqoErcdq4UhrGPJczbCv4AafOv+uWv5K2LZ5gIzgJziQVXaVUOCpTJkC3agT4FyixB4ZJkJBnSM9cPCRpRPiYnj7wsWreF+azoXi6enCt7x9HLW1JmU0IONY3eV6UC1qmBgrbf9ST2BKETxjRMvTVWiGFqbCFohWWJO/NrufORcrdICJjvemlLgRjFOGCY+c/3byTU38cVvc5dJAWUqgS5O2ZVeOEsKdrCwvpdv13Oovoktg2a4I/8TpUzMcH8l619QD5WkSA4/Iib7l0Yc/MZB8xqycCWwb9b5r+8jOa811XFfxMpzud4vta5pPc/0V6HL3pjZO3JHR/tgyS4Rt2GdS00851jWmkbc04jE7LgHDN7mWLPLZLs6Rqvv44lhVjZCmX5UEnIRoEas72dzud0CmJd4qUPQX4unmxFVR1F3t2Zgx7oy0cmdhc1yYOhfdXjenrw/nw1L9PARnJrbx/ENG9GQIwIlHaqHyXwtKCWZ72FKvEsDF2AjQIs59FENFSR96L/oard+si+uZFlLPY1 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)(48200799018)(376014)(61400799027)(32142699015)(9140799003)(5063699009)(56012099006)(4143699003)(5023799004)(261009223027099003)(10067099003)(18002099003)(16102099003)(22082099003)(55112099003)(6133799003)(4113699003)(5113699003)(13003099007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WuTnM2Lx59se+3qpDJYAK1qBNw4hpYJaz/hlkizU/Gw8RGSpYzeyx4tcAN8CpGJHj0gUbWZthCzMIJ+bd4IDNZttnQxwr8+zrmw3FwqtK9rH1w+fSsd1ZBynMH6kWvx4BOLJmxw0hqx+nzYdm94vBpgX6G2sBGXDVqXMRK4hNN2HCmGkotk2uiSINC/NLHgcAeeDAxTVLZJ5aP8dggQ+plMvoMH5TOc/3EMXwZYL37gSGBBsecCk03bJmbCVeDp4ILhqNNXHYN9a03F87j/rHYj6kOL9LYafUsHhbW5LFfnzqlooMPeeY1CiIQCCitjQGM8c3EYPxY88H/rckJ+EaRgKC+FRhs9sa6mt5FmxuYuVrKJgcQbQsqEWfvGcRqUJ2lmHG6SPDpavZ9jjbUtVQbDsxkqP2eTk778e8CWupdtCk7zg+Fl2fCwxI+UEcQ0q X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2026 15:44:16.7853 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 46cbdac8-fb7e-4c1f-71ff-08df2b9c5620 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: CPH1EPF0000052F.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10655 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] kvm: late INTx via kvm_set_irq() still crashes after kvm_close() - [Medium] kvm: kvm_set_ioeventfd_mmio() returns stale -errno on new -ENODE= V path - [Low] kvm: unsynchronized closed-state check in ioctl wrappers races with= kvm_close() -- commit 6d5d5f6faa5b401fc25d81071e7ee69ce2c8465b 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. It also stops kvm_send_msi() from printing the "MSI lost" warning for that case. The goal is to stop the retired cpr-transfer source from crashing on late interrupts. > kvm: tolerate ioctls after kvm_close() > Make the ioctl wrappers honour the closed state instead of assuming a > live KVMState: kvm_ioctl(), kvm_vm_ioctl() and kvm_vcpu_ioctl() return > -ENODEV when kvm_close() has already been called, so any late interrupt > or query on the retired source fails gracefully. The commit message says any late interrupt fails gracefully. Is that accurate? Only the MSI path through kvm_send_msi() is fixed. The findings below describe other late-interrupt paths that still crash. > 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); > accel_ioctl_begin(); > ret =3D ioctl(s->vmfd, type, arg); [Severity: Medium] Can a late INTx or GSI line interrupt still crash after kvm_close()? kvm_close() sets kvm_state to NULL, but kvm_kernel_irqchip and kvm_async_interrupts_allowed stay true. A late line interrupt then takes this path: kvm_ioapic_set_irq() / kvm_pic_set_irq() kvm_set_irq(kvm_state =3D NULL, ...) kvm_vm_ioctl(s, s->irq_set_ioctl, &event) The argument s->irq_set_ioctl is evaluated in kvm_set_irq() before kvm_vm_ioctl() runs. With s =3D=3D NULL it faults there, so the new "!s" check is never reached. If s were non-NULL but closed, the new -ENODEV would make this code take the error branch: ret =3D kvm_vm_ioctl(s, s->irq_set_ioctl, &event); if (ret < 0) { perror("kvm_set_irq"); abort(); } That would turn the late interrupt into an abort() instead. kvm_irqchip_commit_routes() has the same problem: ret =3D kvm_vm_ioctl(s, KVM_SET_GSI_ROUTING, s->irq_routes); assert(ret =3D=3D 0); The new -ENODEV would trip the assert. I compared the end of the series against this patch for accel/kvm and hw/i386/kvm. The only change there is the coalesced MMIO ring handling in kvm_close(). Nothing guards kvm_set_irq(), the IOAPIC and PIC callbacks, or the irqchip route helpers. Should those callers be taught about the closed state as well? [Severity: Low] Is the new closed-state check safe against a concurrent kvm_close()? The check is a plain, unlocked load of s->vmfd: if (!s || s->vmfd =3D=3D -1) { return -ENODEV; } ... accel_ioctl_begin(); ret =3D ioctl(s->vmfd, type, arg); It is not atomic with the later use of s->vmfd. accel_ioctl_begin() returns immediately when the BQL is held and only takes the lockcnt for non-BQL callers. kvm_close() does not call kvm_ioctl_inhibit_begin(). kvm_close() also closes the fd before it stores -1: close(kvm_state->vmfd); kvm_state->vmfd =3D -1; Can a non-BQL thread pass the -1 check and then call ioctl() on a closed or recycled descriptor? The likely result is a spurious -EBADF. A recycled fd number could refer to another file. I did not find a specific non-BQL caller that runs during kvm_close(). The wrappers just don't exclude one. The BQL-held callers and the vCPU threads (stopped by cpu_remove_sync()) are covered. The same applies to kvm_vcpu_ioctl() and cpu->kvm_fd: > @@ -3409,6 +3419,11 @@ int kvm_vcpu_ioctl(CPUState *cpu, unsigned long ty= pe, ...) > arg =3D va_arg(ap, void *); > va_end(ap); > =20 > + /* kvm_close() has been called: the vCPU fds are gone */ > + if (cpu->kvm_fd =3D=3D -1) { > + return -ENODEV; > + } > + > trace_kvm_vcpu_ioctl(cpu->cpu_index, type, arg); > accel_cpu_ioctl_begin(cpu); > ret =3D ioctl(cpu->kvm_fd, type, arg); Similarly, kvm_send_msi() reads the global kvm_state without any synchronization against kvm_close() setting it to NULL. The KVMState object itself is never freed, so only the fd value is racy. [Severity: Medium] Can the new early return in kvm_vm_ioctl() give kvm_set_ioeventfd_mmio() a stale errno? kvm_vm_ioctl() already returns a negative errno value. The new -ENODEV return never calls ioctl(), so errno is not set. kvm_set_ioeventfd_mmio() ignores the returned value and re-reads errno: ret =3D kvm_vm_ioctl(kvm_state, KVM_IOEVENTFD, &iofd); if (ret < 0) { return -errno; } After kvm_close() this returns whatever errno an earlier failed syscall left behind. If errno is 0, the failure is reported as success. If errno is non-zero, the caller reports a misleading error. The callers kvm_mem_ioeventfd_add() and kvm_mem_ioeventfd_del() abort() on any negative return: r =3D kvm_set_ioeventfd_mmio(fd, section->offset_within_address_space, data, true, int128_get64(section->size), match_data); if (r < 0) { fprintf(stderr, "%s: error adding ioeventfd: %s (%d)\n", __func__, strerror(-r), -r); abort(); } Should kvm_set_ioeventfd_mmio() return ret instead of -errno? The sibling kvm_set_ioeventfd_pio() already returns the kvm_vm_ioctl() value directly. I did not confirm that kvm_enabled() stays true after kvm_close(). I also did not find a path that deletes an ioeventfd after kvm_close(), such as device unrealize during qemu_cleanup. So I'm not sure this can be triggered today. --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261016-vfio= _v1-v3-0-47487cb5a8e5@virtuozzo.com?part=3D18