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
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 swiotlb_print_i
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 whe
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 swiotlb_exit
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: Kon
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
---
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
---
drivers/iommu
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
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 serie
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
I
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 pa
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 enab
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
minimi
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
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 outsta
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 mod
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
> DMA_MAPPING_ERRO
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 || !QCOM_SCM
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 d
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 f
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:
https://github.com/hisilicon/kerne
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 st
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 H
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: Robi
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: Chris
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: Rob
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 devi
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(). This,
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 cal
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_fa
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
conf
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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 |
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
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) 9
37 matches
Mail list logo
