iommu_trigger_fault now accepts a flags argument which can be handled by
the individual IOMMU drivers. Take the value written to the debugfs
file by the user and pass it as the flags value.
Change-Id: I803e6585aea35fbb0f6e03e4279587b36a7bad92
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
IOMMU drivers might want more control over the types of faults being
triggered with iommu_trigger_fault. Add a flags parameter that can be
used to provide more control over the types of faults that can be
triggered.
Change-Id: I2f21b383437430e957ab52070d3575e8cb3dee90
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
A client fault handler flag was recently introduced to indicate external
faults. Use it.
Change-Id: Ib9ea59befc3c8324de4fc94a0dbe4acafaa6f9b8
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some IOMMUs (like the ARM SMMU) can raise "external faults" in addition
to translation and permission faults. Add an IOMMU fault flag so that
this fault type can be propagated to client fault handlers.
Change-Id: Ia476ed6c727f5f01011747f30b3a74ebf0fc07f7
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Simultaneous assign or unassign on the same domain during map and unmap
operations manipulate the same pte_info lists and thus can ask hypervisor
to assign the same pte address twice which results in double mapping error.
The lists(pte_info_list and unassign_list) needs to be locked before
traversing it for making the assign/unassign calls.
Change-Id: Iebe3d703d80918af4ab18208f4b5a010c4c14791
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
When unmapping 2MB mappings, which are 2MB aligned, the smmu driver
is leaking the 3rd level page tables.
Fix this leak by updating __arm_lpae_free_pgtable so that it no
longer leaks leaf table entries.
To reproduce this leak simply map and unmap a non-block 2MB mapping
which is 2MB aligned.
Change-Id: Ibdbdb084ceb8d03ebe0a04e8777e3eb9419e9b87
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Currently, the page table is flushed after the installation of each
individual page table entry. This is not terribly efficient since
virtual address ranges are often mapped with physically contiguous
chunks of page table memory. Optimize the map operation by factoring
out the page table flushing so that contiguous ranges of page table
memory can be flushed in one go.
Change-Id: Ie80eb57ef50d253db6489a6f75824d4c746314c7
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
TTBR1 shouldn't currently be used at all. Any such usage is the result
of a bug. Configure TCR such that any usage of TTBR1 will generate a
fault, which will help catch such bugs earlier.
Change-Id: I74f2dc9580e5aed5d391debe23c7f5cc9fc1f672
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
MSM iommu devices' DT bindings defer from upstream
way. And hence, the debug driver doesn't support
to profile MSM iommu devices. Add that support.
Change-Id: I507d500785408b1d96f017648475933ee408b664
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
When a domain is attached for the first time, memory for its top level
of page tables is allocated. If it's a secure domain, this memory needs
to be assigned to a secure VMID. Currently, it's not being assigned to
a secure VMID, so when the domain is torn down and unassigned we get a
warning. Fix this by adding the missing assign call after initial
domain allocation.
Change-Id: I9ff2418749e768e17b4598f5f89e587ad7828d52
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, arm_smmu_unprepare_pgtable makes a hypervisor call to
unassign the memory being freed up. However, this is a sleeping call
and arm_smmu_unprepare_pgtable can be called from atomic context. Fix
this by making arm_smmu_unprepare_pgtable atomic in a similar manner to
arm_smmu_prepare_pgtable (put the addresses to be unprepared on a list
and unprepare them at the end of unmap).
Change-Id: Ifba40ca3ceb4aaf328a1a570e0ee6c39088075ba
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some IOMMU drivers (like arm-smmu) need to perform fixups to page table
memory when it's allocated and freed. Some callbacks were added for
this purpose ({prepare,unprepare}_pgtable) that are called from the
io-pgtable code after each allocation and before each free. However,
this approach is prone to bugs where new calls to allocate/free are
added without corresponding calls to the fixup callbacks. Furthermore,
allocation and free is often done from atomic context, so if the driver
needs to do non-atomic fixups during free they are out of luck since the
memory will be freed back to the system by the time control is turned
back over to the driver.
Adding yet another callback for non-atomic fixups would start to get
tedious, and would only increase the chance of missing callbacks as new
allocations/frees are added. Instead, fix this by allowing all page
table memory allocation and free to be delegated entirely to the driver.
Fall back to {alloc,free}_pages_exact by default if the driver doesn't
need any special handling of page table memory.
Change-Id: I0361bb81e25ff5ad4ef93a45330a35af47bc6013
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, arm_lpae_split_blk_unmap is assuming that the size to be
remapped is the block size of the next level. However, optimizations
have been made to the unmap code that result in the entire remaining
size being passed in, rather than just doing it one block at a time,
which breaks arm_lpae_split_blk_unmap.
Fix this by overriding the size passed in to be the block size of the
next level.
Change-Id: Ifce5b2e07dc15aba3cd37b7ac249e00decd2923f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful to perform tests on secure domains. Add support for
this with a "secure_attach" file that will also set the
DOMAIN_ATTR_SECURE_VMID to the value written to the file.
Example usage:
# cd /sys/kernel/debug/iommu/tests/<device>
# echo 0xA > secure_attach
# echo 0x1000,0x1000,0x1000,1 > map
# echo 0x1000,0x1000 > unmap
# echo 0 > secure_attach
Change-Id: I0181e360f3e98e0e47a3af8c6adb71c9c4a3c9b5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful to know a domain's secure VMID value. Add this
information to the attach info debugfs file.
Change-Id: Ic8a73000b8337639f95376b13ef58a0e2a089dde
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful to query a previously set secure VMID. Add a domain
attribute getter for this.
Change-Id: Iaf14201d321161ce4ccc69b674a3b1247d6a7e94
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
When memory that is assigned a particular VMID is re-assigned
back to HLOS, it needs to get RWX permissions so that HLOS can
use it for data as well as instructions.
Change-Id: Ib5413861de877d9081bdf5bd397f528293deb6e8
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
The unmap debugfs file write handler is currently incorrectly parsing
the size to be unmapped (storing the IOVA as the size). Fix this by
parsing from the correct offset (just after the first comma).
Change-Id: I438851882052acc511c713706bc4f0cbf373353e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, when all of the 4K PTEs beneath a 2M table entry are
unmapped, that 2M table entry is left intact, even though it doesn't
point to any valid 4K mappings anymore. This results in a warning if a
subsequent block mapping lands on top of the dangling table entry, since
we require empty page table entries when we map. It also causes the
page at which that the stomped-on table was pointing to be leaked. Fix
this by keeping track of how many entries are currently mapped beneath a
table. When the map count goes to zero (in unmap), free up the page the
table is pointing at and zero out the table entry.
Change-Id: I470e6ffb2206a09fe7c24253e3fd64a744337a7f
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful for debugging to know how much memory is being used for
IOMMU page tables. Add some dedicated allocation functions and a
debugfs file for this.
Change-Id: Id69b4b1b5df5dcc6c604eec3a12a894b8eab0eb6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we're creating an "iommu" debugfs directory from the
iommu-debug code. Other IOMMU modules might want to make use of this
same directory, so create it from the IOMMU framework code itself.
Change-Id: I679fdfc34ba5fcbd927dc5981438c6fabcfa3639
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Implement support for dynamic domain switching. This feature is
only enabled when the qcom,dynamic device tree attribute for an smmu
instance.
In order to use dynamic domains, a non-dynamic domain must first
be created and attached. This non-dynamic domain must remain
attached while the device is in use.
All domains must be attached before calling any mapping functions, such as
iommu_map(). This allows the pagetable setup to be set up during attach
based on the hardware configuration for the smmu.
Before attaching a dynamic domain, the DOMAIN_ATTR_CONTEXT_BANK must be
set to indicate which context bank registers should be used for
any register programming. Attaching dynamic domain doesn't cause
hardware register programming, but mapping operations may cause
TLBI operations. Additionally, the upstream driver or hardware may
do other register programming.
Because the arm-smmu driver assigns context banks dynamically, the
upstream driver should query DOMAIN_ATTR_CONTEXT_BANK on its non-dynamic
domain, to ensure the correct value is used for all dynamic domains
created.
To switch domains dynamically, the upstream driver or hardware
must program the TTBR0 and CONTEXTIDR registers with the values
from the DOMAIN_ATTR_TTBR0 and DOMAIN_ATTR_CONTEXTIDR attributes
for the desired domain. The upstream driver may also need to do
other hardware specific register programming to properly
synchronize the domain switch. It must ensure that all register
state, except for CONTEXTIDR and TTBR0 registers, is restored
at the end of the domain switch operation.
DOMAIN_ATTR_PROCID may be set to any value for each domain
before it is attached. This value is part of the CONTEXTIDR
register, but it is not used by the SMMU hardware. Setting a unique
value for this attribute in every domain can be useful for debugging.
Change-Id: Ib92d06db06832700bdf56265b169ccddfb192698
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Some devices can support per-process iommu domains, which are used
asynchronously by the hardware which directly updates to the TTBR0
and CONTEXTIDR registers.
Add DOMAIN_ATTR_DYNAMIC to do indicate a domain may be used dynamically.
This attribute must be set before attaching, as it changes what
domain and hardware configuration is done by the iommu driver.
Before attaching any dynamic domains, the driver must first attach
a non-dynamic domain to do initial hardware configuration.
A simplified example:
void use_domain(struct iommu_domain *domain, struct job *job)
{
u64 ttbr0;
u32 contextidr;
iommu_domain_get_attr(domain, DOMAIN_ATTR_TTBR0, &ttbr0);
iommu_domain_get_attr(domain, DOMAIN_ATTR_CONTEXTIDR, &contextidr);
/*
* Schedule work on the hardware, which is time sliced between
* clients. Each client has a separate iommu domain and when
* a job is run, the hardware first programs TTBR0 and
* CONTEXTIDR to use the appropriate domain.
*/
submit_job(ttbr0, contextidr, job);
}
void init(void)
{
struct iommu_domain *master_domain, *dyn_domain1, *dyn_domain2;
int dynamic = 1;
master_domain = iommu_domain_alloc(bus);
dyn_domain1 = iommu_domain_alloc(bus);
dyn_domain2 = iommu_domain_alloc(bus);
iommu_attach_device(base_domain, dev);
iommu_domain_set_attr(dyn_domain1, DOMAIN_ATTR_DYNAMIC, &dynamic);
iommu_domain_set_attr(dyn_domain2, DOMAIN_ATTR_DYNAMIC, &dynamic);
iommu_attach_device(dyn_domain1, dev);
iommu_attach_device(dyn_domain2, dev);
while (keep_going) {
iommu_map(dyn_domain1, ...);
iommu_map(dyn_domain2, ...);
use_domain(dyn_domain1, job1);
use_domain(dyn_domain2, job2);
iommu_unmap(dyn_domain1, ...);
iommu_unmap(dyn_domain2, ...);
}
iommu_detach_device(dyn_domain2, dev);
iommu_detach_device(dyn_domain1, dev);
iommu_detach_device(master_domain, dev);
}
Change-Id: Ic4fa0a831751eb4b10fff5d9aec28a411856fbd1
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Add fields to arm_smmu_cfg to store asid, vmid, and procid so that they
can queried easily.
Program the CONTEXTIDR register during attach so that the PROCID
attribute functions as expected.
Change-Id: I2e2b3926fbf021754e89edda9a6857d2e3a7138b
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
In the ARM SMMU architecture, pagetable programming is controlled
by the TTBR0 and CONTEXTIDR registers. The layout of these
registers varies depending on the pagetable format in use.
In particular, the ASID (address space ID) field is found in
CONTEXTIDR when using V7S format and in the top bits of TTBR0
for V7L and V8L.
Some drivers need to program hardware to switch domains on the
fly. These attributes allow the correct settings to be determined
by querying the domain rather than directly reading registers and
making assumptions about the pagetable format. The domain must be
attached before TTBR0 and CONTEXTIDR may be queried.
The PROCID attribute allows driver set a debug field in the
CONTEXTIDR register. This attribute may only be set before
attaching, but may be queried at any time. The SMMU hardware
doesn't use the contents of this field, but debug can be simpler
if each domain stores a unique value in it.
Change-Id: I175aa78fee02c3e4e0071496d9cc2b8841ff9e3c
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
The attachment tracking code adds a node to debugfs every time a client
attaches a domain to an IOMMU device. The problem is that clients can
start making those attachments during early boot, before iommu-debug
initializes (including setting up the root debugfs directory for the
attachment tracking), which means they get stuck in the root debugfs
directory. Trying to initialize iommu-debug earlier than all possible
IOMMU clients is tricky, so fix this by only installing debugfs entries
onces we've initialized, installing debugfs entries for any early
attachments at initialization time.
Change-Id: I8364015346105187e0c8f787fc2b4155d72b3584
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful during development to trigger faults. Add a debugfs
file to do so.
Change-Id: Ic7b304ef0d908ebd506979f0c87189e34d7dfc67
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In order to facilitate debugging and development, implement the
.trigger_fault method from iommu_ops. This can be done on ARM SMMUv2 by
writing to the FSRRESTORE register. Do it.
Change-Id: Ia8339b54fbb9263d8cf23ff61c4615122316729a
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful to trigger an IOMMU fault during development and
debugging. Add support to the IOMMU framework to do so.
Change-Id: I908c9f5b52c6abe937f031de546d290027ba64b5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Requests from the walker to page table memory are currently inner- and
outer-cacheable. This configuration hasn't been fully validated for
functionality or characterized for performance. Configure these
requests as non-cacheable.
Change-Id: I7efb0a697faff68a67ee0afdb933b6dd6926f30a
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Coherent hardware table walking hasn't been properly validated or
characterized, so all clients are expected to disable it. This is a
recipe for disaster since it could be easy for a new client to come
along without knowing that they need to disable it. Just disable it by
default. Clients can always explicitly enable it in the future if it's
found to be beneficial.
Change-Id: I4badfe33e815a6ba7b25507f5dd5a42f68d4bfa6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
It can be useful to check whether or not coherent hardware table walking
has been explicitly disabled on attached domains. Add this to the
attach info debugfs file.
Change-Id: I432303ecb734d32eaa02038694daad0d8c4d8aba
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently IOMMU attachment info is available in debugfs files located at
<debugfs_root>/iommu/attachments/<attached_device>. However, there are
more actions that can be taken on attached devices besides just printing
their info. Make room for more debugfs files for attached devices by
creating a directory for each one, and move the existing info file to:
<debugfs_root>/iommu/attachments/<attached_device>/info.
Change-Id: Ia56efc3aeb5e82afc34314fe48aaa0cd6e5579be
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently the debug device structure is allocated with kmalloc, without
initializing all of the fields in the structure. Later, those fields
might be uses before they've every been assigned. For example, if a user
executes the following code on a fresh boot:
# cd /sys/kernel/debug/iommu/tests/some_device
# echo 0 > attach
The kernel crashes with something like this (assuming page poisoning is
enabled):
Unable to handle kernel paging request at virtual address aaaaaaaaaaaaaaaa
pgd = ffffffc0a92a1000
[aaaaaaaaaaaaaaaa] *pgd=0000000000000000, *pud=0000000000000000
Fix this by initializing all the fields in the structure to 0 by using
kzalloc instead of kmalloc.
Change-Id: I3514bf7bf174e176ff7a310c7134d0f53e22d771
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The functions for iommu/devices/<device>/profiling don't actually have
the word `profiling' in the name, which will be confusing as we add more
files to that directory. Rename them for clarity.
Change-Id: Ic57d9400d8784d2cbd667185c5b2b0e1275461dd
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
In order to facilitate debugging of context faults, the result of a
software table walk is currently printed as part of the fault handling.
However, there are certain bugs and error conditions that can't be
caught by doing a software table walk (like missing TLB invalidation or
misbehaving hardware). Add a hardware table walk (via ATOS) to improve
debugging capabilities.
Change-Id: Ie89019df62f115627359e29b1f6cc5de3a36d1b5
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The hardware address translation operations (ATOS) can be useful for
debugging. arm-smmu used to have support for ATOS, but it was ripped
out while moving to the io-pgtable framework. Resurrect the old ATOS
code with the following modifications:
- Remove errata workarounds for deprecated hardware.
- Move the atos lock to a spinlock (since the only reason a mutex was
being used previously was due to the fact that some of the old
errata workarounds required sleeping operations).
Change-Id: I1a021026b9ee41ba2c1761bd5d5b7a13399c6417
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Some IOMMU hardware implementations provide hardware translation
operations that can be useful during debugging and development. Add a
function for this purpose along with an associated op in the iommu_ops
structure so that drivers can implement it.
Change-Id: I54ad5df526cdce05f8e04206a4f01253b3976b48
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently, the device name for the SMMU context bank device is used as
the filename for the IOMMU debug info file. This doesn't work in cases
where multiple domains can be attached to a single SMMU context bank
device (like dynamic domains). Make these filenames unique by appending
a 16-byte uuid to the name.
Change-Id: Ie26ece773bfa2e8c75a329a8cb8461bcd598218e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
The last level optimization for __arm_lpae_unmap assumes that
consecutive blocks of 2MB addresses are located in the same
1GB mapping but this isn't always true - if the address spans
a 1GB boundary the next iova is in a different pagetable.
Only perform the optimization for the current pagetable entry and
then kick it back for the loop in arm_lpae_unmap to try again
with the updated iova. All this means that __arm_lpae_unmap may
not unmap all of the size that it was given. This is okay assuming
at least something was unmapped so don't jump out of the loop
in arm_lpae_unmap until the child function returns 0 or the entire
block is freed, whichever comes first.
CRs-Fixed: 867143
Change-Id: Ic0dedbad407d60365a95afdaf03ec3b91f53960d
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
The default mapping type is non-executeable. Check for the
DMA_ATTR_EXEC_MAPPING attribute which allows clients to
request an executeable mapping.
Change-Id: I24a170990cc04a848b6779871ae2025721177d46
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
DMA_ATTR_EXEC_MAPPING specifies that an executable mapping
should be created for the requested buffer. By default, the
DMA mappings are non-executable.
Change-Id: I135077e14996e92fa9d199bdee043c443db48924
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The logic for the iommu executable flag is inverted now and
all the iommu mappings are executable by default.
Provide the IOMMU_NOEXEC flag where the mapping needs to be non-executable.
Change-Id: Ifa0aa3d17ae79c16abdf66d2177a09b868a9f45f
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[pdaly@codeaurora.org Remove gpu/mdss]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
The msm lazy mapping APIs did not allow to pass in
dma attributes that could be passed to the dma-mapping
driver. This patch allows users to specify dma attributes for the
msm lazy mappings.
Change-Id: I3e4cd2bb99d205dce78083a256f4d444d865f3cc
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
DMA_ATTR_NO_DELAYED_UNMAP specifies to the msm lazy mapping
driver that this buffer should be immediately unmapped once
it is freed.
Change-Id: I43e6a6058705502cf91bf5f0c530c3099cba06ae
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
arm32 recently removed the `order' parameter from
arm_iommu_create_mapping: (68efd7d2fb: arm: dma-mapping: remove order
parameter from arm_iommu_create_mapping()) in order to make the API
easier to understand. The arm32 DMA IOMMU mapper has dynamic resizing
of the iova bitmap, so there was no reason to keep the `order' parameter
around (which was introduced to reduce the size of the bitmap).
Although we don't have dynamic iova bitmap reallocation on arm64, we'd
still like to get rid of the `order' parameter since it's confusing and
doesn't really help much (especially since all known clients on our
system are passing order=0). Remove it.
Change-Id: I35e32fdfbe05ec434f64a3a316d13c8f43304bc6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[pdaly@codeaurora.org Remove gpu/ipa etc modifications]
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
An incorrect conflict resolution when picking up 07c17f4e0b71d ("arm64:
add support for NO_KERNEL_MAPPING and STRONGLY_ORDERED") caused
MT_NORMAL_NC attributes being set for strongly-ordered mappings, rather
than MT_DEVICE_nGnRnE attributes.
As a result of this, speculative data fetches of the incorrectly-
mapped memory have been observed. In cases where this memory is
XPU protected or reads result in side-effects, this may result in
device crashes.
Fix this by setting the attributes returned by pgprot_noncached()
regardless of the value of the coherent flag passed to
__get_dma_pgprot()
Change-Id: Iec56027e280ae0920016df3066045b71299a915b
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Currently, debugging IOMMU issues is done via manual instrumentation of
the code or via low-level techniques like using a JTAG debugger.
Introduce a set of library functions and debugfs files to facilitate
interactive debugging and testing.
This patch introduces the basic infrastructure as well an initial
debugfs for:
- viewing IOMMU attachments (domain->dev mappings created by
iommu_attach_device) and resulting attributes (like the base address
of the page tables)
- basic performance profiling
Example usage:
# cd /sys/kernel/debug/iommu/attachments
# cat b40000.qcom,kgsl-iommu:iommu_kgsl_cb2
Domain: 0xffffffc0cb983f00
PT_BASE_ADDR: virt=0xffffffc057eca000 phys=0x00000000d7eca000
# cd /sys/kernel/debug/iommu/tests
# cat soc:qcom,cam_smmu:msm_cam_smmu_cb1/profiling
size iommu_map iommu_unmap
4K 47 us 909 us
64K 97 us 594 us
2M 1536 us 605 us
12M 8737 us 1193 us
20M 26517 us 1121 us
size iommu_map_sg iommu_unmap
64K 31 us 656 us
2M 885 us 600 us
12M 2674 us 687 us
20M 4352 us 1096 us
Change-Id: I1c301eec6e64688831cad80ffd0380743f7f0df6
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Currently we're relying on the smmu_domain->lock for synchronizing
attach and detach. This is a problem because each domain has its own
smmu_domain->lock, so if multiple different domains try to attach to the
same device at the same time, they'll be racing.
Fix the race by holding a lock that's part of the smmu
structure (attach_lock should do just fine).
The test case that uncovered this was:
# cd /sys/kernel/debug/iommu/tests/soc:qcom,msm-audio-ion/
# while :; do cat profiling; done &
# while :; do cat profiling; done &
Change-Id: I8a60cdc214c91967aff63882e3a7280865ffda9e
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
