RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Liu, Yi L
t;; Greg Kroah-Hartman > >> <gre...@linuxfoundation.org>; Wysocki, Rafael J > >> <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>; > >> io...@lists.linux-foundation.org; David Woodhouse > >> <dw...@infradead.org> >

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Liu, Yi L
Rafael J > ; LKML ; > io...@lists.linux-foundation.org; David Woodhouse > Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function > > On 2017/10/12 17:50, Liu, Yi L wrote: > > > > > >> -Original Message- > >> From: Bob Liu [mai

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Jean-Philippe Brucker
socki, Rafael J >>> <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>; >>> io...@lists.linux-foundation.org; David Woodhouse <dw...@infradead.org> >>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function >>

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Jean-Philippe Brucker
el >>> ; Liu, Yi L >>> Cc: Lan, Tianyu ; Liu, Yi L >>> ; Greg >>> Kroah-Hartman ; Wysocki, Rafael J >>> ; LKML ; >>> io...@lists.linux-foundation.org; David Woodhouse >>> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Bob Liu
;linux-kernel@vger.kernel.org>; >> io...@lists.linux-foundation.org; David Woodhouse <dw...@infradead.org> >> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function >> >> On 2017/10/11 20:48, Jean-Philippe Brucker wrote: >>> On 11/10/17 13:

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Bob Liu
Yi L >> ; Greg >> Kroah-Hartman ; Wysocki, Rafael J >> ; LKML ; >> io...@lists.linux-foundation.org; David Woodhouse >> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function >> >> On 2017/10/11 20:48, Jean-Philippe Brucker wrote: >>&

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Liu, Yi L
yu <tianyu@intel.com>; Liu, Yi L <yi.l@linux.intel.com>; > Greg > Kroah-Hartman <gre...@linuxfoundation.org>; Wysocki, Rafael J > <rafael.j.wyso...@intel.com>; LKML <linux-kernel@vger.kernel.org>; > io...@lists.linux-foundation.org; David Woodhous

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Liu, Yi L
...@lists.linux-foundation.org; David Woodhouse > Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function > > On 2017/10/11 20:48, Jean-Philippe Brucker wrote: > > On 11/10/17 13:15, Joerg Roedel wrote: > >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu,

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Bob Liu
On 2017/10/11 20:48, Jean-Philippe Brucker wrote: > On 11/10/17 13:15, Joerg Roedel wrote: >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? >> >> It's short for IO Virtual Memory, basically a replacement term

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Bob Liu
On 2017/10/11 20:48, Jean-Philippe Brucker wrote: > On 11/10/17 13:15, Joerg Roedel wrote: >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? >> >> It's short for IO Virtual Memory, basically a replacement term

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 01:48:00PM +0100, Jean-Philippe Brucker wrote: > I wonder if SVM originated in OpenCL first, rather than intel? That's why > I'm using it, but it is ambiguous. I'm not sure IOVM is precise enough > though, since the name could as well be used without shared tables, for >

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-12 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 01:48:00PM +0100, Jean-Philippe Brucker wrote: > I wonder if SVM originated in OpenCL first, rather than intel? That's why > I'm using it, but it is ambiguous. I'm not sure IOVM is precise enough > though, since the name could as well be used without shared tables, for >

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Jean-Philippe Brucker
On 11/10/17 13:15, Joerg Roedel wrote: > On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? > > It's short for IO Virtual Memory, basically a replacement term for 'svm' > that is not ambiguous (afaik) and not

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Jean-Philippe Brucker
On 11/10/17 13:15, Joerg Roedel wrote: > On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? > > It's short for IO Virtual Memory, basically a replacement term for 'svm' > that is not ambiguous (afaik) and not

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: > I didn't quite get 'iovm' mean. Can you explain a bit about the idea? It's short for IO Virtual Memory, basically a replacement term for 'svm' that is not ambiguous (afaik) and not specific to Intel. Joerg

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: > I didn't quite get 'iovm' mean. Can you explain a bit about the idea? It's short for IO Virtual Memory, basically a replacement term for 'svm' that is not ambiguous (afaik) and not specific to Intel. Joerg

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Liu, Yi L
> On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > > I agree that iommu_invalidate() is too generic. Additionally, also > > better to avoid making it svm specific. > > I also don't like to name the functions after the Intel feature, but I failed > to come up > with a better

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Liu, Yi L
> On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > > I agree that iommu_invalidate() is too generic. Additionally, also > > better to avoid making it svm specific. > > I also don't like to name the functions after the Intel feature, but I failed > to come up > with a better

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > I agree that iommu_invalidate() is too generic. Additionally, also > better to avoid making it svm specific. I also don't like to name the functions after the Intel feature, but I failed to come up with a better alternative so far. The

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Joerg Roedel
On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > I agree that iommu_invalidate() is too generic. Additionally, also > better to avoid making it svm specific. I also don't like to name the functions after the Intel feature, but I failed to come up with a better alternative so far. The

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Liu, Yi L
> On Tue, 10 Oct 2017 15:35:42 +0200 > Joerg Roedel wrote: > > > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > > > +int iommu_invalidate(struct iommu_domain *domain, > > > + struct device *dev, struct tlb_invalidate_info > > > *inv_info) > > > > This name

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-11 Thread Liu, Yi L
> On Tue, 10 Oct 2017 15:35:42 +0200 > Joerg Roedel wrote: > > > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > > > +int iommu_invalidate(struct iommu_domain *domain, > > > + struct device *dev, struct tlb_invalidate_info > > > *inv_info) > > > > This name is way too

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-10 Thread Jacob Pan
On Tue, 10 Oct 2017 15:35:42 +0200 Joerg Roedel wrote: > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > > +int iommu_invalidate(struct iommu_domain *domain, > > + struct device *dev, struct tlb_invalidate_info > > *inv_info) > > This name is way too

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-10 Thread Jacob Pan
On Tue, 10 Oct 2017 15:35:42 +0200 Joerg Roedel wrote: > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > > +int iommu_invalidate(struct iommu_domain *domain, > > + struct device *dev, struct tlb_invalidate_info > > *inv_info) > > This name is way too generic, it should

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-10 Thread Joerg Roedel
On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > +int iommu_invalidate(struct iommu_domain *domain, > + struct device *dev, struct tlb_invalidate_info *inv_info) This name is way too generic, it should at least be called iommu_svm_invalidate() or something like that. With

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-10 Thread Joerg Roedel
On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > +int iommu_invalidate(struct iommu_domain *domain, > + struct device *dev, struct tlb_invalidate_info *inv_info) This name is way too generic, it should at least be called iommu_svm_invalidate() or something like that. With

[PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-05 Thread Jacob Pan
From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of caching

[PATCH v2 03/16] iommu: introduce iommu invalidate API function

2017-10-05 Thread Jacob Pan
From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of caching structure updates unless the guest