Re: [PATCH 5/5] swiotlb: Free tbl memory in swiotlb_exit()

2021-07-19 Thread Claire Chang
On Mon, Jul 19, 2021 at 8:31 PM Will Deacon wrote: > > Although swiotlb_exit() frees the 'slots' metadata array referenced by > 'io_tlb_default_mem', it leaves the underlying buffer pages allocated > despite no longer being usable. > > Extend swiotlb_exit() to free the buffer pages as well as the

Re: [PATCH 4/5] swiotlb: Emit diagnostic in swiotlb_exit()

2021-07-19 Thread Claire Chang
On Mon, Jul 19, 2021 at 8:31 PM Will Deacon wrote: > > A recent debugging session would have been made a little bit easier if > we had noticed sooner that swiotlb_exit() was being called during boot. > > Add a simple diagnostic message to swiotlb_exit() to complement the one > from

Re: [PATCH 3/5] swiotlb: Remove io_tlb_default_mem indirection

2021-07-19 Thread Claire Chang
On Mon, Jul 19, 2021 at 8:31 PM Will Deacon wrote: > > The indirection from the global 'io_tlb_default_mem' pointer to the > static '_io_tlb_default_mem' structure is ugly and unnecessary. > > Convert all users to reference the static structure directly, using the > 'nslabs' field to determine

Re: [PATCH 2/5] swiotlb: Point io_default_tlb_mem at static allocation

2021-07-19 Thread Claire Chang
On Mon, Jul 19, 2021 at 8:31 PM Will Deacon wrote: > > Since commit 69031f500865 ("swiotlb: Set dev->dma_io_tlb_mem to the > swiotlb pool used"), 'struct device' may hold a copy of the global > 'io_default_tlb_mem' pointer if the device is using swiotlb for DMA. A > subsequent call to

Re: [PATCH 1/5] of: Return success from of_dma_set_restricted_buffer() when !OF_ADDRESS

2021-07-19 Thread Claire Chang
On Mon, Jul 19, 2021 at 8:31 PM Will Deacon wrote: > > When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV > and breaks the boot for sparc[64] machines. Return 0 instead, since the > function is essentially a glorified NOP in this configuration. > > Cc: Claire Chang > Cc:

[PATCH 3/3] iommu/vt-d: Move clflush'es from iotlb_sync_map() to map_pages()

2021-07-19 Thread Lu Baolu
As the Intel VT-d driver has switched to use the iommu_ops.map_pages() callback, multiple pages of the same size will be mapped in a call. There's no need to put the clflush'es in iotlb_sync_map() callback. Move them back into __domain_mapping() to simplify the code. Signed-off-by: Lu Baolu ---

[PATCH 2/3] iommu/vt-d: Implement map/unmap_pages() iommu_ops callback

2021-07-19 Thread Lu Baolu
Implement the map_pages() and unmap_pages() callback for the Intel IOMMU driver to allow calls from iommu core to map and unmap multiple pages of the same size in one call. With map/unmap_pages() implemented, the prior map/unmap callbacks are deprecated. Signed-off-by: Lu Baolu ---

[PATCH 1/3] iommu/vt-d: Report real pgsize bitmap to iommu core

2021-07-19 Thread Lu Baolu
The pgsize bitmap is used to advertise the page sizes our hardware supports to the IOMMU core, which will then use this information to split physically contiguous memory regions it is mapping into page sizes that we support. Traditionally the IOMMU core just handed us the mappings directly, after

[PATCH 0/3] iommu/vt-d: Implement [map/unmap]_pages callbacks

2021-07-19 Thread Lu Baolu
Hi, The "Optimizing iommu_[map/unmap] performance" series posted here, https://lore.kernel.org/linux-iommu/1623850736-389584-1-git-send-email-quic_c_gdj...@quicinc.com/ improves the iommu_[map/unmap] performce by reducing the number of calls to the vendor-specific map/unmap callbacks. This

[PATCH 5/5] iommu/vt-d: Allow devices to have more than 32 outstanding PRs

2021-07-19 Thread Lu Baolu
The minimum per-IOMMU PRQ queue size is one 4K page, this is more entries than the hardcoded limit of 32 in the current VT-d code. Some devices can support up to 512 outstanding PRQs but underutilized by this limit of 32. Although, 32 gives some rough fairness when multiple devices share the same

[PATCH 4/5] iommu/vt-d: Disallow SVA if devices don't support 64-bit address

2021-07-19 Thread Lu Baolu
When the device and CPU share an address space (such as SVA), the device must support the same addressing capability as the CPU. The CPU does not consider the addressing ability of any device when managing the page table of a process, so the device must have enough addressing ability to bind the

[PATCH 2/5] iommu/vt-d: Enable Intel IOMMU scalable mode by default

