From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a169c44a80-19795216-d297-49b1-ab30-b830e9c322b9-000000@eu-central-1.amazonses.com> Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023139.outbound.protection.outlook.com [40.107.162.139]) by lore.virtuozzo.com (Postfix) with ESMTPS id 308EE8045D for ; Fri, 23 Oct 2026 17:17:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Rkhnp8KlTQjWsu5+yQm9K7DMYIAcVGDUuio51c/7/ptswylAz4dV/CBg2j7g8DoWrDjQTTI19h3nNToSI/U68Xa41/sEV2xoVtGw2uIhmBGORXiDeJ8IhXTr9srgBpN+eekOQgqA6yDmb6M0Usrvv7NKUgSvrmK2mLa8LgH7qg/Dye03IsaC/iFJt4Ijj2eAnAOCFkq8i2FhVkomFECJVpmsEFZfkCIWVTsleuZvzFvFZaekegMcaMWiK4wCx6JvbI/8HT2Zn1AeXADhofuR8EoIMrcdw/JnZ8E3ZbvDM1PuLyvEEvLJs0AnuchIl1YU11sMOclGUQKo76b4kYIrcQ== 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=zhcg4Uv/yZUD4v0lR7cMoCwyx8fX4TMaZVHo6/M8OCM=; b=X+Bv0i3VCnWEeUBgb/p2i57BiCAv8IVWbxsGS86LpiPkL1RKAVCtukLKvAXyu8B7UwwqdTdOfjFEOwzUwz/rAQ9Wqadm08lCQT38rHilvVXu5ehg7dJScddiL6U6Iblg75IJfzZSAdsP3uK8Vk3/ByIwY5PwRFNWJQshFeki0L61HzAAQNMKpdNnm+Etgz3azB8AQGwtdnh3guGUFuURji7MSIh2RaenBrxqcJ9NBZmuBoQi+6Uw6yhvFxdmXvGI/TLSseDdc/ZscXGmu8igT77z1C8YLLIpsNV4/qr28ik8wo4vLaqJgoRifqOspsYLrMlnwiSEObUiTuSFBMypzg== 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=zhcg4Uv/yZUD4v0lR7cMoCwyx8fX4TMaZVHo6/M8OCM=; b=Q8qSI+aQR5ZIiq8ChKD26hwrLvvqmHw8kbBB2v5ZURuJcSUxpwqNpa8u5ohuLJmO8q26YJRKeYyoV5RmCBKMuexKUu5l6GMUSQzfSN92Ouk5imItZdt51Jp5JBiVx+Ok9jn8ba6q1qcfsv+JLuohOqx8V1nfTzk/RmrPyh8xWfM= Received: from GVX0EPF0005F6CD.SWEP280.PROD.OUTLOOK.COM (2603:10a6:158:401::64a) by AS4PR08MB7856.eurprd08.prod.outlook.com (2603:10a6:20b:51f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.16; Fri, 23 Oct 2026 17:17:17 +0000 Received: from WA1PEPF00009B39.eurprd05.prod.outlook.com (2603:10a6:1d8::116) by GVX0EPF0005F6CD.outlook.office365.com (2603:10a6:158:401::64a) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.19 via Frontend Transport; Fri, 23 Oct 2026 17:17:15 +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 WA1PEPF00009B39.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.569.4 via Frontend Transport; Fri, 23 Oct 2026 17:17:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792775834; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=P+Tvvye0/Otu7aROU17x9YJwtfaQRAX+np12S6e8HOM=; b=t12jqtncuMHTYKvvNC6+dSZK3qxqg70sITNVxnuVlwmcI3l2diT0xkymxzipO+6K sB/O6ayYds5EKJvZDhXqUsZoe9ax0DoKXo36w+U6iS3grlVs8lT812yRhW8zMkd3e+L byOHBbCl63fw4vUJG5s8W4EaDxebpW0IqEnZz66JXJcGsJDJAxHS4NVae50pU5tzhLw 28PLhxoyNriZgR9LRV8ENESWrfbvxWsbaS5MujtcOj0Z4X7mFANXPePFcNmDIPDLep1 eOKK3+uz6ITq9O/JfoHDrToMFDXUoB1MyO2H3hKJxO1vXv27qjCcdreSN8jkP7+nUcb Gzx/JeBX9w== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792775834; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=P+Tvvye0/Otu7aROU17x9YJwtfaQRAX+np12S6e8HOM=; b=WWRg6fY4GZw+IQecJgM81qRKAxfZswt1LNofvlbHbroE22iRnDp6rdCPRawJpEV8 6thxu9cJbJyJhaAOTREUm3Zv0TdVfnwBzIFKKIjdX4ihRuR+skdprBexnsG4CktTf+C xhLKJ69SEnmAtWxDY6AmPKKANO77Zm0uevZVXdFc= Message-ID: <010701a169c44a80-19795216-d297-49b1-ab30-b830e9c322b9-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v5 22/36] kvm: tolerate ioctls after kvm_close() To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261023-vfio_v1-v5-22-ba0bf3c6d122@virtuozzo.com> References: <20261023-vfio_v1-v5-0-ba0bf3c6d122@virtuozzo.com> <20261023-vfio_v1-v5-22-ba0bf3c6d122@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2026 17:17:14 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.23-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: WA1PEPF00009B39:EE_|AS4PR08MB7856:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f0e65f0f-936e-449e-50fd-08df31297bb8 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|32142699015|48200799018|376014|61400799027|9140799003|4143699003|261022105027099003|56012099006|5063699009|261009223027099003|261021123027099003|261021121427099003|10067099003|16102099003|22082099003|18002099003|55112099003|5113699003|4113699003|13003099007|3023799007; X-Microsoft-Antispam-Message-Info: MVQoSti6cHXBHOdAuEo34XgyztstEdviaRTC9LcN8sZPzcCOMwV82pvodcp35rwTUBwr4oJUsLScP4pJrOJ1tT35snmqB8S/7SiDtVvLyd4VZdE2VrDnqw8qs0UrTISB6uhKJRujB+/68oPT4VXC9C2ves/JJtdLn7yFXDcmWxBMNUZrAjCugVoifJsgYQLh4cIWa1c8Ior2rXPEflJPdJWDDqwxNce4ipOMtv04adyZXuw0HEWBk2SoZvdAotogWVA4/ZeotaMYUWS7m+65uQAzSYQmbWPRxvYD8dHt2CyI8bCJ4SdJyPAS5wyzgCij5Iq9czHrgN5guqz7jUs8FObEfYh9JhhRrrR48N4MZKErGJ326K4oZ+f46GXkjHMAjeKTVF3m8xm+1yg/E7ojBDsYmc9iSVliHoHvA6dt8GO3RQWIi6zbNbijeju+f1WW7RG8pFYlgK+4hH5ng68Pl97pwl4NuJEFEySUDcBu4oAInP62YjD3Onj4LSPfeV2EFkQCc8I8koJRWLkRvA88S/C41FiTZBDUoKzvDSCQW90BvcdkeMQ/45iCx/j4cq1g+68AmC/al3lFwPp4RupAzAdnIFfo4ZT0zaFGic2cUD1s4QoAk5TuRVdecoje6QIK+8r3pU0Sb5Q9FoIpBlsxN4OFkMxxafyGF0Gh6WnpumwYBAtxhrLPAmaWxuJtFJsZx80ENr9xI4pYYKr69yXxFq+q2RCm5XJomjOnj+ty7O8dMtcZiO+QtKl2bE+BrLBkmbBHJOEJRomXU0D7kg7xE/qoqpTR5PHMUELPHBKYhuGbfUZk31uyaP8joQA6MxTYhKWDweNE+ZMzGH/XutIGpflsD8GuA1hHY+z4ETM8f48Zdl+PggwJzxlDB5Kodpe+ 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)(32142699015)(48200799018)(376014)(61400799027)(9140799003)(4143699003)(261022105027099003)(56012099006)(5063699009)(261009223027099003)(261021123027099003)(261021121427099003)(10067099003)(16102099003)(22082099003)(18002099003)(55112099003)(5113699003)(4113699003)(13003099007)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +Iq+gPiedhuzGfgKFnp9xCmpxzjhBI03pv4mVPEArGXR7w56eWZRuXYhJ+brvhqbKasU+dqL8COlVcuEXywbm3b4NuPhml4ccqLkQFGDV80uClLQmNbAKGvH/S/UoqJFguMD8hmgP2IrogTC+bO7cP1qKluPYSRBCyRGparrW2WPoqdffS3BKv6KLH+4Ierv0vzGZcC5q3Yx8ogAdwTfpKhHn52hVVUCswJGN2uaSGCk6JQha4HOWRvZCm30nJvHSjfXvD7qnnjcs3Yelj89Khz29ESltBzaihkivdWk/j8TOivO/46Xa9CQ0Cq6ks9YhIy7W0DZDrgKaT56aghpu1tBbhWgEhj58jJaK8xq2TtVQHHG3te+03AfH5BjePWbXyqQXbFllMRoBLPpb0EhVYnpWFTMGmUNMhyS+JFEm3IYgo7jlHGrKCaIAqrRidJI X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2026 17:17:14.7463 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f0e65f0f-936e-449e-50fd-08df31297bb8 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: WA1PEPF00009B39.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7856 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] kvm: ioctl wrappers return 0 after kvm_close(), faking fd 0 for = fd-returning ioctls - [Medium] kvm: fd=3D=3D-1 early return makes vfio_kvm_device_add_fd() stor= e bogus fd 0 -- commit 78cd49a51c86e49590c679c12aaf6d28efd634ee Author: Andrey Drobyshev kvm: tolerate ioctls after kvm_close() This patch keeps kvm_state allocated after kvm_close() and makes kvm_ioctl(= ), kvm_vm_ioctl() and kvm_vcpu_ioctl() return 0 once the descriptors are cl= osed. The goal is to stop a retired cpr-transfer source from crashing on a = late interrupt, such as kvm_irqchip_send_msi() with kvm_state set to NULL. > 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 +3393,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->vmfd =3D=3D -1) { > + return 0; > + } > + [Severity: Medium] Can this early return of 0 be mistaken for a valid file descriptor? Several= kvm_vm_ioctl() requests return a new fd on success, and callers treat 0 as= success. query_stats_cb() and query_stats_schemas_cb() only treat -1 as an error: stats_fd =3D kvm_vm_ioctl(s, KVM_GET_STATS_FD, NULL); if (stats_fd =3D=3D -1) { ... } query_stats(result, target, names, stats_fd, NULL, errp); close(stats_fd); After kvm_close(), kvm_state is non-NULL and vmfd is -1. The fake 0 then pa= sses the check, the stats are read through fd 0, and close(stats_fd) closes= stdin. kvm_create_guest_memfd() checks only "if (fd < 0)", so it would return 0 as= a valid guest_memfd. kvm_create_vcpu() checks only "if (kvm_fd < 0)", so i= t would store 0 in cpu->kvm_fd. Later vCPU ioctls would then go to stdin. The vCPU stats path is not affected, because kvm_close() sets kvm_vcpu_stat= s_fd to -1 and query_stats_vcpu() checks for it. I did not verify that the = QMP stats commands are reachable on a retired source. I also did not find a= kvm_enabled() or closed-state guard that would block these callers. Would it be better to have these fd-returning requests fail explicitly afte= r kvm_close(), or to have the callers check for the closed state? [Severity: Medium] Can the same early return cause vfio_kvm_device_add_fd() to store a bogus f= d? After vfio_kvm_device_close() calls kvm_close(), it resets vfio_kvm_devi= ce_fd to -1, and kvm_enabled() stays true. A later VFIO add on the retired = source takes this path in hw/vfio/helpers.c: if (kvm_vm_ioctl(kvm_state, KVM_CREATE_DEVICE, &cd)) { error_setg_errno(errp, errno, "Failed to create KVM VFIO device"); return -errno; } vfio_kvm_device_fd =3D cd.fd; kvm_vm_ioctl() now returns 0 without running the ioctl. cd.fd is still 0 be= cause cd is zero-initialised apart from .type, so vfio_kvm_device_fd become= s 0, which is stdin. The following KVM_SET_DEVICE_ATTR ioctl on fd 0 fails with ENOTTY, so the a= dd reports an error with a stale errno. vfio_kvm_device_fd is left at 0. La= ter add and del calls then skip creation and issue ioctls on fd 0, instead = of reporting that no KVM VFIO device exists. Is this the intended behaviour for VFIO hotplug on a retired source? A related case is kvm_vm_check_extension(). It skips its "ret < 0" fallback= to the global check after close. That looks benign, because kvm_check_exte= nsion() also returns 0 after close. It does show that callers cannot tell t= he closed state from success. The commit message describes only the interrupt and ioeventfd callers. It d= oes not mention callers that use the return value as an fd or that depend o= n the ioctl filling an output buffer. Examples are KVM_CREATE_DEVICE, KVM_G= ET_STATS_FD and KVM_GET_DIRTY_LOG, which would report success with an unfil= led bitmap. The final series state (f62ee5bb) has the same code in query_stats_cb(), qu= ery_stats_schemas_cb(), kvm_create_vcpu() and kvm_create_guest_memfd(). The= later patch "kvm: fix coalesced MMIO flush racing with kvm_close()" and th= e other follow-ups do not change this. hw/vfio/helpers.c is also unchanged = by the series. > @@ -3409,6 +3418,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 0; > + } > + [Severity: Medium] This is the same fake-success behaviour as in kvm_vm_ioctl(). Any vCPU ioct= l that fills a buffer, such as KVM_GET_REGS, now returns 0 with the output = left unfilled once cpu->kvm_fd is -1. Can callers that consume that output = be affected? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261023-vfio= _v1-v5-0-ba0bf3c6d122@virtuozzo.com?part=3D22