linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] iommu/arm-smmu: Add function that conditionally isolates all masters of all SMMUs
Date: Tue, 8 Oct 2013 11:43:04 +0100	[thread overview]
Message-ID: <20131008104304.GH17148@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20131007154227.GC2935@alberich>

On Mon, Oct 07, 2013 at 04:42:27PM +0100, Andreas Herrmann wrote:
> On Fri, Sep 27, 2013 at 09:00:01AM -0400, Will Deacon wrote:
> > On Thu, Sep 26, 2013 at 11:36:19PM +0100, Andreas Herrmann wrote:
> > > +	list_for_each_entry(smmu, &arm_smmu_devices, list) {
> > > +		if (arm_smmu_disable_isolation ||
> > > +			(!(smmu->features & ARM_SMMU_FEAT_ISOLATE_DEVICES)
> > > +				&& !arm_smmu_force_isolation))
> > > +			continue;
> > > +		rbn = rb_first(&smmu->masters);
> > > +		while (rbn) {
> > > +			master = container_of(rbn, struct arm_smmu_master, node);
> > > +			pdev = of_find_device_by_node(master->of_node);
> > > +			if (!pdev)
> > > +				break;
> > > +			dev = &pdev->dev;
> > > +
> > > +			size = (size_t) dev->coherent_dma_mask;
> > > +			size = size ? : (unsigned long) dev->dma_mask;
> > 
> > Hmm, this could be *huge* with 64-bit capable DMA controllers (think LPAE).
> 
> Yes, agreed.
> (And even for 32-bit DMA this requires a large bitmap_size for the
> mapping.)
> 
> > Russell also has some pending dma mask cleanup, which might break some
> > assumptions here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/199397.html
> > 
> > (namely that we're offsetting everything from zero).
> 
> What do you think is a reasonable general value for the size of a
> mapping? (Do we need a DT property to specify this?)
> 
> What about a size of 128 MB -- if I'm not mistaken this requires a
> bitmap_size of 4K.

I don't think we can reasonably pick a sane number for this. We *could* try
doing it lazily (i.e. driving the mapping off a fault handler) but that's
pretty scary and probably doesn't interact well with endpoints incompatible
with the stall model (e.g. PCIe).

So the right solution is probably to get this information from the device
drivers, but I don't know what the interaction is with the dma_mask...
You'll need to do some digging.

Will

  reply	other threads:[~2013-10-08 10:43 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26 22:36 [PATCH 0/9] arm-smmu: Misc changes/Calxeda ECX-2000 support Andreas Herrmann
2013-09-26 22:36 ` [PATCH 1/9] iommu/arm-smmu: Switch to arch_initcall for driver registration Andreas Herrmann
2013-09-27  8:58   ` Will Deacon
2013-09-27  9:24     ` Andreas Herrmann
2013-09-27 10:02       ` [PATCH] iommu/arm-smmu: Switch to subsys_initcall " Andreas Herrmann
2013-09-26 22:36 ` [PATCH 2/9] iommu/arm-smmu: Calculate SMMU_CB_BASE from smmu register values Andreas Herrmann
2013-09-27  9:51   ` Will Deacon
2013-09-27 10:23     ` Andreas Herrmann
2013-09-27 10:51       ` Will Deacon
2013-09-27 11:05         ` Andreas Herrmann
2013-09-27 11:08           ` Will Deacon
2013-09-27 14:33             ` [PATCH] iommu/arm-smmu: Refine check for proper size of mapped region Andreas Herrmann
2013-09-26 22:36 ` [PATCH 3/9] ARM: dma-mapping: Always pass proper prot flags to iommu_map() Andreas Herrmann
2013-09-27  8:35   ` Will Deacon
2013-09-30 13:40   ` Marek Szyprowski
2013-09-26 22:36 ` [PATCH 4/9] iommu/arm-smmu: Check for num_context_irqs > 0 to avoid divide by zero exception Andreas Herrmann
2013-09-27  8:41   ` Will Deacon
2013-09-27  9:03     ` Andreas Herrmann
2013-09-27 10:23       ` Will Deacon
2013-09-27 10:39         ` Andreas Herrmann
2013-09-27 10:48           ` Will Deacon
2013-09-27 11:07             ` Andreas Herrmann
2013-09-27 14:30               ` [PATCH] " Andreas Herrmann
2013-09-26 22:36 ` [PATCH 5/9] iommu/arm-smmu: Clear global and context bank fault status registers Andreas Herrmann
2013-09-27  8:52   ` Will Deacon
2013-09-30 13:54     ` Andreas Herrmann
2013-09-30 13:56       ` [PATCH] " Andreas Herrmann
2013-09-30 16:06         ` Will Deacon
2013-09-30 17:17           ` Andreas Herrmann
2013-09-30 18:30             ` Will Deacon
2013-09-30 21:06               ` Andreas Herrmann
2013-09-26 22:36 ` [PATCH 6/9] iommu/arm-smmu: Support buggy implemenations where all config accesses are secure Andreas Herrmann
2013-09-27 13:05   ` Will Deacon
2013-09-27 13:48     ` Andreas Herrmann
2013-09-26 22:36 ` [PATCH 7/9] iommu/arm-smmu: Add function that conditionally isolates all masters of all SMMUs Andreas Herrmann
2013-09-27 13:00   ` Will Deacon
2013-10-07 15:42     ` Andreas Herrmann
2013-10-08 10:43       ` Will Deacon [this message]
2013-09-26 22:36 ` [PATCH 8/9] iommu/arm-smmu: Introduce a default fault handler Andreas Herrmann
2013-09-27 10:09   ` Will Deacon
2013-09-27 10:45     ` Andreas Herrmann
2013-09-27 21:22       ` [PATCH] iommu/arm-smmu: Print context fault information Andreas Herrmann
2013-09-26 22:36 ` [PATCH 9/9] ARM: dts: Add nodes for SMMUs on Calxeda ECX-2000 Andreas Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131008104304.GH17148@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).