Thank you for the suggestions. On 19/05/2026 09:11, Dmitry Osipenko wrote: > On 5/18/26 09:45, Ryosuke Yasuoka wrote: >>> It may be acceptable to have wait_event_timeout() in a loop, printing >>> warnings about unresponsive host. >> I considered this approach, but it does not solve the recovery problem >> described above. The guest would still be stuck in the loop with no way >> to remove the device or shut down gracefully. > > Could `system_state != SYSTEM_RUNNING` be checked in the wait loop? This > may allow to handle system shutdown, aborting the timed out wait in the > special case.
Instead of checking system_state directly, I'm planning to add a driver flag (e.g. vqs_released) to struct virtio_gpu_device. The shutdown path (virtio_gpu_shutdown) will set this flag and wake up the wait queues before calling drm_dev_unplug(). The wait loop checks the flag and aborts if set. This may cover both the shutdown and the unbind cases with a sinble check, so I believe a separate system_state check is not needed. If my plan turns out to have issues, I will use system_state check. > Userspace may also get stuck in a zombie state. For that, code should > use wait_event_interruptible(). But driver has code unprepared to be > interrupted, it all needs to be reworked first [1]. Agreed. I will leave wait_event_interruptible() for follow-up once the interruptible is prepared. For now, userspace stuck in D state remains a pre-exsiting limitation. > Similarly, for unbind there could a driver flag that the wait loop will > check and handle specially. Yes, the driver flag described above will handle this as well. Best regards, Ryosuke > WDYT? > > [1] > https://lore.kernel.org/dri-devel/[email protected]/
