On Wed, Jul 20, 2016 at 02:33:18AM +0200, Rafael J. Wysocki wrote:
> On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote:
> > On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote:
> > > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote:
> > > > On Fri, Jun 17, 2016 at 08:26:52A
Mediatek V4l2 depend on the IOMMU and SMI. we should add probe-defer
to wait for the IOMMU and SMI is ready.
Signed-off-by: Yong Wu
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_
If DRM begin to probe before SMI probe done. It will hang:
[7.832359] Call trace:
[7.834778] [] mtk_smi_larb_get+0x24/0xa8
[7.840300] [] mtk_drm_crtc_enable+0x6c/0x450
Use the new interface(mtk_smi_larb_is_ready) to wait for IOMMU and
SMI probe done.
Signed-off-by: Yong Wu
---
driv
eir probe. If it return false, the iommu consumer should
probe-defer for the IOMMU and SMI.
Signed-off-by: Yong Wu
---
Adding this interface is for avoid adjust the sequence of power
domain probe[1]. This patch-set is based on next-20160719. And
patch[1/3] base on [2], patch[3/3] base on [3], b
On Friday, June 17, 2016 04:07:38 PM Lukas Wunner wrote:
> On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote:
> > > On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote:
> > > > From: "Rafael J. Wysocki"
> > > W
The PL330 performs privileged instruction fetches. This can result in
SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
specifies that mappings that are writeable at one execution level shall
not be executable at any higher-privileged level. Fix this by using the
DMA_ATTR_PRIVI
The following patch to the ARM SMMU driver:
commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy
Date: Tue Jan 26 18:06:34 2016 +
iommu/arm-smmu: Treat all device transactions as unprivileged
started forcing all SMMU transactions to come through as
This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping
subsystem.
Some advanced peripherals such as remote processors and GPUs perform
accesses to DMA buffers in both privileged "supervisor" and unprivileged
"user" modes. This attribute is used to indicate to the DMA-mapping
subsyst
From: Jeremy Gebben
Allow the creation of privileged mode mappings, for stage 1 only.
Signed-off-by: Jeremy Gebben
---
Notes:
v2..v3
- Use existing bit definitions.
drivers/iommu/io-pgtable-arm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i
Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.
Signed-off-by: Mitchel Humpherys
---
Notes:
v2..v3
- Added comment
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 664683aed
The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
are only accessible to privileged DMA engines. Implement it in
dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.
Signed-off-by: Mitchel Humpherys
---
Notes:
v2..v3
- Renamed and redocumented
This reverts commit d346180e70b9 ("iommu/arm-smmu: Treat all device
transactions as unprivileged") since some platforms actually make use of
privileged transactions.
Signed-off-by: Mitchel Humpherys
---
Notes:
v2..v3
- Moved to the end of the series.
drivers/iommu/arm-smmu.c | 5
On Tue, 19 Jul 2016, Eric Auger wrote:
> msi_doorbell_pages sum up the number of iommu pages of a given order
adding () to the function name would make it immediately clear that
msi_doorbell_pages is a function.
> +/**
> + * msi_doorbell_pages: compute the number of iommu pages of size 1 << order
On Tue, 19 Jul 2016, Eric Auger wrote:
> +
> +#include
> +#include
> +#include
> +
> +struct irqchip_doorbell {
> + struct irq_chip_msi_doorbell_info info;
> + struct list_head next;
Again, please align the struct members.
> +};
> +
> +static LIST_HEAD(irqchip_doorbell_list);
> +static
On Tue, 19 Jul 2016, Eric Auger wrote:
>
> +/* Describe all the MSI doorbell regions for an irqchip */
> +struct irq_chip_msi_doorbell_info {
> + union {
> + phys_addr_t __percpu *percpu_doorbells;
> + phys_addr_t global_doorbell;
> + };
> + bool doorbell_is_pe
On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller.
Since we currently have no way to detect whether the MSI controller is
upstream or downstream to the IOMMU we rely on the MSI doorbell information
registered by the interrupt controllers. In case at l
Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots,
let's implement the expected behavior for removal and replay.
As opposed to user dma slots, reserved IOVAs are not systematically bound
to PAs and PAs are not pinned. VFIO just initializes the IOVA "aperture".
IOVAs are allocated
The user is allowed to register a reserved MSI IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
This region is stored in the vfio_dma rb tree. At that point the iova
range is not mapped to any target address yet. The host kernel will use
those iova
This patch allows the user-space to retrieve the MSI geometry. The
implementation is based on capability chains, now also added to
VFIO_IOMMU_GET_INFO.
The returned info comprise:
- whether the MSI IOVA are constrained to a reserved range (x86 case) and
in the positive, the start/end of the aper
This patch handles the case where a node is encountered, matching
@start and @size arguments but not matching the @type argument.
In that case, we need to skip that node and pursue the search in the
node's leaves. In case @start is inferior to the node's base, we
resume the search on the left leaf.
Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu(-v3). 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 remapping capability, the msi domain needs to be
checked instead.
This commit affects platform a
In our RB-tree we get prepared to insert slots of different types
(USER and RESERVED). It becomes useful to be able to search for dma
slots of a specific type or any type.
This patch introduces vfio_find_dma_from_node which starts the
search from a given node and stops on the first node that match
We introduce a vfio_dma type since we will need to discriminate
different types of dma slots:
- VFIO_IOVA_USER: IOVA region used to map user vaddr
- VFIO_IOVA_RESERVED_MSI: IOVA region reserved to map MSI doorbells
Signed-off-by: Eric Auger
---
v9 -> v10:
- renamed VFIO_IOVA_RESERVED into VFIO_I
This series allows the user-space to register a reserved IOVA domain.
This completes the kernel integration of the whole functionality on top
of the 2 previous parts (v11).
We reuse the VFIO DMA MAP ioctl with a new flag to bridge to the
msi-iommu API. The need for provisioning such MSI IOVA range
This patch handles the iommu mapping of MSI doorbells that require to
be mapped in an iommu domain. This happens on msi_domain_alloc/free_irqs
since this is called in code that can sleep (pci_enable/disable_msi):
iommu_map/unmap is not stated as atomic. On msi_domain_(de)activate and
msi_domain_set
On MSI message composition we now use the MSI doorbell's IOVA in
place of the doorbell's PA in case the device is upstream to an
IOMMU that requires MSI addresses to be mapped. The doorbell's
allocation and mapping happened on an early stage (pci_enable_msi).
Signed-off-by: Eric Auger
---
v8 ->
This patch adds the registration of the MSI global doorbell in
gicv3-its driver plus the implementation for irq_chip
msi_doorbell_info ops.
This will allow the msi layer to iommu_map this doorbell when
requested.
Signed-off-by: Eric Auger
---
v10 -> v11:
- adapt to new doorbell registration AP
Currently the MSI message is composed by directly calling
irq_chip_compose_msi_msg and erased by setting the memory to zero.
On some platforms, we will need to complexify this composition to
properly handle MSI emission through IOMMU. Also we will need to track
when the MSI message is erased.
We
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
Use the msi-doorbell API to register the global doorbell
and implement the msi_doorbell_info
Signed-off-by: Eric Auger
---
v10 -> v11:
- use the new registration API and re-implement the msi_doorbell_info
ops
v9 -> v10:
- introduce the registration concept in place of msi_doorbell_info
call
From: Eric Auger
The purpose is to be able to retrieve the MSI doorbells of an irqchip.
This is now needed since on some platforms those doorbells must be
iommu mapped (in case the MSIs transit through an IOMMU that do not
bypass those transactions).
The assumption is there is a maximum of one d
msi_doorbell_safe returns whether all the registered doorbells
implement irq_remapping.
When assigning a PCIe device whose host controller is upstream to
an IOMMU, we currently do not know whether the MSI controller is
upstream or downstream to the IOMMU.
Signed-off-by: Eric Auger
---
include/l
This new API aims at allowing irqchips to allocate & register
the MSI doorbells likely to be iommu mapped.
Later on, other services will be added allowing the VFIO layer
to query information based on all registered doorbells.
Signed-off-by: Eric Auger
---
v10 -> v11:
- remove void *chip_data a
msi_doorbell_pages sum up the number of iommu pages of a given order
requested to map all the registered doorbells. This function will allow
to dimension the intermediate physical address (IPA) aperture requested
to map the MSI doorbells.
Signed-off-by: Eric Auger
---
v10: creation
---
include
KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
This series implements the MSI address mapping/unmapping in the MSI layer.
IOMMU binding happens on pci_enable_msi since this function can sleep and
return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which
are not
For IOMMU_DOMAIN_UNMANAGED type we now also get the msi
cookie in both arm-smmu and arm-smmu-v3. This initializes
resources for MSI doorbell mapping.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c | 16
drivers/iommu/arm-smmu.c| 15 +++
2 files changed
On ARM, MSI write transactions from device upstream to the smmu
are conveyed through the iommu. Therefore target physical addresses
must be mapped and DOMAIN_ATTR_MSI_GEOMETRY advertises the support of
the IOMMU-MSI API.
Signed-off-by: Eric Auger
---
v8 -> v9:
- reword the title and patch descri
Introduce a new DOMAIN_ATTR_MSI_GEOMETRY domain attribute. It enables
to query the aperture of the IOVA window dedicated to MSIs and
test whether the MSIs must be mapped with the IOMMU-MSI API.
x86 IOMMUs will typically expose an MSI aperture matching the 1MB
region [FEE0_h - FEF0_000h] corres
This opaque pointer will enable to store information about msi
iommu mappings.
Signed-off-by: Eric Auger
---
v7 -> v8:
remove spinlock and RB tree
v5 -> v6:
- initialize reserved_binding_list
- use a spinlock instead of a mutex
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
d
iommu_get/put_msi_cookie allocates/frees the resource used to store
and ref count the MSI doorbell mappings. iommu_msi_set_aperture
initializes the iova domain used for MSI IOVA allocation and sets the
iommu domain's msi geometry.
The implementation relies on dma-iommu API and iova API.
New msi f
iommu_msi_get_doorbell_iova allows to iommu map an MSI doorbell contiguous
physical region onto a reserved contiguous IOVA region. The physical
region base address does not need to be iommu page size aligned. iova
pages are allocated and mapped so that they cover all the physical region.
This mappi
This function checks whether
- the device belongs to a non default iommu domain
- this iommu domain requires the MSI address to be mapped.
If those conditions are met, the function returns the iommu domain
to be used for mapping the MSI doorbell; else it returns NULL.
Signed-off-by: Eric Auger
Introduce iommu_msi_msg_pa_to_va whose role consists in
detecting whether the device's MSIs must to be mapped into an IOMMU.
It case it must, the function overrides the MSI msg originally composed
and replaces the doorbell's PA by a pre-allocated and pre-mapped reserved
IOVA. In case the correspond
This series introduces the msi-iommu api used to:
- allocate/free resources for MSI IOMMU mapping
- set the MSI iova window aperture
- map/unmap physical addresses onto MSI IOVAs.
- determine whether an msi needs to be iommu mapped
- overwrite an msi_msg PA address with its pre-allocated/mapped IO
44 matches
Mail list logo
