From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>, <cjia@nvidia.com>,
<kevin.tian@intel.com>, <ziye.yang@intel.com>,
<changpeng.liu@intel.com>, <yi.l.liu@intel.com>,
<mlevitsk@redhat.com>, <eskultet@redhat.com>,
<dgilbert@redhat.com>, <jonathan.davies@nutanix.com>,
<eauger@redhat.com>, <aik@ozlabs.ru>, <pasic@linux.ibm.com>,
<felipe@nutanix.com>, <Zhengxiao.zx@Alibaba-inc.com>,
<shuangtai.tst@alibaba-inc.com>, <Ken.Xue@amd.com>,
<zhi.a.wang@intel.com>, <yan.y.zhao@intel.com>,
<qemu-devel@nongnu.org>, <kvm@vger.kernel.org>
Subject: Re: [PATCH Kernel v20 4/8] vfio iommu: Add ioctl definition for dirty pages tracking
Date: Tue, 19 May 2020 18:00:59 +0200 [thread overview]
Message-ID: <20200519180059.68f2c338.cohuck@redhat.com> (raw)
In-Reply-To: <20200519095356.5d1f6ffa@x1.home>
On Tue, 19 May 2020 09:53:56 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Tue, 19 May 2020 17:35:07 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
>
> > On Fri, 15 May 2020 23:05:24 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> > > On 5/15/2020 4:29 PM, Cornelia Huck wrote:
> > > > On Fri, 15 May 2020 02:07:43 +0530
> > > > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> > > >
> > > >> IOMMU container maintains a list of all pages pinned by vfio_pin_pages API.
> > > >> All pages pinned by vendor driver through this API should be considered as
> > > >> dirty during migration. When container consists of IOMMU capable device and
> > > >> all pages are pinned and mapped, then all pages are marked dirty.
> > > >> Added support to start/stop dirtied pages tracking and to get bitmap of all
> > > >> dirtied pages for requested IO virtual address range.
> > > >>
> > > >> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> > > >> Reviewed-by: Neo Jia <cjia@nvidia.com>
> > > >> ---
> > > >> include/uapi/linux/vfio.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++
> > > >> 1 file changed, 55 insertions(+)
> >
> > (...)
> >
> > > >> + * When IOCTL is called with VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP flag set,
> > > >> + * IOCTL returns dirty pages bitmap for IOMMU container during migration for
> > > >> + * given IOVA range.
> > > >
> > > > "Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_GET_BITMAP returns the
> > > > dirty pages bitmap for the IOMMU container for a given IOVA range." ?
> > > >
> > > > Q: How does this interact with the two other operations? I imagine
> > > > getting an empty bitmap before _START
> > >
> > > No, if dirty page tracking is not started, get_bitmap IOCTL will fail
> > > with -EINVAL.
> > >
> > > > and a bitmap-in-progress between
> > > > _START and _STOP. > After _STOP, will subsequent calls always give the
> > > > same bitmap?
> > > >
> > >
> > > No, return -EINVAL.
> >
> > Maybe add
> >
> > "If the IOCTL has not yet been called with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_START, or if it has been called with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP, calling it with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP will return -EINVAL." ?
>
> Let's not specify ourselves into a corner, I think we can simply say
> that the dirty bitmap is only available while dirty logging is enabled.
> We certainly don't need to specify specific errno values that'll trip
> us up later.
"If dirty logging is not enabled, an error will be returned." ?
(...)
> > > >> Caller must set argsz including size of structure
> > > >> + * vfio_iommu_type1_dirty_bitmap_get.
> > > >
> > > > s/Caller/The caller/
> > > >
> > > > Does argz also include the size of the bitmap?
> > >
> > > No.
> >
> > "The caller must set argsz to a value including the size of stuct
> > vfio_io_type1_dirty_bitmap_get, but excluding the size of the actual
> > bitmap." ?
>
> Yes, it wouldn't make sense for argsz to include the size of the bitmap
> itself, that's accessed independently via a user provided pointer and
> we have a separate size field for that. Thanks,
>
> Alex
Yes, I just wanted to make it as obvious as possible to make it easier
for folks trying to interact with this interface.
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: 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, Zhengxiao.zx@Alibaba-inc.com,
shuangtai.tst@alibaba-inc.com, dgilbert@redhat.com,
zhi.a.wang@intel.com, mlevitsk@redhat.com, pasic@linux.ibm.com,
aik@ozlabs.ru, Kirti Wankhede <kwankhede@nvidia.com>,
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 Kernel v20 4/8] vfio iommu: Add ioctl definition for dirty pages tracking
Date: Tue, 19 May 2020 18:00:59 +0200 [thread overview]
Message-ID: <20200519180059.68f2c338.cohuck@redhat.com> (raw)
In-Reply-To: <20200519095356.5d1f6ffa@x1.home>
On Tue, 19 May 2020 09:53:56 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Tue, 19 May 2020 17:35:07 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
>
> > On Fri, 15 May 2020 23:05:24 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> > > On 5/15/2020 4:29 PM, Cornelia Huck wrote:
> > > > On Fri, 15 May 2020 02:07:43 +0530
> > > > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> > > >
> > > >> IOMMU container maintains a list of all pages pinned by vfio_pin_pages API.
> > > >> All pages pinned by vendor driver through this API should be considered as
> > > >> dirty during migration. When container consists of IOMMU capable device and
> > > >> all pages are pinned and mapped, then all pages are marked dirty.
> > > >> Added support to start/stop dirtied pages tracking and to get bitmap of all
> > > >> dirtied pages for requested IO virtual address range.
> > > >>
> > > >> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> > > >> Reviewed-by: Neo Jia <cjia@nvidia.com>
> > > >> ---
> > > >> include/uapi/linux/vfio.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++
> > > >> 1 file changed, 55 insertions(+)
> >
> > (...)
> >
> > > >> + * When IOCTL is called with VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP flag set,
> > > >> + * IOCTL returns dirty pages bitmap for IOMMU container during migration for
> > > >> + * given IOVA range.
> > > >
> > > > "Calling the IOCTL with VFIO_IOMMU_DIRTY_PAGES_GET_BITMAP returns the
> > > > dirty pages bitmap for the IOMMU container for a given IOVA range." ?
> > > >
> > > > Q: How does this interact with the two other operations? I imagine
> > > > getting an empty bitmap before _START
> > >
> > > No, if dirty page tracking is not started, get_bitmap IOCTL will fail
> > > with -EINVAL.
> > >
> > > > and a bitmap-in-progress between
> > > > _START and _STOP. > After _STOP, will subsequent calls always give the
> > > > same bitmap?
> > > >
> > >
> > > No, return -EINVAL.
> >
> > Maybe add
> >
> > "If the IOCTL has not yet been called with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_START, or if it has been called with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_STOP, calling it with
> > VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP will return -EINVAL." ?
>
> Let's not specify ourselves into a corner, I think we can simply say
> that the dirty bitmap is only available while dirty logging is enabled.
> We certainly don't need to specify specific errno values that'll trip
> us up later.
"If dirty logging is not enabled, an error will be returned." ?
(...)
> > > >> Caller must set argsz including size of structure
> > > >> + * vfio_iommu_type1_dirty_bitmap_get.
> > > >
> > > > s/Caller/The caller/
> > > >
> > > > Does argz also include the size of the bitmap?
> > >
> > > No.
> >
> > "The caller must set argsz to a value including the size of stuct
> > vfio_io_type1_dirty_bitmap_get, but excluding the size of the actual
> > bitmap." ?
>
> Yes, it wouldn't make sense for argsz to include the size of the bitmap
> itself, that's accessed independently via a user provided pointer and
> we have a separate size field for that. Thanks,
>
> Alex
Yes, I just wanted to make it as obvious as possible to make it easier
for folks trying to interact with this interface.
next prev parent reply other threads:[~2020-05-19 16:01 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 20:37 [PATCH Kernel v20 0/8] Add UAPIs to support migration for VFIO devices Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 1/8] vfio: UAPI for migration interface for device state Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 2/8] vfio iommu: Remove atomicity of ref_count of pinned pages Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 3/8] vfio iommu: Cache pgsize_bitmap in struct vfio_iommu Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 4/8] vfio iommu: Add ioctl definition for dirty pages tracking Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-15 10:59 ` Cornelia Huck
2020-05-15 10:59 ` Cornelia Huck
2020-05-15 17:35 ` Kirti Wankhede
2020-05-15 17:35 ` Kirti Wankhede
2020-05-19 15:35 ` Cornelia Huck
2020-05-19 15:35 ` Cornelia Huck
2020-05-19 15:53 ` Alex Williamson
2020-05-19 15:53 ` Alex Williamson
2020-05-19 16:00 ` Cornelia Huck [this message]
2020-05-19 16:00 ` Cornelia Huck
2020-05-14 20:37 ` [PATCH Kernel v20 5/8] vfio iommu: Implementation of ioctl " Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-15 3:27 ` Alex Williamson
2020-05-15 3:27 ` Alex Williamson
2020-05-15 6:14 ` Alex Williamson
2020-05-15 6:14 ` Alex Williamson
2020-05-15 10:05 ` Yan Zhao
2020-05-15 10:05 ` Yan Zhao
2020-05-15 11:14 ` Kirti Wankhede
2020-05-15 11:14 ` Kirti Wankhede
2020-05-15 15:15 ` Alex Williamson
2020-05-15 15:15 ` Alex Williamson
2020-05-15 15:33 ` Kirti Wankhede
2020-05-15 15:33 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 6/8] vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-15 3:27 ` Alex Williamson
2020-05-15 3:27 ` Alex Williamson
2020-05-15 4:16 ` Kirti Wankhede
2020-05-15 4:16 ` Kirti Wankhede
2020-05-15 5:47 ` Alex Williamson
2020-05-15 5:47 ` Alex Williamson
2020-05-15 6:47 ` Kirti Wankhede
2020-05-15 6:47 ` Kirti Wankhede
2020-05-15 13:31 ` Alex Williamson
2020-05-15 13:31 ` Alex Williamson
2020-05-15 15:30 ` Kirti Wankhede
2020-05-15 15:30 ` Kirti Wankhede
2020-05-15 15:48 ` Alex Williamson
2020-05-15 15:48 ` Alex Williamson
2020-05-14 20:37 ` [PATCH Kernel v20 7/8] vfio iommu: Add migration capability to report supported features Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-14 20:37 ` [PATCH Kernel v20 8/8] vfio: Selective dirty page tracking if IOMMU backed device pins pages Kirti Wankhede
2020-05-14 20:37 ` Kirti Wankhede
2020-05-15 3:32 ` [PATCH Kernel v20 0/8] Add UAPIs to support migration for VFIO devices Alex Williamson
2020-05-15 3:32 ` Alex Williamson
2020-05-15 10:14 ` Yan Zhao
2020-05-15 10:14 ` Yan Zhao
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=20200519180059.68f2c338.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=Ken.Xue@amd.com \
--cc=Zhengxiao.zx@Alibaba-inc.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=changpeng.liu@intel.com \
--cc=cjia@nvidia.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 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.