On Wed, Mar 22, 2017 at 06:38:50PM +, Will Deacon wrote:
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
On Wed, Mar 22, 2017 at 06:31:01PM +, Jean-Philippe Brucker wrote:
> The problem might be too tied to the specifics of the SMMU. As implemented
> in this series, the normal flow for a PPR with the SMMU is the following:
>
> (1) PCI device issues a PPR for PASID 1
> (2) The PPR is queued by the
On Wed, Mar 22, 2017 at 07:36:52PM +0100, Thierry Reding wrote:
> *sigh* I think I messed up the #ifdef line. The attached .config has
> CONFIG_IOMMU_IOVA=m, which means that the #ifdef won't be true. I think
> the proper fix would be to:
>
> -#ifdef CONFIG_IOMMU_IOVA
> +#ifdef IS_ENABLED(CONFIG_I
Hi Joerg,
Please pull these two ARM io-pgtable fixes from Oleksandr for 4.11. They're
not critical, but they mean that we detect misuses in the iommu_{map,unmap}
API instead of deferencing junk pointers in the kernel. I've had them queued
locally for a while, so Robin and I have given them a fair
On Thu, Mar 23, 2017 at 02:28:27AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git core
> head: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992
> commit: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992 [3/3] iommu: Add dummy
> implementations for !IOMMU
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git core
head: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992
commit: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992 [3/3] iommu: Add dummy
implementations for !IOMMU_IOVA
config: x86_64-randconfig-a0-03222342 (attached as .config)
compiler:
On 22/03/17 15:44, Joerg Roedel wrote:
> On Mon, Feb 27, 2017 at 07:54:35PM +, Jean-Philippe Brucker wrote:
>> It is an important distinction because, if the IOMMU driver reassigns a
>> PASID while the IOMMU still holds pending PPR targeting that PASID
>> internally, the PPR will trigger a faul
Hi Joerg,
On 22/03/17 15:36, Joerg Roedel wrote:
> On Fri, Mar 03, 2017 at 06:39:58PM +, Jean-Philippe Brucker wrote:
>> Yes, it would be nice to have a common PASID allocator. But I don't
>> think that a system-wide PASID space is workable for us. At the moment
>> systems might have a few ide
On Wed, Mar 22, 2017 at 03:55:30PM +0100, Joerg Roedel wrote:
> Hi Thierry
>
> On Mon, Mar 20, 2017 at 08:14:31PM +0100, Thierry Reding wrote:
> > I've got a series of patches that I'd like to merge for v4.12 that have
> > a build-time dependency on this patch. It would therefore be great to
> > g
On 2017-03-15 09:33, Robin Murphy wrote:
Hi all,
Hi Robin,
Here's the first bit of lock contention removal to chew on - feedback
welcome! Note that for the current users of the io-pgtable framework,
this is most likely to simply push more contention onto the io-pgtable
lock, so may not show a
Hi Jean-Philippe,
On Mon, Feb 27, 2017 at 07:54:33PM +, Jean-Philippe Brucker wrote:
> +extern int iommu_set_svm_ops(struct device *dev,
> + const struct iommu_svm_ops *svm_ops);
> +extern int iommu_bind_task(struct device *dev, struct task_struct *task,
> +
On Mon, Feb 27, 2017 at 07:54:35PM +, Jean-Philippe Brucker wrote:
> It is an important distinction because, if the IOMMU driver reassigns a
> PASID while the IOMMU still holds pending PPR targeting that PASID
> internally, the PPR will trigger a fault in the wrong address space.
The IOMMU dri
On Fri, Mar 03, 2017 at 06:39:58PM +, Jean-Philippe Brucker wrote:
> Yes, it would be nice to have a common PASID allocator. But I don't
> think that a system-wide PASID space is workable for us. At the moment
> systems might have a few identical devices all supporting 20 bits of
> PASID. But c
On Thu, Mar 16, 2017 at 05:00:19PM +, Robin Murphy wrote:
> Now that we're applying the IOMMU API reserved regions to our IOVA
> domains, we shouldn't need to privately special-case PCI windows, or
> indeed anything else which isn't specific to our iommu-dma layer.
> However, since those aren't
On Thu, Mar 16, 2017 at 05:00:16PM +, Robin Murphy wrote:
> The introduction of reserved regions has left a couple of rough edges
> which we could do with sorting out sooner rather than later. Since we
> are not yet addressing the potential dynamic aspect of software-managed
> reservations and
On 03/22/2017 04:51 AM, Jayachandran C wrote:
> Hi Bjorn, Alex,
>
> Here is v3 of the patchset to handle the PCIe topology quirk of
> Cavium ThunderX2 (previously called Broadcom Vulcan).
>
> The earlier discussions on this can be seen at:
> http://www.spinics.net/lists/linux-pci/msg51001.html
>
Hi Thierry
On Mon, Mar 20, 2017 at 08:14:31PM +0100, Thierry Reding wrote:
> I've got a series of patches that I'd like to merge for v4.12 that have
> a build-time dependency on this patch. It would therefore be great to
> get your Acked-by on this so that I can merge it through the DRM tree
> wit
On Mon, Mar 20, 2017 at 10:17:56AM +0100, Marek Szyprowski wrote:
> Documentation specifies that SYSMMU should be in blocked state while
> performing TLB/FLPD cache invalidation, so add needed calls to
> sysmmu_block/unblock.
>
> Fixes: 66a7ed84b345d ("iommu/exynos: Apply workaround of caching fau
On Thu, Mar 16, 2017 at 04:23:51PM +0200, Andy Shevchenko wrote:
> There is inconsistency in return codes across the functions called from
> detect_intel_iommu().
>
> Make it consistent and propagate return code to the caller.
>
> Signed-off-by: Andy Shevchenko
Applied all, thanks.
___
On Wed, 22 Mar 2017 11:06:47 +
Gabor Locsei wrote:
> Hello,
>
> I have systems with IOMMU optionally enabled, and I would like to find a
> method to check these capabilities that doesn't rely on dmesg.
> The evident problem is that dmesg eventually clear boot time messages so the
> relevan
Hi Jörg,
On Wed, Mar 22, 2017 at 3:23 PM, Joerg Roedel wrote:
> On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
>> iommu/ipmmu-vmsa: r8a7796 support V3
>>
>> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
>> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
On Tue, Mar 07, 2017 at 12:17:33PM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Introduce an alternative set of iommu_ops suitable for 64-bit ARM
> as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the
> Kconfig to depend on ARM or IOMMU_DMA. Initialize the device
> from ->xlate() w
On Fri, Jan 27, 2017 at 03:14:07PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU slave device whitelist V2
>
> [PATCH/RFC v2 1/4] iommu/of: Skip IOMMU devices disabled in DT
> [PATCH/RFC v2 2/4] iommu/ipmmu-vmsa: Get rid of disabled device check
> [PATCH/RFC v2 3/4] iommu/ipmmu-vmsa: Check d
Hey Magnus,
On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: r8a7796 support V3
>
> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT ma
On Tue, Mar 21, 2017 at 05:21:37PM +, Will Deacon wrote:
> On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
> > On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> > > @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
> > > device *dev)
> > >*
On Tue, Mar 21, 2017 at 04:30:55PM +, Deucher, Alexander wrote:
> > I am preparing a debug-patch that disables ATS for these GPUs so someone
> > with such a chip can test it.
>
> Thanks Joerg.
Here is a debug patch, using the hard hammer of disabling the use of ATS
completly in the AMD IOMMU
Hello,
I have systems with IOMMU optionally enabled, and I would like to find a method
to check these capabilities that doesn't rely on dmesg.
The evident problem is that dmesg eventually clear boot time messages so the
relevant lines may just disappear.
Looks like there are sysfs entries that
On Wed, Mar 22, 2017 at 08:51:10AM +, Jayachandran C wrote:
> From: Jayachandran C
Looks like I did not fix up the author to my new mail ID. Please ignore
this part.
I can send out a clean revision if needed, until then please drop the
broadcom.com mail id in any reply to avoid bounces. Sor
From: Jayachandran C
The Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the PCI
topology is slightly unusual. For a multi-node system, it looks like:
[node level PCI bridges - one per node]
[SoC PCI devices with MSI-X but no IOMMU]
[PCI-PCIe "glue" bridges - upto 14, one p
From: Jayachandran C
Add a new quirk flag PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT to limit the DMA
alias search to go no further than the bridge where the IOMMU unit is
attached.
The flag will be used to indicate a bridge device which forwards the
address translation requests to the IOMMU, i.e where the
Hi Bjorn, Alex,
Here is v3 of the patchset to handle the PCIe topology quirk of
Cavium ThunderX2 (previously called Broadcom Vulcan).
The earlier discussions on this can be seen at:
http://www.spinics.net/lists/linux-pci/msg51001.html
https://patchwork.ozlabs.org/patch/582633/ and
https://lists.l
Introduce amd_iommu_get_num_iommus(), which returns the value of
amd_iommus_present. The function is used to replace direct access to
the variable, which is now declared as static.
This function will also be used by Perf AMD IOMMU driver.
Cc: Borislav Petkov
Cc: Joerg Roedel
Signed-off-by: Sura
From: Suravee Suthikulpanit
Introduce static amd_iommu_attr_groups to simplify the
sysfs attributes initialization code.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 81 ++---
1 file chan
Currently, amd_iommu_pc_get_max_[banks|counters]() use end-point
device ID to locate an IOMMU and check the reported max banks/counters.
The logic assumes that the IOMMU_BASE_DEVID belongs to the first IOMMU,
and uses it to acquire a reference to the first IOMMU, which does not work
on certain syst
From: Suravee Suthikulpanit
Current AMD IOMMU Perf PMU inappropriately uses hardware struct
inside the union inside the struct hw_perf_event, mainly the use of
extra_reg.
Instead, introduce amd_iommu-specific struct with required
parameters to be programmed onto the IOMMU performance counter
con
From: Suravee Suthikulpanit
The current amd_iommu_pc_get_set_reg_val() cannot support multiple IOMMUs.
So, modify it to allow callers to specify IOMMU. This prepares the driver
for supporting multi-IOMMU in subsequent patch.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Joerg Roedel
Signed-off-
From: Suravee Suthikulpanit
Add multi-IOMMU support for perf by exposing an AMD IOMMU PMU
for each IOMMU found in the system via:
/bus/event_source/devices/amd_iommu_x
where x is the IOMMU index. This allows users to specify
different events to be programmed onto performance counters
of each
From: Suravee Suthikulpanit
Clean up coding style and fix a bug in the 64-bit register read
logic since it overwrites the upper 32-bit when reading the lower 32-bit.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd_iommu_init.c | 13 -
1 file changed, 8 insertions(+), 5 d
Fix coding style and make use of GENMASK_ULL macro.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Cc: Joerg Roedel
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/x86/events/amd/iommu.c b/
Declare pr_fmt for perf/amd_iommu and remove unnecessary pr_debug.
Also check return value when _init_events_attrs fails.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 22 +-
1 file changed, 9 insertions(+), 1
From: Suravee Suthikulpanit
Clean up register initializaton and make use of BIT_ULL(x)
where appropriate. This should not affect logic and functionality.
Cc: Peter Zijlstra
Cc: Borislav Petkov
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/events/amd/iommu.c | 18 +-
1 fil
From: Suravee Suthikulpanit
This patch series modifies the existing IOMMU and Perf drivers to support
systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU instance.
This allows users to specify performance events and filters separately for each
IOMMU.
This has been tested on the
42 matches
Mail list logo
