From: Jason Gunthorpe <jgg@nvidia.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "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>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"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 v7 09/10] hisi_acc_vfio_pci: Add support for VFIO live migration
Date: Thu, 3 Mar 2022 09:04:11 -0400 [thread overview]
Message-ID: <20220303130411.GY219866@nvidia.com> (raw)
In-Reply-To: <19e294814f284755b207be3ba7054ec2@huawei.com>
On Thu, Mar 03, 2022 at 12:57:29PM +0000, Shameerali Kolothum Thodi wrote:
>
>
> > From: Jason Gunthorpe [mailto:jgg@nvidia.com]
> > Sent: 03 March 2022 00:22
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-crypto@vger.kernel.org; linux-pci@vger.kernel.org;
> > alex.williamson@redhat.com; cohuck@redhat.com; mgurtovoy@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 v7 09/10] hisi_acc_vfio_pci: Add support for VFIO live
> > migration
> >
> > On Wed, Mar 02, 2022 at 05:29:02PM +0000, Shameer Kolothum wrote:
> > > +static long hisi_acc_vf_save_unl_ioctl(struct file *filp,
> > > + unsigned int cmd, unsigned long arg)
> > > +{
> > > + struct hisi_acc_vf_migration_file *migf = filp->private_data;
> > > + struct hisi_acc_vf_core_device *hisi_acc_vdev = container_of(migf,
> > > + struct hisi_acc_vf_core_device, saving_migf);
> > > + loff_t *pos = &filp->f_pos;
> > > + struct vfio_precopy_info info;
> > > + unsigned long minsz;
> > > + int ret;
> > > +
> > > + if (cmd != VFIO_MIG_GET_PRECOPY_INFO)
> > > + return -ENOTTY;
> > > +
> > > + minsz = offsetofend(struct vfio_precopy_info, dirty_bytes);
> > > +
> > > + if (copy_from_user(&info, (void __user *)arg, minsz))
> > > + return -EFAULT;
> > > + if (info.argsz < minsz)
> > > + return -EINVAL;
> > > +
> > > + mutex_lock(&hisi_acc_vdev->state_mutex);
> > > + if (hisi_acc_vdev->mig_state != VFIO_DEVICE_STATE_PRE_COPY) {
> > > + mutex_unlock(&hisi_acc_vdev->state_mutex);
> > > + return -EINVAL;
> > > + }
> >
> > IMHO it is easier just to check the total_length and not grab this
> > other lock
>
> The problem with checking the total_length here is that it is possible that
> in STOP_COPY the dev is not ready and there are no more data to be transferred
> and the total_length remains at QM_MATCH_SIZE.
Tthere is a scenario that transfers only QM_MATCH_SIZE in stop_copy?
This doesn't seem like a good idea, I think you should transfer a
positive indication 'this device is not ready' instead of truncating
the stream. A truncated stream should not be a valid stream.
ie always transfer the whole struct.
> Looks like setting the total_length = 0 in STOP_COPY is a better solution(If there are
> no other issues with that) as it will avoid grabbing the state_mutex as you
> mentioned above.
That seems really weird, I wouldn't recommend doing that..
Kaspm
next prev parent reply other threads:[~2022-03-03 13:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 17:28 [PATCH v7 00/10] vfio/hisilicon: add ACC live migration driver Shameer Kolothum
2022-03-02 17:28 ` [PATCH v7 01/10] crypto: hisilicon/qm: Move the QM header to include/linux Shameer Kolothum
2022-03-02 18:48 ` John Garry
2022-03-02 20:39 ` Shameerali Kolothum Thodi
2022-03-02 17:28 ` [PATCH v7 02/10] crypto: hisilicon/qm: Move few definitions to common header Shameer Kolothum
2022-03-02 18:55 ` John Garry
2022-03-02 20:41 ` Shameerali Kolothum Thodi
2022-03-02 17:28 ` [PATCH v7 03/10] hisi_acc_qm: Move VF PCI device IDs " Shameer Kolothum
2022-03-02 17:28 ` [PATCH v7 04/10] hisi_acc_vfio_pci: add new vfio_pci driver for HiSilicon ACC devices Shameer Kolothum
2022-03-02 19:02 ` John Garry
2022-03-02 20:32 ` Shameerali Kolothum Thodi
2022-03-02 17:28 ` [PATCH v7 05/10] hisi_acc_vfio_pci: Restrict access to VF dev BAR2 migration region Shameer Kolothum
2022-03-02 17:28 ` [PATCH v7 06/10] hisi_acc_vfio_pci: Add helper to retrieve the struct pci_driver Shameer Kolothum
2022-03-02 17:29 ` [PATCH v7 07/10] vfio: Extend the device migration protocol with PRE_COPY Shameer Kolothum
2022-03-02 20:31 ` Alex Williamson
2022-03-03 0:05 ` Jason Gunthorpe
2022-03-03 3:47 ` Alex Williamson
2022-03-03 13:01 ` Jason Gunthorpe
2022-03-03 15:20 ` Alex Williamson
2022-03-03 18:05 ` Shameerali Kolothum Thodi
2022-03-03 19:59 ` Alex Williamson
2022-03-03 23:49 ` Jason Gunthorpe
2022-03-04 19:56 ` Alex Williamson
2022-03-02 17:29 ` [PATCH v7 08/10] crypto: hisilicon/qm: Set the VF QM state register Shameer Kolothum
2022-03-02 17:29 ` [PATCH v7 09/10] hisi_acc_vfio_pci: Add support for VFIO live migration Shameer Kolothum
2022-03-03 0:21 ` Jason Gunthorpe
2022-03-03 12:57 ` Shameerali Kolothum Thodi
2022-03-03 13:04 ` Jason Gunthorpe [this message]
2022-03-03 13:17 ` Shameerali Kolothum Thodi
2022-03-03 13:19 ` Jason Gunthorpe
2022-03-03 13:27 ` Shameerali Kolothum Thodi
2022-03-02 17:29 ` [PATCH v7 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=20220303130411.GY219866@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=linux-pci@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.