On 2024/1/15 08:25, Jason Wang wrote: > On Fri, Jan 12, 2024 at 3:41 PM Chen, Jiqian <jiqian.c...@amd.com> wrote: >> >> Hi all, >> Sorry to reply late. >> I don't know if you still remember this problem, let me briefly descript it. >> I am working to implement virtgpu S3 function on Xen. >> Currently on Xen, if we start a guest through qemu with enabling virtgpu, >> and then suspend and resume guest. We can find that the guest kernel comes >> back, but the display doesn't. It just shown a black screen. >> That is because during suspending, guest called into qemu and qemu destroyed >> all display resources and reset renderer. This made the display gone after >> guest resumed. >> So, I add a new command for virtio-gpu that when guest is suspending, it >> will notify qemu and set parameter(preserver_resource) to 1 and then qemu >> will preserve resources, and when resuming, guest will notify qemu to set >> parameter to 0, and then qemu will keep the normal actions. That can help >> guest's display come back. >> When I upstream above implementation, Parav and MST suggest me to use the PM >> capability to fix this problem instead of adding a new command or state bit. >> Now, I have tried the PM capability of virtio-gpu, it can't be used to solve >> this problem. >> The reason is: >> during guest suspending, it will write D3 state through PM cap, then I can >> save the resources of virtio-gpu on Qemu side(set preserver_resource to 1), >> but during the process of resuming, the state of PM cap will be cleared by >> qemu resetting(qemu_system_wakeup-> qemu_devices_reset-> >> virtio_vga_base_reset-> virtio_gpu_gl_reset), >> it causes that when guest reads state from PM cap, it will find the >> virtio-gpu has already been D0 state, so guest will not write D0 through PM >> cap, so I can't know when to restore the resources(set preserver_resource to >> 0). > > Looks like a bug to be fixed? Do you think the devices_reset behavior of qemu shouldn't happen? Or just the state of PM cap shouldn't be cleared?
> >> Do you have any other suggestions? >> Or can I just fallback to the version that add a new >> command(VIRTIO_GPU_CMD_PRESERVE_RESOURCE) in virtio-gpu? I think that way is >> more reasonable and feasible for virtio-gpu to protect display resources >> during S3. As for other devices, if necessary, they can also refer to the >> implementation of the virtio-gpu to add new commands to prevent resource >> loss during S3. > > Note that there's recently a fix for no_soft_reset, a well behaved > device should not suffer from this issue anymore. If I understand this > correctly, there's no need for any extension for the spec as well.: But in current qemu codes, the bit PCI_PM_CTRL_NO_SOFT_RESET of virtio-pci devices isn't set, is it a bug? Even with the fix you mentioned, the resetting can still happen because of no_soft_reset==0. > > https://lore.kernel.org/lkml/CACGkMEs_MajTFxGVcK5R8oqQzTxuL4Pm=uunoondczwzqau...@mail.gmail.com/T/ > > Thanks > Best Regards, Jiqian Chen.
