Re: [PATCH v2] iommu/arm-smmu: fix some checkpatch issues

2014-07-09 Thread Will Deacon
On Tue, Jul 08, 2014 at 05:52:18PM +0100, Mitchel Humpherys wrote: Fix some issues reported by checkpatch.pl. Mostly whitespace, but also includes min=min_t, kzalloc=kcalloc, and kmalloc=kmalloc_array. Cheers, applied. I dropped the big list of things you fixed and just kept the one you left,

Re: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices

2014-07-09 Thread Will Deacon
[Adding Alex; question below] On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote: +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void +*data) { + *((u16 *)data) = alias; + return 0; /* Continue walking */ +} [...] @@ -1598,15 +1642,36 @@ static

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

2014-07-09 Thread Will Deacon
On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com This commit introduces a generic device tree binding for IOMMU devices. Only a very minimal subset is described here, but it is enough to cover the requirements of both the Exynos System

Re: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices

2014-07-09 Thread Alex Williamson
On Wed, 2014-07-09 at 14:26 +0100, Will Deacon wrote: [Adding Alex; question below] On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote: +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void +*data) { + *((u16 *)data) = alias; + return 0; /*

RE: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices

2014-07-09 Thread Varun Sethi
Hi Will, -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Wednesday, July 09, 2014 6:57 PM To: Sethi Varun-B16395; alex.william...@redhat.com Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux- foundation.org; thierry.red...@gmail.com; a...@arndb.de;

Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()

2014-07-09 Thread Bjorn Helgaas
On Tue, Jul 8, 2014 at 6:26 AM, Alexander Gordeev agord...@redhat.com wrote: On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote: Can you quantify the benefit of this? Can't a device already use MSI-X to request exactly the number of vectors it can use? (I know A Intel AHCI

Re: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices

2014-07-09 Thread Will Deacon
On Wed, Jul 09, 2014 at 03:13:04PM +0100, Alex Williamson wrote: On Wed, 2014-07-09 at 14:26 +0100, Will Deacon wrote: [Adding Alex; question below] On Thu, Jul 03, 2014 at 03:22:37PM +0100, Varun Sethi wrote: +static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void

Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings

2014-07-09 Thread Will Deacon
Hi Thierry, On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote: On Wed, Jul 09, 2014 at 02:40:50PM +0100, Will Deacon wrote: I would like to move the ARM SMMU driver over to this for 3.18, if possible. One use-case there is the ability to describe groups of masters behind a

[RFC PATCHv2 1/3] iommu: introduce domain attribute for nesting IOMMUs

2014-07-09 Thread Will Deacon
Some IOMMUs, such as the ARM SMMU, support two stages of translation. The idea behind such a scheme is to allow a guest operating system to use the IOMMU for DMA mappings in the first stage of translation, with the hypervisor then installing mappings in the second stage to provide isolation of the

[RFC PATCHv2 2/3] vfio/iommu_type1: add new VFIO_TYPE1_NESTING_IOMMU IOMMU type

2014-07-09 Thread Will Deacon
VFIO allows devices to be safely handed off to userspace by putting them behind an IOMMU configured to ensure DMA and interrupt isolation. This enables userspace KVM clients, such as kvmtool and qemu, to further map the device into a virtual machine. With IOMMUs such as the ARM SMMU, it is then

[RFC PATCHv2 0/3] Support for nesting IOMMUs in VFIO

2014-07-09 Thread Will Deacon
Hello, This is v2 of the RFC I originally posted here: RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552 It's changed significantly since then, based on helpful feedback from Alex. In particular, I no longer butcher the IOMMU API, instead making use of a new iommu_attr to

[RFC PATCHv2 3/3] iommu/arm-smmu: add support for DOMAIN_ATTR_NESTING attribute

2014-07-09 Thread Will Deacon
When domains are set with the DOMAIN_ATTR_NESTING flag, we must ensure that we allocate them to stage-2 context banks if the hardware permits it. This patch adds support for the attribute to the ARM SMMU driver, with the actual stage being determined depending on the features supported by the

Re: [RFC PATCHv2 0/3] Support for nesting IOMMUs in VFIO

2014-07-09 Thread Alex Williamson
On Wed, 2014-07-09 at 19:28 +0100, Will Deacon wrote: Hello, This is v2 of the RFC I originally posted here: RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552 It's changed significantly since then, based on helpful feedback from Alex. In particular, I no longer butcher

Re: [RFC/PATCH 2/7] iommu-api: Add map_range/unmap_range functions

2014-07-09 Thread Olav Haugan
On 7/8/2014 4:49 PM, Rob Clark wrote: On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan ohau...@codeaurora.org wrote: Hi Hiroshi, On 7/3/2014 9:29 PM, Hiroshi Doyu wrote: Hi Olav, Olav Haugan ohau...@codeaurora.org writes: Mapping and unmapping are more often than not in the critical path.

Re: [PATCH v2 01/10] iommu/ipmmu-vmsa: Refactor micro-TLB lookup

2014-07-09 Thread Khiem Nguyen
On 5/15/2014 7:40 PM, Laurent Pinchart wrote: Cache the micro-TLB number in archdata allocated in the .add_device handler instead of looking it up when the deviced is attached and detached. This simplifies the .attach_dev and .detach_dev operations and prepares for DT support. [snip]

Re: [RFC/PATCH 2/7] iommu-api: Add map_range/unmap_range functions

2014-07-09 Thread Rob Clark
On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan ohau...@codeaurora.org wrote: On 7/8/2014 4:49 PM, Rob Clark wrote: On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan ohau...@codeaurora.org wrote: Hi Hiroshi, On 7/3/2014 9:29 PM, Hiroshi Doyu wrote: Hi Olav, Olav Haugan ohau...@codeaurora.org writes: