On Fri, Feb 12, 2016 at 05:09:46PM +, 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:
> - Indicate exactly which quirks
On 12/02/16 17:24, Laurent Pinchart wrote:
Hi Robin,
Thank you for the patch.
On Friday 12 February 2016 17:09:46 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 ug
Hi Robin,
Thank you for the patch.
On Friday 12 February 2016 17:09:46 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 Fri, Feb 12, 2016 at 03:23:04PM +, Robin Murphy wrote:
> On 12/02/16 12:32, Laurent Pinchart wrote:
> >On Friday 12 February 2016 12:08:58 Will Deacon wrote:
> >>On Thu, Feb 11, 2016 at 04:13:45PM +, Robin Murphy wrote:
> >>>@@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(st
On 12/02/16 12:32, Laurent Pinchart wrote:
On Friday 12 February 2016 12:08:58 Will Deacon wrote:
On Thu, Feb 11, 2016 at 04:13:45PM +, 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 t
Hi Simon,
* Simon Horman [2016-02-10 18:55:59 +0100]:
> Hi Niklas,
>
> I am deferring accepting this and the similar patch for the r8a7791 pending
> acceptance of the driver changes earlier in this series. Please let me know
> if you prefer a different course of action.
That sounds good, thanks
On Friday 12 February 2016 12:08:58 Will Deacon wrote:
> On Thu, Feb 11, 2016 at 04:13:45PM +, 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 o
On Thu, Feb 11, 2016 at 04:13:45PM +, 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:
> - Indicate exactly which quirks
We plan to use msi_get_domain_info in VFIO module so let's export it.
Signed-off-by: Eric Auger
---
v2 -> v3:
- remove static implementation in case CONFIG_PCI_MSI_IRQ_DOMAIN is not set
---
kernel/irq/msi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
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
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
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
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
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
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 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
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
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
---
v2 -> v3:
- select IOMMU_IOVA when ARM_SMMU or ARM_SMMU_V3 is set
v1 -> v2:
-
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
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
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 +
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
25 matches
Mail list logo
