> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, July 01, 2016 12:40 PM
> To: Stuart Yoder
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout
>
>
On 01/07/16 17:15, Robin Murphy wrote:
> On 01/07/16 17:03, Stuart Yoder wrote:
>>
>>
>>> -Original Message-
>>> From: Robin Murphy
>>> Date: Tue, Jun 28, 2016 at 11:18 AM
>>> Subject: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout
>>> To: iommu@lists.linux-foundation.org, l
Introduce a common structure to hold the per-device firmware data that
non-architectural IOMMU drivers generally need to keep track of.
Initially this is DT-specific to complement the existing of_iommu
support code, but will generalise further once other firmware methods
(e.g. ACPI IORT) come along
Now that we can properly describe the mapping between PCI RIDs and
stream IDs via "iommu-map", and have it fed it to the driver
automatically via of_xlate(), rework the SMMUv3 driver to benefit from
that, and get rid of the current misuse of the "iommus" binding.
Since having of_xlate wired up mea
Now that we have a way to pick up the RID translation and target IOMMU,
hook up of_iommu_configure() to bring PCI devices into the of_xlate
mechanism and allow them IOMMU-backed DMA ops without the need for
driver-specific handling.
Signed-off-by: Robin Murphy
---
v4: No change.
drivers/iommu/
Implement the SMMUv3 equivalent of d346180e70b9 ("iommu/arm-smmu: Treat
all device transactions as unprivileged"), so that once again those
pesky DMA controllers with their privileged instruction fetches don't
unexpectedly fault in stage 1 domains due to VMSAv8 rules.
Signed-off-by: Robin Murphy
With the device <-> stream ID relationship suitably abstracted and
of_xlate() hooked up, the PCI dependency now looks, and is, entirely
arbitrary. Any bus using the of_dma_configure() mechanism will work,
so extend support to the platform and AMBA buses which do just that.
Signed-off-by: Robin Mur
From: Lorenzo Pieralisi
Current bus notifier in ARM64 (__iommu_attach_notifier)
attempts to attach dma_ops to a device on BUS_NOTIFY_ADD_DEVICE
action notification.
This will cause issues on ACPI based systems, where PCI devices
can be added before the IOMMUs the devices are attached to
had a ch
Here's a quick repost to address the comments on v3[1], in the hope of
making some progress while I'm away next week.
I've dropped the workaround consolidation patch (and added the
equivalent to patch 6) since it's as much of a step sideways as in the
right direction, so we may as well hold off un
The PCI msi-map code is already doing double-duty translating IDs and
retrieving MSI parents, which unsurprisingly is the same functionality
we need for the identically-formatted PCI iommu-map property. Drag the
core parsing routine up yet another layer into the general OF-PCI code,
and further gen
From: Mark Rutland
The existing IOMMU bindings are able to specify the relationship between
masters and IOMMUs, but they are insufficient for describing the general
case of hotpluggable busses such as PCI where the set of masters is not
known until runtime, and the relationship between masters an
On 01/07/16 17:03, Stuart Yoder wrote:
>
>
>> -Original Message-
>> From: Robin Murphy
>> Date: Tue, Jun 28, 2016 at 11:18 AM
>> Subject: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout
>> To: iommu@lists.linux-foundation.org, linux-arm-ker...@lists.infradead.org
>>
>>
>> C
> -Original Message-
> From: Robin Murphy
> Date: Tue, Jun 28, 2016 at 11:18 AM
> Subject: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout
> To: iommu@lists.linux-foundation.org, linux-arm-ker...@lists.infradead.org
>
>
> Certain peripherals may be bestowed with knowledge
Hi Linus,
The following changes since commit a4c34ff1c029e90e7d5f8dd8d29b0a93b31c3cb2:
iommu/vt-d: Enable QI on all IOMMUs before setting root entry (2016-06-17
11:29:48 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 30, 2016 19:44
> To: Nipun Gupta ; will.dea...@arm.com; Stuart Yoder
> ; iommu@lists.linux-foundation.org; linux-arm-
> ker...@lists.infradead.org
> Cc: Bharat Bhushan
> Subject: Re: [RFC PATCH
On 01/07/16 13:35, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:48:26PM +0100, Robin Murphy wrote:
>> Now that we can properly describe the mapping between PCI RIDs and
>> stream IDs via "iommu-map", and have it fed it to the driver
>> automatically via of_xlate(), rework the SMMUv3 driver to be
On 01/07/16 13:40, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:48:27PM +0100, Robin Murphy wrote:
>> With the device <-> stream ID relationship suitably abstracted and
>> of_xlate() hooked up, the PCI dependency now looks, and is, entirely
>> arbitrary. Any bus using the of_dma_configure() mech
On Tue, Jun 28, 2016 at 04:48:27PM +0100, Robin Murphy wrote:
> With the device <-> stream ID relationship suitably abstracted and
> of_xlate() hooked up, the PCI dependency now looks, and is, entirely
> arbitrary. Any bus using the of_dma_configure() mechanism will work,
> so extend support to the
On Tue, Jun 28, 2016 at 04:48:26PM +0100, Robin Murphy wrote:
> Now that we can properly describe the mapping between PCI RIDs and
> stream IDs via "iommu-map", and have it fed it to the driver
> automatically via of_xlate(), rework the SMMUv3 driver to benefit from
> that, and get rid of the curre
On Fri, Jul 01, 2016 at 12:19:51PM +0100, Robin Murphy wrote:
> On 01/07/16 11:32, Marek Szyprowski wrote:
> > Frankly, I would avoid moving this workaround to the iommu core. IMHO the
> > best solution would be to let IOMMU controllers to be instantiated as
> > normal
> > devices and implement pro
On 01/07/16 11:55, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:48:25PM +0100, Robin Murphy wrote:
>> Introduce a common structure to hold the per-device firmware data that
>> non-architectural IOMMU drivers generally need to keep track of.
>> Initially this is DT-specific to complement the exis
Hi Robin,
On 2016-07-01 13:19, Robin Murphy wrote:
Hi Marek,
On 01/07/16 11:32, Marek Szyprowski wrote:
Hi Robin,
On 2016-06-28 17:48, Robin Murphy wrote:
So far, all the users of the generic of_xlate configuration mechanism
are resorting to explicit platform device creation to ensure the
On 01/07/16 11:31, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:48:24PM +0100, Robin Murphy wrote:
>> Now that we have a way to pick up the RID translation and target IOMMU,
>> hook up of_iommu_configure() to bring PCI devices into the of_xlate
>> mechanism and allow them IOMMU-backed DMA ops wi
Hi Marek,
On 01/07/16 11:32, Marek Szyprowski wrote:
> Hi Robin,
>
>
> On 2016-06-28 17:48, Robin Murphy wrote:
>> So far, all the users of the generic of_xlate configuration mechanism
>> are resorting to explicit platform device creation to ensure the IOMMU
>> device is ready before anything tr
On Tue, Jun 28, 2016 at 04:48:25PM +0100, Robin Murphy wrote:
> Introduce a common structure to hold the per-device firmware data that
> non-architectural IOMMU drivers generally need to keep track of.
> Initially this is DT-specific to complement the existing of_iommu
> support code, but will gene
Hi Robin,
On 2016-06-28 17:48, Robin Murphy wrote:
So far, all the users of the generic of_xlate configuration mechanism
are resorting to explicit platform device creation to ensure the IOMMU
device is ready before anything tries to refer to it. As I'm about to
convert two more drivers that wil
On Tue, Jun 28, 2016 at 04:48:24PM +0100, Robin Murphy wrote:
> Now that we have a way to pick up the RID translation and target IOMMU,
> hook up of_iommu_configure() to bring PCI devices into the of_xlate
> mechanism and allow them IOMMU-backed DMA ops without the need for
> driver-specific handli
On Tue, Jun 28, 2016 at 04:48:21PM +0100, Robin Murphy wrote:
> So far, all the users of the generic of_xlate configuration mechanism
> are resorting to explicit platform device creation to ensure the IOMMU
> device is ready before anything tries to refer to it. As I'm about to
> convert two more d
28 matches
Mail list logo
