IOMMU Archive on lore.kernel.org
 help / color / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.com>,
	Jonathan Cameron <jic23@kernel.org>
Subject: RE: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support
Date: Tue, 29 Oct 2019 18:04:21 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19D5DED74@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <20191029091139.7ddc155f@jacob-builder>

> From: Jacob Pan [mailto:jacob.jun.pan@linux.intel.com]
> Sent: Wednesday, October 30, 2019 12:12 AM
> 
> On Tue, 29 Oct 2019 07:57:21 +0000
> "Tian, Kevin" <kevin.tian@intel.com> wrote:
> 
> > > From: Jacob Pan [mailto:jacob.jun.pan@linux.intel.com]
> > > Sent: Tuesday, October 29, 2019 12:03 AM
> > >
> > > On Mon, 28 Oct 2019 06:03:36 +0000
> > > "Tian, Kevin" <kevin.tian@intel.com> wrote:
> > >
> > > > > > > +	.sva_bind_gpasid	= intel_svm_bind_gpasid,
> > > > > > > +	.sva_unbind_gpasid	=
> > > > > > > intel_svm_unbind_gpasid, +#endif
> > > > > >
> > > > > > again, pure PASID management logic should be separated from
> > > > > > SVM.
> > > > > I am not following, these two functions are SVM functionality,
> > > > > not pure PASID management which is already separated in
> > > > > ioasid.c
> > > >
> > > > I should say pure "scalable mode" logic. Above callbacks are not
> > > > related to host SVM per se. They are serving gpasid requests from
> > > > guest side, thus part of generic scalable mode capability.
> > > Got your point, but we are sharing data structures with host SVM,
> > > it is very difficult and inefficient to separate the two.
> >
> > I don't think difficulty is the reason against such direction. We
> > need do things right. :-) I'm fine with putting it in a TODO list,
> > but at least need the right information in the 1st place to tell that
> > current way is just a short-term approach, and we should revisit
> > later.
> I guess the fundamental question is: Should the scalable mode logic,
> i.e. guest SVA at PASID granu device, be perceived as part of the
> overall SVA functionality?

guest SVA != guest scalable mode. I'm not sure whether the definition
of SVA has been changed. but iirc it simply means shared virtual
memory usage i.e. sharing CPU page table with device. But with
scalable mode, you can have PASID tagged 1st-level for whatever
usage, guest IOVA, guest SVA, guest nested GPA, etc.

> 
> My view is yes, we shall share SVA and gSVA whenever we can.

sharing is based on scalable mode, not based on sva itself.

> 
> The longer term, which I am working on right now, is to converge
> intel_svm_bind_mm to the generic iommu_sva_bind_device() and use
> common
> data structures as well. It is conceivable that these common structures
> span across hardware architectures, also guest vs host SVA usages.
> 
> i.e. iommu_ops have
> iommu_sva_bind_gpasid() for SM/gSVA
> iommu_sva_bind_device() for native SVA
> 
> Or I am missing your point completely?

since sva is already used in VFIO for broader purpose, it's fine to leave
the name there. But again, it's incorrect to tie iommu_sva_bind_gpasid
under CONFIG_INTEL_IOMMU_SVM. The former is for SM, while the
latter is only for SVA. As long as host IOMMU is in scalable mode, 
bind_gpasid can be supported. If you want a config option, then it should
be a new one instead of IOMMU_SVM.

