kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zeng, Xin" <xin.zeng@intel.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qat-linux <qat-linux@intel.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"jgg@nvidia.com" <jgg@nvidia.com>,
	"yishaih@nvidia.com" <yishaih@nvidia.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Cao, Yahui" <yahui.cao@intel.com>
Subject: RE: [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QAT VF devices
Date: Tue, 13 Feb 2024 13:08:47 +0000	[thread overview]
Message-ID: <DM4PR11MB55025C3ECE1896D9C5CA4E86884F2@DM4PR11MB5502.namprd11.prod.outlook.com> (raw)
In-Reply-To: <972cc8a41a8549d19ed897ee7335f9e0@huawei.com>

Thanks for the comments, Shameer.

> -----Original Message-----
> From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Sent: Thursday, February 8, 2024 8:17 PM
> To: Zeng, Xin <xin.zeng@intel.com>; herbert@gondor.apana.org.au;
> alex.williamson@redhat.com; jgg@nvidia.com; yishaih@nvidia.com; Tian, Kevin
> <kevin.tian@intel.com>
> Cc: linux-crypto@vger.kernel.org; kvm@vger.kernel.org; qat-linux <qat-
> linux@intel.com>; Cao, Yahui <yahui.cao@intel.com>
> Subject: RE: [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QAT VF devices
> 
> 
> > +static struct qat_vf_migration_file *
> > +qat_vf_save_device_data(struct qat_vf_core_device *qat_vdev)
> > +{
> > +	struct qat_vf_migration_file *migf;
> > +	int ret;
> > +
> > +	migf = kzalloc(sizeof(*migf), GFP_KERNEL);
> > +	if (!migf)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	migf->filp = anon_inode_getfile("qat_vf_mig", &qat_vf_save_fops,
> > migf, O_RDONLY);
> > +	ret = PTR_ERR_OR_ZERO(migf->filp);
> > +	if (ret) {
> > +		kfree(migf);
> > +		return ERR_PTR(ret);
> > +	}
> > +
> > +	stream_open(migf->filp->f_inode, migf->filp);
> > +	mutex_init(&migf->lock);
> > +
> > +	ret = qat_vdev->mdev->ops->save_state(qat_vdev->mdev);
> > +	if (ret) {
> > +		fput(migf->filp);
> > +		kfree(migf);
> 
> Probably don't need that kfree(migf) here as fput() -->  qat_vf_release_file () will
> do that.

Thanks, it's redundant, will update it in next version.

> 
> > +static int qat_vf_pci_get_data_size(struct vfio_device *vdev,
> > +				    unsigned long *stop_copy_length)
> > +{
> > +	struct qat_vf_core_device *qat_vdev = container_of(vdev,
> > +			struct qat_vf_core_device, core_device.vdev);
> > +
> > +	*stop_copy_length = qat_vdev->mdev->state_size;
> 
> Do we need a lock here or this is not changing?

Yes, will update it in next version.

> 
> > +	return 0;
> > +}
> > +
> > +static const struct vfio_migration_ops qat_vf_pci_mig_ops = {
> > +	.migration_set_state = qat_vf_pci_set_device_state,
> > +	.migration_get_state = qat_vf_pci_get_device_state,
> > +	.migration_get_data_size = qat_vf_pci_get_data_size,
> > +};
> > +
> > +static void qat_vf_pci_release_dev(struct vfio_device *core_vdev)
> > +{
> > +	struct qat_vf_core_device *qat_vdev = container_of(core_vdev,
> > +			struct qat_vf_core_device, core_device.vdev);
> > +
> > +	qat_vdev->mdev->ops->cleanup(qat_vdev->mdev);
> > +	qat_vfmig_destroy(qat_vdev->mdev);
> > +	mutex_destroy(&qat_vdev->state_mutex);
> > +	vfio_pci_core_release_dev(core_vdev);
> > +}
> > +
> > +static int qat_vf_pci_init_dev(struct vfio_device *core_vdev)
> > +{
> > +	struct qat_vf_core_device *qat_vdev = container_of(core_vdev,
> > +			struct qat_vf_core_device, core_device.vdev);
> > +	struct qat_migdev_ops *ops;
> > +	struct qat_mig_dev *mdev;
> > +	struct pci_dev *parent;
> > +	int ret, vf_id;
> > +
> > +	core_vdev->migration_flags = VFIO_MIGRATION_STOP_COPY |
> > VFIO_MIGRATION_P2P;
> > +	core_vdev->mig_ops = &qat_vf_pci_mig_ops;
> > +
> > +	ret = vfio_pci_core_init_dev(core_vdev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	mutex_init(&qat_vdev->state_mutex);
> > +	spin_lock_init(&qat_vdev->reset_lock);
> > +
> > +	parent = qat_vdev->core_device.pdev->physfn;
> 
> Can we use pci_physfn() here?

Sure, will update it in next version.

> 
> > +	vf_id = pci_iov_vf_id(qat_vdev->core_device.pdev);
> > +	if (!parent || vf_id < 0) {
> 
> Also if the pci_iov_vf_id() return success I don't think you need to
> check for parent and can use directly below.

OK, will update it in next version.

> 
> > +		ret = -ENODEV;
> > +		goto err_rel;
> > +	}
> > +
> > +	mdev = qat_vfmig_create(parent, vf_id);
> > +	if (IS_ERR(mdev)) {
> > +		ret = PTR_ERR(mdev);
> > +		goto err_rel;
> > +	}
> > +
> > +	ops = mdev->ops;
> > +	if (!ops || !ops->init || !ops->cleanup ||
> > +	    !ops->open || !ops->close ||
> > +	    !ops->save_state || !ops->load_state ||
> > +	    !ops->suspend || !ops->resume) {
> > +		ret = -EIO;
> > +		dev_err(&parent->dev, "Incomplete device migration ops
> > structure!");
> > +		goto err_destroy;
> > +	}
> 
> If all these ops are a must why cant we move the check inside the
> qat_vfmig_create()?
> Or rather call them explicitly as suggested by Jason.

We can do it, but it might make sense to leave the check to the APIs' user
as some of these ops interfaces might be optional for other QAT variant driver
in future.

Thanks,
Xin


  reply	other threads:[~2024-02-13 13:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-01 15:33 [PATCH 00/10] crypto: qat - enable SRIOV VF live migration for Xin Zeng
2024-02-01 15:33 ` [PATCH 01/10] crypto: qat - adf_get_etr_base() helper Xin Zeng
2024-02-01 15:33 ` [PATCH 02/10] crypto: qat - relocate and rename 4xxx PF2VM definitions Xin Zeng
2024-02-01 15:33 ` [PATCH 03/10] crypto: qat - move PFVF compat checker to a function Xin Zeng
2024-02-01 15:33 ` [PATCH 04/10] crypto: qat - relocate CSR access code Xin Zeng
2024-02-01 15:33 ` [PATCH 05/10] crypto: qat - rename get_sla_arr_of_type() Xin Zeng
2024-02-01 15:33 ` [PATCH 06/10] crypto: qat - expand CSR operations for QAT GEN4 devices Xin Zeng
2024-02-01 15:33 ` [PATCH 07/10] crypto: qat - add bank save and restore flows Xin Zeng
2024-02-04  7:49   ` [EXTERNAL] " Kamlesh Gurudasani
2024-02-19  3:41     ` Wan, Siming
2024-02-01 15:33 ` [PATCH 08/10] crypto: qat - add interface for live migration Xin Zeng
2024-02-01 15:33 ` [PATCH 09/10] crypto: qat - implement " Xin Zeng
2024-02-01 15:33 ` [PATCH 10/10] vfio/qat: Add vfio_pci driver for Intel QAT VF devices Xin Zeng
2024-02-06 12:55   ` Jason Gunthorpe
2024-02-09  8:23     ` Zeng, Xin
2024-02-09 12:10       ` Jason Gunthorpe
2024-02-11  8:17         ` Yishai Hadas
2024-02-17 16:20           ` Zeng, Xin
2024-02-20 13:24             ` Jason Gunthorpe
2024-02-20 15:53               ` Zeng, Xin
2024-02-20 17:03                 ` Jason Gunthorpe
2024-02-21  8:44                   ` Zeng, Xin
2024-02-21 13:18                     ` Jason Gunthorpe
2024-02-21 15:11                       ` Yishai Hadas
2024-02-22  9:39                         ` Yishai Hadas
2024-02-06 21:14   ` Alex Williamson
2024-02-09 16:16     ` Zeng, Xin
2024-02-08 12:17   ` Shameerali Kolothum Thodi
2024-02-13 13:08     ` Zeng, Xin [this message]
2024-02-13 14:55       ` Jason Gunthorpe

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=DM4PR11MB55025C3ECE1896D9C5CA4E86884F2@DM4PR11MB5502.namprd11.prod.outlook.com \
    --to=xin.zeng@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=qat-linux@intel.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=yahui.cao@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).