All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 18 May 2026 20:35:18 +0100	[thread overview]
Message-ID: <87mrxwcxzd.fsf@draig.linaro.org> (raw)
In-Reply-To: <20260424-gpu-v2-0-9fd2fc0dd1bd@rsg.ci.i.u-tokyo.ac.jp> (Akihiko Odaki's message of "Fri, 24 Apr 2026 23:06:40 +0900")

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.


> 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


  parent reply	other threads:[~2026-05-18 19:36 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 ` Alex Bennée [this message]
2026-05-19  6:29   ` [PATCH v2 0/2] " Akihiko Odaki
2026-05-19 12:36     ` Alex Bennée
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=87mrxwcxzd.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.