On Tue, Sep 02, 2014 at 07:26:01AM +0100, Marek Szyprowski wrote:
> Hi Will,
Hi Marek,
> On 2014-08-29 17:54, Will Deacon wrote:
> > This patch series is an RFC to implement IOMMU master configuration into
> > of_dma_configure. I haven't yet ported any IOMMU drivers to it, so it
> > remains untes
Hi Will,
On 2014-09-02 10:31, Will Deacon wrote:
On Tue, Sep 02, 2014 at 07:26:01AM +0100, Marek Szyprowski wrote:
On 2014-08-29 17:54, Will Deacon wrote:
This patch series is an RFC to implement IOMMU master configuration into
of_dma_configure. I haven't yet ported any IOMMU drivers to it, so
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
>
> > -- I have concerns that allocating one domain per master might be
> > too much, but it's hard to tell without an IOMMU driver ported over.
>
> One domain per master is IMHO a sane default configuration. The only default
> alter
VFIO allows devices to be safely handed off to userspace by putting
them behind an IOMMU configured to ensure DMA and interrupt isolation.
This enables userspace KVM clients, such as kvmtool and qemu, to further
map the device into a virtual machine.
With IOMMUs such as the ARM SMMU, it is then po
Hello,
This is version three of the patches I originally posted here:
RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552
RFCv2: http://permalink.gmane.org/gmane.linux.kernel.iommu/5700
Changes since RFCv2 include:
- Dropped the RFC tag
- Rebased onto 3.17-rc*
- Iterate th
Some IOMMUs, such as the ARM SMMU, support two stages of translation.
The idea behind such a scheme is to allow a guest operating system to
use the IOMMU for DMA mappings in the first stage of translation, with
the hypervisor then installing mappings in the second stage to provide
isolation of the
When domains are set with the DOMAIN_ATTR_NESTING flag, we must ensure
that we allocate them to stage-2 context banks if the hardware permits
it.
This patch adds support for the attribute to the ARM SMMU driver, with
the actual stage being determined depending on the features supported
by the hard
On Mon, Sep 01, 2014 at 09:18:26PM +0100, Arnd Bergmann wrote:
> On Monday 01 September 2014 17:40:00 Will Deacon wrote:
> > On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
> > > On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
> > > >
> > > > I think this could use a bit
On Monday 01 September 2014 16:46:18 Arnd Bergmann wrote:
> On Monday 01 September 2014 10:29:40 Thierry Reding wrote:
> > I think this could use a bit more formalization. As I said in another
> > reply earlier, there's very little standardization in the IOMMU API.
> > That certainly gives us a lot
Hi Arnd,
On 2014-09-02 10:56, Arnd Bergmann wrote:
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
-- I have concerns that allocating one domain per master might be
too much, but it's hard to tell without an IOMMU driver ported over.
One domain per master is IMHO a sane defaul
Hi Will,
Thank you for the patch.
On Friday 29 August 2014 16:54:27 Will Deacon wrote:
> The generic IOMMU device-tree bindings can be used to add arbitrary OF
> masters to an IOMMU with a compliant binding.
>
> This patch introduces of_iommu_configure, which does exactly that.
>
> Signed-off-b
On Tue, Sep 02, 2014 at 11:42:13AM +0100, Marek Szyprowski wrote:
> On 2014-09-02 10:56, Arnd Bergmann wrote:
> > On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
> >>>-- I have concerns that allocating one domain per master might be
> >>> too much, but it's hard to tell without an
On Tue, Sep 02, 2014 at 11:51:54AM +0100, Laurent Pinchart wrote:
> Hi Will,
Hi Laurent,
> On Friday 29 August 2014 16:54:27 Will Deacon wrote:
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index dd5112265cc9..6d13f962f156 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/driv
Hi Will,
We would still need a mechanism to distinguish stage1 mapping from stage2
mapping i.e. for nested translation we should be able to specify whether the
mapping corresponds to stage1 or stage 2 translation. Also, correspondingly we
would require different context banks for stage 1 and sta
On Tue, Sep 02, 2014 at 12:12:20PM +0100, Varun Sethi wrote:
> We would still need a mechanism to distinguish stage1 mapping from stage2
> mapping i.e. for nested translation we should be able to specify whether
> the mapping corresponds to stage1 or stage 2 translation. Also,
> correspondingly we
On Tuesday 02 September 2014 11:03:42 Will Deacon wrote:
> On Mon, Sep 01, 2014 at 09:18:26PM +0100, Arnd Bergmann wrote:
> > On Monday 01 September 2014 17:40:00 Will Deacon wrote:
> > > On Mon, Sep 01, 2014 at 03:46:18PM +0100, Arnd Bergmann wrote:
> > > > On Monday 01 September 2014 10:29:40 Thi
On Tuesday 02 September 2014 12:42:13 Marek Szyprowski wrote:
> Hi Arnd,
>
> On 2014-09-02 10:56, Arnd Bergmann wrote:
> > On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
> >>>-- I have concerns that allocating one domain per master might be
> >>> too much, but it's hard to tell
Hi Will,
On 2014-09-02 12:57, Will Deacon wrote:
On Tue, Sep 02, 2014 at 11:42:13AM +0100, Marek Szyprowski wrote:
On 2014-09-02 10:56, Arnd Bergmann wrote:
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
-- I have concerns that allocating one domain per master might be
too
Hi Arnd,
On 2014-09-02 14:22, Arnd Bergmann wrote:
On Tuesday 02 September 2014 12:42:13 Marek Szyprowski wrote:
On 2014-09-02 10:56, Arnd Bergmann wrote:
On Tuesday 02 September 2014 10:48:02 Marek Szyprowski wrote:
-- I have concerns that allocating one domain per master might be
too mu
On Tuesday 02 September 2014 14:24:18 Marek Szyprowski wrote:
> >>> For isolation purposes, it can only help to have more domains, but
> >>> I would guess that there is some space overhead in maintaining lots
> >>> of page tables.
> >> I'm okay with both approaches (separate domain for each device
On Tuesday 02 September 2014 14:30:36 Marek Szyprowski wrote:
> However we also need to figure out how to let drivers to make their own
> configuration, like it is required by Exynos DRM subsystem, which consist
> of several devices, each having its own IOMMU controller, but for
> >>
On Tue, Sep 02, 2014 at 01:15:06PM +0100, Arnd Bergmann wrote:
> On Tuesday 02 September 2014 11:03:42 Will Deacon wrote:
> > On Mon, Sep 01, 2014 at 09:18:26PM +0100, Arnd Bergmann wrote:
> > > I don't mind handling PCI devices separately. They are different in a
> > > number
> > > of ways alread
On 2014-09-02 14:46, Arnd Bergmann wrote:
On Tuesday 02 September 2014 14:30:36 Marek Szyprowski wrote:
However we also need to figure out how to let drivers to make their own
configuration, like it is required by Exynos DRM subsystem, which consist
of several devices, each having its own IOMMU
On Tuesday 02 September 2014 14:05:08 Will Deacon wrote:
> On Tue, Sep 02, 2014 at 01:15:06PM +0100, Arnd Bergmann wrote:
> > > Anyway, I'll try to hack something together shortly. I think the proposal
> > > is:
> > >
> > > - Make add_device_master_ids take a generic structure (struct iommu)
>
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
> Hi Greg,
>
> On 2014-08-05 12:47, Marek Szyprowski wrote:
> > This patch adds a new flags for device drivers. This flag instructs
> > kernel that the device driver does it own management of IOMMU assisted
> > IO address space tran
Hi Will,
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Friday, August 29, 2014 9:24 PM
> To: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org
> Cc: a...@arndb.de; dw...@infradead.org; jroe...@suse.de;
> hd...@nvidia.com; Sethi Varun-B16
Hi Will,
I am not clear on the functionality we want to achieve with this new API. Is
this a way to link devices to a particular IOMMU? Would this be used to filter
out add_device invocations i.e. iommu group creations just for the devices
attached to a particular IOMMU?
What is the purpose of
Hi Thierry/Will/Arnd,
Where would the of_xlate callback reside and what would be its function?
Regards
Varun
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 02, 2014 5:45 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Will Deacon; jroe...
On Tuesday 02 September 2014 14:47:54 Varun Sethi wrote:
> > +void __init of_iommu_init(void)
> > +{
> > + struct device_node *np;
> > + const struct of_device_id *match, *matches = &__iommu_of_table;
> > +
> > + for_each_matching_node_and_match(np, matches, &match) {
> > +
On Tuesday 02 September 2014 15:03:14 Varun Sethi wrote:
> Hi Thierry/Will/Arnd,
> Where would the of_xlate callback reside and what would be its function?
>
It is an additional function pointer in iommu_ops and replaces the
add_device callback for IOMMUs that are DT-enabled.
The idea is that w
On Sun, Jun 8, 2014 at 12:17 PM, Christoffer Dall
wrote:
> On Thu, Jun 05, 2014 at 07:03:23PM +0200, Antonios Motakis wrote:
>> Adds support to mask interrupts, and also for automasked interrupts.
>> Level sensitive interrupts are exposed as automasked interrupts and
>> are masked and disabled aut
On Sun, Jun 8, 2014 at 12:09 PM, Christoffer Dall
wrote:
>
> On Thu, Jun 05, 2014 at 07:03:22PM +0200, Antonios Motakis wrote:
> > This patch allows to set an eventfd for a patform device's interrupt,
> > and also to trigger the interrupt eventfd from userspace for testing.
> >
> > Signed-off-by:
We need to ensure that the IOMMUs in the system have a chance to perform
some basic initialisation before we start adding masters to them.
This patch adds a call to of_iommu_init before of_platform_populate.
Signed-off-by: Will Deacon
---
arch/arm/kernel/setup.c | 5 -
1 file changed, 4 ins
The generic IOMMU device-tree bindings can be used to add arbitrary OF
masters to an IOMMU with a compliant binding.
This patch introduces of_iommu_configure, which does exactly that.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/of_iommu.c| 52 ++
This patch adds a new function to the iommu_ops structure to allow an
OF device to be added to a specific IOMMU instance using the recently
merged generic devicetree binding for IOMMUs. The callback (of_xlate)
takes a struct device representing the master and an of_phandle_args
representing the IOM
This patch extends of_dma_configure so that it sets up the IOMMU for a
device, as well as the coherent/non-coherent DMA mapping ops.
Signed-off-by: Will Deacon
---
arch/arm/include/asm/dma-mapping.h | 5 -
drivers/of/platform.c | 36 ++--
include
Hello again,
Hot on the heels of my initial RFC, here's a v2 of the posting from here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
The main difference since v1 is that I've introduced some generic
structures to represent IOMMUs and their mappings (stru
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
actually called outside of a few drivers) into arch_setup_dma_ops, so
that we can use IOMMUs for DMA transfers in a more generic fashion.
Since this significantly complicates the arch_setup_dma_ops function,
it is moved out o
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be configured for the bus in
question. To solve this, a number of IOMMU drivers use initcalls to
initialise the driver before anything has a chance to be probed.
Whilst this solves the im
set_arch_dma_coherent_ops is called from of_dma_configure in order to
swizzle the architectural dma-mapping functions over to a cache-coherent
implementation. This is currently implemented only for ARM.
In anticipation of re-using this mechanism for IOMMU-backed dma-mapping
ops too, this patch rep
On Tuesday 02 September 2014 18:56:26 Will Deacon wrote:
> @@ -803,9 +804,11 @@ static int __init customize_machine(void)
> if (machine_desc->init_machine)
> machine_desc->init_machine();
> #ifdef CONFIG_OF
> - else
> + else {
> + of_iommu_init();
On Tuesday 02 September 2014 18:56:27 Will Deacon wrote:
> This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
> actually called outside of a few drivers) into arch_setup_dma_ops, so
> that we can use IOMMUs for DMA transfers in a more generic fashion.
>
> Since this significa
Hi Will,
On Tuesday 02 September 2014 12:03:40 Will Deacon wrote:
> On Tue, Sep 02, 2014 at 11:51:54AM +0100, Laurent Pinchart wrote:
> > On Friday 29 August 2014 16:54:27 Will Deacon wrote:
[snip]
> > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > > index f9209666157c..a
On Tuesday 02 September 2014 18:56:24 Will Deacon wrote:
> +struct iommu_dma_mapping *of_iommu_configure(struct device *dev)
> +{
> + struct of_phandle_args iommu_spec;
> + struct iommu_dma_mapping *mapping;
> + struct bus_type *bus = dev->bus;
> + const struct iommu_ops *op
On Tuesday 02 September 2014 18:56:20 Will Deacon wrote:
> The main difference since v1 is that I've introduced some generic
> structures to represent IOMMUs and their mappings (struct iommu_data and
> struct iommu_dma_mapping). This allows us to propagate the per-instance
> data all the way down t
On Tue, Sep 02, 2014 at 04:01:32PM +0200, Arnd Bergmann wrote:
> This is an artifact of the API being single-instance at the moment.
> We might not in fact need it, I was just trying to think of things
> that naturally fit in there and that are probably already linked
> together in the individual i
On Tuesday 02 September 2014 14:43:18 Arnd Bergmann wrote:
> On Tuesday 02 September 2014 14:24:18 Marek Szyprowski wrote:
> > >>> For isolation purposes, it can only help to have more domains, but
> > >>> I would guess that there is some space overhead in maintaining lots
> > >>> of page tables.
>
47 matches
Mail list logo
