On Wed, Sep 17, 2014 at 09:16:09PM +0100, Mitchel Humpherys wrote:
> ARM SMMUs support memory access control via some bits in the translation
> table descriptor memory attributes. Currently we assume all translations
> are "unprivileged". Add support for privileged mappings, controlled by
> the IOM
We are using the same pfn for every pte we create while constructing the
pmd. Fix this by actually updating the pfn on each iteration of the pmd
construction loop.
It's not clear if we can actually hit this bug right now since iommu_map
splits up the calls to .map based on the page size, so we onl
On Wed, Sep 17, 2014 at 09:53:12AM +0100, Joerg Roedel wrote:
> Hi Will,
Hello Joerg,
> On Mon, Sep 08, 2014 at 05:51:36PM +0100, Will Deacon wrote:
> > On Fri, Sep 05, 2014 at 11:52:56AM +0100, Joerg Roedel wrote:
> > > From: Joerg Roedel
> > >
> > > Cc: Will Deacon
> > > Signed-off-by: Joerg
For a PCI device, aliases from the IVRS table won't be populated
into dma_alias_devfn until after iommu_init_device() is called on
each device. We therefore want to split init_iommu_group() to
be called from a separate loop immediately following.
Signed-off-by: Alex Williamson
Cc: sta...@vger.ke
It turns out that our assumption that aliases are always to the same
slot isn't true. One particular platform reports an IVRS alias of the
SATA controller (00:11.0) for the legacy IDE controller (00:14.1).
When we hit this, we attempt to use a single IOMMU group for
everything on the same bus, whi
We've had surprisingly little fallout from the DMA alias changes, but
unfortunately one regression has popped up. We have an AMD system
that seems to use the SATA controller to master transactions for the
legacy IDE controller and they are different slots on the root complex.
The IVRS reports 00:1
