Re: [PATCH 08/18] iommu: Introduce cache_invalidate API
On Wed, Apr 10, 2019 at 02:21:31PM -0700, Jacob Pan wrote:
> On Tue, 9 Apr 2019 20:37:55 +0300
> Andriy Shevchenko wrote:
> > On Tue, Apr 09, 2019 at 09:43:28AM -0700, Jacob Pan wrote:
> > > On Tue, 9 Apr 2019 13:07:18 +0300
> > > Andriy Shevchenko wrote:
> > > > On Mon, Apr 08, 2019 at 04:59:23PM -0700, Jacob Pan wrote:
> >
> > > > > +int iommu_cache_invalidate(struct iommu_domain *domain, struct
> > > > > device *dev,
> > > > > +struct iommu_cache_invalidate_info
> > > > > *inv_info) +{
> > > > > + int ret = 0;
> > > >
> > > > Redundant assignment.
> > > >
> > > I am not a security expert but initialization of local variable can
> > > be more secure.
> > > I was looking at this talk.
> > > https://outflux.net/slides/2018/lss/danger.pdf
> > > https://cwe.mitre.org/data/definitions/457.html
> >
> > I hardly see any of these applied to your case here.
> > Care to show what I'm missing?
> >
> I thought your comments was that I should not need to initialize local
> variable ret = 0.
Correct.
> Always initialize local variable can be a good
> security practice as suggested in the paper. Perhaps I missed
> something :)
Paper suggested to do that in a sense to avoid use of uninitialized variable.
This is not your case (usually it's not the case for variable which contains
return code), so, assignment is redundant. Moreover, default assignment can
hide an actual warning and an issue. Security people are not always correct.
> > > > > + if (unlikely(!domain->ops->cache_invalidate))
> > > > > + return -ENODEV;
> > > > > +
> > > > > + ret = domain->ops->cache_invalidate(domain, dev,
> > > > > inv_info); +
> > > > > + return ret;
> > > > > +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 08/18] iommu: Introduce cache_invalidate API
On Tue, Apr 09, 2019 at 09:43:28AM -0700, Jacob Pan wrote:
> On Tue, 9 Apr 2019 13:07:18 +0300
> Andriy Shevchenko wrote:
> > On Mon, Apr 08, 2019 at 04:59:23PM -0700, Jacob Pan wrote:
> > > +int iommu_cache_invalidate(struct iommu_domain *domain, struct
> > > device *dev,
> > > +struct iommu_cache_invalidate_info
> > > *inv_info) +{
> > > + int ret = 0;
> >
> > Redundant assignment.
> >
> I am not a security expert but initialization of local variable can be
> more secure.
> I was looking at this talk.
> https://outflux.net/slides/2018/lss/danger.pdf
> https://cwe.mitre.org/data/definitions/457.html
I hardly see any of these applied to your case here.
Care to show what I'm missing?
> > > + if (unlikely(!domain->ops->cache_invalidate))
> > > + return -ENODEV;
> > > +
> > > + ret = domain->ops->cache_invalidate(domain, dev, inv_info);
> > > +
> > > + return ret;
> > > +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/18] drivers core: Add I/O ASID allocator
On Tue, Apr 09, 2019 at 07:53:08AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 09, 2019 at 01:30:30PM +0300, Andriy Shevchenko wrote:
> > On Tue, Apr 09, 2019 at 03:04:36AM -0700, Christoph Hellwig wrote:
> > > On Tue, Apr 09, 2019 at 01:00:49PM +0300, Andriy Shevchenko wrote:
> > > > I think it makes sense to add a helper macro to rcupdate.h
> > > > (and we have several cases in kernel that can utilize it)
> > > >
> > > > #define kfree_non_null_rcu(ptr, rcu_head) \
> > > > do {\
> > > > if (ptr)\
> > > > kfree_rcu(ptr, rcu_head); \
> > > > } while (0)
> > > >
> > > > as a more common pattern for resource deallocators.
> > >
> > > I think that should move straight into kfree_rcu.
> >
> > Possible. I didn't dare to offer this due to lack of knowledge how it's
> > used in
> > other places.
> >
> > > In general
> > > we expect *free* to deal with NULL pointers transparently, so we
> > > should do so here as well.
> >
> > Exactly my point, thanks.
>
> As shown below?
Looks pretty much good to me, thanks!
Reviewed-by: Andriy Shevchenko
>
> And now that you mention it, it is a bit surprising that no one has
> complained before. ;-)
>
> Thanx, Paul
>
>
>
> commit 23ad938244968e9d2a8001a1c52887c113b182f6
> Author: Paul E. McKenney
> Date: Tue Apr 9 07:48:18 2019 -0700
>
> rcu: Make kfree_rcu() ignore NULL pointers
>
> This commit makes the kfree_rcu() macro's semantics be consistent
> with the likes of kfree() by adding a check for NULL pointers, so
> that kfree_rcu(NULL, ...) is a no-op.
>
> Reported-by: Andriy Shevchenko
> Reported-by: Christoph Hellwig
> Signed-off-by: Paul E. McKenney
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 922bb6848813..c68649b9bcec 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -828,9 +828,13 @@ static inline notrace void
> rcu_read_unlock_sched_notrace(void)
> * The BUILD_BUG_ON check must not involve any function calls, hence the
> * checks are done in macros here.
> */
> -#define kfree_rcu(ptr, rcu_head) \
> - __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
> -
> +#define kfree_rcu(ptr, rhf) \
> +do { \
> + typeof (ptr) ___p = (ptr); \
> + \
> + if (___p) \
> + __kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
> +} while (0)
>
> /*
> * Place this after a lock-acquisition primitive to guarantee that
>
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 18/18] iommu/vt-d: Add svm/sva invalidate function
On Mon, Apr 08, 2019 at 04:59:33PM -0700, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared virtual address.
>
> The use case is for supporting caching structure invalidation
> of assigned SVM capable devices. Emulated IOMMU exposes queue
> invalidation capability and passes down all descriptors from the guest
> to the physical IOMMU.
>
> The assumption is that guest to host device ID mapping should be
> resolved prior to calling IOMMU driver. Based on the device handle,
> host IOMMU driver can replace certain fields before submit to the
> invalidation queue.
> +static int intel_iommu_sva_invalidate(struct iommu_domain *domain,
> + struct device *dev, struct iommu_cache_invalidate_info
> *inv_info)
> +{
> + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> + struct device_domain_info *info;
> + struct intel_iommu *iommu;
> + unsigned long flags;
> + int cache_type;
> + u8 bus, devfn;
> + u16 did, sid;
> + int ret = 0;
> + u64 granu;
> + u64 size;
> +
> + if (!inv_info || !dmar_domain ||
> + inv_info->version != IOMMU_CACHE_INVALIDATE_INFO_VERSION_1)
> + return -EINVAL;
> +
> + iommu = device_to_iommu(dev, , );
> + if (!iommu)
> + return -ENODEV;
> +
> + if (!dev || !dev_is_pci(dev))
> + return -ENODEV;
How dev is used in above call? Can be dev NULL there optional and give non-NULL
iommu?
> + switch (1 << cache_type) {
BIT() ?
> + case IOMMU_CACHE_INV_TYPE_IOTLB:
> + if (size && (inv_info->addr_info.addr & ((1 <<
> (VTD_PAGE_SHIFT + size)) - 1))) {
BIT() ?
> + pr_err("Address out of range, 0x%llx, size
> order %llu\n",
> + inv_info->addr_info.addr, size);
> + ret = -ERANGE;
> + goto out_unlock;
> + }
> +
> + qi_flush_piotlb(iommu, did,
> mm_to_dma_pfn(inv_info->addr_info.addr),
> + inv_info->addr_info.pasid,
> + size, granu);
> +
> + /*
> + * Always flush device IOTLB if ATS is enabled since
> guest
> + * vIOMMU exposes CM = 1, no device IOTLB flush will be
> passed
> + * down. REVISIT: cannot assume Linux guest
> + */
> + if (info->ats_enabled) {
> + qi_flush_dev_piotlb(iommu, sid, info->pfsid,
> + inv_info->addr_info.pasid,
> info->ats_qdep,
> + inv_info->addr_info.addr, size,
> + granu);
> + }
> + break;
> + case IOMMU_CACHE_INV_TYPE_DEV_IOTLB:
> + if (info->ats_enabled) {
> + qi_flush_dev_piotlb(iommu, sid, info->pfsid,
> + inv_info->addr_info.pasid,
> info->ats_qdep,
> + inv_info->addr_info.addr, size,
> + granu);
> + } else
> + pr_warn("Passdown device IOTLB flush w/o
> ATS!\n");
> +
> + break;
> + case IOMMU_CACHE_INV_TYPE_PASID:
> + qi_flush_pasid_cache(iommu, did, granu,
> inv_info->pasid);
> +
> + break;
> + default:
> + dev_err(dev, "Unsupported IOMMU invalidation type %d\n",
> + cache_type);
> + ret = -EINVAL;
> + }
> +out_unlock:
> + spin_unlock(>lock);
> + spin_unlock_irqrestore(_domain_lock, flags);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 15/18] iommu/vt-d: Add bind guest PASID support
On Mon, Apr 08, 2019 at 04:59:30PM -0700, Jacob Pan wrote:
> When supporting guest SVA with emulated IOMMU, the guest PASID
> table is shadowed in VMM. Updates to guest vIOMMU PASID table
> will result in PASID cache flush which will be passed down to
> the host as bind guest PASID calls.
>
> For the SL page tables, it will be harvested from device's
> default domain (request w/o PASID), or aux domain in case of
> mediated device.
>
> .-. .---.
> | vIOMMU| | Guest process CR3, FL only|
> | | '---'
> ./
> | PASID Entry |--- PASID cache flush -
> '-' |
> | | V
> | |CR3 in GPA
> '-'
> Guest
> --| Shadow |--|
> vv v
> Host
> .-. .--.
> | pIOMMU| | Bind FL for GVA-GPA |
> | | '--'
> ./ |
> | PASID Entry | V (Nested xlate)
> '\.--.
> | | |SL for GPA-HPA, default domain|
> | | '--'
> '-'
> Where:
> - FL = First level/stage one page tables
> - SL = Second level/stage two page tables
> + list_for_each_entry(sdev, >devs, list) {
> + if (dev == sdev->dev) {
...
> + }
> + }
This pattern occurs at least twice, perhaps something like
#define for_each_svm_dev() \
list_for_each_entry() \
if (dev != sdev->dev) {} else
?
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 16/18] iommu: add max num of cache and granu types
On Mon, Apr 08, 2019 at 04:59:31PM -0700, Jacob Pan wrote:
Commit message?
> Signed-off-by: Jacob Pan
> ---
> include/uapi/linux/iommu.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> index 9344cbb..59569d6 100644
> --- a/include/uapi/linux/iommu.h
> +++ b/include/uapi/linux/iommu.h
> @@ -197,6 +197,7 @@ struct iommu_inv_addr_info {
> __u64 granule_size;
> __u64 nb_granules;
> };
> +#define NR_IOMMU_CACHE_INVAL_GRANU (3)
>
> /**
> * First level/stage invalidation information
> @@ -228,6 +229,7 @@ struct iommu_cache_invalidate_info {
> struct iommu_inv_addr_info addr_info;
> };
> };
> +#define NR_IOMMU_CACHE_TYPE (3)
+ blank line?
> /**
> * struct gpasid_bind_data - Information about device and guest PASID binding
> * @gcr3:Guest CR3 value from guest mm
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/18] drivers core: Add I/O ASID allocator
On Tue, Apr 09, 2019 at 03:04:36AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 09, 2019 at 01:00:49PM +0300, Andriy Shevchenko wrote:
> > I think it makes sense to add a helper macro to rcupdate.h
> > (and we have several cases in kernel that can utilize it)
> >
> > #define kfree_non_null_rcu(ptr, rcu_head) \
> > do {\
> > if (ptr)\
> > kfree_rcu(ptr, rcu_head); \
> > } while (0)
> >
> > as a more common pattern for resource deallocators.
>
> I think that should move straight into kfree_rcu.
Possible. I didn't dare to offer this due to lack of knowledge how it's used in
other places.
> In general
> we expect *free* to deal with NULL pointers transparently, so we
> should do so here as well.
Exactly my point, thanks.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 09/18] iommu/vt-d: Enlightened PASID allocation
On Mon, Apr 08, 2019 at 04:59:24PM -0700, Jacob Pan wrote:
> From: Lu Baolu
>
> If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
> IOMMU driver should rely on the emulation software to allocate
> and free PASID IDs. The Intel vt-d spec revision 3.0 defines a
> register set to support this. This includes a capability register,
> a virtual command register and a virtual response register. Refer
> to section 10.4.42, 10.4.43, 10.4.44 for more information.
>
> This patch adds the enlightened PASID allocation/free interfaces
> via the virtual command register.
> + pr_debug("vcmd alloc pasid\n");
Perhaps tracepoints should be in use?
OTOH we have function tracer, so, this message in any case is a noise.
And this is applicable to other similar cases.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 08/18] iommu: Introduce cache_invalidate API
On Mon, Apr 08, 2019 at 04:59:23PM -0700, Jacob Pan wrote:
> From: "Liu, Yi L"
>
> 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.
> +int iommu_cache_invalidate(struct iommu_domain *domain, struct device *dev,
> +struct iommu_cache_invalidate_info *inv_info)
> +{
> + int ret = 0;
Redundant assignment.
> +
> + if (unlikely(!domain->ops->cache_invalidate))
> + return -ENODEV;
> +
> + ret = domain->ops->cache_invalidate(domain, dev, inv_info);
> +
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 05/18] iommu: introduce device fault data
On Mon, Apr 08, 2019 at 04:59:20PM -0700, Jacob Pan wrote: > Device faults detected by IOMMU can be reported outside the IOMMU > subsystem for further processing. This patch introduces > a generic device fault data structure. > > The fault can be either an unrecoverable fault or a page request, > also referred to as a recoverable fault. > > We only care about non internal faults that are likely to be reported > to an external subsystem. > > Signed-off-by: Jacob Pan > Signed-off-by: Jean-Philippe Brucker > Signed-off-by: Liu, Yi L > Signed-off-by: Ashok Raj > Signed-off-by: Eric Auger JFYI: we have a Co-developed-by tag as well for better granularity of what certain person/people did. -- With Best Regards, Andy Shevchenko ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/18] drivers core: Add I/O ASID allocator
On Mon, Apr 08, 2019 at 04:59:16PM -0700, Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space ID)
> allows to share process address spaces with devices (SVA), partition a
> device into VM-assignable entities (VFIO mdev) or simply provide
> multiple DMA address space to kernel drivers. Add a global PASID
> allocator usable by different drivers at the same time. Name it I/O ASID
> to avoid confusion with ASIDs allocated by arch code, which are usually
> a separate ID space.
>
> The IOASID space is global. Each device can have its own PASID space,
> but by convention the IOMMU ended up having a global PASID space, so
> that with SVA, each mm_struct is associated to a single PASID.
>
> The allocator doesn't really belong in drivers/iommu because some
> drivers would like to allocate PASIDs for devices that aren't managed by
> an IOMMU, using the same ID space as IOMMU. It doesn't really belong in
> drivers/pci either since platform device also support PASID. Add the
> allocator in drivers/base.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/base/Kconfig | 7
> drivers/base/Makefile | 1 +
> drivers/base/ioasid.c | 106
> +
> include/linux/ioasid.h | 40 +++
> 4 files changed, 154 insertions(+)
> create mode 100644 drivers/base/ioasid.c
> create mode 100644 include/linux/ioasid.h
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 059700e..e05288d 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -182,6 +182,13 @@ config DMA_SHARED_BUFFER
> APIs extension; the file's descriptor can then be passed on to other
> driver.
>
> +config IOASID
> + bool
> + default n
Redundant.
> + help
> + Enable the I/O Address Space ID allocator. A single ID space shared
> + between different users.
> +/**
> + * ioasid_free - Free an IOASID
> + * @ioasid: the ID to remove
> + */
> +void ioasid_free(ioasid_t ioasid)
> +{
> + struct ioasid_data *ioasid_data;
> +
> + idr_lock(_idr);
> + ioasid_data = idr_remove(_idr, ioasid);
> + idr_unlock(_idr);
> +
> + if (ioasid_data)
> + kfree_rcu(ioasid_data, rcu);
I think it makes sense to add a helper macro to rcupdate.h
(and we have several cases in kernel that can utilize it)
#define kfree_non_null_rcu(ptr, rcu_head) \
do {\
if (ptr)\
kfree_rcu(ptr, rcu_head); \
} while (0)
as a more common pattern for resource deallocators.
> +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/18] Shared virtual address IOMMU and VT-d support
On Mon, Apr 08, 2019 at 04:59:15PM -0700, Jacob Pan wrote: > Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel > platforms allow address space sharing between device DMA and applications. > SVA can reduce programming complexity and enhance security. > This series is intended to enable SVA virtualization, i.e. shared guest > application address space and physical device DMA address. Only IOMMU portion > of the changes are included in this series. Additional support is needed in > VFIO and QEMU (will be submitted separately) to complete this functionality. > > To make incremental changes and reduce the size of each patchset. This series > does not inlcude support for page request services. > > In VT-d implementation, PASID table is per device and maintained in the host. > Guest PASID table is shadowed in VMM where virtual IOMMU is emulated. This seems missed the comments I gave you internally. > > .-. .---. > | vIOMMU| | Guest process CR3, FL only| > | | '---' > ./ > | PASID Entry |--- PASID cache flush - > '-' | > | | V > | |CR3 in GPA > '-' > Guest > --| Shadow |--| > vv v > Host > .-. .--. > | pIOMMU| | Bind FL for GVA-GPA | > | | '--' > ./ | > | PASID Entry | V (Nested xlate) > '\.--. > | | |SL for GPA-HPA, default domain| > | | '--' > '-' > Where: > - FL = First level/stage one page tables > - SL = Second level/stage two page tables > > > This work is based on collaboration with other developers on the IOMMU > mailing list. Notably, > > [1] [PATCH v6 00/22] SMMUv3 Nested Stage Setup by Eric Auger > https://lkml.org/lkml/2019/3/17/124 > > [2] [RFC PATCH 2/6] drivers core: Add I/O ASID allocator by Jean-Philippe > Brucker > https://www.spinics.net/lists/iommu/msg30639.html > > [3] [RFC PATCH 0/5] iommu: APIs for paravirtual PASID allocation by Lu Baolu > https://lkml.org/lkml/2018/11/12/1921 > > There are roughly three parts: > 1. Generic PASID allocator [1] with extension to support custom allocator > 2. IOMMU cache invalidation passdown from guest to host > 3. Guest PASID bind for nested translation > > All generic IOMMU APIs are reused from [1], which has a v7 just published with > no real impact to the patches used here. It is worth noting that unlike sMMU > nested stage setup, where PASID table is owned by the guest, VT-d PASID table > is > owned by the host, individual PASIDs are bound instead of the PASID table. > > > Jacob Pan (15): > ioasid: Add custom IOASID allocator > ioasid: Convert ioasid_idr to XArray > driver core: add per device iommu param > iommu: introduce device fault data > iommu: introduce device fault report API > iommu: Introduce attach/detach_pasid_table API > iommu/vt-d: Add custom allocator for IOASID > iommu/vt-d: Replace Intel specific PASID allocator with IOASID > iommu: Add guest PASID bind function > iommu/vt-d: Move domain helper to header > iommu/vt-d: Add nested translation support > iommu/vt-d: Add bind guest PASID support > iommu: add max num of cache and granu types > iommu/vt-d: Support flushing more translation cache types > iommu/vt-d: Add svm/sva invalidate function > > Jean-Philippe Brucker (1): > drivers core: Add I/O ASID allocator > > Liu, Yi L (1): > iommu: Introduce cache_invalidate API > > Lu Baolu (1): > iommu/vt-d: Enlightened PASID allocation > > drivers/base/Kconfig| 7 ++ > drivers/base/Makefile | 1 + > drivers/base/ioasid.c | 211 + > drivers/iommu/Kconfig | 1 + > drivers/iommu/dmar.c| 48 + > drivers/iommu/intel-iommu.c | 219 -- > drivers/iommu/intel-pasid.c | 191 +- > drivers/iommu/intel-pasid.h | 24 - > drivers/iommu/intel-svm.c | 217 +++--- > drivers/iommu/iommu.c | 207 +++- > include/linux/device.h | 3 + > include/linux/intel-iommu.h | 40 +-- > include/linux/intel-svm.h | 7 ++ > include/linux/ioasid.h | 66 > include/linux/iommu.h | 127 +++ > include/uapi/linux/iommu.h | 248 > > 16 files changed, 1559 insertions(+), 58 deletions(-) > create mode 100644 drivers/base/ioasid.c > create mode 100644 include/linux/ioasid.h > create mode 100644 include/uapi/linux/iommu.h > >