2021-07-19 Thread Lu Baolu
The commit 8950dcd83ae7d ("iommu/vt-d: Leave scalable mode default off") leaves the scalable mode default off and end users could turn it on with "intel_iommu=sm_on". Using the Intel IOMMU scalable mode for kernel DMA, user-level device access and Shared Virtual Address have been enabled. This

[PATCH 3/5] iommu/vt-d: Preset A/D bits for user space DMA usage

2021-07-19 Thread Lu Baolu
We preset the access and dirty bits for IOVA over first level usage only for the kernel DMA (i.e., when domain type is IOMMU_DOMAIN_DMA). We should also preset the FL A/D for user space DMA usage. The idea is that even the user space A/D bit memory write is unnecessary. We should avoid it to

[PATCH 1/5] iommu/vt-d: Refactor Kconfig a bit

2021-07-19 Thread Lu Baolu
Put all sub-options inside a "if INTEL_IOMMU" so that they don't need to always depend on INTEL_IOMMU. Use IS_ENABLED() instead of #ifdef as well. Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 13 ++--- drivers/iommu/intel/Kconfig | 18 ++ 2 files changed, 12

[PATCH 0/5] iommu/vt-d: Several minor adjustments

2021-07-19 Thread Lu Baolu
Hi, This series includes some adjustments for Intel IOMMU which I have been suggested. Please help to review. - Enable Intel IOMMU scalable mode by default - Preset A/D bits for user space DMA usage - Disallow SVA if devices don't support 64-bit address - Allow devices to have more than 32

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2021-07-19 Thread Saravana Kannan via iommu
On Mon, Jul 19, 2021 at 12:36 PM Bjorn Andersson wrote: > > On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote: > > > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson > > wrote: > > > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > > > Allow the qcom_scm driver to be loadable as a permenent

Re: [PATCH v1 13/16] xen: swiotlb: return error code from xen_swiotlb_map_sg()

2021-07-19 Thread Boris Ostrovsky
On 7/15/21 12:45 PM, Logan Gunthorpe wrote: > From: Martin Oliveira > > The .map_sg() op now expects an error code instead of zero on failure. > > xen_swiotlb_map_sg() may only fail if xen_swiotlb_map_page() fails, but > xen_swiotlb_map_page() only supports returning errors as >

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2021-07-19 Thread Bjorn Andersson
On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote: > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson > wrote: > > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > > > This still uses the "depends on QCOM_SCM ||

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2021-07-19 Thread John Stultz
On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson wrote: > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > > ensure that drivers that call into the qcom_scm

Re: [PATCH v4 3/3] iommu: dart: Add DART iommu driver

2021-07-19 Thread Robin Murphy
On 2021-07-15 17:41, Sven Peter via iommu wrote: [...] + u64 sw_bypass_cpu_start; + u64 sw_bypass_dma_start; + u64 sw_bypass_len; + + struct list_head streams; I'm staring to think this could just be a bitmap, in a u16 even. The problem is that these streams may come

Re: [bug report] iommu_dma_unmap_sg() is very slow then running IO from remote numa node

