Hi Baoquan,
I failed in testing this patchset for 3.18.0-rc1, this upstream
3.18.0-rc1 kernel cannot boot on my system, have not found out the
reason.
Could you please test this patchset on 3.17.0 to see whether it has
these faults?
Thanks
Zhenhua
On 10/22/2014 06:05 PM, Baoquan He wrote:
Hi
Use helpers to access irq_cfg data structure associated with IRQ,
instead of accessing irq_data->chip_data directly. Later we could
rewrite those helpers to support hierarchy irqdomain.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c |6 +++---
1 file changed, 3 insertions(+), 3 d
Use helpers to access irq_cfg data structure associated with IRQ,
instead of accessing irq_data->chip_data directly. Later we could
rewrite those helpers to support hierarchy irqdomain.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c | 10 +-
1 file changed, 5 insertio
Use helpers to access irq_cfg data structure associated with IRQ,
instead of accessing irq_data->chip_data directly. Later we could
rewrite those helpers to support hierarchy irqdomain.
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu.c | 14 +++---
1 file changed, 7 insertions(+),
On Mon, Oct 27, 2014 at 4:32 AM, Heiko Stübner wrote:
> Hi Daniel,
>
> Am Freitag, 24. Oktober 2014, 15:33:47 schrieb Daniel Kurtz:
>
> [...]
>
>> +static int rk_iommu_attach_device(struct iommu_domain *domain,
>> + struct device *dev)
>> +{
>> + struct rk_iommu *
On 10/27/14 at 03:29pm, Li, ZhenHua wrote:
> Hi Baoquan,
> I failed in testing this patchset for 3.18.0-rc1, this upstream
> 3.18.0-rc1 kernel cannot boot on my system, have not found out the
> reason.
>
> Could you please test this patchset on 3.17.0 to see whether it has
> these faults?
>
> Tha
On Tue, Oct 14, 2014 at 01:53:59PM +0100, Laurent Pinchart wrote:
> Hi Will,
Hi Laurent,
> On Monday 22 September 2014 18:50:27 Will Deacon wrote:
> > On Mon, Sep 22, 2014 at 10:29:10AM +0100, Thierry Reding wrote:
> > > Agreed. I wonder how useful it is to know the set of IOMMU instances
> > > t
Hello,
On 2014-10-27 11:51, Will Deacon wrote:
On Tue, Oct 14, 2014 at 01:53:59PM +0100, Laurent Pinchart wrote:
On Monday 22 September 2014 18:50:27 Will Deacon wrote:
On Mon, Sep 22, 2014 at 10:29:10AM +0100, Thierry Reding wrote:
Agreed. I wonder how useful it is to know the set of IOMMU i
Hi Will,
On Monday 27 October 2014 10:51:59 Will Deacon wrote:
> On Tue, Oct 14, 2014 at 01:53:59PM +0100, Laurent Pinchart wrote:
> > On Monday 22 September 2014 18:50:27 Will Deacon wrote:
> > > On Mon, Sep 22, 2014 at 10:29:10AM +0100, Thierry Reding wrote:
> > > > Agreed. I wonder how useful i
On Tue, Oct 14, 2014 at 10:53:30PM +0100, Mitchel Humpherys wrote:
> Currently, we provide the iommu_ops.iova_to_phys service by doing a
> table walk in software to translate IO virtual addresses to physical
> addresses. On SMMUs that support it, it can be useful to ask the SMMU
> itself to do the
Hello,
On 2014-10-24 15:15, Stefan Hengelein wrote:
Hello,
adding a dependency to CONFIG_ARM_DMA_USE_IOMMU is probably not a good
idea anyways.
If you read the Documentation/kbuild/kconfig-language.txt, you will see that:
1. in general, selected options should have no prompt and no dependencies
The rk3288 has several iommus. Each iommu belongs to a single master
device. There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.
At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus. The master devices fin
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
Acked-by: Sebastian Ott
---
arch/s390/include/asm/pci.h |1 +
arch/s390/pci/pci.c | 19 +--
2 fi
Now there are a lot of weak arch MSI functions in MSI code.
These functions make MSI driver complex. Because people need
to know much which arch MSI function should be overrode and
which is not. Thierry introduced MSI chip framework to configure
MSI/MSI-X irq in arm. MSI chip framework is better th
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/ia64/include/asm/pci.h |3 ++-
arch/ia64/kernel/msi_ia64.c | 24 ++--
arch/ia64/pci/pci.c
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/octeon/pci-octeon.h |4 +++
arch/mips/pci/msi-octeon.c| 31
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
Acked-by: Michael Ellerman
---
arch/powerpc/include/asm/pci-bridge.h |8
arch/powerpc/kernel/msi.c |
Now we use MSI controller in all platforms to configure
MSI/MSI-X. We can clean up the unused arch functions.
Signed-off-by: Yijing Wang
Reviewed-by: Lucas Stach
---
drivers/pci/msi.c | 90 ++
include/linux/msi.h | 11 --
2 files changed
This series is based on "[PATCH 00/10] Save MSI chip in pci_sys_data",
https://lkml.org/lkml/2014/10/27/85.
This series is the v4 of "Use MSI chip framework to configure MSI/MSI-X in all
platforms".
I split it out and post it together.
v3->new:
Some trivial changes in "IA64/MSI: Use MSI controll
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
drivers/iommu/irq_remapping.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/io
Save MSI controller in pci sysdata, add arch pcibios_msi_controller()
to extract out MSI controller.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/pci.h |3 +++
arch/mips/pci/pci.c |9 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/mips/incl
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/pci/pci-xlr.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/mips
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X IRQ. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/mips/include/asm/netlogic/xlp-hal/pcibus.h |1 +
arch/mips/pci/msi-xlp.c | 11 +-
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
Acked-by: David S. Miller
---
arch/sparc/kernel/pci.c | 20 ++--
arch/sparc/kernel/pci_impl.h |3 ++
Now we can clean up MSI weak arch functions in x86.
Signed-off-by: Yijing Wang
---
arch/x86/include/asm/pci.h |5 +
arch/x86/include/asm/x86_init.h |4
arch/x86/kernel/apic/io_apic.c | 21 +
arch/x86/kernel/x86_init.c | 24 -
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/tile/include/asm/pci.h |2 ++
arch/tile/kernel/pci_gx.c | 18 --
2 files changed, 18 insertion
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/arm/mach-iop13xx/include/mach/pci.h |4
arch/arm/mach-iop13xx/iq81340mc.c|3 +++
arch/arm/mach-io
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
CC: David Vrabel
CC: Konrad Rzeszutek Wilk
---
arch/x86/pci/xen.c | 45 +++--
1 fil
Use MSI controller framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
---
arch/x86/include/asm/pci.h |4
arch/x86/kernel/apic/io_apic.c | 25 +
arch/x86/pci/a
On Wed, Oct 15, 2014 at 11:07:04AM +0800, Yijing Wang wrote:
> +static inline struct msi_chip *pci_msi_chip(struct pci_bus *bus)
> +{
> + struct pci_controller *control = (struct pci_controller *)bus->sysdata;
bus->sysdata is void * so this cast is unnecessary.
Ralf
___
Hello,
adding a dependency to CONFIG_ARM_DMA_USE_IOMMU is probably not a good
idea anyways.
If you read the Documentation/kbuild/kconfig-language.txt, you will see that:
1. in general, selected options should have no prompt and no dependencies
2. giving ARM_DMA_USE_IOMMU a dependency on MMU will a
Applied, thanks.
Ralf
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Oct 27, 2014 at 11:30:33AM +, Laurent Pinchart wrote:
> Hi Will,
Hey Laurent,
> On Monday 27 October 2014 10:51:59 Will Deacon wrote:
> > On Tue, Oct 14, 2014 at 01:53:59PM +0100, Laurent Pinchart wrote:
> > > On Monday 22 September 2014 18:50:27 Will Deacon wrote:
> > > > On Mon, Sep
On Mon, Oct 27, 2014 at 03:32:01PM +0100, Gerald Schaefer wrote:
> Not sure if I understood the concept of IOMMU domains right. But if this
> is about having multiple devices in the same domain, so that iommu_ops->map
> will establish the _same_ DMA mapping on _all_ registered devices, then
> this
On Mon, Oct 27, 2014 at 04:02:16PM +, Will Deacon wrote:
> On Mon, Oct 27, 2014 at 11:30:33AM +, Laurent Pinchart wrote:
> > I'm not sure to follow you here. Aren't we already exposing masters that
> > master through multiple IOMMUs as single instances of struct device ?
>
> Hmm, yes, now
On Thu, 23 Oct 2014 16:04:37 +0200
Frank Blaschka wrote:
> On Thu, Oct 23, 2014 at 02:41:15PM +0200, Joerg Roedel wrote:
> > On Wed, Oct 22, 2014 at 05:43:20PM +0200, Frank Blaschka wrote:
> > > Basically there are no limitations. Depending on the s390 maschine
> > > generation a device starts it
On Mon, 27 Oct 2014 17:25:02 +0100
Joerg Roedel wrote:
> On Mon, Oct 27, 2014 at 03:32:01PM +0100, Gerald Schaefer wrote:
> > Not sure if I understood the concept of IOMMU domains right. But if
> > this is about having multiple devices in the same domain, so that
> > iommu_ops->map will establish
On Mon, Oct 27, 2014 at 06:02:19PM +0100, Gerald Schaefer wrote:
> On Mon, 27 Oct 2014 17:25:02 +0100
> Joerg Roedel wrote:
> > Is there some hardware reason for this or is that just an
> > implementation detail that can be changed. In other words, does the
> > hardware allow to use the same DMA t
This patch series makes the VFIO_IOMMU_TYPE1 driver buildable on ARM, so it
may be used with ARM SMMUs. It also adds support for the IOMMU_NOEXEC flag
supported by SMMUs adhering to the ARM SMMU specification so the VFIO user can
specify whether the target memory can be executed by the device behin
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of t
Some IOMMU drivers, such as the ARM SMMU driver, make available the
IOMMU_NOEXEC flag to set the page tables for a device as XN (execute never).
This affects devices such as the ARM PL330 DMA Controller, which respects
this flag and will refuse to fetch DMA instructions from memory where the
XN fla
This allows to make use of the VFIO_IOMMU_TYPE1 driver with platform
devices on ARM. The driver can then be used with an Exynos SMMU, or
ARM SMMU driver.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/Kcon
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis
---
include/uapi/linux/vfio.h | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git
Replace the function vfio_domains_have_iommu_cache() with a more generic
function vfio_domains_have_iommu_cap() which allows to check all domains
of an vfio_iommu structure for a given cached capability.
Signed-off-by: Antonios Motakis
---
drivers/vfio/vfio_iommu_type1.c | 37 +++
VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
flags it always applies to all mappings in the domain. This is used for
domains that support IOMMU_CAP_CACHE_COHERENCY.
Refactor this slightly, by keeping track instead that a given domain
supports the capability, and apply
This patch series aims to implement VFIO support for platform devices that
reside behind an IOMMU. Examples of such devices are devices behind an ARM
SMMU, or behind a Samsung Exynos System MMU.
The API used is based on the existing VFIO API that is also used with PCI
devices. Only devices that in
This patch forms the common skeleton code for platform devices support
with VFIO. This will include the core functionality of VFIO_PLATFORM,
however binding to the device and discovering the device resources will
be done with the help of a separate file where any Linux platform bus
specific code wi
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig | 9 +
drivers/vfio/platform/Makefile | 4
4 f
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_amba.c | 116 ++
include/uapi/linux/vfio.h | 1 +
2 files changed, 117 insertions(+
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory regions and
interrupts, and their properties. This patch enables the
VFIO_DEVICE_GET_INFO ioctl call.
Signed-off
Enable building the VFIO AMBA driver. VFIO_AMBA depends on VFIO_PLATFORM,
since it is sharing a portion of the code, and it is essentially implemented
as a platform device whose resources are discovered via AMBA specific APIs
in the kernel.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platfo
VFIO returns a file descriptor which we can use to manipulate the memory
regions of the device. Usually, the user will mmap memory regions that are
addressable on page boundaries, however for memory regions where this is
not the case we cannot provide mmap functionality due to security concerns.
Fo
This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
which allows the user to learn about the available MMIO resources of
a device.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 110 +-
drivers/vfio/platform/vfio_plat
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/Makefile| 2 +-
drivers/vfio/platform/vfio_platform_common
This patch allows to set an eventfd for a patform device's interrupt,
and also to trigger the interrupt eventfd from userspace for testing.
Level sensitive interrupts are marked as maskable and are handled in
a later patch. Edge triggered interrupts are not advertised as maskable
and are implemente
This patch is a skeleton for the VFIO_DEVICE_SET_IRQS IOCTL, around which
most IRQ functionality is implemented in VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 52 +++--
drivers/vfio/platform/vfio_platform_irq.c | 56 ++
Allow to memory map the MMIO regions of the device so userspace can
directly access them. PIO regions are not being handled at this point.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 65
1 file changed, 65 insertions(+)
diff --
With this patch the VFIO user will be able to set an eventfd that can be
used in order to mask and unmask IRQs of platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 47 ---
drivers/vfio/platform/vfio_platform_private.h |
The virqfd functionality that is used by VFIO_PCI to implement interrupt
masking and unmasking via an eventfd, is generic enough and can be reused
by another driver. Move it to a separate file in order to allow the code
to be shared.
Also properly export virqfd_enable and virqfd_disable in the pro
VFIO_PCI passes the VFIO device structure *vdev via eventfd to the handler
that implements masking/unmasking of IRQs via an eventfd. We can replace
it in the virqfd infrastructure with an opaque type so we can make use
of the mechanism from other VFIO bus drivers.
Signed-off-by: Antonios Motakis
The virqfd_enable and virqfd_disable functions are now global. Add the
vfio_ prefix to those functions.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci_intrs.c | 18 +-
drivers/vfio/virqfd.c | 14 +++---
include/linux/vfio.h | 10 +++
Level sensitive interrupts are exposed as maskable and automasked
interrupts and are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 102 +-
drivers/vfio/platform/vfio_platform_private.h
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform.c | 114 ++
include/uapi/linux/vfio.h | 1 +
2 file
Virqfd just needs to keep accesses to any struct *virqfd safe, but this
comes into play only when creating or destroying eventfds, so sharing
the same spinlock with the VFIO bus driver is not necessary.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
driver
Now we have finally completely decoupled virqfd from VFIO_PCI. We can
initialize it from the VFIO generic code, in order to safely use it from
multiple independent VFIO bus drivers.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci.c | 8
drivers/vfio/vfio.c | 8
On Mon, 27 Oct 2014 18:58:35 +0100
Joerg Roedel wrote:
> On Mon, Oct 27, 2014 at 06:02:19PM +0100, Gerald Schaefer wrote:
> > On Mon, 27 Oct 2014 17:25:02 +0100
> > Joerg Roedel wrote:
> > > Is there some hardware reason for this or is that just an
> > > implementation detail that can be changed
Hi Antonios,
On Mon, Oct 27, 2014 at 12:07 PM, Antonios Motakis
wrote:
> The virqfd functionality that is used by VFIO_PCI to implement interrupt
> masking and unmasking via an eventfd, is generic enough and can be reused
> by another driver. Move it to a separate file in order to allow the code
On Mon, Oct 27, 2014 at 12:08 PM, Antonios Motakis
wrote:
> The virqfd_enable and virqfd_disable functions are now global. Add the
> vfio_ prefix to those functions.
Wouldn't it be better to change the name *before* making them global?
Bjorn
___
iommu
68 matches
Mail list logo
