From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"Zeng, Xin" <xin.zeng@intel.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"yishaih@nvidia.com" <yishaih@nvidia.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
qat-linux <qat-linux@intel.com>,
"Cao, Yahui" <yahui.cao@intel.com>
Subject: Re: [PATCH v6 1/1] vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devices
Date: Fri, 19 Apr 2024 11:10:57 -0300 [thread overview]
Message-ID: <20240419141057.GG3050601@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52767D5F7FF5D6498C974B388C0D2@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Apr 19, 2024 at 05:23:30AM +0000, Tian, Kevin wrote:
> > From: Alex Williamson <alex.williamson@redhat.com>
> > Sent: Friday, April 19, 2024 6:55 AM
> >
> > On Wed, 17 Apr 2024 22:31:41 +0800
> > Xin Zeng <xin.zeng@intel.com> wrote:
> >
> > > +
> > > + /*
> > > + * As the device is not capable of just stopping P2P DMAs, suspend
> > the
> > > + * device completely once any of the P2P states are reached.
> > > + * On the opposite direction, resume the device after transiting from
> > > + * the P2P state.
> > > + */
> > > + if ((cur == VFIO_DEVICE_STATE_RUNNING && new ==
> > VFIO_DEVICE_STATE_RUNNING_P2P) ||
> > > + (cur == VFIO_DEVICE_STATE_PRE_COPY && new ==
> > VFIO_DEVICE_STATE_PRE_COPY_P2P)) {
> > > + ret = qat_vfmig_suspend(qat_vdev->mdev);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > + return NULL;
> > > + }
> >
> > This doesn't appear to be a valid way to support P2P, the P2P states
> > are defined as running states. The guest driver may legitimately
> > access and modify the device state during P2P states.
>
> yes it's a conceptual violation of the definition of the P2P states.
It depends what suspend actually does.
Like if it halts all queues and keeps them halted, while still
allowing queue head/tail pointer updats then it would be a fine
implementation for P2P.
> > Should this device be advertising support for P2P?
>
> Jason suggests all new migration drivers must support P2P state.
> In an old discussion [1]
I did? I don't think that is what the link says..
We've been saying for a while that devices should try hard to
implement P2P because if they don't then multi VFIO VMM's won't work
and people will be unhappy..
> But obviously we overlooked that by definition RUNNING_P2P is
> a running state so could still see state changed from either CPU
> or other devices.
Yes, incoming MMIO writes that change the state must be recorded, but
as long as DMA does not start and remains suspended then it is OK.
Jason
next prev parent reply other threads:[~2024-04-19 14:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 14:31 [PATCH v6 0/1] vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF device Xin Zeng
2024-04-17 14:31 ` [PATCH v6 1/1] vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devices Xin Zeng
2024-04-18 22:54 ` Alex Williamson
2024-04-19 5:23 ` Tian, Kevin
2024-04-19 14:10 ` Jason Gunthorpe [this message]
2024-04-23 2:44 ` Tian, Kevin
2024-04-24 3:34 ` Zeng, Xin
2024-04-24 14:17 ` Jason Gunthorpe
2024-04-18 1:36 ` [PATCH v6 0/1] vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF device Yi Liu
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=20240419141057.GG3050601@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=herbert@gondor.apana.org.au \
--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=xin.zeng@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).