Am 20.08.19 um 03:24 schrieb Christoph Hellwig:
> Hi Stefan,
>
> please try the patch below.
>
> ---
> From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Tue, 20 Aug 2019 10:08:38 +0900
> Subject: arm: select the dma-noncoherent symbols for
Raven Ridge systems may have malfunction touchpad or hang at boot if
incorrect IVRS IOAPIC is provided by BIOS.
Users already found correct "ivrs_ioapic=" values, let's put them inside
kernel to workaround buggy BIOS.
BugLink: https://bugs.launchpad.net/bugs/1795292
BugLink:
The default domain type of an iommu group can be changed using file
"/sys/kernel/iommu_groups//type". Hence, document it's usage and
more importantly spell out it's limitations and an example.
Cc: Christoph Hellwig
Cc: Joerg Roedel
Cc: Ashok Raj
Cc: Will Deacon
Cc: Lu Baolu
Cc: Sohil Mehta
Presently, the default domain of an iommu_group is allocated during boot
time (i.e. when a device is being added to a group) and it cannot be
changed later. So, the device would typically be either in identity (also
known as pass_through) mode (controlled by "iommu=pt" kernel command line
device_def_domain_type() determines the domain type a device could have and
currently it's called only during boot time. Since the function is called
only during boot time, it *always* considers command line arguments like
"intel_iommu=igfx_off" and "iommu=pt" to determine the domain type of a
When user requests kernel to change the default domain type of a group
through sysfs, kernel has to make sure that it's ok to change the domain
type of every device in the group to the requested domain (every device may
not support both the domain types i.e. DMA and identity). Hence, add a call
Presently, the default domain of a group is allocated during boot time and it
cannot be changed later. So, the device would typically be either in identity
(pass_through) mode or the device would be in DMA mode as long as the
system is up and running. There is no way to change the default domain
Dear Linux folks,
I'm investigating a problem, that the crash utility fails to work with our
crash dumps:
buczek@kreios:/mnt$ crash vmlinux crash.vmcore
crash 7.2.6
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright
Global pages support is removed from VT-d spec 3.0. Since global pages G
flag only affects first-level paging structures and because DMA request
with PASID are only supported by VT-d spec. 3.0 and onward, we can
safely remove global pages support.
For kernel shared virtual address IOTLB
On 20.08.19 09:12, Christoph Hellwig wrote:
On Tue, Aug 20, 2019 at 02:58:33PM +0800, Hillf Danton wrote:
On Tue, 20 Aug 2019 05:05:14 +0200 Christoph Hellwig wrote:
Tobias, plase try this patch:
New version below:
---
From b8a805e93be5a5662323b8ac61fe686df839c4ac Mon Sep 17 00:00:00
Support the DOMAIN_ATTR_SPLIT_TABLES attribute to let the leaf driver
know if split pagetables are enabled for the domain.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index
This is another iteration to support split pagetables for Adreno GPUs as part of
an incremental process to enable per-context pagetables.
In order to support per-context pagetables the GPU needs to enable split
pagetables so that we can store the global buffers in the TTBR1 space leaving
the GPU
Add a new attribute to query the state of split pagetables for the domain.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index fdc355c..b06db6c 100644
--- a/include/linux/iommu.h
+++
Support a split pagetable format for SMMU models that support it. If
enabled, mirror the TTBR0 setup for TTBR1 and program the pagetable
address in TTBR1 instead of TTBR0.
For now only allow split pagetables for ARM64 stage 1 IOMMUs with 49 bit
upstream buses. This is the only real-life use case
Add a SMMU model for the Adreno GPU and use it to enable split
pagetable support if the conditions are right.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu-impl.c | 15 +++
drivers/iommu/arm-smmu.c | 2 ++
drivers/iommu/arm-smmu.h | 1 +
3 files changed, 18
Add a compatible string to identify SMMUs that are attached
to Adreno GPU devices that wish to support split pagetables.
Signed-off-by: Jordan Crouse
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
On 20/08/2019 17:07, Will Deacon wrote:
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
On 20/08/2019 11:31, Will Deacon wrote:
On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR
Hi Rob,
thanks for the rewiew.
On Tue, 2019-08-20 at 12:16 -0500, Rob Herring wrote:
> On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
> wrote:
> > Provides the same functionality as of_machine_is_compatible.
> >
> > Signed-off-by: Nicolas Saenz Julienne
> > ---
> >
> > Changes in v2:
On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
wrote:
>
> Provides the same functionality as of_machine_is_compatible.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
>
> Changes in v2: None
>
> drivers/of/fdt.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne
wrote:
>
> Some devices might have weird DMA addressing limitations that only apply
> to a subset of the available peripherals. For example the Raspberry Pi 4
> has two interconnects, one able to address the whole lower 4G memory
> area and
On Tue, Aug 20, 2019 at 05:50:06PM +0100, Robin Murphy wrote:
> On 20/08/2019 16:45, Will Deacon wrote:
> > When invalidating the ATC for an PCIe endpoint using ATS, we must take
> > care to complete invalidation of the main SMMU TLBs beforehand, otherwise
> > the device could immediately
On 20/08/2019 16:45, Will Deacon wrote:
When invalidating the ATC for an PCIe endpoint using ATS, we must take
care to complete invalidation of the main SMMU TLBs beforehand, otherwise
the device could immediately repopulate its ATC with stale translations.
Hooking the ATC invalidation into
On Tue, Aug 20, 2019 at 05:12:11PM +0100, Robin Murphy wrote:
> On 20/08/2019 16:45, Will Deacon wrote:
> > To prevent any potential issues arising from speculative Address
> > Translation Requests from an ATS-enabled PCIe endpoint, rework our ATS
> > enabling/disabling logic so that we enable ATS
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> >On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> >>Although it's conceptually nice for the io_pgtable_cfg to provide a
> >>standard VMSA TCR value, the reality is that no
set_msi_sid_cb() is used to determine whether device aliases share the
same bus, but it can provide false indications that aliases use the same
bus when in fact they do not. The reason is that set_msi_sid_cb()
assumes that pdev is fixed, while actually pci_for_each_dma_alias() can
call fn() when
On 20/08/2019 16:45, Will Deacon wrote:
To prevent any potential issues arising from speculative Address
Translation Requests from an ATS-enabled PCIe endpoint, rework our ATS
enabling/disabling logic so that we enable ATS at the SMMU before we
enable it at the endpoint, and disable things in
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> > > Although it's conceptually nice for the io_pgtable_cfg to provide a
> > > standard VMSA TCR value, the reality is that no
On Tue, Aug 20, 2019 at 03:51:45PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:30, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> > > Now that callers are free to use a given table for TTBR1 if they wish
> > > (all they need do is shift the provided
On Tue, Aug 20, 2019 at 03:17:19PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:19, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
> > > TTBR1 values have so far been redundant since no users implement any
> > > support for split address spaces. Crucially,
When ATS is not in use, we can avoid taking the 'devices_lock' for the
domain on the invalidation path by simply caching the number of ATS
masters currently attached. The fiddly part is handling a concurrent
->attach() of an ATS-enabled master to a domain that is being
invalidated, but we can
It turns out that we've always relied on some subtle ordering guarantees
when inserting commands into the SMMUv3 command queue. With the recent
changes to elide locking when possible, these guarantees become more
subtle and even more important.
Add a comment documented the barrier semantics of
When invalidating the ATC for an PCIe endpoint using ATS, we must take
care to complete invalidation of the main SMMU TLBs beforehand, otherwise
the device could immediately repopulate its ATC with stale translations.
Hooking the ATC invalidation into ->unmap() as we currently do does the
exact
To prevent any potential issues arising from speculative Address
Translation Requests from an ATS-enabled PCIe endpoint, rework our ATS
enabling/disabling logic so that we enable ATS at the SMMU before we
enable it at the endpoint, and disable things in the opposite order.
Signed-off-by: Will
Hi all,
This series arose from my attempt to remove the 'devices_lock' from the
->unmap() path. In actual fact, I think the current code in mainline
gets this wrong, so I've fixed up the ordering and then removed the lock.
Unfortunately, this relies on my deferred invalidation work so that the
On 20/08/2019 11:31, Will Deacon wrote:
On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
looks exactly like an Arm CPU, and they all have various
By the time we call zones_sizes_init() arm64_dma_phys_limit already
contains the result of max_zone_dma_phys(). We use the variable instead
of calling the function directly to save some precious cpu time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2: None
arch/arm64/mm/init.c | 2
Some devices might have multiple interconnects with different DMA
addressing limitations. This function provides the higher physical
address accessible by all peripherals on the SoC. If such limitation
doesn't exist it'll return the maximum physical address of the 32 bit
addressable area.
These zones usage has evolved with time and the comments were outdated.
This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date
examples on how they are used on different architectures.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2:
- Try another approach merging
Some devices might have weird DMA addressing limitations that only apply
to a subset of the available peripherals. For example the Raspberry Pi 4
has two interconnects, one able to address the whole lower 4G memory
area and another one limited to the lower 1G.
Being an uncommon situation we
Some architectures, notably arm64, are interested in tweaking this
depending on their runtime dma addressing limitations.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2:
- Rename new variable to zone_dma_bits
- Update comment with Christoph's suggestion
- Remove old powerpc comment
So far all arm64 devices have supported 32 bit DMA masks for their
peripherals. This is not true anymore for the Raspberry Pi 4 as most of
it's peripherals can only address the first GB or memory of a total of
up to 4 GB.
This goes against ZONE_DMA32's original intent, and breaks other
subsystems
With the introduction of ZONE_DMA in arm64 devices are not forced to
support 32 bit DMA masks. We have to inform dma-direct of this
limitation whenever it happens.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2:
- Make sure to filter the higher part of arm64_dma_phys_limit
- Rename
Hi all,
this series attempts to address some issues we found while bringing up
the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
up of these discussions:
v1: https://lkml.org/lkml/2019/7/31/922
RFC: https://lkml.org/lkml/2019/7/17/476
The new Raspberry Pi 4 has up to 4GB of
'dma_zone_size' was created as a generic replacement to
'arm_dma_zone_size'. Use it accordingly.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2: None
arch/arm/include/asm/dma.h | 8 +---
arch/arm/mm/init.c | 12
2 files changed, 9 insertions(+), 11
Some architectures have platform specific DMA addressing limitations.
This will allow for hardware description code to provide the constraints
in a generic manner, so as for arch code to properly setup it's memory
zones and DMA mask.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2: None
Let the name indicate that they are used to calculate ZONE_DMA32's size
as opposed to ZONE_DMA.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2: None
arch/arm64/mm/init.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git
Provides the same functionality as of_machine_is_compatible.
Signed-off-by: Nicolas Saenz Julienne
---
Changes in v2: None
drivers/of/fdt.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9cdf14b9aaab..06ffbd39d9af 100644
---
On 20/08/2019 11:30, Will Deacon wrote:
On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
Now that callers are free to use a given table for TTBR1 if they wish
(all they need do is shift the provided attributes when constructing
their final TCR value), the only remaining impediment
On 20/08/2019 11:19, Will Deacon wrote:
On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
TTBR1 values have so far been redundant since no users implement any
support for split address spaces. Crucially, though, one of the main
reasons for wanting to do so is to be able to manage
On 19/08/2019 23:34, Jordan Crouse wrote:
On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
Now that callers are free to use a given table for TTBR1 if they wish
(all they need do is shift the provided attributes when constructing
their final TCR value), the only remaining
From: Robin Murphy
[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
From: Robin Murphy
[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
From: Robin Murphy
[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
From: Lucas Stach
[ Upstream commit d8ad55538abe443919e20e0bb996561bca9cad84 ]
The dma required_mask needs to reflect the actual addressing capabilities
needed to handle the whole system RAM. When truncated down to the bus
addressing capabilities dma_addressing_limited() will incorrectly signal
From: Robin Murphy
[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]
Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
On 20/08/2019 11:15, Vivek Gautam wrote:
[...]
Hi Robin,
Sorry for responding late to this series. I have couple of doubts here
that I wanted to discuss.
Are we standardizing these implementation specific ops? Each vendor
implementations will have something peculiar to take care. Things are
Hi Gregory, Hanna,
On Thu, Jul 11, 2019 at 05:02:39PM +0200, Gregory CLEMENT wrote:
> From: Hanna Hawa
>
> This patch introduces the smmu_writeq_relaxed/smmu_readq_relaxed
> helpers, as preparation to add specific Marvell work-around for
> accessing 64 bits width registers of ARM SMMU.
>
>
On Tue, Aug 20, 2019 at 12:38:49PM +0100, Robin Murphy wrote:
> In a hurry to get things ready for merging, we missed that one more
> include needs moving to arm-smmu.h along with the register accessors
> to prevent 32-bit builds breaking, and some missing static specifiers
> made Sparse sad.
I
In a hurry to get things ready for merging, we missed that one more
include needs moving to arm-smmu.h along with the register accessors
to prevent 32-bit builds breaking, and some missing static specifiers
made Sparse sad.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-impl.c | 8
On Mon, Aug 19, 2019 at 03:22:51PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This variable has no users anymore. Remove it and tell the
> IOMMU code via its new functions about requested DMA modes.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/iommu.h | 1 -
>
On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> Now that callers are free to use a given table for TTBR1 if they wish
> (all they need do is shift the provided attributes when constructing
> their final TCR value), the only remaining impediment is the address
> validation on
On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> Although it's conceptually nice for the io_pgtable_cfg to provide a
> standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> looks exactly like an Arm CPU, and they all have various other TCR
> controls which
On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
> TTBR1 values have so far been redundant since no users implement any
> support for split address spaces. Crucially, though, one of the main
> reasons for wanting to do so is to be able to manage each half entirely
> independently,
On 8/16/2019 12:07 AM, Robin Murphy wrote:
Allocating and initialising a context for a domain is another point
where certain implementations are known to want special behaviour.
Currently the other half of the Cavium workaround comes into play here,
so let's finish the job to get the whole
Hi Will,
On Mon, Aug 19, 2019 at 05:58:34PM +0100, Will Deacon wrote:
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the git repository at:
>
>
> +static int handle_deferred_device(struct device *dev,
> + struct iommu_domain *domain)
Nitick: we usually use double tab indents (or indents to after
the opening brace) for multi-line prototyped.
> + if (!is_kdump_kernel())
> + return 0;
> +
> + if
Looks good, and should probably be queued up asap as a bug fix:
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> iommu_map doesn’t lock while mapping and so no two calls should touch
> the same iova range. The AMD driver already handles the page table page
> allocations without
On 8/16/2019 12:07 AM, Robin Murphy wrote:
Hi all,
v1 for context: https://patchwork.kernel.org/cover/11087347/
Here's a quick v2 attempting to address all the minor comments; I've
tweaked a whole bunch of names, added some verbosity in macros and
comments for clarity, and rejigged
On Tue, Aug 20, 2019 at 02:58:33PM +0800, Hillf Danton wrote:
>
> On Tue, 20 Aug 2019 05:05:14 +0200 Christoph Hellwig wrote:
> >
> > Tobias, plase try this patch:
> >
New version below:
---
>From b8a805e93be5a5662323b8ac61fe686df839c4ac Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date:
On Mon, Aug 19, 2019 at 07:10:45PM +0100, Robin Murphy wrote:
> On 19/08/2019 16:56, Will Deacon wrote:
> > On Thu, Aug 15, 2019 at 07:37:20PM +0100, Robin Murphy wrote:
> > > v1 for context: https://patchwork.kernel.org/cover/11087347/
> > >
> > > Here's a quick v2 attempting to address all the
On Tue, 20 Aug 2019 05:05:14 +0200 Christoph Hellwig wrote:
>
> Tobias, plase try this patch:
>
A minute!
> --
> >From 88c590a2ecafc8279388f25bfbe1ead8ea3507a6 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Tue, 20 Aug 2019 11:45:49 +0900
> Subject: dma-direct: fix zone selection
73 matches
Mail list logo
