Hi Dmitry, > -----Original Message----- > From: Dmitry Osipenko <[email protected]> > Sent: Friday, November 21, 2025 1:04 PM > To: Kim, Dongwon <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [PATCH v6 3/3] drm/virtio: Add PM notifier to restore objects > after > hibernation > > On 11/21/25 21:12, Dmitry Osipenko wrote: > > Hi, > > > > On 11/20/25 04:41, Kim, Dongwon wrote: > >> Hi Dmitry, > >> > >>> -----Original Message----- > >>> From: Dmitry Osipenko <[email protected]> > >>> Sent: Friday, November 14, 2025 5:16 AM > >>> To: Kim, Dongwon <[email protected]>; dri- > >>> [email protected] > >>> Cc: [email protected]; [email protected]; [email protected] > >>> Subject: Re: [PATCH v6 3/3] drm/virtio: Add PM notifier to restore > >>> objects after hibernation > >>> > >>> On 11/13/25 23:47, Kim, Dongwon wrote: > >>>>> One option could be to explicitly destroy all stored objs upon > >>>>> hibernation, that way the restoring will always work. > >>>> Yes, we can do it to avoid that corner case. Or maybe we can just > >>>> let it just > >>> run. > >>>> In this case, virtio_gpu_object_restore_all won't fail as shmem > >>>> init will still work but QEMU will justsend back errored replies as > >>>> all of those resources for BOs are still there in QEMU side but I > >>>> think it won't break anything. Do you see any issues in doing this > >>>> that I might be missing?? My assumption here is that the QEMU > >>>> hasn't done any of > >>> virtio-gpu resets here as hibernation failed. > >>> > >>> Correct, QEMU will emit a ton of "resource already exists" errors on > >>> aborted hibernation. There should be no errors neither from guest, nor > from host. > >>> Note that QEMU is not the only VMM using VirtIO-GPU. > >>> > >>> Two options here: > >>> > >>> 1. Destroy stored host resources upon hibernation 2. Extend > >>> hibernation core [1] with addition of PM_HIBERNATION_UNPREPARE event > >>> that will be invoked when hibernation fails, while > >>> PM_POST_HIBERNATION will be invoked only after a successful > >>> hibernation > >>> > >>> You may start with implementing the first option right away and > >>> later implement the second. > >> > >> I am testing the first method - send unref message to QEMU so that > >> connected resources can be all removed from QEMU. But I found out > >> there is cb that clean up the object once this unref is processed and > >> response is received. It means that we can't just remove the > >> resource/bo only in QEMU side. There is a way to do this though. We > >> can simply add one more fuction in virtgpu_vq.c that handles unref but with > cb = NULL. Is this what you want to try or do you have any better ideas? > > The cb certainly shall not be invoked. You only need to send the > > "DETACH" cmd to host. This should be akin to what I did in my older > > patches adding memory shmem shrinker support to virtio-gpu, please see > > [1] for inspiration. > > > > [1] > > https://lore.kernel.org/dri-devel/20231029230205.93277-26-dmitry.osipe > > [email protected]/ > > Actually, in your case it will be the "UNREF" cmd, not "DETACH". But the idea > in the same, you need to destroy resource only on host on suspend.
Yes, this is the point. Current unref command always comes with a callback that cleans up virtio-gpu bo on the guest side. One way to avoid is to introduce another special version of unref that doesn't register any callback or.. I am wondering if we just make virtio-gpu driver ignores that callback in this specific situation (pre hibernation??). Either way looks like a dirty hack to me though. What do you think? > > -- > Best regards, > Dmitry
