Hi Robin,
Thank you for the patch.
On Thursday 11 February 2016 16:13:45 Robin Murphy wrote:
> As the number of io-pgtable implementations grows beyond 1, it's time
> to rationalise the quirks mechanism before things have a chance to
> start getting really ugly and out-of-hand.
>
> To that end:
As the number of io-pgtable implementations grows beyond 1, it's time
to rationalise the quirks mechanism before things have a chance to
start getting really ugly and out-of-hand.
To that end:
- Indicate exactly which quirks each format can/does support.
- Fail creating a table if a caller wants u
On 11/02/16 00:02, Laurent Pinchart wrote:
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote:
From: Robin Murphy
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO
Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the
irq_remapping capability is abstracted on irqchip side for ARM as
opposed to Intel IOMMU featuring IRQ remapping HW.
So to check IRQ remmapping capability, the msi domain needs to be
checked instead.
Signed-off-by: Eric Auger
---
dr
In case the msi_desc references a device attached to an iommu
domain, the msi address needs to be mapped in the IOMMU. Else any
MSI write transaction will cause a fault.
gic_set_msi_addr detects that case and allocates an iova bound
to the physical address page comprising the MSI frame. This iova
On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller. vfio_msi_parent_irq_remapping_capable allows to
check whether interrupts are "safe" for a given device. There are if the device
does not use MSI or if the device uses MSI and the msi-parent controller
Implement the iommu_get/put_single_reserved API in arm-smmu.
In order to track which physical address is already mapped we
use the RB tree indexed by PA.
Signed-off-by: Eric Auger
---
v1 -> v2:
- previously in vfio_iommu_type1.c
---
drivers/iommu/arm-smmu.c | 114 +
We plan to use msi_get_domain_info in VFIO module so let's export it.
Signed-off-by: Eric Auger
---
include/linux/msi.h | 4
kernel/irq/msi.c| 1 +
2 files changed, 5 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 03eda72..df19315 100644
--- a/include/linux/
The user is allowed to register a reserved IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
It provides the base address and the size. This region is stored in the
vfio_dma rb tree. At that point the iova range is not mapped to any target
address ye
arm_smmu_unmap_reserved releases all reserved binding resources:
destroy all bindings, free iova, free iova_domain. This happens
on domain deletion.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
d
Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING
meant to tell the domain supports IRQ REMAPPING, also known as Interrupt
Translation Service. On Intel HW this capability is abstracted on IOMMU
side while on ARM it is abstracted on MSI controller side.
GICv3 ITS HW is the f
This patch allows the user-space to retrieve whether msi write
transaction addresses must be mapped. This is returned through the
VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.
Signed-off-by: Bharat Bhushan
Signed-off-by: Eric Auger
---
RFC v1 -> v1:
- derived from
Introduce alloc/free_reserved_iova_domain in the IOMMU API.
alloc_reserved_iova_domain initializes an iova domain at a given
iova base address and with a given size. This iova domain will
be used to allocate iova within that window. Those IOVAs will be reserved
for special purpose, typically MSI fr
We introduce a vfio_dma type since we will need to discriminate
legacy vfio_dma's from new reserved ones. Since those latter are
not mapped at registration, some treatments need to be reworked:
removal, replay. Currently they are unplugged. In subsequent patches
they will be reworked.
Signed-off-b
we will need to track which host physical addresses are mapped to
reserved IOVA. In that prospect we introduce a new RB tree indexed
by physical address. This RB tree only is used for reserved IOVA
bindings.
It is expected this RB tree will contain very few bindings. Those
generally correspond to
This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
It pursues the efforts done on [1], [2], [3]. It also aims at covering the
same need on PowerPC platforms although the same kind of integration
should be carried out.
On x86 all accesses to the 1MB PA region [FEE0_h - FE
This patch introduces iommu_get/put_single_reserved.
iommu_get_single_reserved allows to allocate a new reserved iova page
and map it onto the physical page that contains a given physical address.
It returns the iova that is mapped onto the provided physical address.
Hence the physical address pas
Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.
x86 IOMMUs typically don't expose the attribute since on x86, MSI write
transaction addresses always are within
Implement alloc/free_reserved_iova_domain for arm-smmu. we use
the iova allocator (iova.c). The iova_domain is attached to the
arm_smmu_domain struct. A mutex is introduced to protect it.
Signed-off-by: Eric Auger
---
v1 -> v2:
- formerly implemented in vfio_iommu_type1
---
drivers/iommu/arm-s
From: Suravee Suthikulpanit
This patch declares pr_fmt for perf/amd_iommu, removes unnecessary
pr_debug, and clean up error messages.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/x86/
The current amd_iommu_pc_get_set_reg_val() does not support muli-IOMMU
system. This patch replace amd_iommu_pc_get_set_reg_val() with
amd_iommu_pc_set_reg_val() and amd_iommu_pc_[set|get]_cnt_vals().
Also, the current struct hw_perf_event.prev_count can only store the
previous counter value only f
Currently, amd_iommu_pc_get_max_[banks|counters]() require devid,
which should not be the case. Also, these don't properly support
multi-IOMMU system.
Current and future AMD systems with IOMMU that support perf counter
would likely contain homogeneous IOMMUs where multiple IOMMUs are
availalbe. So
Introduce a helper function to calculate bit-index for assigning
performance counter assignment.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/ev
This patch introduces amd_iommu_get_num_iommus(). Initially, this is
intended to be used by Perf AMD IOMMU driver.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/include/asm/perf/amd/iommu.h | 2 ++
drivers/iommu/amd_iommu_init.c| 7 ++-
2 files changed, 8 insertions(+), 1 deletio
From: Suravee Suthikulpanit
First, this patch move arch/x86/events/amd/iommu.h to
arch/x86/include/asm/perf/amd/iommu.h so that we easily include
it in both perf-amd-iommu and amd-iommu drivers.
Then, we consolidate declarion of AMD IOMMU performance counter
APIs into one file.
Reviewed-by: Joe
From: Suravee Suthikulpanit
This patch series modifies the existing perf_event_amd_iommu driver
to support systems with multiple IOMMUs. It introduces new AMD IOMMU APIs,
which are used by the AMD IOMMU Perf driver to access performance
counters in multiple IOMMUs.
In addition, this series shoul
Hi Boris,
Thank you very much for catching several styling issues. I should have
taken care of that earlier. I'll clean them up. Please see my other
comments below.
Thanks,
Suravee
On 02/11/2016 12:14 AM, Borislav Petkov wrote:
On Tue, Feb 09, 2016 at 04:53:55PM -0600, Suravee Suthikulpan
27 matches
Mail list logo
