- Nov 26, 2021
-
-
Alex Williamson authored
When supporting only the .map and .unmap callbacks of iommu_ops, the IOMMU driver can make assumptions about the size and alignment used for mappings based on the driver provided pgsize_bitmap. VT-d previously used essentially PAGE_MASK for this bitmap as any power of two mapping was acceptably filled by native page sizes. However, with the .map_pages and .unmap_pages interface we're now getting page-size and count arguments. If we simply combine these as (page-size * count) and make use of the previous map/unmap functions internally, any size and alignment assumptions are very different. As an example, a given vfio device assignment VM will often create a 4MB mapping at IOVA pfn [0x3fe00 - 0x401ff]. On a system that does not support IOMMU super pages, the unmap_pages interface will ask to unmap 1024 4KB pages at the base IOVA. dma_pte_clear_level() will recurse down to level 2 of the page table where the first half of the pfn range exactly matches the entire pte level. We clear the pte, increment the pfn by the level size, but (oops) the next pte is on a new page, so we exit the loop an pop back up a level. When we then update the pfn based on that higher level, we seem to assume that the previous pfn value was at the start of the level. In this case the level size is 256K pfns, which we add to the base pfn and get a results of 0x7fe00, which is clearly greater than 0x401ff, so we're done. Meanwhile we never cleared the ptes for the remainder of the range. When the VM remaps this range, we're overwriting valid ptes and the VT-d driver complains loudly, as reported by the user report linked below. The fix for this seems relatively simple, if each iteration of the loop in dma_pte_clear_level() is assumed to clear to the end of the level pte page, then our next pfn should be calculated from level_pfn rather than our working pfn. Fixes: 3f34f125 ("iommu/vt-d: Implement map/unmap_pages() iommu_ops callback") Reported-by:
Ajay Garg <ajaygargnsit@gmail.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Tested-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Link: https://lore.kernel.org/all/20211002124012.18186-1-ajaygargnsit@gmail.com/ Link: https://lore.kernel.org/r/163659074748.1617923.12716161410774184024.stgit@omen Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20211126135556.397932-3-baolu.lu@linux.intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
Christophe JAILLET authored
If we return -EOPNOTSUPP, the rcu lock remains lock. This is spurious. Go through the end of the function instead. This way, the missing 'rcu_read_unlock()' is called. Fixes: 7afd7f6a ("iommu/vt-d: Check FL and SL capability sanity in scalable mode") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/40cc077ca5f543614eab2a10e84d29dd190273f6.1636217517.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Alex Bee authored
With the submission of iommu driver for RK3568 a subtle bug was introduced: PAGE_DESC_HI_MASK1 and PAGE_DESC_HI_MASK2 have to be the other way arround - that leads to random errors, especially when addresses beyond 32 bit are used. Fix it. Fixes: c55356c5 ("iommu: rockchip: Add support for iommu v2") Signed-off-by:
Alex Bee <knaerzche@gmail.com> Tested-by:
Peter Geis <pgwipeout@gmail.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Dan Johansen <strit@manjaro.org> Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Link: https://lore.kernel.org/r/20211124021325.858139-1-knaerzche@gmail.com Signed-off-by:
-
Joerg Roedel authored
The messages printed on the initialization of the AMD IOMMUv2 driver have caused some confusion in the past. Clarify the messages to lower the confusion in the future. Cc: stable@vger.kernel.org Signed-off-by:
-
- Nov 04, 2021
-
-
Marc Zyngier authored
The MSI doorbell on Apple HW can be any address in the low 4GB range. However, the MSI write is matched by the PCIe block before hitting the iommu. It must thus be excluded from the IOVA range that is assigned to any PCIe device. Link: https://lore.kernel.org/r/20210929163847.2807812-9-maz@kernel.org Tested-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Sven Peter <sven@svenpeter.dev>
-
- Oct 28, 2021
-
-
Logan Gunthorpe authored
scsi_dma_map() was reporting a failure during boot on an AMD machine with the IOMMU enabled. scsi_dma_map failed: request for 36 bytes! The issue was tracked down to a mistake in logic: should not return an error if iommu_deferred_attach() returns zero. Reported-by:
Marshall Midden <marshallmidden@gmail.com> Fixes: dabb16f6 ("iommu/dma: return error code from iommu_dma_map_sg()") Link: https://lore.kernel.org/all/CAD2CkAWjS8=kKwEEN4cgVNjyFORUibzEiCUA-X+SMtbo0JoMmA@mail.gmail.com Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20211027174757.119755-1-logang@deltatee.com Signed-off-by:
-
- Oct 27, 2021
-
-
Sven Peter authored
DART has an additional global register to control which streams are isolated. This register is a bit redundant since DART_TCR can already be used to control isolation and is usually initialized to DART_STREAM_ALL by the time we get control. Some DARTs (namely the one used for the audio controller) however have some streams disabled initially. Make sure those work by initializing DART_STREAMS_ENABLE during reset. Reported-by:
Martin Povišer <povik@protonmail.com> Signed-off-by:
Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211019162253.45919-1-sven@svenpeter.dev Signed-off-by:
-
Gustavo A. R. Silva authored
Use 2-factor argument form kvcalloc() instead of kvzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210928222229.GA280355@embeddedor Signed-off-by:
-
- Oct 18, 2021
-
-
Christophe JAILLET authored
'smmu->asids' is a bitmap. So use 'devm_kzalloc()' to simplify code, improve the semantic of the code and avoid some open-coded arithmetic in allocator arguments. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/2c0f4da80c3b5ef83299c651f69a563034c1c6cb.1632661557.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Wan Jiabing authored
Fix following coccicheck warning: drivers/iommu/apple-dart.c:704:20-27: WARNING opportunity for kmemdup Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Acked-by:
-
Longpeng(Mike) authored
The __domain_mapping() always removes the pages in the range from 'iov_pfn' to 'end_pfn', but the 'end_pfn' is always the last pfn of the range that the caller wants to map. This would introduce too many duplicated removing and leads the map operation take too long, for example: Map iova=0x100000,nr_pages=0x7d61800 iov_pfn: 0x100000, end_pfn: 0x7e617ff iov_pfn: 0x140000, end_pfn: 0x7e617ff iov_pfn: 0x180000, end_pfn: 0x7e617ff iov_pfn: 0x1c0000, end_pfn: 0x7e617ff iov_pfn: 0x200000, end_pfn: 0x7e617ff ... it takes about 50ms in total. We can reduce the cost by recalculate the 'end_pfn' and limit it to the boundary of the end of this pte page. Map iova=0x100000,nr_pages=0x7d61800 iov_pfn: 0x100000, end_pfn: 0x13ffff iov_pfn: 0x140000, end_pfn: 0x17ffff iov_pfn: 0x180000, end_pfn: 0x1bffff iov_pfn: 0x1c0000, end_pfn: 0x1fffff iov_pfn: 0x200000, end_pfn: 0x23ffff ... it only need 9ms now. This also removes a meaningless BUG_ON() in __domain_mapping(). Signed-off-by:Longpeng(Mike) <longpeng2@huawei.com> Tested-by:
Liujunjie <liujunjie23@huawei.com> Link: https://lore.kernel.org/r/20211008000433.1115-1-longpeng2@huawei.com Signed-off-by:
-
Fenghua Yu authored
update_pasid() and its call chain are currently unused in the tree because Thomas disabled the ENQCMD feature. The feature will be re-enabled shortly using a different approach and update_pasid() and its call chain will not be used in the new approach. Remove the useless functions. Signed-off-by:
Fenghua Yu <fenghua.yu@intel.com> Reviewed-by:
Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20210920192349.2602141-1-fenghua.yu@intel.com Signed-off-by:
-
Lu Baolu authored
The commit 262948f8 ("iommu: Delete iommu_dev_has_feature()") has deleted the iommu_dev_has_feature() interface. Remove the dev_has_feat callback to avoid dead code. Signed-off-by:
-
Lu Baolu authored
The IOMMU VT-d implementation uses the first level for GPA->HPA translation by default. Although both the first level and the second level could handle the DMA translation, they're different in some way. For example, the second level translation has separate controls for the Access/Dirty page tracking. With the first level translation, there's no such control. On the other hand, the second level translation has the page-level control for forcing snoop, but the first level only has global control with pasid granularity. This uses the second level for GPA->HPA translation so that we can provide a consistent hardware interface for use cases like dirty page tracking for live migration. Signed-off-by:
Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20210926114535.923263-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20211014053839.727419-6-baolu.lu@linux.intel.com Signed-off-by:
-
Lu Baolu authored
An iommu domain could be allocated and mapped before it's attached to any device. This requires that in scalable mode, when the domain is allocated, the format (FL or SL) of the page table must be determined. In order to achieve this, the platform should support consistent SL or FL capabilities on all IOMMU's. This adds a check for this and aborts IOMMU probing if it doesn't meet this requirement. Signed-off-by:
-
Lu Baolu authored
The iommu_domain data structure already has the "type" field to keep the type of a domain. It's unnecessary to have the DOMAIN_FLAG_STATIC_IDENTITY flag in the vt-d implementation. This cleans it up with no functionality change. Signed-off-by:
-
Kyung Min Park authored
When the dmar translation fault happens, the kernel prints a single line fault reason with corresponding hexadecimal code defined in the Intel VT-d specification. Currently, when user wants to debug the translation fault in detail, debugfs is used for dumping the dmar_translation_struct, which is not available when the kernel failed to boot. Dump the DMAR translation structure, pagewalk the IO page table and print the page table entry when the fault happens. This takes effect only when CONFIG_DMAR_DEBUG is enabled. Signed-off-by:
Kyung Min Park <kyung.min.park@intel.com> Link: https://lore.kernel.org/r/20210815203845.31287-1-kyung.min.park@intel.com Signed-off-by:
-
Tvrtko Ursulin authored
Handling of intel_iommu kernel command line option should return "true" to indicate option is valid and so avoid logging it as unknown by the core parsing code. Also log unknown sub-options at the notice level to let user know of potential typos or similar. Reported-by:
Eero Tamminen <eero.t.tamminen@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://lore.kernel.org/r/20210831112947.310080-1-tvrtko.ursulin@linux.intel.com Signed-off-by:
-
- Oct 13, 2021
-
-
Arnd Bergmann authored
My previous bugfix ended up making things worse for the QCOM IOMMU driver when it forgot to add the Kconfig symbol that is getting used to control the compilation of the SMMU implementation specific code for Qualcomm. Fixes: 424953cf ("qcom_scm: hide Kconfig symbol") Reported-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Reported-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by:
John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/lkml/20211010023350.978638-1-dmitry.baryshkov@linaro.org/ Acked-by:
Will Deacon <will@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Oct 08, 2021
-
-
Sibi Sankar authored
The SID configuration requirement for Modem on SC7280 is similar to the ones found on SC7180/SDM845 SoCs. So, add the SC7280 modem compatible to the list to defer the programming of the modem SIDs to the kernel. Signed-off-by:
Sibi Sankar <sibis@codeaurora.org> Reviewed-by:
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1631886935-14691-5-git-send-email-sibis@codeaurora.org Signed-off-by:
-
- Oct 07, 2021
-
-
Arnd Bergmann authored
Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' ld.lld: error: undefined symbol: qcom_scm_is_available >>> referenced by adreno_gpu.c >>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in archive drivers/built-in.a This can happen when CONFIG_ARCH_QCOM is disabled and we don't select QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd use a similar dependency here to what we have for QCOM_RPROC_COMMON, but that causes dependency loops from other things selecting QCOM_SCM. This appears to be an endless problem, so try something different this time: - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' but that is simply selected by all of its users - All the stubs in include/linux/qcom_scm.h can go away - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to allow compile-testing QCOM_SCM on all architectures. - To avoid a circular dependency chain involving RESET_CONTROLLER and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement. According to my testing this still builds fine, and the QCOM platform selects this symbol already. Acked-by:
Kalle Valo <kvalo@codeaurora.org> Acked-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
- Oct 04, 2021
-
-
Loic Poulain authored
Add compatible for QCM2290 SMMU to use the Qualcomm Technologies, Inc. specific implementation. Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1633096832-7762-1-git-send-email-loic.poulain@linaro.org [will: Sort by alphabetical order, add commit message] Signed-off-by:
-
Konrad Dybcio authored
Add compatible for SM6350 SMMU to use the Qualcomm Technologies, Inc. specific implementation. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20210820202906.229292-2-konrad.dybcio@somainline.org Signed-off-by:
-
Zhen Lei authored
1. Build command CMD_SYNC cannot fail. So the return value can be ignored. 2. The arm_smmu_cmdq_build_cmd() almost never fails, the addition of "unlikely()" can optimize the instruction pipeline. 3. Check the return value in arm_smmu_cmdq_batch_add(). Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210818080452.2079-2-thunder.leizhen@huawei.com Signed-off-by:
-
Zhen Lei authored
Pre-zeroing the batched commands structure is inefficient, as individual commands are zeroed later in arm_smmu_cmdq_build_cmd(). Therefore, only the member 'num' needs to be initialized to 0. Signed-off-by:
John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20210817113411.1962-1-thunder.leizhen@huawei.com Signed-off-by:
-
Tom Lendacky authored
Replace uses of mem_encrypt_active() with calls to cc_platform_has() with the CC_ATTR_MEM_ENCRYPT attribute. Remove the implementation of mem_encrypt_active() across all arches. For s390, since the default implementation of the cc_platform_has() matches the s390 implementation of mem_encrypt_active(), cc_platform_has() does not need to be implemented in s390 (the config option ARCH_HAS_CC_PLATFORM is not set). Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210928191009.32551-9-bp@alien8.de
-
Tom Lendacky authored
Replace uses of sme_active() with the more generic cc_platform_has() using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT can be updated, as required. This also replaces two usages of sev_active() that are really geared towards detecting if SME is active. Signed-off-by:
-
- Sep 29, 2021
-
-
Lennert Buytenhek authored
This patch makes iommu/amd call report_iommu_fault() when an I/O page fault occurs, which has two effects: 1) It allows device drivers to register a callback to be notified of I/O page faults, via the iommu_set_fault_handler() API. 2) It triggers the io_page_fault tracepoint in report_iommu_fault() when an I/O page fault occurs. The latter point is the main aim of this patch, as it allows rasdaemon-like daemons to be notified of I/O page faults, and to possibly initiate corrective action in response. A number of other IOMMU drivers already use report_iommu_fault(), and I/O page faults on those IOMMUs therefore already trigger this tracepoint -- but this isn't yet the case for AMD-Vi and Intel DMAR. The AMD IOMMU specification suggests that the bit in an I/O page fault event log entry that signals whether an I/O page fault was for a read request or for a write request is only meaningful when the faulting access was to a present page, but some testing on a Ryzen 3700X suggests that this bit encodes the correct value even for I/O page faults to non-present pages, and therefore, this patch passes the R/W information up the stack even for I/O page faults to non-present pages. Signed-off-by:
Lennert Buytenhek <buytenh@arista.com> Link: https://lore.kernel.org/r/YVLyBW97vZLpOaAp@wantstofly.org Signed-off-by:
-
David Stevens authored
Pass the non-aligned size to __iommu_dma_map when using swiotlb bounce buffers in iommu_dma_map_page, to account for min_align_mask. To deal with granule alignment, __iommu_dma_map maps iova_align(size + iova_off) bytes starting at phys - iova_off. If iommu_dma_map_page passes aligned size when using swiotlb, then this becomes iova_align(iova_align(orig_size) + iova_off). Normally iova_off will be zero when using swiotlb. However, this is not the case for devices that set min_align_mask. When iova_off is non-zero, __iommu_dma_map ends up mapping an extra page at the end of the buffer. Beyond just being a security issue, the extra page is not cleaned up by __iommu_dma_unmap. This causes problems when the IOVA is reused, due to collisions in the iommu driver. Just passing the original size is sufficient, since __iommu_dma_map will take care of granule alignment. Fixes: 1f221a0d ("swiotlb: respect min_align_mask") Signed-off-by:
David Stevens <stevensd@chromium.org> Link: https://lore.kernel.org/r/20210929023300.335969-8-stevensd@google.com Signed-off-by:
-
David Stevens authored
Add an argument to swiotlb_tbl_map_single that specifies the desired alignment of the allocated buffer. This is used by dma-iommu to ensure the buffer is aligned to the iova granule size when using swiotlb with untrusted sub-granule mappings. This addresses an issue where adjacent slots could be exposed to the untrusted device if IO_TLB_SIZE < iova granule < PAGE_SIZE. Signed-off-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210929023300.335969-7-stevensd@google.com Signed-off-by:
-
David Stevens authored
Introduce a new dev_use_swiotlb function to guard swiotlb code, instead of overloading dev_is_untrusted. This allows CONFIG_SWIOTLB to be checked more broadly, so the swiotlb related code can be removed more aggressively. Signed-off-by:
-
David Stevens authored
Fold the _swiotlb helper functions into the respective _page functions, since recent fixes have moved all logic from the _page functions to the _swiotlb functions. Signed-off-by:
-
David Stevens authored
Calling the iommu_dma_sync_*_for_cpu functions during unmap can cause two copies out of the swiotlb buffer. Do the arch sync directly in __iommu_dma_unmap_swiotlb instead to avoid this. This makes the call to iommu_dma_sync_sg_for_cpu for untrusted devices in iommu_dma_unmap_sg no longer necessary, so move that invocation later in the function. Signed-off-by:
-
David Stevens authored
When calling arch_sync_dma, we need to pass it the memory that's actually being used for dma. When using swiotlb bounce buffers, this is the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb helper, so it can use the bounce buffer address if necessary. Now that iommu_dma_map_sg delegates to a function which takes care of architectural syncing in the untrusted device case, the call to iommu_dma_sync_sg_for_device can be moved so it only occurs for trusted devices. Doing the sync for untrusted devices before mapping never really worked, since it needs to be able to target swiotlb buffers. This also moves the architectural sync to before the call to __iommu_dma_map, to guarantee that untrusted devices can't see stale data they shouldn't see. Fixes: 82612d66 ("iommu: Allow the iommu/dma api to use bounce buffers") Signed-off-by:
-
David Stevens authored
The is_swiotlb_buffer function takes the physical address of the swiotlb buffer, not the physical address of the original buffer. The sglist contains the physical addresses of the original buffer, so for the sync_sg functions to work properly when a bounce buffer might have been used, we need to use iommu_iova_to_phys to look up the physical address. This is what sync_single does, so call that function on each sglist segment. The previous code mostly worked because swiotlb does the transfer on map and unmap. However, any callers which use DMA_ATTR_SKIP_CPU_SYNC with sglists or which call sync_sg would not have had anything copied to the bounce buffer. Fixes: 82612d66 ("iommu: Allow the iommu/dma api to use bounce buffers") Signed-off-by:
-
- Sep 28, 2021
-
-
Arnd Bergmann authored
clang-14 notices that a comparison is never true when CONFIG_PHYS_ADDR_T_64BIT is disabled: drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant 5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE) ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add an explicit check for the type of the variable to skip the check and the warning in that case. Fixes: b4dad40e ("iommu/mediatek: Adjust the PA for the 4GB Mode") Signed-off-by:Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20210927121857.941160-1-arnd@kernel.org Signed-off-by:
-
Sven Peter authored
sid2groups keeps track of which stream id combinations belong to a iommu_group to assign those correctly to devices. When a iommu_group is freed a stale pointer will however remain in sid2groups. This prevents devices with the same stream id combination to ever be attached again (see below). Fix that by creating a shadow copy of the stream id configuration when a group is allocated for the first time and clear the sid2group entry when that group is freed. # echo 1 >/sys/bus/pci/devices/0000\:03\:00.0/remove pci 0000:03:00.0: Removing from iommu group 1 # echo 1 >/sys/bus/pci/rescan [...] pci 0000:03:00.0: BAR 0: assigned [mem 0x6a0000000-0x6a000ffff 64bit pref] pci 0000:03:00.0: BAR 2: assigned [mem 0x6a0010000-0x6a001ffff 64bit pref] pci 0000:03:00.0: BAR 6: assigned [mem 0x6c0100000-0x6c01007ff pref] tg3 0000:03:00.0: Failed to add to iommu group 1: -2 [...] Fixes: 46d1fb07 ("iommu/dart: Add DART iommu driver") Reported-by:
-
Nikita Yushchenko authored
Add r8a77980 (R-Car V3H) to the list of supported devices. The hardware is the same as on already-supportred V3M and other R-Car Gen3 chips. Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Link: https://lore.kernel.org/r/20210923191115.22864-1-nikita.yoush@cogentembedded.com Signed-off-by:
-
Bjorn Helgaas authored
719a1933 ("iommu/vt-d: Tweak the description of a DMA fault") changed the DMA fault reason from hex to decimal. It also added "0x" prefixes to the PCI bus/device, e.g., - DMAR: [INTR-REMAP] Request device [00:00.5] + DMAR: [INTR-REMAP] Request device [0x00:0x00.5] These no longer match dev_printk() and other similar messages in dmar_match_pci_path() and dmar_acpi_insert_dev_scope(). Drop the "0x" prefixes from the bus and device addresses. Fixes: 719a1933 ("iommu/vt-d: Tweak the description of a DMA fault") Signed-off-by:
-
Sven Peter authored
apple_dart_tlb_flush_{all,walk} expect to get a struct apple_dart_domain but instead get a struct iommu_domain right now. This breaks those two functions and can lead to kernel panics like the one below. DART can only invalidate the entire TLB and apple_dart_iotlb_sync will already flush everything. There's no need to do that again inside those two functions. Let's just drop them. pci 0000:03:00.0: Removing from iommu group 1 Unable to handle kernel paging request at virtual address 0000000100000023 [...] Call trace: _raw_spin_lock_irqsave+0x54/0xbc apple_dart_hw_stream_command.constprop.0+0x2c/0x130 apple_dart_tlb_flush_all+0x48/0x90 free_io_pgtable_ops+0x40/0x70 apple_dart_domain_free+0x2c/0x44 iommu_group_release+0x68/0xac kobject_cleanup+0x4c/0x1fc kobject_cleanup+0x14c/0x1fc kobject_put+0x64/0x84 iommu_group_remove_device+0x110/0x180 iommu_release_device+0x50/0xa0 [...] Fixes: 46d1fb07 ("iommu/dart: Add DART iommu driver") Reported-by:
-
