qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Wang <jasowang@redhat.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"peterx@redhat.com" <peterx@redhat.com>
Cc: "tianyu.lan@intel.com" <tianyu.lan@intel.com>,
	"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Tian, Jun J" <jun.j.tian@intel.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"Sun, Yi Y" <yi.y.sun@intel.com>,
	"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>
Subject: RE: [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM
Date: Sat, 2 Nov 2019 07:35:19 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D5E2309@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <4fae7d47-93c6-1278-b55e-ec06fa3ca7f1@redhat.com>

> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Friday, November 1, 2019 4:10 PM
> 
> 
> On 2019/11/1 下午4:04, Jason Wang wrote:
> >
> > On 2019/11/1 下午3:46, Tian, Kevin wrote:
> >>> From: Jason Wang [mailto:jasowang@redhat.com]
> >>> Sent: Friday, November 1, 2019 3:30 PM
> >>>
> >>>
> >>> On 2019/10/31 下午10:07, Liu, Yi L wrote:
> >>>>> From: Jason Wang [mailto:jasowang@redhat.com]
> >>>>> Sent: Thursday, October 31, 2019 5:33 AM
> >>>>> Subject: Re: [RFC v2 00/22] intel_iommu: expose Shared Virtual
> >>> Addressing to VM
> >>>>>
> >>>>> On 2019/10/25 下午6:12, Tian, Kevin wrote:
> >>>>>>> From: Jason Wang [mailto:jasowang@redhat.com]
> >>>>>>> Sent: Friday, October 25, 2019 5:49 PM
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2019/10/24 下午8:34, Liu Yi L wrote:
> >>>>>>>> Shared virtual address (SVA), a.k.a, Shared virtual memory
> >>>>>>>> (SVM) on
> >>>>>>>> Intel platforms allow address space sharing between device DMA
> >>> and
> >>>>>>> applications.
> >>>>>>>
> >>>>>>>
> >>>>>>> Interesting, so the below figure demonstrates the case of VM. I
> >>>>>>> wonder how much differences if we compare it with doing SVM
> >>> between
> >>>>>>> device and an ordinary process (e.g dpdk)?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>> One difference is that ordinary process requires only stage-1
> >>>>>> translation, while VM requires nested translation.
> >>>>> A silly question, then I believe there's no need for VFIO DMA API
> >>>>> in this
> >>> case consider
> >>>>> the page table is shared between MMU and IOMMU?
> >>>> Echo Kevin's reply. We use nested translation here. For stage-1,
> >>>> yes, no
> >>> need to use
> >>>> VFIO DMA API. For stage-2, we still use VFIO DMA API to program the
> >>> GPA->HPA
> >>>> mapping to host. :-)
> >>>
> >>> Cool, two more questions:
> >>>
> >>> - Can EPT shares its page table with IOMMU L2?
> >> yes, their formats are compatible.
> >>
> >>> - Similar to EPT, when GPA->HPA (actually HVA->HPA) is modified by
> mm,
> >>> VFIO need to use MMU notifier do modify L2 accordingly besides DMA
> API?
> >>>
> >> VFIO devices need to pin-down guest memory pages that are mapped
> >> in IOMMU. So notifier is not required since mm won't change the
> mapping
> >> for those pages.
> >
> >
> > The GUP tends to lead a lot of issues, we may consider to allow
> > userspace to choose to not pin them in the future.
> 
> 
> Btw, I'm asking since I see MMU notifier is used by intel-svm.c to flush
> IOTLB. (I don't see any users in kernel source that use that API though
> e.g intel_svm_bind_mm()).
> 

intel-svm.c requires MMU notifier to invalidate IOTLB upon any change
on the CPU page table, when the latter is shared with device in SVA
case. But for VFIO usage, which is based on stage2, the map/unmap 
requests explicitly come from userspace. there is no need to sync with
mm.

