Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-09 Thread Jacob Pan
On Tue, 8 May 2018 11:35:00 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > Looks mostly good to me, I just have a couple more comments > > On 04/05/18 19:07, Jacob Pan wrote: > > Now the passdown invalidation granularities look like: > > (sorted by

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-09 Thread Jacob Pan
On Tue, 8 May 2018 11:35:00 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > Looks mostly good to me, I just have a couple more comments > > On 04/05/18 19:07, Jacob Pan wrote: > > Now the passdown invalidation granularities look like: > > (sorted by coarseness), will send out in v5 patchset

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-08 Thread Jean-Philippe Brucker
Hi Jacob, Looks mostly good to me, I just have a couple more comments On 04/05/18 19:07, Jacob Pan wrote: > Now the passdown invalidation granularities look like: > (sorted by coarseness), will send out in v5 patchset soon if no issues. > > /** > * enum iommu_inv_granularity - Generic

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-08 Thread Jean-Philippe Brucker
Hi Jacob, Looks mostly good to me, I just have a couple more comments On 04/05/18 19:07, Jacob Pan wrote: > Now the passdown invalidation granularities look like: > (sorted by coarseness), will send out in v5 patchset soon if no issues. > > /** > * enum iommu_inv_granularity - Generic

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-07 Thread Jacob Pan
On Sat, 5 May 2018 15:19:43 -0700 Jerry Snitselaar wrote: > > > >+static inline int iommu_sva_invalidate(struct iommu_domain *domain, > >+struct device *dev, struct tlb_invalidate_info > >*inv_info) +{ > >+return -EINVAL; > >+} > >+ > > Would -ENODEV make

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-07 Thread Jacob Pan
On Sat, 5 May 2018 15:19:43 -0700 Jerry Snitselaar wrote: > > > >+static inline int iommu_sva_invalidate(struct iommu_domain *domain, > >+struct device *dev, struct tlb_invalidate_info > >*inv_info) +{ > >+return -EINVAL; > >+} > >+ > > Would -ENODEV make more sense here? >

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-05 Thread Jerry Snitselaar
On Mon Apr 16 18, Jacob Pan wrote: 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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-05 Thread Jerry Snitselaar
On Mon Apr 16 18, Jacob Pan wrote: 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

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-04 Thread Jacob Pan
On Thu, 3 May 2018 21:46:16 -0700 Jacob Pan wrote: > On Wed, 2 May 2018 10:31:50 +0100 > Jean-Philippe Brucker wrote: > > > On 01/05/18 23:58, Jacob Pan wrote: > > Maybe this should be called "NG_PAGE_PASID", > > >>>

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-04 Thread Jacob Pan
On Thu, 3 May 2018 21:46:16 -0700 Jacob Pan wrote: > On Wed, 2 May 2018 10:31:50 +0100 > Jean-Philippe Brucker wrote: > > > On 01/05/18 23:58, Jacob Pan wrote: > > Maybe this should be called "NG_PAGE_PASID", > > >>> Sure. I was thinking page range already implies non-global > >

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-03 Thread Jacob Pan
On Wed, 2 May 2018 10:31:50 +0100 Jean-Philippe Brucker wrote: > On 01/05/18 23:58, Jacob Pan wrote: > Maybe this should be called "NG_PAGE_PASID", > >>> Sure. I was thinking page range already implies non-global > >>> pages. > and "DOMAIN_PAGE"

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-03 Thread Jacob Pan
On Wed, 2 May 2018 10:31:50 +0100 Jean-Philippe Brucker wrote: > On 01/05/18 23:58, Jacob Pan wrote: > Maybe this should be called "NG_PAGE_PASID", > >>> Sure. I was thinking page range already implies non-global > >>> pages. > and "DOMAIN_PAGE" should > instead be

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-02 Thread Jean-Philippe Brucker
On 01/05/18 23:58, Jacob Pan wrote: Maybe this should be called "NG_PAGE_PASID", >>> Sure. I was thinking page range already implies non-global pages. and "DOMAIN_PAGE" should instead be "PAGE_PASID". If I understood their meaning correctly, it would be more consistent with

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-02 Thread Jean-Philippe Brucker
On 01/05/18 23:58, Jacob Pan wrote: Maybe this should be called "NG_PAGE_PASID", >>> Sure. I was thinking page range already implies non-global pages. and "DOMAIN_PAGE" should instead be "PAGE_PASID". If I understood their meaning correctly, it would be more consistent with

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-01 Thread Jacob Pan
On Fri, 27 Apr 2018 19:07:43 +0100 Jean-Philippe Brucker wrote: > On 23/04/18 21:43, Jacob Pan wrote: > [...] > >> The last name is a bit unfortunate. Since the Arm architecture uses > >> the name "context" for what a PASID points to, "Device cache" would > >> suit

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-05-01 Thread Jacob Pan
On Fri, 27 Apr 2018 19:07:43 +0100 Jean-Philippe Brucker wrote: > On 23/04/18 21:43, Jacob Pan wrote: > [...] > >> The last name is a bit unfortunate. Since the Arm architecture uses > >> the name "context" for what a PASID points to, "Device cache" would > >> suit us better but it's not

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-27 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, April 28, 2018 2:08 AM > > [...] > >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should > >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it > >> different from

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-27 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Saturday, April 28, 2018 2:08 AM > > [...] > >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should > >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it > >> different from

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-27 Thread Jean-Philippe Brucker
On 23/04/18 21:43, Jacob Pan wrote: [...] >> The last name is a bit unfortunate. Since the Arm architecture uses >> the name "context" for what a PASID points to, "Device cache" would >> suit us better but it's not important. >> > or call it device context cache. actually so far context cache is

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-27 Thread Jean-Philippe Brucker
On 23/04/18 21:43, Jacob Pan wrote: [...] >> The last name is a bit unfortunate. Since the Arm architecture uses >> the name "context" for what a PASID points to, "Device cache" would >> suit us better but it's not important. >> > or call it device context cache. actually so far context cache is

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-23 Thread Jacob Pan
On Fri, 20 Apr 2018 19:19:54 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: > [...] > > +/** > > + * enum iommu_inv_granularity - Generic invalidation granularity > > + * > > + * When an invalidation

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-23 Thread Jacob Pan
On Fri, 20 Apr 2018 19:19:54 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: > [...] > > +/** > > + * enum iommu_inv_granularity - Generic invalidation granularity > > + * > > + * When an invalidation request is sent to IOMMU to

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-20 Thread Jean-Philippe Brucker
Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-20 Thread Jean-Philippe Brucker
Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

[PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-04-16 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 v4 05/22] iommu: introduce iommu invalidate API function

2018-04-16 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

[PATCH v4 05/22] iommu: introduce iommu invalidate API function

2018-03-22 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 v4 05/22] iommu: introduce iommu invalidate API function

2018-03-22 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