All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirti Wankhede <kwankhede@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Jike Song <jike.song@intel.com>, <pbonzini@redhat.com>,
	<kraxel@redhat.com>, <cjia@nvidia.com>, <qemu-devel@nongnu.org>,
	<kvm@vger.kernel.org>, <kevin.tian@intel.com>,
	<bjsdjshi@linux.vnet.ibm.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP
Date: Sat, 29 Oct 2016 16:07:05 +0530	[thread overview]
Message-ID: <9cfebf8f-7c30-6d2c-a1ec-cc9c9ee1bdd7@nvidia.com> (raw)
In-Reply-To: <20161028143350.45df29c1@t450s.home>



On 10/29/2016 2:03 AM, Alex Williamson wrote:
> On Sat, 29 Oct 2016 01:32:35 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> 
>> On 10/28/2016 6:10 PM, Alex Williamson wrote:
>>> On Fri, 28 Oct 2016 15:33:58 +0800
>>> Jike Song <jike.song@intel.com> wrote:
>>>   
...
>>>>>  
>>>>> +/*
>>>>> + * This function finds pfn in domain->external_addr_space->pfn_list for given
>>>>> + * iova range. If pfn exist, notify pfn to registered notifier list. On
>>>>> + * receiving notifier callback, vendor driver should invalidate the mapping and
>>>>> + * call vfio_unpin_pages() to unpin this pfn. With that vfio_pfn for this pfn
>>>>> + * gets removed from rb tree of pfn_list. That re-arranges rb tree, so while
>>>>> + * searching for next vfio_pfn in rb tree, start search from first node again.
>>>>> + * If any vendor driver doesn't unpin that pfn, vfio_pfn would not get removed
>>>>> + * from rb tree and so in next search vfio_pfn would be same as previous
>>>>> + * vfio_pfn. In that case, exit from loop.
>>>>> + */
>>>>> +static void vfio_notifier_call_chain(struct vfio_iommu *iommu,
>>>>> +				     struct vfio_iommu_type1_dma_unmap *unmap)
>>>>> +{
>>>>> +	struct vfio_domain *domain = iommu->external_domain;
>>>>> +	struct rb_node *n;
>>>>> +	struct vfio_pfn *vpfn = NULL, *prev_vpfn;
>>>>> +
>>>>> +	do {
>>>>> +		prev_vpfn = vpfn;
>>>>> +		mutex_lock(&domain->external_addr_space->pfn_list_lock);
>>>>> +
>>>>> +		n = rb_first(&domain->external_addr_space->pfn_list);
>>>>> +
>>>>> +		for (; n; n = rb_next(n), vpfn = NULL) {
>>>>> +			vpfn = rb_entry(n, struct vfio_pfn, node);
>>>>> +
>>>>> +			if ((vpfn->iova >= unmap->iova) &&
>>>>> +			    (vpfn->iova < unmap->iova + unmap->size))
>>>>> +				break;
>>>>> +		}
>>>>> +
>>>>> +		mutex_unlock(&domain->external_addr_space->pfn_list_lock);
>>>>> +
>>>>> +		/* Notify any listeners about DMA_UNMAP */
>>>>> +		if (vpfn)
>>>>> +			blocking_notifier_call_chain(&iommu->notifier,
>>>>> +						    VFIO_IOMMU_NOTIFY_DMA_UNMAP,
>>>>> +						    &vpfn->pfn);    
>>>>
>>>> Hi Kirti, 
>>>>
>>>> The information carried by notifier is only a pfn.
>>>>
>>>> Since your pin/unpin interfaces design, it's the vendor driver who should
>>>> guarantee pin/unpin same times. To achieve that, the vendor driver must
>>>> cache it's iova->pfn mapping on its side, to avoid pinning a same page
>>>> for multiple times.
>>>>
>>>> With the notifier carrying only a pfn, to find the iova by this pfn,
>>>> the vendor driver must *also* keep a reverse-mapping. That's a bit
>>>> too much.
>>>>
>>>> Since the vendor could also suffer from IOMMU-compatible problem,
>>>> which means a local cache is always helpful, so I'd like to have the
>>>> iova carried to the notifier.
>>>>
>>>> What'd you say?  
>>>
>>> I agree, the pfn is not unique, multiple guest pfns (iovas) might be
>>> backed by the same host pfn.  DMA_UNMAP calls are based on iova, the
>>> notifier through to the vendor driver must be based on the same.  
>>
>> Host pfn should be unique, right?
> 
> Let's say a user does a malloc of a single page and does 100 calls to
> MAP_DMA populating 100 pages of IOVA space all backed by the same
> malloc'd page.  This is valid, I have unit tests that do essentially
> this.  Those will all have the same pfn.  The user then does an
> UNMAP_DMA to a single one of those IOVA pages.  Did the user unmap
> everything matching that pfn?  Of course not, they only unmapped that
> one IOVA page.  There is no guarantee of a 1:1 mapping of pfn to IOVA.
> UNMAP_DMA works based on IOVA.  Invalidation broadcasts to the vendor
> driver MUST therefore also work based on IOVA.  This is not an academic
> problem, address space aliases exist in real VMs, imagine a virtual
> IOMMU.  Thanks,
> 


So struct vfio_iommu_type1_dma_unmap should be passed as argument to
notifier callback:

        if (unmapped && iommu->external_domain)
-               vfio_notifier_call_chain(iommu, unmap);
+               blocking_notifier_call_chain(&iommu->notifier,
+                                           VFIO_IOMMU_NOTIFY_DMA_UNMAP,
+                                            unmap);

Then vendor driver should find pfns he has pinned from this range of
iovas, then invalidate and unpin pfns. Right?

Thanks,
Kirti

WARNING: multiple messages have this Message-ID (diff)
From: Kirti Wankhede <kwankhede@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Jike Song <jike.song@intel.com>,
	pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com,
	bjsdjshi@linux.vnet.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP
Date: Sat, 29 Oct 2016 16:07:05 +0530	[thread overview]
Message-ID: <9cfebf8f-7c30-6d2c-a1ec-cc9c9ee1bdd7@nvidia.com> (raw)
In-Reply-To: <20161028143350.45df29c1@t450s.home>



On 10/29/2016 2:03 AM, Alex Williamson wrote:
> On Sat, 29 Oct 2016 01:32:35 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> 
>> On 10/28/2016 6:10 PM, Alex Williamson wrote:
>>> On Fri, 28 Oct 2016 15:33:58 +0800
>>> Jike Song <jike.song@intel.com> wrote:
>>>   
...
>>>>>  
>>>>> +/*
>>>>> + * This function finds pfn in domain->external_addr_space->pfn_list for given
>>>>> + * iova range. If pfn exist, notify pfn to registered notifier list. On
>>>>> + * receiving notifier callback, vendor driver should invalidate the mapping and
>>>>> + * call vfio_unpin_pages() to unpin this pfn. With that vfio_pfn for this pfn
>>>>> + * gets removed from rb tree of pfn_list. That re-arranges rb tree, so while
>>>>> + * searching for next vfio_pfn in rb tree, start search from first node again.
>>>>> + * If any vendor driver doesn't unpin that pfn, vfio_pfn would not get removed
>>>>> + * from rb tree and so in next search vfio_pfn would be same as previous
>>>>> + * vfio_pfn. In that case, exit from loop.
>>>>> + */
>>>>> +static void vfio_notifier_call_chain(struct vfio_iommu *iommu,
>>>>> +				     struct vfio_iommu_type1_dma_unmap *unmap)
>>>>> +{
>>>>> +	struct vfio_domain *domain = iommu->external_domain;
>>>>> +	struct rb_node *n;
>>>>> +	struct vfio_pfn *vpfn = NULL, *prev_vpfn;
>>>>> +
>>>>> +	do {
>>>>> +		prev_vpfn = vpfn;
>>>>> +		mutex_lock(&domain->external_addr_space->pfn_list_lock);
>>>>> +
>>>>> +		n = rb_first(&domain->external_addr_space->pfn_list);
>>>>> +
>>>>> +		for (; n; n = rb_next(n), vpfn = NULL) {
>>>>> +			vpfn = rb_entry(n, struct vfio_pfn, node);
>>>>> +
>>>>> +			if ((vpfn->iova >= unmap->iova) &&
>>>>> +			    (vpfn->iova < unmap->iova + unmap->size))
>>>>> +				break;
>>>>> +		}
>>>>> +
>>>>> +		mutex_unlock(&domain->external_addr_space->pfn_list_lock);
>>>>> +
>>>>> +		/* Notify any listeners about DMA_UNMAP */
>>>>> +		if (vpfn)
>>>>> +			blocking_notifier_call_chain(&iommu->notifier,
>>>>> +						    VFIO_IOMMU_NOTIFY_DMA_UNMAP,
>>>>> +						    &vpfn->pfn);    
>>>>
>>>> Hi Kirti, 
>>>>
>>>> The information carried by notifier is only a pfn.
>>>>
>>>> Since your pin/unpin interfaces design, it's the vendor driver who should
>>>> guarantee pin/unpin same times. To achieve that, the vendor driver must
>>>> cache it's iova->pfn mapping on its side, to avoid pinning a same page
>>>> for multiple times.
>>>>
>>>> With the notifier carrying only a pfn, to find the iova by this pfn,
>>>> the vendor driver must *also* keep a reverse-mapping. That's a bit
>>>> too much.
>>>>
>>>> Since the vendor could also suffer from IOMMU-compatible problem,
>>>> which means a local cache is always helpful, so I'd like to have the
>>>> iova carried to the notifier.
>>>>
>>>> What'd you say?  
>>>
>>> I agree, the pfn is not unique, multiple guest pfns (iovas) might be
>>> backed by the same host pfn.  DMA_UNMAP calls are based on iova, the
>>> notifier through to the vendor driver must be based on the same.  
>>
>> Host pfn should be unique, right?
> 
> Let's say a user does a malloc of a single page and does 100 calls to
> MAP_DMA populating 100 pages of IOVA space all backed by the same
> malloc'd page.  This is valid, I have unit tests that do essentially
> this.  Those will all have the same pfn.  The user then does an
> UNMAP_DMA to a single one of those IOVA pages.  Did the user unmap
> everything matching that pfn?  Of course not, they only unmapped that
> one IOVA page.  There is no guarantee of a 1:1 mapping of pfn to IOVA.
> UNMAP_DMA works based on IOVA.  Invalidation broadcasts to the vendor
> driver MUST therefore also work based on IOVA.  This is not an academic
> problem, address space aliases exist in real VMs, imagine a virtual
> IOMMU.  Thanks,
> 


So struct vfio_iommu_type1_dma_unmap should be passed as argument to
notifier callback:

        if (unmapped && iommu->external_domain)
-               vfio_notifier_call_chain(iommu, unmap);
+               blocking_notifier_call_chain(&iommu->notifier,
+                                           VFIO_IOMMU_NOTIFY_DMA_UNMAP,
+                                            unmap);

Then vendor driver should find pfns he has pinned from this range of
iovas, then invalidate and unpin pfns. Right?

Thanks,
Kirti

  reply	other threads:[~2016-10-29 10:37 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 21:29 [PATCH v10 00/19] Add Mediated device support Kirti Wankhede
2016-10-26 21:29 ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 01/19] vfio: Mediated device Core driver Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-29  4:30   ` Jike Song
2016-10-29  4:30     ` [Qemu-devel] " Jike Song
2016-10-29 10:06     ` Kirti Wankhede
2016-10-29 10:06       ` [Qemu-devel] " Kirti Wankhede
2016-10-29 18:11       ` Jike Song
2016-10-29 18:11         ` [Qemu-devel] " Jike Song
2016-11-02  7:59         ` Kirti Wankhede
2016-11-02  7:59           ` [Qemu-devel] " Kirti Wankhede
2016-11-02 10:31           ` Jike Song
2016-11-01  3:08   ` Jike Song
2016-11-01  3:08     ` [Qemu-devel] " Jike Song
2016-11-01  3:44     ` Alex Williamson
2016-11-01  3:44       ` [Qemu-devel] " Alex Williamson
2016-11-01  5:28       ` Jike Song
2016-11-01  5:28         ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 02/19] vfio: VFIO based driver for Mediated devices Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29   ` Kirti Wankhede
2016-11-02 10:39   ` Jike Song
2016-11-02 10:39     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 03/19] vfio: Rearrange functions to get vfio_group from dev Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29   ` Kirti Wankhede
2016-11-02 10:41   ` Jike Song
2016-11-02 10:41     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 04/19] vfio: Common function to increment container_users Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-11-02 11:34   ` Jike Song
2016-11-02 11:34     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 05/19] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-11-01  8:07   ` Jike Song
2016-11-01  8:07     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 06/19] vfio iommu type1: Update arguments of vfio_lock_acct Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 07/19] vfio iommu type1: Update argument of vaddr_get_pfn() Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-27 12:11   ` Jike Song
2016-10-27 12:11     ` [Qemu-devel] " Jike Song
2016-10-27 12:11     ` Jike Song
2016-10-27 12:24     ` Kirti Wankhede
2016-10-27 12:24       ` [Qemu-devel] " Kirti Wankhede
2016-10-27 12:24       ` Kirti Wankhede
2016-10-28  6:01       ` Jike Song
2016-10-28  6:01         ` [Qemu-devel] " Jike Song
2016-11-02  8:06         ` Kirti Wankhede
2016-11-02  8:06           ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 08/19] vfio iommu type1: Add find_iommu_group() function Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-11-02 14:13   ` Jike Song
2016-11-02 14:13     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 09/19] vfio iommu type1: Add support for mediated devices Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-27 23:01   ` Alex Williamson
2016-10-27 23:01     ` [Qemu-devel] " Alex Williamson
2016-11-02 13:29   ` Jike Song
2016-11-02 13:29     ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-28  7:33   ` Jike Song
2016-10-28  7:33     ` [Qemu-devel] " Jike Song
2016-10-28 12:38     ` Kirti Wankhede
2016-10-28 12:38       ` [Qemu-devel] " Kirti Wankhede
2016-10-28 12:40     ` Alex Williamson
2016-10-28 12:40       ` [Qemu-devel] " Alex Williamson
2016-10-28 20:02       ` Kirti Wankhede
2016-10-28 20:02         ` [Qemu-devel] " Kirti Wankhede
2016-10-28 20:33         ` Alex Williamson
2016-10-28 20:33           ` [Qemu-devel] " Alex Williamson
2016-10-29 10:37           ` Kirti Wankhede [this message]
2016-10-29 10:37             ` Kirti Wankhede
2016-10-29 14:03             ` Alex Williamson
2016-10-29 14:03               ` [Qemu-devel] " Alex Williamson
2016-10-29 14:03               ` Alex Williamson
2016-11-01  3:45               ` [Qemu-devel] " Dong Jia Shi
2016-11-01  7:47                 ` Kirti Wankhede
2016-11-01  7:47                   ` [Qemu-devel] " Kirti Wankhede
2016-11-01  8:33                   ` Dong Jia Shi
2016-11-01  8:33                   ` Dong Jia Shi
2016-11-01  3:45               ` Dong Jia Shi
2016-10-31  3:50   ` Jike Song
2016-10-31  3:50     ` [Qemu-devel] " Jike Song
2016-10-31  5:59     ` Kirti Wankhede
2016-10-31  5:59       ` [Qemu-devel] " Kirti Wankhede
2016-10-31  6:05       ` Jike Song
2016-10-31  6:05         ` [Qemu-devel] " Jike Song
2016-10-26 21:29 ` [PATCH v10 11/19] vfio: Introduce common function to add capabilities Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 12/19] vfio_pci: Update vfio_pci to use vfio_info_add_capability() Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 13/19] vfio: Introduce vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 14/19] vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 15/19] vfio_platform: " Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 16/19] vfio: Define device_api strings Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 17/19] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 18/19] docs: Sysfs ABI for mediated device framework Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-31  7:19   ` Jike Song
2016-10-31  7:19     ` [Qemu-devel] " Jike Song
2016-11-02  7:55     ` Kirti Wankhede
2016-11-02  7:55       ` [Qemu-devel] " Kirti Wankhede
2016-10-26 21:29 ` [PATCH v10 19/19] docs: Sample driver to demonstrate how to use Mediated " Kirti Wankhede
2016-10-26 21:29   ` [Qemu-devel] " Kirti Wankhede
2016-10-27 14:29   ` Jonathan Corbet
2016-10-27 14:29     ` [Qemu-devel] " Jonathan Corbet
2016-11-01  8:32 ` [PATCH v10 00/19] Add Mediated device support Jike Song
2016-11-01  8:32   ` [Qemu-devel] " Jike Song
2016-11-01 15:24   ` Gerd Hoffmann
2016-11-01 15:24     ` [Qemu-devel] " Gerd Hoffmann
2016-11-02  1:01     ` Jike Song

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=9cfebf8f-7c30-6d2c-a1ec-cc9c9ee1bdd7@nvidia.com \
    --to=kwankhede@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=jike.song@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.