All of lore.kernel.org
 help / color / mirror / Atom feed
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 16:29:19 -0400	[thread overview]
Message-ID: <20220228202919.GP219866@nvidia.com> (raw)
In-Reply-To: <20220228131614.27ad37dc.alex.williamson@redhat.com>

On Mon, Feb 28, 2022 at 01:16:14PM -0700, Alex Williamson wrote:
> On Mon, 28 Feb 2022 14:05:20 -0400
> Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Mon, Feb 28, 2022 at 06:01:44PM +0000, Shameerali Kolothum Thodi 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;
> > > +       loff_t *pos = &filp->f_pos;
> > > +       struct vfio_device_mig_precopy precopy;
> > > +       unsigned long minsz;
> > > +
> > > +       if (cmd != VFIO_DEVICE_MIG_PRECOPY)
> > > +               return -EINVAL;  
> > 
> > ENOTTY
> > 
> > > +
> > > +       minsz = offsetofend(struct vfio_device_mig_precopy, dirty_bytes);
> > > +
> > > +       if (copy_from_user(&precopy, (void __user *)arg, minsz))
> > > +               return -EFAULT;
> > > +       if (precopy.argsz < minsz)
> > > +               return -EINVAL;
> > > +
> > > +       mutex_lock(&migf->lock);
> > > +       if (*pos > migf->total_length) {
> > > +               mutex_unlock(&migf->lock);
> > > +               return -EINVAL;
> > > +       }
> > > +
> > > +       precopy.dirty_bytes = 0;
> > > +       precopy.initial_bytes = migf->total_length - *pos;
> > > +       mutex_unlock(&migf->lock);
> > > +       return copy_to_user((void __user *)arg, &precopy, minsz) ? -EFAULT : 0;
> > > +}  
> > 
> > Yes
> > 
> > And I noticed this didn't include the ENOMSG handling, read() should
> > return ENOMSG when it reaches EOS for the pre-copy:
> > 
> > + * During pre-copy the migration data FD has a temporary "end of stream" that is
> > + * reached when both initial_bytes and dirty_byte are zero. For instance, this
> > + * may indicate that the device is idle and not currently dirtying any internal
> > + * state. When read() is done on this temporary end of stream the kernel driver
> > + * should return ENOMSG from read(). Userspace can wait for more data (which may
> > + * never come) by using poll.
> 
> I'm confused by your previous reply that the use of curr_state should
> be eliminated, isn't this ioctl only valid while the device is in the
> PRE_COPY or PRE_COPY_P2P states?  Otherwise the STOP_COPY state would
> have some expectation to be able to use this ioctl for devices
> supporting PRE_COPY.  

I think it is fine to keep working on stop copy, though the
implementation here isn't quite right for that..

if (migf->total_length > QM_MATCH_SIZE)
   precopy.dirty_bytes = migf->total_length - QM_MATCH_SIZE - *pos;
else
   precopy.dity_bytes = 0;

if (*pos < QM_MATCH_SIZE)
    precopy.initial_bytes = QM_MATCH_SIZE - *pos;
else
    precopy.initial_Bytes = 0;

Unless you think we should block it.

> I'd like to see the uapi clarify exactly what states allow this
> ioctl and define the behavior of the ioctl when transitioning out of
> those states with an open data_fd, ie. is it defined to return an
> -errno once in STOP_COPY?  Thanks,

The ioctl is on the data_fd, so it should follow all the normal rules
of the data_fd just like read() - ie all ioctls/read/write fails when
teh state is moved outside one where the data_fd is valid.

That looks like another issue with the above, it doesn't chck
migf->disabled.

Should we add another sentence about this?

Jason

  reply	other threads:[~2022-02-28 20:29 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 [this message]
2022-02-28 21:20             ` Alex Williamson
2022-02-28 23:47               ` Jason Gunthorpe
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=20220228202919.GP219866@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.