Re: [PATCH v6 1/1] content: Add new feature VIRTIO_F_PRESERVE_RESOURCES

["Chen, Jiqian" <Jiqian.Chen@amd.com>]

On 2024/1/15 08:25, Jason Wang wrote:
> On Fri, Jan 12, 2024 at 3:41âPM Chen, Jiqian <Jiqian.Chen@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=uUnOonDczWzqaucsw@mail.gmail.com/T/
> 
> Thanks
> 

Best Regards,
Jiqian Chen.