Message ID | 20190317172232.1068-6-eric.auger@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | SMMUv3 Nested Stage Setup | expand |
On Sun, 17 Mar 2019 18:22:15 +0100 Eric Auger <eric.auger@redhat.com> wrote: > From: "Liu, Yi L" <yi.l.liu@linux.intel.com> > > In any virtualization use case, when the first translation stage > is "owned" by the guest OS, the host IOMMU driver has no knowledge > of caching structure updates unless the guest invalidation activities > are trapped by the virtualizer and passed down to the host. > > Since the invalidation data are obtained from user space and will be > written into physical IOMMU, we must allow security check at various > layers. Therefore, generic invalidation data format are proposed here, > model specific IOMMU drivers need to convert them into their own > format. > > Signed-off-by: Liu, Yi L <yi.l.liu@linux.intel.com> > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Signed-off-by: Ashok Raj <ashok.raj@intel.com> > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > --- > v5 -> v6: > - fix merge issue > > v3 -> v4: > - full reshape of the API following Alex' comments > > v1 -> v2: > - add arch_id field > - renamed tlb_invalidate into cache_invalidate as this API allows > to invalidate context caches on top of IOTLBs > > v1: > renamed sva_invalidate into tlb_invalidate and add iommu_ prefix in > header. Commit message reworded. > --- > drivers/iommu/iommu.c | 14 ++++++++ > include/linux/iommu.h | 15 ++++++++ > include/uapi/linux/iommu.h | 71 > ++++++++++++++++++++++++++++++++++++++ 3 files changed, 100 > insertions(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 7d9285cea100..b72e326ddd41 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -1544,6 +1544,20 @@ void iommu_detach_pasid_table(struct > iommu_domain *domain) } > EXPORT_SYMBOL_GPL(iommu_detach_pasid_table); > > +int iommu_cache_invalidate(struct iommu_domain *domain, struct > device *dev, > + struct iommu_cache_invalidate_info > *inv_info) +{ > + int ret = 0; > + > + if (unlikely(!domain->ops->cache_invalidate)) > + return -ENODEV; > + > + ret = domain->ops->cache_invalidate(domain, dev, inv_info); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(iommu_cache_invalidate); > + > static void __iommu_detach_device(struct iommu_domain *domain, > struct device *dev) > { > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index fb9b7a8de25f..7c7c6bad1420 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -191,6 +191,7 @@ struct iommu_resv_region { > * driver init to device driver init (default > no) > * @attach_pasid_table: attach a pasid table > * @detach_pasid_table: detach the pasid table > + * @cache_invalidate: invalidate translation caches > * @pgsize_bitmap: bitmap of all possible supported page sizes > */ > struct iommu_ops { > @@ -239,6 +240,9 @@ struct iommu_ops { > struct iommu_pasid_table_config > *cfg); void (*detach_pasid_table)(struct iommu_domain *domain); > > + int (*cache_invalidate)(struct iommu_domain *domain, struct > device *dev, > + struct iommu_cache_invalidate_info > *inv_info); + > unsigned long pgsize_bitmap; > }; > > @@ -349,6 +353,9 @@ extern void iommu_detach_device(struct > iommu_domain *domain, extern int iommu_attach_pasid_table(struct > iommu_domain *domain, struct iommu_pasid_table_config *cfg); > extern void iommu_detach_pasid_table(struct iommu_domain *domain); > +extern int iommu_cache_invalidate(struct iommu_domain *domain, > + struct device *dev, > + struct iommu_cache_invalidate_info > *inv_info); extern struct iommu_domain > *iommu_get_domain_for_dev(struct device *dev); extern struct > iommu_domain *iommu_get_dma_domain(struct device *dev); extern int > iommu_map(struct iommu_domain *domain, unsigned long iova, @@ -797,6 > +804,14 @@ int iommu_attach_pasid_table(struct iommu_domain *domain, > static inline void iommu_detach_pasid_table(struct iommu_domain > *domain) {} > +static inline int > +iommu_cache_invalidate(struct iommu_domain *domain, > + struct device *dev, > + struct iommu_cache_invalidate_info *inv_info) > +{ > + return -ENODEV; > +} > + > #endif /* CONFIG_IOMMU_API */ > > #ifdef CONFIG_IOMMU_DEBUGFS > diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h > index 532a64075f23..e4c6a447e85a 100644 > --- a/include/uapi/linux/iommu.h > +++ b/include/uapi/linux/iommu.h > @@ -159,4 +159,75 @@ struct iommu_pasid_table_config { > }; > }; > > +/* defines the granularity of the invalidation */ > +enum iommu_inv_granularity { > + IOMMU_INV_GRANU_DOMAIN, /* domain-selective > invalidation */ > + IOMMU_INV_GRANU_PASID, /* pasid-selective > invalidation */ > + IOMMU_INV_GRANU_ADDR, /* page-selective invalidation > */ +}; > + > +/** > + * Address Selective Invalidation Structure > + * > + * @flags indicates the granularity of the address-selective > invalidation > + * - if PASID bit is set, @pasid field is populated and the > invalidation > + * relates to cache entries tagged with this PASID and matching the > + * address range. > + * - if ARCHID bit is set, @archid is populated and the invalidation > relates > + * to cache entries tagged with this architecture specific id and > matching > + * the address range. > + * - Both PASID and ARCHID can be set as they may tag different > caches. > + * - if neither PASID or ARCHID is set, global addr invalidation > applies > + * - LEAF flag indicates whether only the leaf PTE caching needs to > be > + * invalidated and other paging structure caches can be preserved. > + * @pasid: process address space id > + * @archid: architecture-specific id > + * @addr: first stage/level input address > + * @granule_size: page/block size of the mapping in bytes > + * @nb_granules: number of contiguous granules to be invalidated > + */ > +struct iommu_inv_addr_info { > +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) > +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) > +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) > + __u32 flags; > + __u32 archid; > + __u64 pasid; > + __u64 addr; > + __u64 granule_size; > + __u64 nb_granules; > +}; > + > +/** > + * First level/stage invalidation information > + * @cache: bitfield that allows to select which caches to invalidate > + * @granularity: defines the lowest granularity used for the > invalidation: > + * domain > pasid > addr > + * > + * Not all the combinations of cache/granularity make sense: > + * > + * type | DEV_IOTLB | IOTLB | PASID | > + * granularity | | | > cache | > + * -------------+---------------+---------------+---------------+ > + * DOMAIN | N/A | Y | > Y | > + * PASID | Y | Y | > Y | > + * ADDR | Y | Y | > N/A | > + */ > +struct iommu_cache_invalidate_info { > +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 > + __u32 version; > +/* IOMMU paging structure cache */ > +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ > +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device > IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID > cache */ Just a clarification, this used to be an enum. You do intend to issue a single invalidation request on multiple cache types? Perhaps for virtio-IOMMU? I only see a single cache type in your patch #14. For VT-d we plan to issue one cache type at a time for now. So this format works for us. However, if multiple cache types are issued in a single invalidation. They must share a single granularity, not all combinations are valid. e.g. dev IOTLB does not support domain granularity. Just a reminder, not an issue. Driver could filter out invalid combinations. > + __u8 cache; > + __u8 granularity; > + __u8 padding[2]; > + union { > + __u64 pasid; > + struct iommu_inv_addr_info addr_info; > + }; > +}; > + > + > #endif /* _UAPI_IOMMU_H */ [Jacob Pan]
On 20/03/2019 16:37, Jacob Pan wrote: [...] >> +struct iommu_inv_addr_info { >> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) >> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) >> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) >> + __u32 flags; >> + __u32 archid; >> + __u64 pasid; >> + __u64 addr; >> + __u64 granule_size; >> + __u64 nb_granules; >> +}; >> + >> +/** >> + * First level/stage invalidation information >> + * @cache: bitfield that allows to select which caches to invalidate >> + * @granularity: defines the lowest granularity used for the >> invalidation: >> + * domain > pasid > addr >> + * >> + * Not all the combinations of cache/granularity make sense: >> + * >> + * type | DEV_IOTLB | IOTLB | PASID | >> + * granularity | | | >> cache | >> + * -------------+---------------+---------------+---------------+ >> + * DOMAIN | N/A | Y | >> Y | >> + * PASID | Y | Y | >> Y | >> + * ADDR | Y | Y | >> N/A | >> + */ >> +struct iommu_cache_invalidate_info { >> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 >> + __u32 version; >> +/* IOMMU paging structure cache */ >> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ >> +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device >> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID >> cache */ > Just a clarification, this used to be an enum. You do intend to issue a > single invalidation request on multiple cache types? Perhaps for > virtio-IOMMU? I only see a single cache type in your patch #14. For VT-d > we plan to issue one cache type at a time for now. So this format works > for us. Yes for virtio-iommu I'd like as little overhead as possible, which means a single invalidation message to hit both IOTLB and ATC at once, and the ability to specify multiple pages with @nb_granules. > However, if multiple cache types are issued in a single invalidation. > They must share a single granularity, not all combinations are valid. > e.g. dev IOTLB does not support domain granularity. Just a reminder, > not an issue. Driver could filter out invalid combinations. Agreed. Even the core could filter out invalid combinations based on the table above: IOTLB and domain granularity are N/A. Thanks, Jean > >> + __u8 cache; >> + __u8 granularity; >> + __u8 padding[2]; >> + union { >> + __u64 pasid; >> + struct iommu_inv_addr_info addr_info; >> + }; >> +}; >> + >> + >> #endif /* _UAPI_IOMMU_H */ > > [Jacob Pan] > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >
Hi Jacob, Jean-Philippe, On 3/20/19 5:50 PM, Jean-Philippe Brucker wrote: > On 20/03/2019 16:37, Jacob Pan wrote: > [...] >>> +struct iommu_inv_addr_info { >>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) >>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) >>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) >>> + __u32 flags; >>> + __u32 archid; >>> + __u64 pasid; >>> + __u64 addr; >>> + __u64 granule_size; >>> + __u64 nb_granules; >>> +}; >>> + >>> +/** >>> + * First level/stage invalidation information >>> + * @cache: bitfield that allows to select which caches to invalidate >>> + * @granularity: defines the lowest granularity used for the >>> invalidation: >>> + * domain > pasid > addr >>> + * >>> + * Not all the combinations of cache/granularity make sense: >>> + * >>> + * type | DEV_IOTLB | IOTLB | PASID | >>> + * granularity | | | >>> cache | >>> + * -------------+---------------+---------------+---------------+ >>> + * DOMAIN | N/A | Y | >>> Y | >>> + * PASID | Y | Y | >>> Y | >>> + * ADDR | Y | Y | >>> N/A | >>> + */ >>> +struct iommu_cache_invalidate_info { >>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 >>> + __u32 version; >>> +/* IOMMU paging structure cache */ >>> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ >>> +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device >>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID >>> cache */ >> Just a clarification, this used to be an enum. You do intend to issue a >> single invalidation request on multiple cache types? Perhaps for >> virtio-IOMMU? I only see a single cache type in your patch #14. For VT-d >> we plan to issue one cache type at a time for now. So this format works >> for us. > > Yes for virtio-iommu I'd like as little overhead as possible, which > means a single invalidation message to hit both IOTLB and ATC at once, > and the ability to specify multiple pages with @nb_granules. The original request/explanation from Jean-Philippe can be found here: https://lkml.org/lkml/2019/1/28/1497 > >> However, if multiple cache types are issued in a single invalidation. >> They must share a single granularity, not all combinations are valid. >> e.g. dev IOTLB does not support domain granularity. Just a reminder, >> not an issue. Driver could filter out invalid combinations. Sure I will add a comment about this restriction. > > Agreed. Even the core could filter out invalid combinations based on the > table above: IOTLB and domain granularity are N/A. I don't get this sentence. What about vtd IOTLB domain-selective invalidation: " • IOTLB entries caching mappings associated with the specified domain-id are invalidated. • Paging-structure-cache entries caching mappings associated with the specified domain-id are invalidated. " Thanks Eric > > Thanks, > Jean > >> >>> + __u8 cache; >>> + __u8 granularity; >>> + __u8 padding[2]; >>> + union { >>> + __u64 pasid; >>> + struct iommu_inv_addr_info addr_info; >>> + }; >>> +}; >>> + >>> + >>> #endif /* _UAPI_IOMMU_H */ >> >> [Jacob Pan] >> _______________________________________________ >> iommu mailing list >> iommu@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu >> >
On 21/03/2019 13:54, Auger Eric wrote: > Hi Jacob, Jean-Philippe, > > On 3/20/19 5:50 PM, Jean-Philippe Brucker wrote: >> On 20/03/2019 16:37, Jacob Pan wrote: >> [...] >>>> +struct iommu_inv_addr_info { >>>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) >>>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) >>>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) >>>> + __u32 flags; >>>> + __u32 archid; >>>> + __u64 pasid; >>>> + __u64 addr; >>>> + __u64 granule_size; >>>> + __u64 nb_granules; >>>> +}; >>>> + >>>> +/** >>>> + * First level/stage invalidation information >>>> + * @cache: bitfield that allows to select which caches to invalidate >>>> + * @granularity: defines the lowest granularity used for the >>>> invalidation: >>>> + * domain > pasid > addr >>>> + * >>>> + * Not all the combinations of cache/granularity make sense: >>>> + * >>>> + * type | DEV_IOTLB | IOTLB | PASID | >>>> + * granularity | | | >>>> cache | >>>> + * -------------+---------------+---------------+---------------+ >>>> + * DOMAIN | N/A | Y | >>>> Y | >>>> + * PASID | Y | Y | >>>> Y | >>>> + * ADDR | Y | Y | >>>> N/A | >>>> + */ >>>> +struct iommu_cache_invalidate_info { >>>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 >>>> + __u32 version; >>>> +/* IOMMU paging structure cache */ >>>> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ >>>> +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device >>>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID >>>> cache */ >>> Just a clarification, this used to be an enum. You do intend to issue a >>> single invalidation request on multiple cache types? Perhaps for >>> virtio-IOMMU? I only see a single cache type in your patch #14. For VT-d >>> we plan to issue one cache type at a time for now. So this format works >>> for us. >> >> Yes for virtio-iommu I'd like as little overhead as possible, which >> means a single invalidation message to hit both IOTLB and ATC at once, >> and the ability to specify multiple pages with @nb_granules. > The original request/explanation from Jean-Philippe can be found here: > https://lkml.org/lkml/2019/1/28/1497 > >> >>> However, if multiple cache types are issued in a single invalidation. >>> They must share a single granularity, not all combinations are valid. >>> e.g. dev IOTLB does not support domain granularity. Just a reminder, >>> not an issue. Driver could filter out invalid combinations. > Sure I will add a comment about this restriction. >> >> Agreed. Even the core could filter out invalid combinations based on the >> table above: IOTLB and domain granularity are N/A. > I don't get this sentence. What about vtd IOTLB domain-selective > invalidation: My mistake: I meant dev-IOTLB and domain granularity are N/A Thanks, Jean > " > • IOTLB entries caching mappings associated with the specified domain-id > are invalidated. > • Paging-structure-cache entries caching mappings associated with the > specified domain-id are invalidated. > " > > Thanks > > Eric > >> >> Thanks, >> Jean >> >>> >>>> + __u8 cache; >>>> + __u8 granularity; >>>> + __u8 padding[2]; >>>> + union { >>>> + __u64 pasid; >>>> + struct iommu_inv_addr_info addr_info; >>>> + }; >>>> +}; >>>> + >>>> + >>>> #endif /* _UAPI_IOMMU_H */ >>> >>> [Jacob Pan] >>> _______________________________________________ >>> iommu mailing list >>> iommu@lists.linux-foundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>> >> > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >
Hi jean, Jacob, On 3/21/19 3:13 PM, Jean-Philippe Brucker wrote: > On 21/03/2019 13:54, Auger Eric wrote: >> Hi Jacob, Jean-Philippe, >> >> On 3/20/19 5:50 PM, Jean-Philippe Brucker wrote: >>> On 20/03/2019 16:37, Jacob Pan wrote: >>> [...] >>>>> +struct iommu_inv_addr_info { >>>>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) >>>>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) >>>>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) >>>>> + __u32 flags; >>>>> + __u32 archid; >>>>> + __u64 pasid; >>>>> + __u64 addr; >>>>> + __u64 granule_size; >>>>> + __u64 nb_granules; >>>>> +}; >>>>> + >>>>> +/** >>>>> + * First level/stage invalidation information >>>>> + * @cache: bitfield that allows to select which caches to invalidate >>>>> + * @granularity: defines the lowest granularity used for the >>>>> invalidation: >>>>> + * domain > pasid > addr >>>>> + * >>>>> + * Not all the combinations of cache/granularity make sense: >>>>> + * >>>>> + * type | DEV_IOTLB | IOTLB | PASID | >>>>> + * granularity | | | >>>>> cache | >>>>> + * -------------+---------------+---------------+---------------+ >>>>> + * DOMAIN | N/A | Y | >>>>> Y | >>>>> + * PASID | Y | Y | >>>>> Y | >>>>> + * ADDR | Y | Y | >>>>> N/A | >>>>> + */ >>>>> +struct iommu_cache_invalidate_info { >>>>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 >>>>> + __u32 version; >>>>> +/* IOMMU paging structure cache */ >>>>> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ >>>>> +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device >>>>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID >>>>> cache */ >>>> Just a clarification, this used to be an enum. You do intend to issue a >>>> single invalidation request on multiple cache types? Perhaps for >>>> virtio-IOMMU? I only see a single cache type in your patch #14. For VT-d >>>> we plan to issue one cache type at a time for now. So this format works >>>> for us. >>> >>> Yes for virtio-iommu I'd like as little overhead as possible, which >>> means a single invalidation message to hit both IOTLB and ATC at once, >>> and the ability to specify multiple pages with @nb_granules. >> The original request/explanation from Jean-Philippe can be found here: >> https://lkml.org/lkml/2019/1/28/1497 >> >>> >>>> However, if multiple cache types are issued in a single invalidation. >>>> They must share a single granularity, not all combinations are valid. >>>> e.g. dev IOTLB does not support domain granularity. Just a reminder, >>>> not an issue. Driver could filter out invalid combinations. >> Sure I will add a comment about this restriction. >>> >>> Agreed. Even the core could filter out invalid combinations based on the >>> table above: IOTLB and domain granularity are N/A. >> I don't get this sentence. What about vtd IOTLB domain-selective >> invalidation: > > My mistake: I meant dev-IOTLB and domain granularity are N/A Ah OK, no worries. How do we proceed further with those user APIs? Besides the comment to be added above and previous suggestion from Jean ("Invalidations by @granularity use field ...), have we reached a consensus now on: - attach/detach_pasid_table - cache_invalidate - fault data and fault report API? If not, please let me know. Thanks Eric > > Thanks, > Jean > >> " >> • IOTLB entries caching mappings associated with the specified domain-id >> are invalidated. >> • Paging-structure-cache entries caching mappings associated with the >> specified domain-id are invalidated. >> " >> >> Thanks >> >> Eric >> >>> >>> Thanks, >>> Jean >>> >>>> >>>>> + __u8 cache; >>>>> + __u8 granularity; >>>>> + __u8 padding[2]; >>>>> + union { >>>>> + __u64 pasid; >>>>> + struct iommu_inv_addr_info addr_info; >>>>> + }; >>>>> +}; >>>>> + >>>>> + >>>>> #endif /* _UAPI_IOMMU_H */ >>>> >>>> [Jacob Pan] >>>> _______________________________________________ >>>> iommu mailing list >>>> iommu@lists.linux-foundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>>> >>> >> _______________________________________________ >> iommu mailing list >> iommu@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu >> >
On Thu, 21 Mar 2019 15:32:45 +0100 Auger Eric <eric.auger@redhat.com> wrote: > Hi jean, Jacob, > > On 3/21/19 3:13 PM, Jean-Philippe Brucker wrote: > > On 21/03/2019 13:54, Auger Eric wrote: > >> Hi Jacob, Jean-Philippe, > >> > >> On 3/20/19 5:50 PM, Jean-Philippe Brucker wrote: > >>> On 20/03/2019 16:37, Jacob Pan wrote: > >>> [...] > >>>>> +struct iommu_inv_addr_info { > >>>>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) > >>>>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) > >>>>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) > >>>>> + __u32 flags; > >>>>> + __u32 archid; > >>>>> + __u64 pasid; > >>>>> + __u64 addr; > >>>>> + __u64 granule_size; > >>>>> + __u64 nb_granules; > >>>>> +}; > >>>>> + > >>>>> +/** > >>>>> + * First level/stage invalidation information > >>>>> + * @cache: bitfield that allows to select which caches to > >>>>> invalidate > >>>>> + * @granularity: defines the lowest granularity used for the > >>>>> invalidation: > >>>>> + * domain > pasid > addr > >>>>> + * > >>>>> + * Not all the combinations of cache/granularity make sense: > >>>>> + * > >>>>> + * type | DEV_IOTLB | IOTLB | > >>>>> PASID | > >>>>> + * granularity | | | > >>>>> cache | > >>>>> + * > >>>>> -------------+---------------+---------------+---------------+ > >>>>> + * DOMAIN | N/A | Y | > >>>>> Y | > >>>>> + * PASID | Y | Y | > >>>>> Y | > >>>>> + * ADDR | Y | Y | > >>>>> N/A | > >>>>> + */ > >>>>> +struct iommu_cache_invalidate_info { > >>>>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 > >>>>> + __u32 version; > >>>>> +/* IOMMU paging structure cache */ > >>>>> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU > >>>>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << > >>>>> 1) /* Device IOTLB */ +#define > >>>>> IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID cache */ > >>>> Just a clarification, this used to be an enum. You do intend to > >>>> issue a single invalidation request on multiple cache types? > >>>> Perhaps for virtio-IOMMU? I only see a single cache type in your > >>>> patch #14. For VT-d we plan to issue one cache type at a time > >>>> for now. So this format works for us. > >>> > >>> Yes for virtio-iommu I'd like as little overhead as possible, > >>> which means a single invalidation message to hit both IOTLB and > >>> ATC at once, and the ability to specify multiple pages with > >>> @nb_granules. > >> The original request/explanation from Jean-Philippe can be found > >> here: https://lkml.org/lkml/2019/1/28/1497 > >> > >>> > >>>> However, if multiple cache types are issued in a single > >>>> invalidation. They must share a single granularity, not all > >>>> combinations are valid. e.g. dev IOTLB does not support domain > >>>> granularity. Just a reminder, not an issue. Driver could filter > >>>> out invalid combinations. > >> Sure I will add a comment about this restriction. > >>> > >>> Agreed. Even the core could filter out invalid combinations based > >>> on the table above: IOTLB and domain granularity are N/A. > >> I don't get this sentence. What about vtd IOTLB domain-selective > >> invalidation: > > > > My mistake: I meant dev-IOTLB and domain granularity are N/A > > Ah OK, no worries. > > How do we proceed further with those user APIs? Besides the comment to > be added above and previous suggestion from Jean ("Invalidations by > @granularity use field ...), have we reached a consensus now on: > > - attach/detach_pasid_table > - cache_invalidate > - fault data and fault report API? > These APIs are sufficient for today's VT-d use and leave enough space for extension. E.g. new fault reasons. I have cherry picked the above APIs from your patchset to enable VT-d nested translation. Going forward, I will reuse these until they get merged. > If not, please let me know. > > Thanks > > Eric > > > > > > Thanks, > > Jean > > > >> " > >> • IOTLB entries caching mappings associated with the specified > >> domain-id are invalidated. > >> • Paging-structure-cache entries caching mappings associated with > >> the specified domain-id are invalidated. > >> " > >> > >> Thanks > >> > >> Eric > >> > >>> > >>> Thanks, > >>> Jean > >>> > >>>> > >>>>> + __u8 cache; > >>>>> + __u8 granularity; > >>>>> + __u8 padding[2]; > >>>>> + union { > >>>>> + __u64 pasid; > >>>>> + struct iommu_inv_addr_info addr_info; > >>>>> + }; > >>>>> +}; > >>>>> + > >>>>> + > >>>>> #endif /* _UAPI_IOMMU_H */ > >>>> > >>>> [Jacob Pan] > >>>> _______________________________________________ > >>>> iommu mailing list > >>>> iommu@lists.linux-foundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu > >>>> > >>> > >> _______________________________________________ > >> iommu mailing list > >> iommu@lists.linux-foundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/iommu > >> > > [Jacob Pan]
Hi Jacob, On 3/21/19 11:10 PM, Jacob Pan wrote: > On Thu, 21 Mar 2019 15:32:45 +0100 > Auger Eric <eric.auger@redhat.com> wrote: > >> Hi jean, Jacob, >> >> On 3/21/19 3:13 PM, Jean-Philippe Brucker wrote: >>> On 21/03/2019 13:54, Auger Eric wrote: >>>> Hi Jacob, Jean-Philippe, >>>> >>>> On 3/20/19 5:50 PM, Jean-Philippe Brucker wrote: >>>>> On 20/03/2019 16:37, Jacob Pan wrote: >>>>> [...] >>>>>>> +struct iommu_inv_addr_info { >>>>>>> +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) >>>>>>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) >>>>>>> +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) >>>>>>> + __u32 flags; >>>>>>> + __u32 archid; >>>>>>> + __u64 pasid; >>>>>>> + __u64 addr; >>>>>>> + __u64 granule_size; >>>>>>> + __u64 nb_granules; >>>>>>> +}; >>>>>>> + >>>>>>> +/** >>>>>>> + * First level/stage invalidation information >>>>>>> + * @cache: bitfield that allows to select which caches to >>>>>>> invalidate >>>>>>> + * @granularity: defines the lowest granularity used for the >>>>>>> invalidation: >>>>>>> + * domain > pasid > addr >>>>>>> + * >>>>>>> + * Not all the combinations of cache/granularity make sense: >>>>>>> + * >>>>>>> + * type | DEV_IOTLB | IOTLB | >>>>>>> PASID | >>>>>>> + * granularity | | | >>>>>>> cache | >>>>>>> + * >>>>>>> -------------+---------------+---------------+---------------+ >>>>>>> + * DOMAIN | N/A | Y | >>>>>>> Y | >>>>>>> + * PASID | Y | Y | >>>>>>> Y | >>>>>>> + * ADDR | Y | Y | >>>>>>> N/A | >>>>>>> + */ >>>>>>> +struct iommu_cache_invalidate_info { >>>>>>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 >>>>>>> + __u32 version; >>>>>>> +/* IOMMU paging structure cache */ >>>>>>> +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU >>>>>>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << >>>>>>> 1) /* Device IOTLB */ +#define >>>>>>> IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID cache */ >>>>>> Just a clarification, this used to be an enum. You do intend to >>>>>> issue a single invalidation request on multiple cache types? >>>>>> Perhaps for virtio-IOMMU? I only see a single cache type in your >>>>>> patch #14. For VT-d we plan to issue one cache type at a time >>>>>> for now. So this format works for us. >>>>> >>>>> Yes for virtio-iommu I'd like as little overhead as possible, >>>>> which means a single invalidation message to hit both IOTLB and >>>>> ATC at once, and the ability to specify multiple pages with >>>>> @nb_granules. >>>> The original request/explanation from Jean-Philippe can be found >>>> here: https://lkml.org/lkml/2019/1/28/1497 >>>> >>>>> >>>>>> However, if multiple cache types are issued in a single >>>>>> invalidation. They must share a single granularity, not all >>>>>> combinations are valid. e.g. dev IOTLB does not support domain >>>>>> granularity. Just a reminder, not an issue. Driver could filter >>>>>> out invalid combinations. >>>> Sure I will add a comment about this restriction. >>>>> >>>>> Agreed. Even the core could filter out invalid combinations based >>>>> on the table above: IOTLB and domain granularity are N/A. >>>> I don't get this sentence. What about vtd IOTLB domain-selective >>>> invalidation: >>> >>> My mistake: I meant dev-IOTLB and domain granularity are N/A >> >> Ah OK, no worries. >> >> How do we proceed further with those user APIs? Besides the comment to >> be added above and previous suggestion from Jean ("Invalidations by >> @granularity use field ...), have we reached a consensus now on: >> >> - attach/detach_pasid_table >> - cache_invalidate >> - fault data and fault report API? >> > These APIs are sufficient for today's VT-d use and leave enough space > for extension. E.g. new fault reasons. > > I have cherry picked the above APIs from your patchset to enable VT-d > nested translation. Going forward, I will reuse these until they get > merged. OK thanks! Eric > >> If not, please let me know. >> >> Thanks >> >> Eric >> >> >>> >>> Thanks, >>> Jean >>> >>>> " >>>> • IOTLB entries caching mappings associated with the specified >>>> domain-id are invalidated. >>>> • Paging-structure-cache entries caching mappings associated with >>>> the specified domain-id are invalidated. >>>> " >>>> >>>> Thanks >>>> >>>> Eric >>>> >>>>> >>>>> Thanks, >>>>> Jean >>>>> >>>>>> >>>>>>> + __u8 cache; >>>>>>> + __u8 granularity; >>>>>>> + __u8 padding[2]; >>>>>>> + union { >>>>>>> + __u64 pasid; >>>>>>> + struct iommu_inv_addr_info addr_info; >>>>>>> + }; >>>>>>> +}; >>>>>>> + >>>>>>> + >>>>>>> #endif /* _UAPI_IOMMU_H */ >>>>>> >>>>>> [Jacob Pan] >>>>>> _______________________________________________ >>>>>> iommu mailing list >>>>>> iommu@lists.linux-foundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>>>>> >>>>> >>>> _______________________________________________ >>>> iommu mailing list >>>> iommu@lists.linux-foundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu >>>> >>> > > [Jacob Pan] >
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 7d9285cea100..b72e326ddd41 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -1544,6 +1544,20 @@ void iommu_detach_pasid_table(struct iommu_domain *domain) } EXPORT_SYMBOL_GPL(iommu_detach_pasid_table); +int iommu_cache_invalidate(struct iommu_domain *domain, struct device *dev, + struct iommu_cache_invalidate_info *inv_info) +{ + int ret = 0; + + if (unlikely(!domain->ops->cache_invalidate)) + return -ENODEV; + + ret = domain->ops->cache_invalidate(domain, dev, inv_info); + + return ret; +} +EXPORT_SYMBOL_GPL(iommu_cache_invalidate); + static void __iommu_detach_device(struct iommu_domain *domain, struct device *dev) { diff --git a/include/linux/iommu.h b/include/linux/iommu.h index fb9b7a8de25f..7c7c6bad1420 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -191,6 +191,7 @@ struct iommu_resv_region { * driver init to device driver init (default no) * @attach_pasid_table: attach a pasid table * @detach_pasid_table: detach the pasid table + * @cache_invalidate: invalidate translation caches * @pgsize_bitmap: bitmap of all possible supported page sizes */ struct iommu_ops { @@ -239,6 +240,9 @@ struct iommu_ops { struct iommu_pasid_table_config *cfg); void (*detach_pasid_table)(struct iommu_domain *domain); + int (*cache_invalidate)(struct iommu_domain *domain, struct device *dev, + struct iommu_cache_invalidate_info *inv_info); + unsigned long pgsize_bitmap; }; @@ -349,6 +353,9 @@ extern void iommu_detach_device(struct iommu_domain *domain, extern int iommu_attach_pasid_table(struct iommu_domain *domain, struct iommu_pasid_table_config *cfg); extern void iommu_detach_pasid_table(struct iommu_domain *domain); +extern int iommu_cache_invalidate(struct iommu_domain *domain, + struct device *dev, + struct iommu_cache_invalidate_info *inv_info); extern struct iommu_domain *iommu_get_domain_for_dev(struct device *dev); extern struct iommu_domain *iommu_get_dma_domain(struct device *dev); extern int iommu_map(struct iommu_domain *domain, unsigned long iova, @@ -797,6 +804,14 @@ int iommu_attach_pasid_table(struct iommu_domain *domain, static inline void iommu_detach_pasid_table(struct iommu_domain *domain) {} +static inline int +iommu_cache_invalidate(struct iommu_domain *domain, + struct device *dev, + struct iommu_cache_invalidate_info *inv_info) +{ + return -ENODEV; +} + #endif /* CONFIG_IOMMU_API */ #ifdef CONFIG_IOMMU_DEBUGFS diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h index 532a64075f23..e4c6a447e85a 100644 --- a/include/uapi/linux/iommu.h +++ b/include/uapi/linux/iommu.h @@ -159,4 +159,75 @@ struct iommu_pasid_table_config { }; }; +/* defines the granularity of the invalidation */ +enum iommu_inv_granularity { + IOMMU_INV_GRANU_DOMAIN, /* domain-selective invalidation */ + IOMMU_INV_GRANU_PASID, /* pasid-selective invalidation */ + IOMMU_INV_GRANU_ADDR, /* page-selective invalidation */ +}; + +/** + * Address Selective Invalidation Structure + * + * @flags indicates the granularity of the address-selective invalidation + * - if PASID bit is set, @pasid field is populated and the invalidation + * relates to cache entries tagged with this PASID and matching the + * address range. + * - if ARCHID bit is set, @archid is populated and the invalidation relates + * to cache entries tagged with this architecture specific id and matching + * the address range. + * - Both PASID and ARCHID can be set as they may tag different caches. + * - if neither PASID or ARCHID is set, global addr invalidation applies + * - LEAF flag indicates whether only the leaf PTE caching needs to be + * invalidated and other paging structure caches can be preserved. + * @pasid: process address space id + * @archid: architecture-specific id + * @addr: first stage/level input address + * @granule_size: page/block size of the mapping in bytes + * @nb_granules: number of contiguous granules to be invalidated + */ +struct iommu_inv_addr_info { +#define IOMMU_INV_ADDR_FLAGS_PASID (1 << 0) +#define IOMMU_INV_ADDR_FLAGS_ARCHID (1 << 1) +#define IOMMU_INV_ADDR_FLAGS_LEAF (1 << 2) + __u32 flags; + __u32 archid; + __u64 pasid; + __u64 addr; + __u64 granule_size; + __u64 nb_granules; +}; + +/** + * First level/stage invalidation information + * @cache: bitfield that allows to select which caches to invalidate + * @granularity: defines the lowest granularity used for the invalidation: + * domain > pasid > addr + * + * Not all the combinations of cache/granularity make sense: + * + * type | DEV_IOTLB | IOTLB | PASID | + * granularity | | | cache | + * -------------+---------------+---------------+---------------+ + * DOMAIN | N/A | Y | Y | + * PASID | Y | Y | Y | + * ADDR | Y | Y | N/A | + */ +struct iommu_cache_invalidate_info { +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1 + __u32 version; +/* IOMMU paging structure cache */ +#define IOMMU_CACHE_INV_TYPE_IOTLB (1 << 0) /* IOMMU IOTLB */ +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB (1 << 1) /* Device IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID (1 << 2) /* PASID cache */ + __u8 cache; + __u8 granularity; + __u8 padding[2]; + union { + __u64 pasid; + struct iommu_inv_addr_info addr_info; + }; +}; + + #endif /* _UAPI_IOMMU_H */