On 2023/9/20 15:56, Parav Pandit wrote:
> Hi Jiquian,
>
>> From: Chen, Jiqian
>> 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
Hi Jiquian,
> From: Chen, Jiqian
> 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
On 9/20/2023 3:51 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 1:17 PM
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
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
>>> Sent: Wednesday, September 20, 2023 1:00 PM
>>>
>>> On 9/20/2023 3:24 PM,
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 1:17 PM
> > 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
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 1:16 PM
[..]
> > In my view, setting the DRIVER_OK is the signal regardless of hypervisor or
> physical device.
> > Hence the re-read is must.
> Yes, as I said below, should verify by re-read.
> >
Thanks.
On 9/20/2023 3:35 PM, Parav Pandit wrote:
From: Zhu, Lingshan
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
On 9/20/2023 3:32 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:58 PM
On 9/20/2023 3:10 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:37 PM
The problem to overcome in [1] is, resume operation needs to be
On 9/20/2023 3:17 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 14:58, Zhu, Lingshan wrote:
On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 13:59, Zhu, Lingshan wrote:
On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800,
> From: Zhu, Lingshan
> 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
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 12:58 PM
>
> On 9/20/2023 3:10 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan
> >> Sent: Wednesday, September 20, 2023 12:37 PM
> >>> The problem to overcome in [1] is, resume operation needs to be
> >>> synchronous
> >> as it
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.
On 2023/9/20
On 9/20/2023 3:10 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:37 PM
The problem to overcome in [1] is, resume operation needs to be synchronous
as it involves large part of context to resume back, and hence just
asynchronously setting DRIVER_OK is not
Hi Lingshan,
It seems you reply to the wrong email thread. They are not related to my patch.
On 2023/9/20 15:06, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 2:58 PM, Parav Pandit wrote:
>>> From: Chen, Jiqian
>>> Sent: Wednesday, September 20, 2023 12:03 PM
>>> If driver write 0 to reset device,
Hi Lingshan,
On 2023/9/20 14:58, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
>> Hi Lingshan,
>>
>> On 2023/9/20 13:59, Zhu, Lingshan wrote:
>>>
>>> On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
>
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 12:37 PM
> > The problem to overcome in [1] is, resume operation needs to be synchronous
> as it involves large part of context to resume back, and hence just
> asynchronously setting DRIVER_OK is not enough.
> > The sw must verify
On 9/20/2023 2:58 PM, Parav Pandit wrote:
From: Chen, Jiqian
Sent: Wednesday, September 20, 2023 12:03 PM
If driver write 0 to reset device, can the SUSPEND bit be cleared?
It must as reset operation, resets everything else and so the suspend too.
On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 13:59, Zhu, Lingshan wrote:
On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
When guest vm does S3, Qemu will reset and clear some things of virtio
devices, but
> From: Chen, Jiqian
> Sent: Wednesday, September 20, 2023 12:03 PM
> If driver write 0 to reset device, can the SUSPEND bit be cleared?
It must as reset operation, resets everything else and so the suspend too.
> (pci_pm_resume->virtio_pci_restore->virtio_device_restore-
>
Hi Lingshan,
On 2023/9/20 13:59, Zhu, Lingshan wrote:
>
>
> On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
>> On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
>>> When guest vm does S3, Qemu will reset and clear some things of virtio
>>> devices, but guest can't aware that, so that
20 matches
Mail list logo
