Enhance error recovery in function intel_enable_irq_remapping()
by tearing down all created data structures.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/driv
Implement required callback functions for intel-iommu driver
to support DMAR unit hotplug.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 206 +++
1 file changed, 151 insertions(+), 55 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/d
Finally enhance pci_root driver to support DMAR device hotplug when
hot-plugging PCI host bridges.
Signed-off-by: Jiang Liu
---
drivers/acpi/pci_root.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index
According to Intel VT-d specification, _DSM method to support DMAR
hotplug should exist directly under corresponding ACPI object
representing PCI host bridge. But some BIOSes doesn't conform to
this, so search for _DSM method in the subtree starting from the
ACPI object representing the PCI host br
Implement required callback functions for intel_irq_remapping driver
to support DMAR unit hotplug.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c | 222 ++-
1 file changed, 169 insertions(+), 53 deletions(-)
diff --git a/drivers/iommu/intel_irq
On Intel platforms, an IO Hub (PCI/PCIe host bridge) may contain DMAR
units, so we need to support DMAR hotplug when supporting PCI host
bridge hotplug on Intel platforms.
According to Section 8.8 "Remapping Hardware Unit Hot Plug" in "Intel
Virtualization Technology for Directed IO Architecture S
Static identity and virtual machine domains may be cached in
iommu->domain_ids array after corresponding IOMMUs have been removed
from domain->iommu_bmp. So we should check domain->iommu_bmp before
decreasing domain->iommu_count in function free_dmar_iommu(), otherwise
it may cause free of inuse do
Introduce functions to support dynamic IOMMU seq_id allocating and
releasing, which will be used to support DMAR hotplug.
Also rename IOMMU_UNITS_SUPPORTED as DMAR_UNITS_SUPPORTED.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c| 40 ++--
drivers/
Virtual machine domains are created by intel_iommu_domain_init() and
should be destroyed by intel_iommu_domain_destroy(). So avoid freeing
virtual machine domain data structure in free_dmar_iommu() when
doamin->iommu_count reaches zero, otherwise it may cause invalid
memory access because the IOMMU
Introduce intel_unmap() to reduce duplicated code in intel_unmap_sg()
and intel_unmap_page().
Also let dma_pte_free_pagetable() to call dma_pte_clear_range() directly,
so caller only needs to call dma_pte_free_pagetable().
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 70
Introduce helper function dmar_walk_resources to walk resource entries
in DMAR table and ACPI buffer object returned by ACPI _DSM method
for IOMMU hot-plug.
Signed-off-by: Jiang Liu
---
drivers/iommu/dmar.c| 208 +++
drivers/iommu/intel-iommu.c |
Check the same domain id is allocated for si_domain on each IOMMU,
otherwise the IOTLB flush for si_domain will fail.
Now the rules to allocate and manage domain id are:
1) For normal and static identity domains, domain id is allocated
when creating domain structure. And this id will be written
IOMMU units may dynamically attached to/detached from domains,
so we should scan all active IOMMU units when computing iommu_snooping
flag for a domain instead of only scanning IOMMU units associated
with the domain.
Also check snooping and superpage capabilities when hot-adding DMAR units.
Signe
Simplify include/linux/dmar.h a bit based on the fact that
both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP select CONFIG_DMAR_TABLE.
Signed-off-by: Jiang Liu
---
include/linux/dmar.h | 50 ++
1 file changed, 18 insertions(+), 32 deletions(-)
diff -
Simplify error handling path by changing iommu_{enable|disable}_translation
to return void.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
Introduce helper function domain_pfn_within_range() to simplify code
and improve readability.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iomm
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |7 +++
include/linux/iova.h|5 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c9e65edaa2ad..cd1ba24c766a 100644
--- a/drivers/iommu/i
Introduce domain_attach_iommu()/domain_detach_iommu() and refine
iommu_attach_domain()/iommu_detach_domain() to make code symmetric
and improve readability.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 147 +++
1 file changed, 80 insertions(
For virtual machine domains, domain->id is a virtual id, and the real
domain id written into context entry is dynamically allocated.
So use the real domain id instead of domain->id when flushing iotlbs
for virtual machine domains.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c |2 +
Introduce domain_type_is_vm() and domain_type_is_vm_or_si() to improve
code readability.
Also kill useless macro DOMAIN_FLAG_P2P_MULTIPLE_DEVICES.
Signed-off-by: Jiang Liu
---
drivers/iommu/intel-iommu.c | 59 +++
1 file changed, 26 insertions(+), 33 de
For virtual machine and static identity domains, there may be devices
from different PCI segments associated with the same domain.
So function iommu_support_dev_iotlb() should also match PCI segment
number (iommu unit) when searching for dev_iotlb capable devices.
Signed-off-by: Jiang Liu
---
dr
When hot plugging a descrete IOH or a physical processor with embedded
IIO, we need to handle DMAR(or IOMMU) unit in the PCIe host bridge if
DMAR is in use. This patch set tries to enhance current DMAR/IOMMU/IR
drivers to support hotplug and is based on latest Joerg's iommu/next
branch.
Patch 1-13
On Thu, Jul 10, 2014 at 5:53 PM, Stephen Boyd wrote:
> On 07/10, Rob Clark wrote:
>> So, in it's current form, this is superficially a copy of msm_iommu
>> plus DT conversion. But the pre-DT IOMMU driver had fairly different
>> structure.. ie. psuedo root device, with IOMMU devices hanging off
>>
On Thu, Jul 10, 2014 at 6:43 PM, Olav Haugan wrote:
> On 7/9/2014 5:40 PM, Rob Clark wrote:
>> On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
>>> On 7/8/2014 4:49 PM, Rob Clark wrote:
On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
> Hi Hiroshi,
>
> On 7/3/2014 9:29 PM, H
On 7/9/2014 5:40 PM, Rob Clark wrote:
> On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
>> On 7/8/2014 4:49 PM, Rob Clark wrote:
>>> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
Hi Hiroshi,
On 7/3/2014 9:29 PM, Hiroshi Doyu wrote:
> Hi Olav,
>
> Olav Haugan wr
On 07/10, Rob Clark wrote:
> So, in it's current form, this is superficially a copy of msm_iommu
> plus DT conversion. But the pre-DT IOMMU driver had fairly different
> structure.. ie. psuedo root device, with IOMMU devices hanging off
> that, and context devices hanging off that. The context de
On 7/9/2014 3:54 AM, Will Deacon wrote:
> On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
>> On 6/30/2014 2:52 AM, Will Deacon wrote:
>>> On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote:
Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the
following s
So, in it's current form, this is superficially a copy of msm_iommu
plus DT conversion. But the pre-DT IOMMU driver had fairly different
structure.. ie. psuedo root device, with IOMMU devices hanging off
that, and context devices hanging off that. The context devices were
what the client device w
On Thu, Jul 10, 2014 at 4:11 AM, Alexander Gordeev wrote:
> On Wed, Jul 09, 2014 at 10:06:48AM -0600, Bjorn Helgaas wrote:
>> Out of curiosity, do you have a pointer to this? It looks like it
>
> I.e. ICH8 chapter 12.1.30 or ICH10 chapter 14.1.27
>
>> uses one vector per port, and I'm wondering i
On Thu, 2014-07-10 at 16:45 +0100, Will Deacon wrote:
> On Thu, Jul 10, 2014 at 04:38:18PM +0100, Alex Williamson wrote:
> > On Thu, 2014-07-10 at 12:34 +0100, Will Deacon wrote:
> > > On Wed, Jul 09, 2014 at 09:37:15PM +0100, Alex Williamson wrote:
> > > > On Wed, 2014-07-09 at 19:28 +0100, Will D
On Thu, Jul 10, 2014 at 04:38:18PM +0100, Alex Williamson wrote:
> On Thu, 2014-07-10 at 12:34 +0100, Will Deacon wrote:
> > On Wed, Jul 09, 2014 at 09:37:15PM +0100, Alex Williamson wrote:
> > > On Wed, 2014-07-09 at 19:28 +0100, Will Deacon wrote:
> > > > Hello,
> > > >
> > > > This is v2 of the
On Thu, 2014-07-10 at 12:34 +0100, Will Deacon wrote:
> Hey Alex,
>
> On Wed, Jul 09, 2014 at 09:37:15PM +0100, Alex Williamson wrote:
> > 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://per
On Thu, Jul 10, 2014 at 11:33:47AM +0100, Will Deacon wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
From: Joerg Roedel
With mmu_notifiers we don't need to hold a reference to the
mm_struct during the time the pasid is bound to a device. We
can rely on the .mn_release call back to inform us when the
mm_struct goes away.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd
From: Joerg Roedel
This function is called only in the mn_release() path, so
there is no need to unregister the mmu_notifer here.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu
From: Joerg Roedel
In case we are not able to allocate a fault structure a
reference to the pasid_state will be leaked. Fix that by
dropping the reference in the error path in case we hold
one.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c |4
1
From: Joerg Roedel
On the error path of amd_iommu_bind_pasid() we call
mmu_notifier_unregister() for cleanup. This calls
mn_release() which calls the users inv_ctx_cb function if
one is available. Since the pasid is not set up yet there is
nothing the user can to tear down in this call-back. So
d
From: Joerg Roedel
Unbind_pasid is only called from mn_release which already
has the pasid_state. Use this to simplify the unbind_pasid
path and get rid of __unbind_pasid.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 17 ++---
1 file chan
From: Joerg Roedel
Fix typo in a comment.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_v2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index 92fb77c..0e29f6f 100644
--- a/drivers/iommu/amd_iommu_
From: Joerg Roedel
Since we are only caring about the lifetime of the mm_struct
and not the task we can't safely keep a reference to it. The
reference is also not needed anymore, so remove that code
entirely.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c
From: Joerg Roedel
The mmu_notifier state is part of pasid_state so it can't be
freed in the mn_release path. Free the pasid_state after
mmu_notifer_unregister has completed.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 10 +++---
1 file changed,
From: Joerg Roedel
This is used to signal the ppr_notifer function that no more
faults should be processes on this pasid_state. This way we
can keep the pasid_state safely in the state-table so that
it can be freed in the amd_iommu_unbind_pasid() function.
This allows us to not hold a reference
Hi,
here is a queue of patches for the AMD IOMMUv2 driver that came up
during development of the radeon_kfd driver. The enhance the semantics
and fix a number of bugs found in the code.
Joerg
Diffstat:
drivers/iommu/amd_iommu_v2.c | 104 --
1 f
On Thu, Jul 10, 2014 at 11:57:38AM +0100, Thierry Reding wrote:
> On Thu, Jul 10, 2014 at 11:23:34AM +0100, Will Deacon wrote:
> > On Thu, Jul 10, 2014 at 10:49:10AM +0100, Thierry Reding wrote:
> > > On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> > > > On Wed, Jul 09, 2014 at 03:21
Hey Alex,
On Wed, Jul 09, 2014 at 09:37:15PM +0100, Alex Williamson wrote:
> 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 sig
On Thu, Jul 10, 2014 at 3:10 AM, Thierry Reding
wrote:
> On Wed, Jul 09, 2014 at 08:40:21PM -0400, Rob Clark wrote:
>> On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
>> > On 7/8/2014 4:49 PM, Rob Clark wrote:
>> >> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan
>> >> wrote:
>> >>> Hi Hiroshi,
On Thu, Jul 10, 2014 at 11:23:34AM +0100, Will Deacon wrote:
> On Thu, Jul 10, 2014 at 10:49:10AM +0100, Thierry Reding wrote:
> > On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> > > On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> > > > Anything beyond that (e.g. lo
On Thursday 10 July 2014 09:03:26 Khiem Nguyen wrote:
> 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 .deta
Hi Joerg,
Please can you pull the following ARM SMMU updates for 3.17?
The main changes are:
- Removal of unused SMMU chaining code
- Initial support for PCI masters
- Misc. non-critical fixes to the capability checking code and TCR
configuration
This has largely come out of work enabling
On Thu, Jul 10, 2014 at 10:49:10AM +0100, Thierry Reding wrote:
> On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> > On Wed, Jul 09, 2014 at 03:21:27PM +0100, Thierry Reding wrote:
> > > Anything beyond that (e.g. logical grouping of masters) isn't directly
> > > within the scope of t
On Wed, Jul 09, 2014 at 10:06:48AM -0600, Bjorn Helgaas wrote:
> Out of curiosity, do you have a pointer to this? It looks like it
I.e. ICH8 chapter 12.1.30 or ICH10 chapter 14.1.27
> uses one vector per port, and I'm wondering if the reason it requests
> 16 is because there's some possibility o
On Wed, Jul 09, 2014 at 07:10:48PM +0100, Will Deacon wrote:
> 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.
On Wed, Jul 09, 2014 at 08:40:21PM -0400, Rob Clark wrote:
> On Wed, Jul 9, 2014 at 8:03 PM, Olav Haugan wrote:
> > On 7/8/2014 4:49 PM, Rob Clark wrote:
> >> On Tue, Jul 8, 2014 at 5:53 PM, Olav Haugan wrote:
> >>> Hi Hiroshi,
> >>>
> >>> On 7/3/2014 9:29 PM, Hiroshi Doyu wrote:
> Hi Olav,
53 matches
Mail list logo