2021-07-19 Thread John Garry
On 09/07/2021 15:24, Ming Lei wrote: associated compromises. Follows the log of 'perf report' 1) good(run fio from cpus in the nvme's numa node) Hi Ming, If you're still interested in this issue, as an experiment only you can try my rebased patches here:

Re: [PATCH v6 0/9] ACPI/IORT: Support for IORT RMR node

2021-07-19 Thread Laurentiu Tudor
On 7/16/2021 11:34 AM, Shameer Kolothum wrote: > Hi, > > Major Changes from v5: > - Addressed comments from Robin & Lorenzo. > : Moved iort_parse_rmr() to acpi_iort_init() from > iort_init_platform_devices(). > : Removed use of struct iort_rmr_entry during the initial > parse. Using

[PATCH 4/5] swiotlb: Emit diagnostic in swiotlb_exit()

2021-07-19 Thread Will Deacon
A recent debugging session would have been made a little bit easier if we had noticed sooner that swiotlb_exit() was being called during boot. Add a simple diagnostic message to swiotlb_exit() to complement the one from swiotlb_print_info() during initialisation. Cc: Claire Chang Cc: Christoph

[PATCH 5/5] swiotlb: Free tbl memory in swiotlb_exit()

2021-07-19 Thread Will Deacon
Although swiotlb_exit() frees the 'slots' metadata array referenced by 'io_tlb_default_mem', it leaves the underlying buffer pages allocated despite no longer being usable. Extend swiotlb_exit() to free the buffer pages as well as the slots array. Cc: Claire Chang Cc: Christoph Hellwig Cc:

[PATCH 3/5] swiotlb: Remove io_tlb_default_mem indirection

2021-07-19 Thread Will Deacon
The indirection from the global 'io_tlb_default_mem' pointer to the static '_io_tlb_default_mem' structure is ugly and unnecessary. Convert all users to reference the static structure directly, using the 'nslabs' field to determine whether swiotlb has been initialised. Cc: Claire Chang Cc:

[PATCH 1/5] of: Return success from of_dma_set_restricted_buffer() when !OF_ADDRESS

2021-07-19 Thread Will Deacon
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV and breaks the boot for sparc[64] machines. Return 0 instead, since the function is essentially a glorified NOP in this configuration. Cc: Claire Chang Cc: Konrad Rzeszutek Wilk Reported-by: Guenter Roeck Suggested-by:

[PATCH 2/5] swiotlb: Point io_default_tlb_mem at static allocation

2021-07-19 Thread Will Deacon
Since commit 69031f500865 ("swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used"), 'struct device' may hold a copy of the global 'io_default_tlb_mem' pointer if the device is using swiotlb for DMA. A subsequent call to swiotlb_exit() will therefore leave dangling pointers behind in these

[PATCH 0/5] Fix restricted DMA vs swiotlb_exit()

2021-07-19 Thread Will Deacon
Hi all, This series fixes the issues which have been reported against the Restricted DMA series in -next: * Fix the build for Sparc as reported by Guenter [1]. * Rework the lifetime of 'io_tlb_default_mem' so that devices can retain valid references to it even after swiotlb_exit().

Re: [PATCH v4 6/6] dma-iommu: Pass iova len for IOVA domain init

2021-07-19 Thread John Garry
On 19/07/2021 10:32, Robin Murphy wrote: 7c1b058c8b5a31 Robin Murphy  2017-03-16  393  if (!dev) Old code has checks for NULL I doubt that in practice we need this check. Function iommu_dma_init_domain() is only

[PATCH,RFC] iommu/amd: Use report_iommu_fault()

2021-07-19 Thread Lennert Buytenhek
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

Re: [PATCH v4 6/6] dma-iommu: Pass iova len for IOVA domain init

2021-07-19 Thread Robin Murphy
On 2021-07-19 10:12, John Garry wrote: On 19/07/2021 08:58, Dan Carpenter wrote: Hi John, url: https://github.com/0day-ci/linux/commits/John-Garry/iommu-Allow-IOVA-rcache-range-be-configured/20210714-184328 base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next

Re: [PATCH v2] dma-mapping: use vmalloc_to_page for vmalloc addresses

2021-07-19 Thread Christoph Hellwig
On Sat, Jul 17, 2021 at 11:39:21AM +0300, Roman Skakun wrote: > > We can merge this patch and create a new one for > > xen_swiotlb_free_coherent() later. > > Yeah, no worries, I didn't know that exposing dma_common_vaddr_to_page > > was problematic. > > > > This patch is fine by me. > > Good. I'm

Re: [PATCH] iommu/amd: Convert from atomic_t to refcount_t on device_state->count

2021-07-19 Thread Xiyu Yang via iommu
___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 6/6] dma-iommu: Pass iova len for IOVA domain init

2021-07-19 Thread John Garry
On 19/07/2021 08:58, Dan Carpenter wrote: Hi John, url: https://github.com/0day-ci/linux/commits/John-Garry/iommu-Allow-IOVA-rcache-range-be-configured/20210714-184328 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: ia64-randconfig-m031-20210714 (attached

Re: [PATCH] iommu/amd: Convert from atomic_t to refcount_t on device_state->count

2021-07-19 Thread Will Deacon
On Mon, Jul 19, 2021 at 02:00:37PM +0800, Xiyu Yang wrote: > refcount_t type and corresponding API can protect refcounters from > accidental underflow and overflow and further use-after-free situations. > > Signed-off-by: Xiyu Yang > Signed-off-by: Xin Tan > --- > drivers/iommu/amd/iommu_v2.c

[PATCH] iommu/amd: Convert from atomic_t to refcount_t on pasid_state->count

2021-07-19 Thread Xiyu Yang via iommu
refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan --- drivers/iommu/amd/iommu_v2.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff

Re: [PATCH v4 6/6] dma-iommu: Pass iova len for IOVA domain init

2021-07-19 Thread Dan Carpenter
Hi John, url: https://github.com/0day-ci/linux/commits/John-Garry/iommu-Allow-IOVA-rcache-range-be-configured/20210714-184328 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: ia64-randconfig-m031-20210714 (attached as .config) compiler: ia64-linux-gcc (GCC)

[PATCH] iommu/amd: Convert from atomic_t to refcount_t on device_state->count

2021-07-19 Thread Xiyu Yang via iommu
refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan --- drivers/iommu/amd/iommu_v2.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff