From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: Zhengxiao.zx@Alibaba-inc.com, kevin.tian@intel.com,
yi.l.liu@intel.com, cjia@nvidia.com, kvm@vger.kernel.org,
eskultet@redhat.com, ziye.yang@intel.com, qemu-devel@nongnu.org,
cohuck@redhat.com, shuangtai.tst@alibaba-inc.com,
dgilbert@redhat.com, zhi.a.wang@intel.com, mlevitsk@redhat.com,
pasic@linux.ibm.com, aik@ozlabs.ru, eauger@redhat.com,
felipe@nutanix.com, jonathan.davies@nutanix.com,
yan.y.zhao@intel.com, changpeng.liu@intel.com, Ken.Xue@amd.com
Subject: Re: [PATCH v17 Kernel 6/7] vfio iommu: Adds flag to indicate dirty pages tracking capability support
Date: Tue, 31 Mar 2020 13:15:39 -0600 [thread overview]
Message-ID: <20200331131539.390259e1@w520.home> (raw)
In-Reply-To: <6c6e6625-6dfd-d885-23fe-511744816d5b@nvidia.com>
On Wed, 1 Apr 2020 00:38:49 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 3/31/2020 2:28 AM, Alex Williamson wrote:
> > On Mon, 30 Mar 2020 22:20:43 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> >> Flag VFIO_IOMMU_INFO_DIRTY_PGS in VFIO_IOMMU_GET_INFO indicates that driver
> >> support dirty pages tracking.
> >>
> >> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> >> Reviewed-by: Neo Jia <cjia@nvidia.com>
> >> ---
> >> drivers/vfio/vfio_iommu_type1.c | 3 ++-
> >> include/uapi/linux/vfio.h | 5 +++--
> >> 2 files changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> >> index 266550bd7307..9fe12b425976 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -2390,7 +2390,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
> >> info.cap_offset = 0; /* output, no-recopy necessary */
> >> }
> >>
> >> - info.flags = VFIO_IOMMU_INFO_PGSIZES;
> >> + info.flags = VFIO_IOMMU_INFO_PGSIZES |
> >> + VFIO_IOMMU_INFO_DIRTY_PGS;
> >>
> >> info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
> >>
> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> >> index e3cbf8b78623..0fe7c9a6f211 100644
> >> --- a/include/uapi/linux/vfio.h
> >> +++ b/include/uapi/linux/vfio.h
> >> @@ -985,8 +985,9 @@ struct vfio_device_feature {
> >> struct vfio_iommu_type1_info {
> >> __u32 argsz;
> >> __u32 flags;
> >> -#define VFIO_IOMMU_INFO_PGSIZES (1 << 0) /* supported page sizes info */
> >> -#define VFIO_IOMMU_INFO_CAPS (1 << 1) /* Info supports caps */
> >> +#define VFIO_IOMMU_INFO_PGSIZES (1 << 0) /* supported page sizes info */
> >> +#define VFIO_IOMMU_INFO_CAPS (1 << 1) /* Info supports caps */
> >> +#define VFIO_IOMMU_INFO_DIRTY_PGS (1 << 2) /* supports dirty page tracking */
> >> __u64 iova_pgsizes; /* Bitmap of supported page sizes */
> >> __u32 cap_offset; /* Offset within info struct of first cap */
> >> };
> >
> >
> > As I just mentioned in my reply to Yan, I'm wondering if
> > VFIO_CHECK_EXTENSION would be a better way to expose this. The
> > difference is relatively trivial, but currently the only flag
> > set by VFIO_IOMMU_GET_INFO is to indicate the presence of a field in
> > the returned structure. I think this is largely true of other INFO
> > ioctls within vfio as well and we're already using the
> > VFIO_CHECK_EXTENSION ioctl to check supported IOMMU models, and IOMMU
> > cache coherency. We'd simply need to define a VFIO_DIRTY_PGS_IOMMU
> > value (9) and return 1 for that case. Then when we enable support for
> > dirt pages that can span multiple mappings, we can add a v2 extensions,
> > or "MULTI" variant of this extension, since it should be backwards
> > compatible.
> >
> > The v2/multi version will again require that the user provide a zero'd
> > bitmap, but I don't think that should be a problem as part of the
> > definition of that version (we won't know if the user is using v1 or
> > v2, but a v1 user should only retrieve bitmaps that exactly match
> > existing mappings, where all bits will be written). Thanks,
> >
> > Alex
> >
>
> I look at these two ioctls as : VFIO_CHECK_EXTENSION is used to get
> IOMMU type, while VFIO_IOMMU_GET_INFO is used to get properties of a
> particular IOMMU type, right?
Not exclusively, see for example VFIO_DMA_CC_IOMMU,
> Then I think VFIO_IOMMU_INFO_DIRTY_PGS should be part of
> VFIO_IOMMU_GET_INFO and when we add code for v2/multi, a flag should be
> added to VFIO_IOMMU_GET_INFO.
Which burns through flags, which is a far more limited resource than
our 32bit extension address space, especially when we're already
planning for one or more extensions to this support. Thanks,
Alex
next prev parent reply other threads:[~2020-03-31 19:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 16:50 [PATCH v17 Kernel 0/7] KABIs to support migration for VFIO devices Kirti Wankhede
2020-03-30 16:50 ` [PATCH v17 Kernel 1/7] vfio: UAPI for migration interface for device state Kirti Wankhede
2020-03-30 16:50 ` [PATCH v17 Kernel 2/7] vfio iommu: Remove atomicity of ref_count of pinned pages Kirti Wankhede
2020-03-30 16:50 ` [PATCH v17 Kernel 3/7] vfio iommu: Add ioctl definition for dirty pages tracking Kirti Wankhede
2020-03-30 16:50 ` [PATCH v17 Kernel 4/7] vfio iommu: Implementation of ioctl " Kirti Wankhede
2020-03-30 21:19 ` Alex Williamson
2020-03-31 0:10 ` Yan Zhao
2020-04-08 1:10 ` Yan Zhao
2020-03-30 16:50 ` [PATCH v17 Kernel 5/7] vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap Kirti Wankhede
2020-03-30 21:34 ` Alex Williamson
2020-03-31 18:46 ` Kirti Wankhede
2020-03-31 19:06 ` Alex Williamson
2020-03-30 16:50 ` [PATCH v17 Kernel 6/7] vfio iommu: Adds flag to indicate dirty pages tracking capability support Kirti Wankhede
2020-03-30 20:58 ` Alex Williamson
2020-03-31 19:08 ` Kirti Wankhede
2020-03-31 19:15 ` Alex Williamson [this message]
2020-04-01 17:25 ` Kirti Wankhede
2020-04-01 17:51 ` Alex Williamson
2020-04-01 17:56 ` Alex Williamson
2020-03-30 16:50 ` [PATCH v17 Kernel 7/7] vfio: Selective dirty page tracking if IOMMU backed device pins pages Kirti Wankhede
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=20200331131539.390259e1@w520.home \
--to=alex.williamson@redhat.com \
--cc=Ken.Xue@amd.com \
--cc=Zhengxiao.zx@Alibaba-inc.com \
--cc=aik@ozlabs.ru \
--cc=changpeng.liu@intel.com \
--cc=cjia@nvidia.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eauger@redhat.com \
--cc=eskultet@redhat.com \
--cc=felipe@nutanix.com \
--cc=jonathan.davies@nutanix.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=mlevitsk@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=shuangtai.tst@alibaba-inc.com \
--cc=yan.y.zhao@intel.com \
--cc=yi.l.liu@intel.com \
--cc=zhi.a.wang@intel.com \
--cc=ziye.yang@intel.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).