Hi Lingshan,
Please reply to your own email thread, below are not related to my patches. Thanks a lot.
On 2023/9/20 15:47, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 3:35 PM, Parav Pandit wrote:
>>> From: Zhu, Lingshan <[email protected]>
>>> Sent: Wednesday, September 20, 2023 1:00 PM
>>>
>>> On 9/20/2023 3:24 PM, Chen, Jiqian wrote:
>>>> Hi Lingshan,
>>>> It seems you reply to the wrong email thread. They are not related to my
>>> patch.
>>> These reply to Parva's comments.
>>> @Parva, if you want to discuss more about live migration, please reply in my
>>> thread, lets don't flood here.
>> You made the point that "this is not live migration".
>> I am not discussing live migration in this thread.
>>
>> I replied for the point that device restoration from suspend for physical and hypevisor based device is not a 40nsec worth of work to restore by just doing a register write.
>> This is not live or device migration. This is restoring the device context initiated by the driver owning the device.
> restore the device context should be done by the hypervisor before setting DRIVER_OK and waking up the guest, not a concern here, out of spec
>
--
Best regards,
Jiqian Chen.
Hi Jiquian,
> From: Chen, Jiqian <[email protected]>
> 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.
You probably missed my previous response explaining the same at [1].
[1] https://lists.oasis-open.org/archives/virtio-comment/202309/msg00255.html
On 2023/9/20 15:56, Parav Pandit wrote:
> Hi Jiquian,
>
>> From: Chen, Jiqian <[email protected]>
>> 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.