From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"mgurtovoy@nvidia.com" <mgurtovoy@nvidia.com>,
"yishaih@nvidia.com" <yishaih@nvidia.com>,
Linuxarm <linuxarm@huawei.com>,
liulongfang <liulongfang@huawei.com>,
"Zengtao (B)" <prime.zeng@hisilicon.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: [PATCH v6 09/10] hisi_acc_vfio_pci: Add support for VFIO live migration
Date: Mon, 28 Feb 2022 19:47:09 -0400 [thread overview]
Message-ID: <20220228234709.GV219866@nvidia.com> (raw)
In-Reply-To: <20220228142034.024e7be6.alex.williamson@redhat.com>
On Mon, Feb 28, 2022 at 02:20:34PM -0700, Alex Williamson wrote:
> > Unless you think we should block it.
>
> What's the meaning of initial_bytes and dirty_bytes while in
> STOP_COPY?
Same as during pre-copy - both numbers are the bytes remaining to be
read() from the FD in each bucket. They should continue to decline as
read() progresses regardless of what state the data_fd is in.
The only special thing about STOP_COPY is that dirty_bytes should not
increase as the device should not be generating new dirty data.
How about:
* Drivers should attempt to return estimates so that initial_bytes +
* dirty_bytes matches the amount of data an immediate transition to STOP_COPY
* will require to be streamed. While in STOP_COPY the initial_bytes
* and dirty_bytes should continue to be decrease as the data_fd
* progresses streaming out the data.
Remove the 'in the precopy phase' from the first sentance
Adjust the last paragraph as:
+ * returning readable. ENOMSG may not be returned in STOP_COPY. Support
+ * for this ioctl is required when VFIO_MIGRATION_PRE_COPY is set.
Jason
next prev parent reply other threads:[~2022-02-28 23:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-28 9:01 [PATCH v6 00/10] vfio/hisilicon: add ACC live migration driver Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 01/10] crypto: hisilicon/qm: Move the QM header to include/linux Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 02/10] crypto: hisilicon/qm: Move few definitions to common header Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 03/10] hisi_acc_qm: Move PCI device IDs " Shameer Kolothum
2022-02-28 17:33 ` Alex Williamson
2022-02-28 20:12 ` Bjorn Helgaas
2022-02-28 20:23 ` Alex Williamson
2022-02-28 20:55 ` Bjorn Helgaas
2022-02-28 9:01 ` [PATCH v6 04/10] hisi_acc_vfio_pci: add new vfio_pci driver for HiSilicon ACC devices Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 05/10] hisi_acc_vfio_pci: Restrict access to VF dev BAR2 migration region Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 06/10] hisi_acc_vfio_pci: Add helper to retrieve the struct pci_driver Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 07/10] vfio: Extend the device migration protocol with PRE_COPY Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 08/10] crypto: hisilicon/qm: Set the VF QM state register Shameer Kolothum
2022-02-28 9:01 ` [PATCH v6 09/10] hisi_acc_vfio_pci: Add support for VFIO live migration Shameer Kolothum
2022-02-28 14:57 ` Jason Gunthorpe
2022-02-28 18:01 ` Shameerali Kolothum Thodi
2022-02-28 18:05 ` Jason Gunthorpe
2022-02-28 20:16 ` Alex Williamson
2022-02-28 20:29 ` Jason Gunthorpe
2022-02-28 21:20 ` Alex Williamson
2022-02-28 23:47 ` Jason Gunthorpe [this message]
2022-03-01 4:41 ` Alex Williamson
2022-03-01 13:15 ` Jason Gunthorpe
2022-03-01 19:30 ` Alex Williamson
2022-03-01 20:39 ` Jason Gunthorpe
2022-03-01 22:44 ` Alex Williamson
2022-03-02 0:03 ` Jason Gunthorpe
2022-03-02 9:07 ` Shameerali Kolothum Thodi
2022-02-28 9:01 ` [PATCH v6 10/10] hisi_acc_vfio_pci: Use its own PCI reset_done error handler Shameer Kolothum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220228234709.GV219866@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liulongfang@huawei.com \
--cc=mgurtovoy@nvidia.com \
--cc=prime.zeng@hisilicon.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.