Thanks
Kevin

  reply	other threads:[~2019-11-02  7:36 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 12:34 [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM Liu Yi L
2019-10-24 12:34 ` [RFC v2 01/22] update-linux-headers: Import iommu.h Liu Yi L
2019-10-24 12:34 ` [RFC v2 02/22] header update VFIO/IOMMU vSVA APIs against 5.4.0-rc3+ Liu Yi L
2019-10-24 12:34 ` [RFC v2 03/22] intel_iommu: modify x-scalable-mode to be string option Liu Yi L
2019-11-01 14:57   ` Peter Xu
2019-11-05  9:14     ` Liu, Yi L
2019-11-05 12:50       ` Peter Xu
2019-11-06  9:50         ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 04/22] hw/iommu: introduce IOMMUContext Liu Yi L
2019-10-27 17:39   ` David Gibson
2019-11-06 11:18     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 05/22] vfio/common: add iommu_ctx_notifier in container Liu Yi L
2019-11-01 14:58   ` Peter Xu
2019-11-06 11:08     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 06/22] hw/pci: modify pci_setup_iommu() to set PCIIOMMUOps Liu Yi L
2019-10-27 17:43   ` David Gibson
2019-11-06  8:18     ` Liu, Yi L
2019-11-01 18:09   ` Peter Xu
2019-11-06  8:15     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 07/22] hw/pci: introduce pci_device_iommu_context() Liu Yi L
2019-10-29 11:50   ` David Gibson
2019-11-06  8:20     ` Liu, Yi L
2019-11-01 18:09   ` Peter Xu
2019-11-06  8:14     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 08/22] intel_iommu: provide get_iommu_context() callback Liu Yi L
2019-11-01 14:55   ` Peter Xu
2019-11-06 11:07     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 09/22] vfio/pci: add iommu_context notifier for pasid alloc/free Liu Yi L
2019-10-29 12:15   ` David Gibson
2019-11-01 17:26     ` Peter Xu
2019-11-06 12:46       ` Liu, Yi L
2019-11-06 12:14     ` Liu, Yi L
2019-11-20  4:27       ` David Gibson
2019-11-26  7:07         ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 10/22] intel_iommu: add virtual command capability support Liu Yi L
2019-11-01 18:05   ` Peter Xu
2019-11-06 12:40     ` Liu, Yi L
2019-11-06 14:00       ` Peter Xu
2019-11-12  6:27         ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 11/22] intel_iommu: process pasid cache invalidation Liu Yi L
2019-11-02 16:05   ` Peter Xu
2019-11-06  5:55     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 12/22] intel_iommu: add present bit check for pasid table entries Liu Yi L
2019-11-02 16:20   ` Peter Xu
2019-11-06  8:14     ` Liu, Yi L
2019-10-24 12:34 ` [RFC v2 13/22] intel_iommu: add PASID cache management infrastructure Liu Yi L
2019-11-04 17:08   ` Peter Xu
2019-11-04 20:06   ` Peter Xu
2019-11-06  7:56     ` Liu, Yi L
2019-11-07 15:46       ` Peter Xu
2019-10-24 12:34 ` [RFC v2 14/22] vfio/pci: add iommu_context notifier for pasid bind/unbind Liu Yi L
2019-11-04 16:02   ` David Gibson
2019-11-06 12:22     ` Liu, Yi L
2019-11-06 14:25       ` Peter Xu
2019-10-24 12:34 ` [RFC v2 15/22] intel_iommu: bind/unbind guest page table to host Liu Yi L
2019-11-04 20:25   ` Peter Xu
2019-11-06  8:10     ` Liu, Yi L
2019-11-06 14:27       ` Peter Xu
2019-10-24 12:34 ` [RFC v2 16/22] intel_iommu: replay guest pasid bindings " Liu Yi L
2019-10-24 12:34 ` [RFC v2 17/22] intel_iommu: replay pasid binds after context cache invalidation Liu Yi L
2019-10-24 12:34 ` [RFC v2 18/22] intel_iommu: do not passdown pasid bind for PASID #0 Liu Yi L
2019-10-24 12:34 ` [RFC v2 19/22] vfio/pci: add iommu_context notifier for PASID-based iotlb flush Liu Yi L
2019-10-24 12:34 ` [RFC v2 20/22] intel_iommu: process PASID-based iotlb invalidation Liu Yi L
2019-10-24 12:34 ` [RFC v2 21/22] intel_iommu: propagate PASID-based iotlb invalidation to host Liu Yi L
2019-10-24 12:34 ` [RFC v2 22/22] intel_iommu: process PASID-based Device-TLB invalidation Liu Yi L
2019-10-25  6:21 ` [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM no-reply
2019-10-25  6:30 ` no-reply
2019-10-25  9:49 ` Jason Wang
2019-10-25 10:12   ` Tian, Kevin
2019-10-31  4:33     ` Jason Wang
2019-10-31  5:39       ` Tian, Kevin
2019-10-31 14:07       ` Liu, Yi L
2019-11-01  7:29         ` Jason Wang
2019-11-01  7:46           ` Tian, Kevin
2019-11-01  8:04             ` Jason Wang
2019-11-01  8:09               ` Jason Wang
2019-11-02  7:35                 ` Tian, Kevin [this message]
2019-11-04 17:22 ` Peter Xu
2019-11-05  9:09   ` Liu, Yi L

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=AADFC41AFE54684AB9EE6CBC0274A5D19D5E2309@SHSMSX104.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=eric.auger@redhat.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jasowang@redhat.com \
    --cc=jun.j.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tianyu.lan@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@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).