Thanks
Kevin
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply index

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 19:54 [PATCH v7 00/11] Nested Shared Virtual Address (SVA) VT-d support Jacob Pan
2019-10-24 19:54 ` [PATCH v7 01/11] iommu/vt-d: Cache virtual command capability register Jacob Pan
2019-10-25  2:53   ` Lu Baolu
2019-10-25  6:06   ` Tian, Kevin
2019-11-08 10:32   ` Auger Eric
2019-10-24 19:54 ` [PATCH v7 02/11] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-10-25  6:19   ` Tian, Kevin
2019-10-29 17:14     ` Jacob Pan
2019-10-29 18:16       ` Tian, Kevin
2019-11-08 10:33   ` Auger Eric
2019-11-08 22:22     ` Jacob Pan
2019-10-24 19:54 ` [PATCH v7 03/11] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-10-25  2:30   ` Lu Baolu
2019-10-25  4:43     ` Jacob Pan
2019-10-25  6:40       ` Tian, Kevin
2019-10-25 14:39         ` Lu Baolu
2019-10-25 15:52           ` Tian, Kevin
2019-10-28 22:49             ` Jacob Pan
2019-10-29  2:22               ` Lu Baolu
2019-10-25  6:31   ` Tian, Kevin
2019-10-28 22:52     ` Jacob Pan
2019-11-08 10:40   ` Auger Eric
2019-11-08 22:26     ` Jacob Pan
2019-10-24 19:54 ` [PATCH v7 04/11] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-10-25  5:47   ` Lu Baolu
2019-11-01 18:29     ` Jacob Pan
2019-10-25  6:41   ` Tian, Kevin
2019-10-28 22:46     ` Jacob Pan
2019-11-08 11:30   ` Auger Eric
2019-11-08 22:55     ` Jacob Pan
2019-11-12  9:54       ` Auger Eric
2019-10-24 19:54 ` [PATCH v7 05/11] iommu/vt-d: Move domain helper to header Jacob Pan
2019-10-25  5:26   ` Lu Baolu
2019-10-24 19:54 ` [PATCH v7 06/11] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-10-25  5:32   ` Lu Baolu
2019-10-25  6:42   ` Tian, Kevin
2019-10-28 22:41     ` Jacob Pan
2019-11-12  9:54   ` Auger Eric
2019-10-24 19:55 ` [PATCH v7 07/11] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-10-25  7:04   ` Tian, Kevin
2019-11-01 21:10     ` Jacob Pan
2019-10-25 15:04   ` Lu Baolu
2019-10-25 16:06     ` Jacob Pan
2019-11-08 13:55   ` Auger Eric
2019-10-24 19:55 ` [PATCH v7 08/11] iommu/vt-d: Misc macro clean up for SVM Jacob Pan
2019-10-26  1:00   ` Lu Baolu
2019-10-28 22:38     ` Jacob Pan
2019-10-24 19:55 ` [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-10-25  7:19   ` Tian, Kevin
2019-10-25 17:33     ` Jacob Pan
2019-10-28  6:03       ` Tian, Kevin
2019-10-28 16:02         ` Jacob Pan
2019-10-29  7:57           ` Tian, Kevin
2019-10-29 16:11             ` Jacob Pan
2019-10-29 18:04               ` Tian, Kevin [this message]
2019-10-29  2:33         ` Lu Baolu
2019-10-26  2:01   ` Lu Baolu
2019-10-28 22:29     ` Jacob Pan
2019-10-29  2:54       ` Lu Baolu
2019-10-29  4:11         ` Jacob Pan
2019-10-29  5:04           ` Lu Baolu
2019-10-24 19:55 ` [PATCH v7 10/11] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-10-25  7:21   ` Tian, Kevin
2019-11-01 21:30     ` Jacob Pan
2019-10-26  2:22   ` Lu Baolu
2019-11-01 21:28     ` Jacob Pan
2019-11-08 16:18   ` Auger Eric
2019-11-08 23:05     ` Jacob Pan
2019-10-24 19:55 ` [PATCH v7 11/11] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-10-25  7:27   ` Tian, Kevin
2019-10-26  2:40     ` Lu Baolu
2019-10-26  7:03       ` Lu Baolu
2019-10-28  6:06         ` Tian, Kevin
2019-10-28 16:10           ` Jacob Pan
2019-10-29 18:52             ` Tian, Kevin
2019-10-29 19:25               ` Jacob Pan
2019-10-28 16:13     ` Jacob Pan
2019-11-12 10:28   ` Auger Eric

Reply instructions:

You may reply publically 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=AADFC41AFE54684AB9EE6CBC0274A5D19D5DED74@SHSMSX104.ccr.corp.intel.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.com \
    --cc=jic23@kernel.org \
    --cc=linux-kernel@vger.kernel.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

IOMMU Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \
		iommu@lists.linux-foundation.org
	public-inbox-index linux-iommu

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git