Hi,
>Hi Marek,
>
>On 09/01/17 12:03, Marek Szyprowski wrote:
>> This patch prepares Exynos IOMMU driver for deferred probing
>> support. Once it gets added, of_xlate() callback might be called
>> more than once for the same SYSMMU controller and master device
>> (for example it happens when master
This patch introduces amd_iommu_get_num_iommus(). This is intended for
Perf AMD IOMMU driver.
Cc: Joerg Roedel
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.h| 2 ++
drivers/iommu/amd_iommu_init.c | 7 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git
This patch cleans up:
* Various bitwise operations in perf_iommu_enable_event
* Make use macros BIT(x)
This should not affect logic and functionality.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 12 ++--
1 file chan
This patch contains the following minor fixup:
* Fixed overflow handling since u64 delta would lose the MSB sign bit.
* Remove unnecessary local64_set().
* Coding style and make use of GENMASK_ULL macro.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch
This patch declare pr_fmt for perf/amd_iommu and remove unnecessary
pr_debug.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c
This patch adds multi-IOMMU support for perf by exposing
an AMD IOMMU PMU for each IOMMU found in the system via:
/sys/device/amd_iommu_x /* where x is the IOMMU index. */
This allows users to specify different events to be programed
onto performance counters of each IOMMU.
Cc: Peter Zijls
The current amd_iommu_pc_get_set_reg_val() cannot support multi-IOMMU.
It is also confusing since it is trying to support set and get in
one function.
So, this patch breaks it down to amd_iommu_pc_[get|set]_counter(),
and modifies them to allow callers to specify IOMMU index. This prepares
the dri
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point
device ID to locate an IOMMU and check the reported max banks/counters.
The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU,
and uses it to acquire a reference to the first IOMMU, which does not work
on certain syst
From: Suravee Suthikulpanit
This patch series modifies the existing IOMMU and Perf drivers to support
systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU instance.
This allows users to specify performance events and filters separately for each
IOMMU.
This has been tested on the
Hi Laurent,
On 2017-01-02 01:08:04 +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> On Monday 05 Sep 2016 12:52:44 Laurent Pinchart wrote:
> > On Wednesday 10 Aug 2016 13:22:19 Niklas Söderlund wrote:
> > > Enable slave transfers to a device behind a IPMMU by mapping the slave
> > > addresses usin
Hi Marek,
On 09/01/17 12:03, Marek Szyprowski wrote:
> This patch prepares Exynos IOMMU driver for deferred probing
> support. Once it gets added, of_xlate() callback might be called
> more than once for the same SYSMMU controller and master device
> (for example it happens when masters device dri
Now we have a flag value indicating an IRQ domain implements MSI,
let's set it on msi_create_irq_domain().
Signed-off-by: Eric Auger
---
v6: new
---
kernel/irq/msi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ee23006..ddc2f
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
---
v3 -> v4:
- do not handle PCI host bridge windows anymore
- encode
When attaching a group to the container, check the group's
reserved regions and test whether the IOMMU translates MSI
transactions. If yes, we initialize an IOVA allocator through
the iommu_get_msi_cookie API. This will allow the MSI IOVAs
to be transparently allocated on MSI controller's compose()
IOMMU_CAP_INTR_REMAP has been advertised in arm-smmu(-v3) although
on ARM this property is not attached to the IOMMU but rather is
implemented in the MSI controller (GICv3 ITS).
Now vfio_iommu_type1 checks MSI remapping capability at MSI controller
level, let's correct this.
Signed-off-by: Eric A
This patch registers the MSI and HT regions as non mappable
reserved regions. They will be exposed in the iommu-group sysfs.
For direct-mapped regions let's also use iommu_alloc_resv_region().
Signed-off-by: Eric Auger
---
v6 -> v7:
- use IOMMU_RESV_RESERVED
v5: creation
---
drivers/iommu/amd
This new function checks whether all MSI irq domains
implement IRQ remapping. This is useful to understand
whether VFIO passthrough is safe with respect to interrupts.
On ARM typically an MSI controller can sit downstream
to the IOMMU without preventing VFIO passthrough.
As such any assigned devic
In case the IOMMU translates MSI transactions (typical case
on ARM), we check MSI remapping capability at IRQ domain
level. Otherwise it is checked at IOMMU level.
At this stage the arm-smmu-(v3) still advertise the
IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be
removed in subsequent
This patch registers the [FEE0_h - FEF0_000h] 1MB MSI
range as a reserved region and RMRR regions as direct regions.
This will allow to report those reserved regions in the
iommu-group sysfs.
Signed-off-by: Eric Auger
---
v6 -> v7:
- report RMRR regions as direct regions
- Due to the usage
Introduce iommu_get_group_resv_regions whose role consists in
enumerating all devices from the group and collecting their
reserved regions. The list is sorted and overlaps between
regions of the same type are handled by merging the regions.
Signed-off-by: Eric Auger
---
v6 -> v7:
- avoid merge o
We introduce a new field to differentiate the reserved region
types and specialize the apply_resv_region implementation.
Legacy direct mapped regions have IOMMU_RESV_DIRECT type.
We introduce 2 new reserved memory types:
- IOMMU_RESV_MSI will characterize MSI regions that are mapped
- IOMMU_RESV_R
We introduce two new enum values for the irq domain flag:
- IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
an MSI domain
- IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
remapping capabilities.
Those values will be useful to check all MSI irq domains have
MSI remapping
iommu/arm-smmu: Implement reserved region get/put callbacks
The get() populates the list with the MSI IOVA reserved window.
At the moment an arbitray MSI IOVA window is set at 0x800
of size 1MB. This will allow to report those info in iommu-group
sysfs.
Signed-off-by: Eric Auger
---
v4: c
We want to extend the callbacks used for dm regions and
use them for reserved regions. Reserved regions can be
- directly mapped regions
- regions that cannot be iommu mapped (PCI host bridge windows, ...)
- MSI regions (because they belong to another address space or because
they are not transla
The GICv3 ITS is MSI remapping capable. Let's advertise
this property so that VFIO passthrough can assess IRQ safety.
Signed-off-by: Eric Auger
---
drivers/irqchip/irq-gic-v3-its.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-i
A new iommu-group sysfs attribute file is introduced. It contains
the list of reserved regions for the iommu-group. Each reserved
region is described on a separate line:
- first field is the start IOVA address,
- second is the end IOVA address,
- third is the type.
Signed-off-by: Eric Auger
---
As we introduced new reserved region types which do not require
mapping, let's make sure we only map direct mapped regions.
Signed-off-by: Eric Auger
---
v3 -> v4:
- use region's type and reword commit message and title
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff -
Introduce a new helper serving the purpose to allocate a reserved
region. This will be used in iommu driver implementing reserved
region callbacks.
Signed-off-by: Eric Auger
---
v3 -> v4:
- add INIT_LIST_HEAD(®ion->list)
- use int for prot param and add int type param
- remove implementation ou
From: Robin Murphy
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
Following LPC discussions, we now report reserved regions through
the iommu-group sysfs reserved_regions attribute file.
Reserved regions are populated through the IOMMU get_resv_region
callback (former get_dm_regions), now implemented by amd-iommu,
intel-iommu and arm-smmu:
- the intel-iommu repo
From: Robin Murphy
Whilst PCI devices may have 64-bit DMA masks, they still benefit from
using 32-bit addresses wherever possible in order to avoid DAC (PCI) or
longer address packets (PCIe), which may incur a performance overhead.
Implement the same optimisation as other allocators by trying to
Add master device name to default IOMMU fault message to make easier to
find which device triggered the fault. While at it, move printing some
information (like page table base and first level entry addresses) to
dev_dbg(), because those are typically not very useful for typical device
driver user/
Add a simple checks for dma_map_single() return value to make DMA-debug
checker happly. Exynos IOMMU on Samsung Exynos SoCs always use device,
which has linear DMA mapping ops (dma address is equal to physical memory
address), so no failures are returned from dma_map_single().
Signed-off-by: Marek
IOMMU core doesn't detach device from the default domain before calling
->iommu_remove_device, so check that and do the proper cleanup or
warn if device is still attached to non-default domain.
Signed-off-by: Marek Szyprowski
---
drivers/iommu/exynos-iommu.c | 12
1 file changed, 12
This patch prepares Exynos IOMMU driver for deferred probing
support. Once it gets added, of_xlate() callback might be called
more than once for the same SYSMMU controller and master device
(for example it happens when masters device driver fails with
EPROBE_DEFER). This patch adds a check, which e
Hello,
This is collection of fixes for Exynos IOMMU driver. Patches 1-2 are
resend and update of the patches, which got lost on mainline list.
Patches 3-4 solve the issue, which arises when IOMMU deferred probe
patches will be merged.
Patches are based on current iommu/next branch.
Best regards
Hi Robin,
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Nipun Gupta
> Sent: Sunday, December 18, 2016 2:37 AM
> To: Robin Murphy ; iommu@lists.linux-
> foundation.org; devicet...@vger.kernel.org; linu
On 1/4/17 21:48, Joerg Roedel wrote:
On Fri, Dec 23, 2016 at 08:38:45PM +0700, Suravee Suthikulpanit wrote:
--- a/arch/x86/events/amd/iommu.h
+++ b/arch/x86/events/amd/iommu.h
@@ -24,15 +24,12 @@
#define PC_MAX_SPEC_BNKS 64
#define PC_MAX_SPEC_CNTRS
Hi Lorenzo,
On 2017-01-03 18:34, Lorenzo Pieralisi wrote:
With the introduction of the new iommu_{register/get}_instance()
interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
agnostic") (based on struct fwnode_handle as look-up token, so firmware
agnostic) to register IOMMU
39 matches
Mail list logo
