From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11023073.outbound.protection.outlook.com [52.101.72.73]) by lore.virtuozzo.com (Postfix) with ESMTPS id 0602080726 for ; Tue, 13 Oct 2026 15:44:44 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gno7tf8nFYPzPfOQfRpd/vHeMOA/RfAInzOom8z36JufDD+07PvNYHG2yBpFuy0DW6WR4J8GAvHFm3aaanMAdA3pxvKd1YMJKwKuhbPRdpakj7gS206Roo1JezVBKgKiKKkie/APi3MPcW+OUM46qwKVxQCQMMfroFcBBIYsD92F467c4o3l0ohZwntkKuoNg4KRT0c2M1SSXuzf+lHEq6sKUP6JdRxgVE+GwwDnmyAO4T8fD6lOxE55C3wAYVPzq3urg715t6jCH3dL5+csnWKqkuE6QbhQT58pS7Fdv7i5MpElgTldI/8FGxmw1guXD6LSNFKULwbykb0cvGHG6A== 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=DCIHa1E0gqZ/68gY3RJisv9nb2kGo6bSFpLSaf0akuo=; b=OwCAinyFQ7u+NpsML2V3I/jGIXiiEn37WrUuzeW4n3VjgP0J7dfp9djdZXE0YVu+z6pQl+vl5rlDoTVJ2K6H5EJMsTsO0Koimew5D9niV6xbOn3Jsb5szqOtiF80qyryld55yH8HsTO+WgBv/QBiYT5eK4VWS3s7jYivM+wOxpSh/ObvOwHI7fYbypa2AC6mE8HQCaaDjg9h4/KAXW+cdUdrmM7WGNd1a61k0Tsy1cavpEGST1GNv/N0ge2OxcISyJWcIBD3rzuldO0WlO67vPjXF2ZeiKxgXUO0/v4sQYdPZSrnIwLlfIX3Q3hkzBLmgsL3YC0r4EfByzVpelzfyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.2) 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=DCIHa1E0gqZ/68gY3RJisv9nb2kGo6bSFpLSaf0akuo=; b=AEJO/qaDAWJLtabvXc4++v7IhQZr/wah16tHkkvheJWAvWAPBC+L7jgXWcAvYL1XegGkPXUh49GGM+RgHqctx4EFJ2I4IFdv0u/ZzzUpS4WN36YPvbK2zBkHivcUdGyz5olExJTZ/zFizDgIzjVLnTV5AmT0goZSX/oD1zeeLFs= Received: from PR3P189CA0059.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:53::34) by DU0PR08MB9557.eurprd08.prod.outlook.com (2603:10a6:10:44e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.7; Tue, 13 Oct 2026 15:44:37 +0000 Received: from ZR1PEPF0000E6BA.eurprd07.prod.outlook.com (2603:10a6:102:53:cafe::8) by PR3P189CA0059.outlook.office365.com (2603:10a6:102:53::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.496.5 via Frontend Transport; Tue, 13 Oct 2026 15:44:37 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.2) 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.2 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.2; helo=b224-2.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-2.smtp-out.eu-central-1.amazonses.com (69.169.224.2) by ZR1PEPF0000E6BA.mail.protection.outlook.com (10.167.241.73) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Tue, 13 Oct 2026 15:44:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791906276; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=Scj6HG7xqx6oP+XPcxgFI91k09AQIeji5uqekvMpJes=; b=Pk/JODbjReSBCYel4WDtNCGJATyIAvm/2oZxgHVCxyzRBha5fGM/rnbaufHgtBQx HiROZwLrHvLjNnJ4xHGWTzSBA7kNYtDnMUH5Yr+8h8Jzx/dWGvfst+pU1k5EC6DHbFU UxkoI8QJJbGk4j0Q6/Tk4hVbfrPGYLTY60oDR0+WkL48Rsg7pTGgqw5mJzc3noGD1EX PborjNDYKqOt93TJcE9DKbTygVBUNGtREreRcyoeWuvxHHcFQ0OI41mBOQH8eoZG5mY XqERIt1tbmrcGd0oY8J8N45U+KmZQuBSERZToWBC93Fm2bxPAjD0HXwEk9tR6vd2AhS Vm7UdTmoFw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791906276; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=Scj6HG7xqx6oP+XPcxgFI91k09AQIeji5uqekvMpJes=; b=mGg9bMYVoT+wW5SGFsO9l9uuPIyZx9vPwbiSvnTSHI0UqVkGec7HmxsvgxOxt7V1 Nl+i5Ws3RrR1slGxo/vopbXlTQAjIY1xcm+EumLnPe9rJUyBRL8+ftLVcHgCvAKc3rj yhoCEITmat5QmnnLEq+a9UQ3FIhcbPdNGS75VbUM= Message-ID: <010701a135efe4c7-e45b9bd0-4d45-42e6-b3cd-cef25bccae49-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v2 15/24] kvm: tolerate ioctls after kvm_close() To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261013-vfio_v1-v2-15-433455c0a294@virtuozzo.com> References: <20261013-vfio_v1-v2-0-433455c0a294@virtuozzo.com> <20261013-vfio_v1-v2-15-433455c0a294@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2026 15:44:36 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.13-69.169.224.2 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: ZR1PEPF0000E6BA:EE_|DU0PR08MB9557:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 387ce6b0-633c-46b8-8787-08df2940e2db X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|48200799018|376014|61400799027|9140799003|32142699015|56012099006|5063699009|4143699003|22082099003|16102099003|55112099003|10067099003|5113699003|4113699003|18002099003|13003099007|261009223027099003; X-Microsoft-Antispam-Message-Info: 9nr0uRSsGKtg8a+Uhns3BQaQAMwGs5ARie/+9+2aF6+KK2TH0hmbLEk8kQfdJE6xqBz5sBEhIiGEhMVumexGnpX5UolOWejk9VNlJJhHapI6IiGD3Vfl7TnJ8dALgs2hfvAVWQBy+lzgutaNZSHW6TQxrnFt7MNzACiGK9VczwQ8+o/TpkeAjTffg9VtORpQsDHf3iS4kDFyxpAakFg/Xo3f3kW12B4XLDIAKAmIn7Q4bxMQNeZXtY7inO6uQQpfklBPYKxX7xrNCoiRKaUAM/GSg/+ppO+52358z3ZOwMtwfVxjg5pM3kSzfhXZhtcM4u3xM2OGBwrghSACia6QT3JBYIQxeBEErkcjNJ1Ft7Fp91F7Nk+BdcUrbPYJSrkzGra4dsH7uMtg6ydg5qluUVyBCgd/oDsFovI6xHE6YziamAgH5eGivnrxKCFfJd9b7VYTY/+2kKriEk/0HpfLLI+CVDUtmlYJRV4G5b3f22rVVnpcjPYL88NKuXtegNMZfNfi00nNLctkDaAPbUIC8pa/nkONkwkirNTinl5UKJPtXVgx3zCHu4Bg5VgM992kTDTpteLpbTFeJJe1TSMdarrVwl9GIHE1iL86GbAkPN8wxUJ2iiupe2yIQFFkkTnSR5Prk401tYZC3786J365eua3QuLY+8hsaGBtOfcLe18Rk19hhTsJr6NbGq8b03MFUp0JkH9X7tsDOKuI0o4IhEyVjSHXGkru7B5yPfGJswjA83lJ7GubH+7zvCcDMDyvSnG6BA/dnpgNabdc4Fk76HlI8l2aONqD5FQvinlFIeePEcUuZf7NZa/j+rb8Y4LK X-Forefront-Antispam-Report: CIP:69.169.224.2;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-2.smtp-out.eu-central-1.amazonses.com;PTR:b224-2.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(48200799018)(376014)(61400799027)(9140799003)(32142699015)(56012099006)(5063699009)(4143699003)(22082099003)(16102099003)(55112099003)(10067099003)(5113699003)(4113699003)(18002099003)(13003099007)(261009223027099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: h+gpYHeNFNX0rAmvU5GO21XE2Gm++IZkjwrtWGYwaHXGbEQdadfABsfYwnlRtcx5H9zuqLe9Zki7UubZ85jiCELpKD/EMvxMpzSUyLZs4VqU72jkVoOI9fhwjpvJcUvqA0UlCL2+B7/kaznaU3WVgTRCas98ike2ADjNa7OwL15k5/AtouaE+YF3U6pB3maHIzOxZh/naGOH1ZgUoB8FsHWiv8OBJPo6/E8aMcyTfRZbMmDh9s48qRZbPm/it5eel1kvOHON9Qd/XOyJS+hIABl8XGW0816XHCW5EMPMOHEx5mMrxw3gk6YpLMvlzQ+pBc8L5LPvzt3zmZ1Wd1xI4bawMSwcBKXa9EsCFSxFZyo1aaUiHxGF4GotBKl2RW3loJCQPFa47AbD0ad+y+sqLNr6gVbdAPosLRoBbl9j/UtTLQ/sG1LicepCJaTleK7P X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 15:44:36.9726 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 387ce6b0-633c-46b8-8787-08df2940e2db X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: ZR1PEPF0000E6BA.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9557 Thank you for your contribution! Sashiko AI review found 3 potential issue(= s) to consider: - [Medium] kvm: kvm_set_irq() and listeners still deref NULL kvm_state afte= r kvm_close() - [Medium] kvm: -ENODEV from closed-state guards still aborts in fail-fast = callers; stale errno in ioeventfd - [Low] kvm: closed-state sentinel reuses -ENODEV, which kvm_send_msi() can= not tell from a kernel -ENODEV -- commit 32c3566efef848fa0bd62b2fabb9b95d82114443 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() no longer warns on -ENODEV. 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; > + } > + [Severity: Medium] Can callers that treat any negative return as fatal still bring down the retired source? After kvm_close() the memory listeners are still registered and kvm_enabled() is still true, so these callers now receive -ENODEV: kvm_mem_ioeventfd_del() if (r < 0) { fprintf(stderr, "%s: error deleting ioeventfd: %s (%d)\n", __func__, strerror(-r), -r); abort(); } kvm_set_irq() ret =3D kvm_vm_ioctl(s, s->irq_set_ioctl, &event); if (ret < 0) { perror("kvm_set_irq"); abort(); } kvm_irqchip_commit_routes() ret =3D kvm_vm_ioctl(s, KVM_SET_GSI_ROUTING, s->irq_routes); assert(ret =3D=3D 0); kvm_update_clock() in hw/i386/kvm/clock.c ret =3D kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data); if (ret < 0) { fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(-ret)); abort(); The same applies to kvm_mem_ioeventfd_add(), the PIO ioeventfd variants and kvm_log_clear(). Would a late legacy IRQ, a memory region update, a routing commit or a clock query on the retired source still end in abort() or assert()? The commit message says these cases now "fail gracefully". Also, the new early return skips ioctl(), so errno is not updated. In kvm_set_ioeventfd_mmio(): ret =3D kvm_vm_ioctl(kvm_state, KVM_IOEVENTFD, &iofd); if (ret < 0) { return -errno; } Doesn't this return a stale errno, which may be 0 or an unrelated value, when kvm_vm_ioctl() returns -ENODEV from the new guard? [Severity: Medium] This isn't fully fixed for legacy interrupt callers either. The guard helps only if the call reaches kvm_vm_ioctl(), but kvm_set_irq() evaluates s->irq_set_ioctl as an argument before the call: kvm_set_irq(s, irq, level) ret =3D kvm_vm_ioctl(s, s->irq_set_ioctl, &event); With s =3D=3D NULL this is a NULL dereference before the !s check can run. = It is reached with kvm_state =3D=3D NULL from: 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); The final return in kvm_set_irq() also reads s->irq_set_ioctl. Memory listener callbacks such as kvm_coalesce_pio_del() also use kvm_state directly: KVMState *s =3D kvm_state; if (s->coalesced_pio) { kvm_close() sets kvm_state =3D NULL but does not unregister the memory listeners or the irqchip users. Can an emulated INTx device raising a legacy interrupt, or a memory region removed during qemu_cleanup(), still hit the SIGSEGV this patch is meant to remove? The later patches in the series change only coalesced-MMIO ring handling in kvm_close() and the CPR-exec and VFIO code. They do not address these callers. [Severity: Low] Is -ENODEV distinct enough to mean "closed"? The check in kvm_vm_ioctl() tests s->vmfd =3D=3D -1, and kvm_accel_instance_init() also sets: s->fd =3D -1; s->vmfd =3D -1; so callers that run before the VM is opened now get -ENODEV instead of -EBADF. I did not find any caller in accel/kvm, target/i386 or hw/ that depends on -EBADF. [ ... ] > diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c > --- a/hw/i386/kvm/apic.c > +++ b/hw/i386/kvm/apic.c > @@ -196,7 +196,11 @@ static void kvm_send_msi(MSIMessage *msg) > msg->address =3D kvm_swizzle_msi_ext_dest_id(msg->address); > =20 > ret =3D kvm_irqchip_send_msi(kvm_state, *msg); > - if (ret < 0) { > + /* > + * -ENODEV means kvm_close() has already run (the VM was handed over > + * via CPR); the interrupt is meaningless here and not worth a warni= ng. > + */ > + if (ret < 0 && ret !=3D -ENODEV) { [Severity: Low] This isn't a bug I could confirm, but the check suppresses the "MSI lost" warning for any -ENODEV, not only the post-kvm_close() case. Since the same value is also an errno the kernel could return from KVM_SIGNAL_MSI, the two cases cannot be told apart here. I could not confirm that the kernel returns -ENODEV for that ioctl. Would testing kvm_state =3D=3D NULL in kvm_send_msi() before the call be a more precise way to detect the closed state? > fprintf(stderr, "KVM: injection failed, MSI lost (%s)\n", > strerror(-ret)); > } --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261013-vfio= _v1-v2-0-433455c0a294@virtuozzo.com?part=3D15