From nobody Mon May 25 13:49:02 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=reject dis=none) header.from=rsg.ci.i.u-tokyo.ac.jp Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1777039647985586.4965645572878; Fri, 24 Apr 2026 07:07:27 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wGHBa-0002Yv-9Z; Fri, 24 Apr 2026 10:07:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wGHBY-0002Yf-1R for qemu-devel@nongnu.org; Fri, 24 Apr 2026 10:07:12 -0400 Received: from www3579.sakura.ne.jp ([49.212.243.89]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wGHBU-0007Oc-Ln for qemu-devel@nongnu.org; Fri, 24 Apr 2026 10:07:11 -0400 Received: from h205.csg.ci.i.u-tokyo.ac.jp (h205.csg.ci.i.u-tokyo.ac.jp [133.11.54.205]) (authenticated bits=0) by www3579.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 63OE6rPa008037 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Apr 2026 23:06:54 +0900 (JST) (envelope-from odaki@rsg.ci.i.u-tokyo.ac.jp) DKIM-Signature: a=rsa-sha256; bh=7G78Igp1Lu4v5hrzs81W2MRUUjdazJoXCvgc1oemwsU=; c=relaxed/relaxed; d=rsg.ci.i.u-tokyo.ac.jp; h=From:Message-Id:To:Subject:Date; s=rs20250326; t=1777039614; v=1; b=I+86AiLMnFnJDxIxqZaO5Min/1beEcY3PNZoegX8oO7wWphDoNVAZNoYHzbQVzby JNYQw/0tpo+jlm/LU04ezqi8EvkIaHa1MTaUpy54n4eoZ3yRhjS/X5OzIHDWQ0jv 1Wq1GoUXMg/T+ev7bNWqWUmulJXHuXk9Vm8gyYalqj2mEomSAGY88olhlAbHKLai S2fIj2NBCoGBvU4g4r7ql8HvrwiT3OCbKjXNk/Irtc4OkawJilTPGxnV1bC8t5sh EGZOxtrMZQse0DX3ar0AgNbKEMfnLqVVHjBRSI26hYqEmpwkA5q7bhBTSLOCpK3w FV8ibtY3Trin2WcgjqJc9Q== From: Akihiko Odaki Subject: [PATCH v2 0/2] virtio-gpu: Do not wait for the main thread during reset Date: Fri, 24 Apr 2026 23:06:40 +0900 Message-Id: <20260424-gpu-v2-0-9fd2fc0dd1bd@rsg.ci.i.u-tokyo.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-B4-Tracking: v=1; b=H4sIAAAAAAAC/1WOQQ6DIBBFr2JmXQigxuiq92hcIB112lgsIKkx3 r1UV12+yZ/3/wYeHaGHJtvAYSRP9pVAXTIwo34NyOieGJRQpRSqZsO8MJP3RVkVVV91GlJydtj T57Dc2sQj+WDdekij/F3//6NkkmGOuakQO1Pj1fmBG+LEFxbsc7VcG/6Yod1Pu8P3kqaFswI67 ZEZO00UmixKyQUXKbt/AY0yuJ7OAAAA X-Change-ID: 20251029-gpu-c3f45747f7ba To: qemu-devel@nongnu.org Cc: =?utf-8?q?Alex_Benn=C3=A9e?= , Dmitry Osipenko , "Michael S. Tsirkin" , Akihiko Odaki X-Mailer: b4 0.16-dev-16047 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=49.212.243.89; envelope-from=odaki@rsg.ci.i.u-tokyo.ac.jp; helo=www3579.sakura.ne.jp X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZM-MESSAGEID: 1777039650569158500 This fixes a deadlock I previously observed with the test in [1]. However, I can no longer reproduce the issue reliably with that test, so I used Codex, a coding agent, to write a more reliable local test case, shown below. I applied to Codex for Open Source to get access. The test case is not intended for merge: current policy prohibits that, and it is probably not worth carrying anyway because race-condition tests are inherently fragile. The remaining patches were written by me. [1] https://lore.kernel.org/qemu-devel/20251014111234.3190346-9-alex.bennee= @linaro.org/ To: qemu-devel@nongnu.org Cc: Alex Benn=C3=A9e Cc: Dmitry Osipenko Cc: Michael S. Tsirkin Signed-off-by: Akihiko Odaki Below is the Codex-written test case: diff --git a/tests/functional/aarch64/test_gpu_blob.py b/tests/functional/a= arch64/test_gpu_blob.py index a913d3b29c84..52627b4541f9 100755 --- a/tests/functional/aarch64/test_gpu_blob.py +++ b/tests/functional/aarch64/test_gpu_blob.py @@ -13,7 +13,9 @@ # # SPDX-License-Identifier: GPL-2.0-or-later =20 -from qemu.machine.machine import VMLaunchFailure +import subprocess + +from qemu.machine.machine import AbnormalShutdown, VMLaunchFailure =20 from qemu_test import Asset from qemu_test import wait_for_console_pattern @@ -25,8 +27,7 @@ class Aarch64VirtBlobTest(LinuxKernelTest): 'download?path=3D%2Fblob-test&files=3Dqemu-880.bin', '2f6ab85d0b156c94fcedd2c4c821c5cbd52925a2de107f8e2d= 569ea2e34e42eb') =20 - def test_virtio_gpu_blob(self): - + def launch_blob_test(self): self.set_machine('virt') self.require_accelerator("tcg") =20 @@ -65,9 +66,27 @@ def test_virtio_gpu_blob(self): self.log.info("unhandled launch failure: %s", excp.output) raise excp =20 + def test_virtio_gpu_blob(self): + self.launch_blob_test() + self.wait_for_console_pattern('[INFO] virtio-gpu test finished') # the test should cleanly exit =20 + def test_virtio_gpu_blob_shutdown_race(self): + self.launch_blob_test() + + self.wait_for_console_pattern('[INFO] unmapping blob object resour= ce') + + try: + self.vm.shutdown(timeout=3D10) + except AbnormalShutdown as excp: + if isinstance(excp.__cause__, subprocess.TimeoutExpired): + raise AssertionError( + "QEMU failed to exit while virtio-gpu reset was racing= " + "with shutdown") from excp + self.log.info("QEMU exited before the shutdown request complet= ed: %s", + excp) + =20 if __name__ =3D=3D '__main__': LinuxKernelTest.main() --- Changes in v2: - Added the patch "virtio-gpu: Run reset cleanup in the same BH". - My assumption about the ordering was incorrect, so I changed the patch to follow the approach used by virtio-gpu-gl. - Link to v1: https://lore.kernel.org/qemu-devel/20251029-gpu-v1-1-e3e3c7ee= bc9e@rsg.ci.i.u-tokyo.ac.jp --- Akihiko Odaki (2): virtio-gpu: Run reset cleanup in the same BH virtio-gpu: Do not wait for the main thread during reset include/hw/virtio/virtio-gpu.h | 4 +-- hw/display/virtio-gpu.c | 60 ++++++++++++++++++++------------------= ---- 2 files changed, 30 insertions(+), 34 deletions(-) --- base-commit: 14f38a63b9adc02c0ebe3b5ada1f1208abaf21ea change-id: 20251029-gpu-c3f45747f7ba Best regards, -- =20 Akihiko Odaki