On Fri, 24 May 2019, Sergey Dyasli wrote:
> Current repeat code is plain broken for the early=true case. Xen exchanges
> all DMA (<4GB) pages that it can on the first xen_swiotlb_fixup() attempt.
> All further attempts with a halved region will fail immediately because
> all DMA pages already
Presently, "/sys/kernel/debug/iommu/intel/dmar_translation_struct" file
dumps DMAR tables in the below format
IOMMU dmar2: Root Table Address:4362cc000
Root Table Entries:
Bus: 0 H: 0 L: 4362f0001
Context Table Entries for Bus: 0
Entry B:D.F HighLow
160 00:14.0 102 4362ef001
A scalable mode DMAR table walk would involve looking at bits in each stage
of walk, like,
1. Is PASID enabled in the context entry?
2. What's the size of PASID directory?
3. Is the PASID directory entry present?
4. Is the PASID table entry present?
5. Number of PASID table entries?
Hence, add
Presently, "/sys/kernel/debug/iommu/intel/dmar_translation_struct" file dumps
only legacy DMAR table which consists of root table and context table. Scalable
mode DMAR table adds PASID directory and PASID table. Hence, add support to dump
these tables as well.
Directly extending the present
A DMAR table walk would typically follow the below process.
1. Bus number is used to index into root table which points to a context
table.
2. Device number and Function number are used together to index into
context table which then points to a pasid directory.
3. PASID[19:6] is used to
This allows the iommu generic layer to allocate an identity domain
and attach it to a device. Hence, the identity domain is delegated
to upper layer. As a side effect, iommu_identity_mapping can't be
used to check the existence of identity domains any more.
Signed-off-by: James Sewart
The code to prepare the static identity map for various reserved
memory ranges in intel_iommu_init() is duplicated with the default
domain mechanism now. Remove it to avoid duplication.
Signed-off-by: James Sewart
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 144
Previously, get_valid_domain_for_dev() is used to retrieve the
DMA domain which has been attached to the device or allocate one
if no domain has been attached yet. As we have delegated the DMA
domain management to upper layer, this function is used purely to
allocate a private DMA domain if the
As a domain is now attached to a device earlier, we should
implement the is_attach_deferred call-back and use it to
defer the domain attach from iommu driver init to device
driver init when iommu is pre-enabled in kdump kernel.
Suggested-by: Tom Murphy
Signed-off-by: Lu Baolu
---
When we put a device into an iommu group, the group's default
domain will be attached to the device. There are some corner
cases where the type (identity or dma) of the default domain
doesn't work for the device and the request of a new default
domain results in failure (e.x. multiple devices have
The iommu driver doesn't know whether the bit width of a PCI
device is sufficient for access to the whole system memory.
Hence, the driver checks this when the driver calls into the
dma APIs. If a device is using an identity domain, but the
bit width is less than the system requirement, we need to
The iommu generic code has handled the device hotplug cases.
Remove the duplicated code.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
Some platforms may support ACPI name-space enumerated devices
that are capable of generating DMA requests. Platforms which
support DMA remapping explicitly declares any such DMA-capable
ACPI name-space devices in the platform through ACPI Name-space
Device Declaration (ANDD) structure and
It isn't used anywhere. Remove it to make code concise.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 59cd8b7e793f..ba425db8cfc6 100644
This allows the iommu generic layer to allocate a dma domain and
attach it to a device through the iommu api's. With all types of
domains being delegated to upper layer, we can remove an internal
flag which was used to distinguish domains mananged internally or
externally.
Signed-off-by: James
This helper returns the default domain type that the device
requires.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 40 +
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
Normally during iommu probing a device, a default doamin will
be allocated and attached to the device. The domain type of
the default domain is statically defined, which results in a
situation where the allocated default domain isn't suitable
for the device due to some limitations. We already have
To support mapping ISA region via iommu_group_create_direct_mappings,
make sure its exposed by iommu_get_resv_regions.
Signed-off-by: James Sewart
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
Hi,
This patchset delegates the iommu DMA domain management to the
generic iommu layer. It avoids the use of find_or_alloc_domain
whose domain assignment is inconsistent with the iommu grouping
as determined by pci_device_group.
The major change is to permit domains of type IOMMU_DOMAIN_DMA
and
From: James Sewart
Used by iommu.c before creating identity mappings for reserved
ranges to ensure dma-ops won't ever remap these ranges.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
The rmrr devices require identity map of the rmrr regions before
enabling DMA remapping. Otherwise, there will be a window during
which DMA from/to the rmrr regions will be blocked. In order to
alleviate this, we move enabling DMA remapping after all rmrr
regions get mapped.
Signed-off-by: Lu
On Thu, May 23, 2019 at 10:08 PM Nicolin Chen wrote:
>
> [ Per discussion at v1, we decide to add two new functions and start
> replacing callers one by one. For this series, it only touches the
> dma-direct part. And instead of merging two PATCHes, I still keep
> them separate so that we
On Thu, 23 May 2019 19:06:13 +0100
Jean-Philippe Brucker wrote:
> Some IOMMU hardware features, for example PCI PRI and Arm SMMU Stall,
> enable recoverable I/O page faults. Allow IOMMU drivers to report PRI
> Page Requests and Stall events through the new fault reporting API.
> The consumer of
On Mon, Nov 26, 2018 at 11:31 AM Will Deacon wrote:
>
> Hi Rob,
>
> On Tue, Nov 13, 2018 at 08:12:35AM -0500, Rob Clark wrote:
> > On Tue, Nov 13, 2018 at 1:32 AM Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 01:01:55PM -0500, Rob Clark wrote:
> > > > On Mon, Oct 29, 2018 at 3:09 PM Will
So that all types are printed in the same format.
Fixes: c52c72d3dee81 ("iommu: Add sysfs attribyte for domain type")
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
On Thu, 23 May 2019 19:43:46 +0100
Robin Murphy wrote:
> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
> > From: Jacob Pan
> >
> > Device faults detected by IOMMU can be reported outside the IOMMU
> > subsystem for further processing. This patch introduces
> > a generic device fault data
Current repeat code is plain broken for the early=true case. Xen exchanges
all DMA (<4GB) pages that it can on the first xen_swiotlb_fixup() attempt.
All further attempts with a halved region will fail immediately because
all DMA pages already belong to Dom0.
Introduce contig_pages param for
On 21/05/2019 17:10, Clément Péron wrote:
Hi,
The Allwinner H6 has a Mali-T720 MP2 which should be supported by
the new panfrost driver. This series fix two issues and introduce the
dt-bindings but a simple benchmark show that it's still NOT WORKING.
I'm pushing it in case someone want to
On Fri, 24 May 2019 17:14:30 +0100
Jean-Philippe Brucker wrote:
> On 24/05/2019 14:49, Jacob Pan wrote:
> > On Thu, 23 May 2019 19:43:46 +0100
> > Robin Murphy wrote:
> >>> +/**
> >>> + * struct iommu_fault_event - Generic fault event
> >>> + *
> >>> + * Can represent recoverable faults such
On Thu, 23 May 2019 19:56:54 +0100
Robin Murphy wrote:
> On 23/05/2019 19:06, Jean-Philippe Brucker wrote:
> > From: Jacob Pan
> >
> > Traditionally, device specific faults are detected and handled
> > within their own device drivers. When IOMMU is enabled, faults such
> > as DMA related
On 24/05/2019 14:49, Jacob Pan wrote:
> On Thu, 23 May 2019 19:43:46 +0100
> Robin Murphy wrote:
>>> +/**
>>> + * struct iommu_fault_event - Generic fault event
>>> + *
>>> + * Can represent recoverable faults such as a page requests or
>>> + * unrecoverable faults such as DMA or IRQ remapping
On Thu, May 23, 2019 at 09:06:33PM -0700, Nicolin Chen wrote:
> The addresses within a single page are always contiguous, so it's
> not so necessary to always allocate one single page from CMA area.
> Since the CMA area has a limited predefined size of space, it may
> run out of space in heavy use
32 matches
Mail list logo
