qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: "Zhengxiao.zx@Alibaba-inc.com" <Zhengxiao.zx@Alibaba-inc.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"cjia@nvidia.com" <cjia@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"eskultet@redhat.com" <eskultet@redhat.com>,
	"Yang, Ziye" <ziye.yang@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"shuangtai.tst@alibaba-inc.com" <shuangtai.tst@alibaba-inc.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>,
	"Wang, Zhi A" <zhi.a.wang@intel.com>,
	"mlevitsk@redhat.com" <mlevitsk@redhat.com>,
	"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
	"aik@ozlabs.ru" <aik@ozlabs.ru>,
	"eauger@redhat.com" <eauger@redhat.com>,
	"felipe@nutanix.com" <felipe@nutanix.com>,
	"jonathan.davies@nutanix.com" <jonathan.davies@nutanix.com>,
	Yan Zhao <yan.y.zhao@intel.com>,
	"Liu, Changpeng" <changpeng.liu@intel.com>,
	"Ken.Xue@amd.com" <Ken.Xue@amd.com>
Subject: Re: [PATCH Kernel v18 4/7] vfio iommu: Implementation of ioctl for dirty pages tracking.
Date: Thu, 7 May 2020 12:19:56 -0600	[thread overview]
Message-ID: <20200507121956.45b2500f@x1.home> (raw)
In-Reply-To: <24223faa-15ac-bd71-6c5d-9d0401fbd839@nvidia.com>

On Thu, 7 May 2020 01:12:25 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:

> On 5/6/2020 1:45 PM, Yan Zhao wrote:
> > On Mon, May 04, 2020 at 11:58:56PM +0800, Kirti Wankhede wrote:  
> 
> <snip>
> 
> >>   /*
> >>    * Helper Functions for host iova-pfn list
> >>    */
> >> @@ -567,6 +654,18 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
> >>   			vfio_unpin_page_external(dma, iova, do_accounting);
> >>   			goto pin_unwind;
> >>   		}
> >> +
> >> +		if (iommu->dirty_page_tracking) {
> >> +			unsigned long pgshift =
> >> +					 __ffs(vfio_pgsize_bitmap(iommu));
> >> +  
> > hi Kirti,
> > may I know if there's any vfio_pin_pages() happpening during NVidia's vGPU migration?
> > the code would enter into deadlock as I reported in last version.
> >   
> 
> Hm, you are right and same is the case in vfio_iommu_type1_dma_rw_chunk().
> 
> Instead of calling vfio_pgsize_bitmap() from lots of places, I'm 
> thinking of saving pgsize_bitmap in struct vfio_iommu, which should be 
> populated whenever domain_list is updated. Alex, will that be fine?

I've wondered why we don't already cache this, so yes, that's fine, but
the cached value will only be valid when evaluated under iommu->lock.
Thanks,

Alex



  reply	other threads:[~2020-05-07 18:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-04 15:58 [PATCH Kernel v18 0/7] KABIs to support migration for VFIO devices Kirti Wankhede
2020-05-04 15:58 ` [PATCH Kernel v18 1/7] vfio: UAPI for migration interface for device state Kirti Wankhede
2020-05-04 15:58 ` [PATCH Kernel v18 2/7] vfio iommu: Remove atomicity of ref_count of pinned pages Kirti Wankhede
2020-05-04 15:58 ` [PATCH Kernel v18 3/7] vfio iommu: Add ioctl definition for dirty pages tracking Kirti Wankhede
2020-05-04 15:58 ` [PATCH Kernel v18 4/7] vfio iommu: Implementation of ioctl " Kirti Wankhede
2020-05-06  8:15   ` Yan Zhao
2020-05-06 19:42     ` Kirti Wankhede
2020-05-07 18:19       ` Alex Williamson [this message]
2020-05-06 10:54   ` Cornelia Huck
2020-05-13 20:26     ` Kirti Wankhede
2020-05-04 15:58 ` [PATCH Kernel v18 5/7] vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap Kirti Wankhede
2020-05-06 22:25   ` Alex Williamson
2020-05-12 20:30     ` Kirti Wankhede
2020-05-12 21:21       ` Alex Williamson
2020-05-04 15:58 ` [PATCH Kernel v18 6/7] vfio iommu: Add migration capability to report supported features Kirti Wankhede
2020-05-06 22:27   ` Alex Williamson
2020-05-07  5:37     ` Kirti Wankhede
2020-05-07 15:17       ` Alex Williamson
2020-05-04 15:58 ` [PATCH Kernel v18 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=20200507121956.45b2500f@x1.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).