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
> 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 t
> 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.
> 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 operatio
> 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 back
> 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-
> >virtio_reset_device
> From: Chen, Jiqian
> Sent: Wednesday, September 20, 2023 9:28 AM
> >> For above purpose, we need a mechanism that allows guests and QEMU to
> >> negotiate their reset behavior. So this patch add a new parameter
> >> named
> > Freeze != reset. :)
> > Please fix it to say freeze or suspend.
> B
Hi Jiqian,
> From: Jiqian Chen
> Sent: Tuesday, September 19, 2023 5:13 PM
>
> When guest vm does S3, Qemu will reset and clear some things of virtio
> devices, but guest can't aware that, so that may cause some problems.
It is not true that guest VM is not aware of it.
As you show in your kerne
> From: Jason Wang
> Sent: Wednesday, January 11, 2023 12:51 AM
>
> On Wed, Jan 11, 2023 at 12:40 PM Parav Pandit wrote:
> >
> >
> > > From: Jason Wang
> > > Sent: Tuesday, January 10, 2023 11:35 PM
> > >
> > > On Tue, Jan 10, 20
> From: Jason Wang
> Sent: Tuesday, January 10, 2023 11:35 PM
>
> On Tue, Jan 10, 2023 at 11:02 AM Parav Pandit wrote:
> >
> > Hi Jason,
> >
> > > From: Jason Wang
> > > Sent: Monday, December 5, 2022 10:25 PM
> >
> > >
>
Hi Jason,
> From: Jason Wang
> Sent: Monday, December 5, 2022 10:25 PM
>
> A dumb question, any reason we need bother with virtio-net? It looks to me
> it's
> not a must and would complicate migration compatibility.
Virtio net vdpa device is processing the descriptors out of order.
This vdpa
> From: Eugenio Pérez
> Sent: Monday, December 5, 2022 12:05 PM
>
> There is currently no data to be migrated, since nothing populates or read
> the fields on virtio-net.
>
> The migration of in-flight descriptors is modelled after the migration of
> requests in virtio-blk. With some difference
> From: Eugenio Perez Martin
> Sent: Tuesday, May 17, 2022 4:12 AM
> > 2. Each VQ enablement one at a time, requires constant steering update
> > for the VQ While this information is something already known. Trying to
> reuse brings a callback result in this in-efficiency.
> > So better to star
> From: Jason Wang
> Sent: Monday, May 16, 2022 11:05 PM
> >> Although it's a longer route, I'd very much prefer an in-band virtio
> >> way to perform it rather than a linux/vdpa specific. It's one of the
> >> reasons I prefer the CVQ behavior over a vdpa specific ioctl.
> >>
> > What is the in-b
> From: Eugenio Perez Martin
> Sent: Monday, May 16, 2022 4:51 AM
>
> On Fri, May 13, 2022 at 8:25 PM Parav Pandit wrote:
> >
> > Hi Gautam,
> >
> > Please fix your email client to have right response format.
> > Otherwise, it will be confusing for th
Hi Gautam,
Please fix your email client to have right response format.
Otherwise, it will be confusing for the rest and us to follow the conversation.
More below.
> From: Gautam Dawar
> Sent: Friday, May 13, 2022 1:48 PM
> > Our proposal diverge in step 7: Instead of enabling *all* the
> > vir
> From: Eugenio Perez Martin
> Sent: Wednesday, May 11, 2022 3:44 PM
>
> This is a proposal to restore the state of the vhost-vdpa device at the
> destination after a live migration. It uses as many available features both
> from the device and from qemu as possible so we keep the communication
> From: Jason Wang
> Sent: Wednesday, August 19, 2020 12:19 PM
>
>
> On 2020/8/19 下午1:26, Parav Pandit wrote:
> >
> >> From: Jason Wang
> >> Sent: Wednesday, August 19, 2020 8:16 AM
> >
> >> On 2020/8/18 下午5:32, Parav Pandit wrote:
&g
> From: Yan Zhao
> Sent: Wednesday, August 19, 2020 9:01 AM
> On Tue, Aug 18, 2020 at 09:39:24AM +0000, Parav Pandit wrote:
> > Please refer to my previous email which has more example and details.
> hi Parav,
> the example is based on a new vdpa tool running over
> From: Jason Wang
> Sent: Wednesday, August 19, 2020 8:16 AM
> On 2020/8/18 下午5:32, Parav Pandit wrote:
> > Hi Jason,
> >
> > From: Jason Wang
> > Sent: Tuesday, August 18, 2020 2:32 PM
> >
> >
> > On 2020/8/18 下午4:55, Daniel P. Berrangé
..@lwn.net; openstack-
> disc...@lists.openstack.org; shaohe.f...@intel.com; kevin.t...@intel.com;
> Parav Pandit ; jian-feng.d...@intel.com;
> dgilb...@redhat.com; zhen...@linux.intel.com; hejie...@intel.com;
> bao.yum...@zte.com.cn; Alex Williamson ;
> eskul...@redhat.com
Hi Jason,
From: Jason Wang
Sent: Tuesday, August 18, 2020 2:32 PM
On 2020/8/18 下午4:55, Daniel P. Berrangé wrote:
On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote:
On 2020/8/14 下午1:16, Yan Zhao wrote:
On Thu, Aug 13, 2020 at 12:24:50PM +0800, Jason Wang wrote:
On 2020/8/10 下午3:46, Yan
Hi Jens,
> -Original Message-
> From: Jens Freimann
> Sent: Tuesday, October 29, 2019 6:49 AM
> To: qemu-devel@nongnu.org
> Cc: ehabk...@redhat.com; m...@redhat.com; berra...@redhat.com;
> la...@redhat.com; aa...@redhat.com; ai...@redhat.com; Parav Pandit
>
> -Original Message-
> From: Jens Freimann
> Sent: Thursday, October 24, 2019 4:38 AM
> To: Parav Pandit
> Cc: qemu-devel@nongnu.org; ehabk...@redhat.com; m...@redhat.com;
> berra...@redhat.com; pkre...@redhat.com; la...@redhat.com;
> aa...@redhat.com; ai
> -Original Message-
> From: Jens Freimann
> Sent: Wednesday, October 23, 2019 3:27 AM
> To: qemu-devel@nongnu.org
> Cc: ehabk...@redhat.com; m...@redhat.com; berra...@redhat.com;
> pkre...@redhat.com; la...@redhat.com; aa...@redhat.com;
> ai...@redhat.com; P
26 matches
Mail list logo
