From: "Alex Bennée" <alex.bennee@linaro.org>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: qemu-devel@nongnu.org,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2 0/2] virtio-gpu: Do not wait for the main thread during reset
Date: Tue, 19 May 2026 13:36:38 +0100 [thread overview]
Message-ID: <87h5o3bmp5.fsf@draig.linaro.org> (raw)
In-Reply-To: <aeeb9f81-3dd8-4fea-83ae-7d88ec1be971@rsg.ci.i.u-tokyo.ac.jp> (Akihiko Odaki's message of "Tue, 19 May 2026 15:29:28 +0900")
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> writes:
> On 2026/05/19 4:35, Alex Bennée wrote:
>> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> writes:
>>
>>> 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.
>> What sort of hit rate where you getting with the race? So far they
>> have
>> both been rock solid without the additional patches for me.
>
> I hit the deadlock in 8 out of 10 trials.
It's taking a lot longer on my system (~ 1 in 100) but with these
patches I'm still seeing a hang, it just takes a lot longer to get
there.
>
>>
>>> 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ée <alex.bennee@linaro.org>
>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
>>>
>>> Below is the Codex-written test case:
>>>
>>> diff --git a/tests/functional/aarch64/test_gpu_blob.py b/tests/functional/aarch64/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
>>> -from qemu.machine.machine import VMLaunchFailure
>>> +import subprocess
>>> +
>>> +from qemu.machine.machine import AbnormalShutdown, VMLaunchFailure
>>> from qemu_test import Asset
>>> from qemu_test import wait_for_console_pattern
>>> @@ -25,8 +27,7 @@ class Aarch64VirtBlobTest(LinuxKernelTest):
>>> 'download?path=%2Fblob-test&files=qemu-880.bin',
>>> '2f6ab85d0b156c94fcedd2c4c821c5cbd52925a2de107f8e2d569ea2e34e42eb')
>>> - def test_virtio_gpu_blob(self):
>>> -
>>> + def launch_blob_test(self):
>>> self.set_machine('virt')
>>> self.require_accelerator("tcg")
>>> @@ -65,9 +66,27 @@ def test_virtio_gpu_blob(self):
>>> self.log.info("unhandled launch failure: %s", excp.output)
>>> raise excp
>>> + 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
>>> + def test_virtio_gpu_blob_shutdown_race(self):
>>> + self.launch_blob_test()
>>> +
>>> + self.wait_for_console_pattern('[INFO] unmapping blob object resource')
>>> +
>>> + try:
>>> + self.vm.shutdown(timeout=10)
>>> + 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 completed: %s",
>>> + excp)
>>> +
>>> if __name__ == '__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-e3e3c7eebc9e@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,
>>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2026-05-19 12:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 14:06 [PATCH v2 0/2] virtio-gpu: Do not wait for the main thread during reset Akihiko Odaki
2026-04-24 14:06 ` [PATCH v2 1/2] virtio-gpu: Run reset cleanup in the same BH Akihiko Odaki
2026-04-27 6:17 ` Philippe Mathieu-Daudé
2026-04-24 14:06 ` [PATCH v2 2/2] virtio-gpu: Do not wait for the main thread during reset Akihiko Odaki
2026-05-18 19:35 ` [PATCH v2 0/2] " Alex Bennée
2026-05-19 6:29 ` Akihiko Odaki
2026-05-19 12:36 ` Alex Bennée [this message]
2026-05-19 12:45 ` Alex Bennée
2026-05-19 14:25 ` Akihiko Odaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h5o3bmp5.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=dmitry.osipenko@collabora.com \
--cc=mst@redhat.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.