qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO P


From: Chen, Jiqian
Subject: Re: [virtio-comment] RE: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg
Date: Wed, 20 Sep 2023 08:18:27 +0000


On 2023/9/20 15:56, Parav Pandit wrote:
> Hi Jiquian,
> 
>> From: Chen, Jiqian <Jiqian.Chen@amd.com>
>> Sent: Wednesday, September 20, 2023 1:24 PM
>>
>> Hi Lingshan,
>> Please reply to your own email thread, below are not related to my patches.
>> Thanks a lot.
> 
> They are related to your patch.
>  Both the patches have overlapping functionalities.
But Lingshan's patch is not meet my need. It clears the SUSPEND bit during 
reset.

> 
> You probably missed my previous response explaining the same at [1].
> 
> [1] https://lists.oasis-open.org/archives/virtio-comment/202309/msg00255.html
Yes, I didn't receive this response. 
After reading your responses, I think your concerns are below:
> The point is when driver tells to freeze, it is freeze command and not reset.
> So resume() should not invoke device_reset() when FREEZE+RESUME supported.
The modifications in my Qemu and kernel patches, I just set freeze_mode to be 
S3, and then when guest resume I can change the reset behavior according the S3 
mode, see below callstack:
pci_pm_resume
        virtio_pci_restore
                virtio_device_restore
                        virtio_reset_device(set 0 the device status and then 
call virtio_reset to reset device)
                        drv->restore(virtio_gpu_restore)
So, reset will be done during the restore process(resume invoke the reset), and 
I want to affect the reset behavior during the restore process.

> 

-- 
Best regards,
Jiqian Chen.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]