Re: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers

is some thing like this looks good +#ifdef CONFIG_64BIT +#define smmu_writeq(reg64, addr) writeq_relaxed((reg64), (addr)) +#else +#define smmu_writeq(reg64, addr) \ + writel_relaxed(((reg64) >> 32), ((addr) + 4)); \ + writel_relaxed((reg64),

Re: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers

On 30/07/15 19:45, Will Deacon wrote: Hello, On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalama...@caviumnetworks.com wrote: From: Tirumalesh Chalamarla The SMMU architecture defines two different behaviors when 64-bit registers are written with 32-bit writes. The first behavior causes zero

Re: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers

On Jul 30, 2015, at 11:45 AM, Will Deacon mailto:will.dea...@arm.com>> wrote: Hello, On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalama...@caviumnetworks.com wrote: From: Tirumalesh Chalamarla mailto:tchalama...@caviumnetworks.com>> The SMMU architectur

Re: [PATCH] iommu/arm-smmu-v2: ThunderX(errata-23399) mis-extends 64bit registers

Hello, On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalama...@caviumnetworks.com wrote: > From: Tirumalesh Chalamarla > > The SMMU architecture defines two different behaviors when 64-bit > registers are written with 32-bit writes. The first behavior causes > zero extension into the upper 32-bit

Re: [Bugfix]

On Thu, Jul 30, 2015 at 12:44 PM, Jiang Liu wrote: > Hi Alexander, Mark, Alex, > Could you please help to apply the debug patch and send me back > the dmesg? Please also help to turn kernel paramemter "apic=debug". See attached. Thanks, Alex > > Hi Mark, > It seems that this re

[Debug Patch] Collect more information about the regression

Hi Alexander, Mark, Alex, Could you please help to apply the debug patch and send me back the dmesg? Please also help to turn kernel paramemter "apic=debug". Hi Mark, It seems that this regression is caused by support of multiple-MSI, but I have no PCI card supportting multiple-MSI

Re: [Bugfix]

Hi all, Sorry, send email too quick. Will resend with correct title. Thanks! Gerry On 2015/7/31 0:44, Jiang Liu wrote: > Hi Alexander, Mark, Alex, > Could you please help to apply the debug patch and send me back > the dmesg? Please also help to turn kernel paramemter "apic=debug". >

[Bugfix]

Hi Alexander, Mark, Alex, Could you please help to apply the debug patch and send me back the dmesg? Please also help to turn kernel paramemter "apic=debug". Hi Mark, It seems that this regression is caused by support of multiple-MSI, but I have no PCI card supportting multiple-MSI

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

Hi Oded, On Thu, Jul 30, 2015 at 01:08:46PM +0300, Oded Gabbay wrote: > Why amdkfd's devices are considered a non-IOMMUv2 capable devices ? > After all, they contain the IOMMUv2 H/W and use it constantly for HSA. With 4.2 the AMD IOMMU driver relies on iommu groups from the iommu core code. With

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

On Tue, Jul 28, 2015 at 5:58 PM, Joerg Roedel wrote: > Hi, > > here are a couple of fixes for the AMD IOMMU driver for > issues found recently. The issues were introduced by the > default-domain conversion in this development cycle. I plan > to send these fixes upstream by the end of the week. > >

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

On Thu, Jul 30, 2015 at 1:05 PM, Joerg Roedel wrote: > From: Joerg Roedel > > With the grouping of multi-function devices a non-ATS > capable device might also end up in the same domain as an > IOMMUv2 capable device. > So handle this situation gracefully and don't consider it a > bug anymore. >

Re: [PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

Joerg, Why amdkfd's devices are considered a non-IOMMUv2 capable devices ? After all, they contain the IOMMUv2 H/W and use it constantly for HSA. ODed On Thu, Jul 30, 2015 at 1:05 PM, Joerg Roedel wrote: > From: Joerg Roedel > > With the grouping of multi-function devices a non-ATS > capable de

[PATCH] iommu/amd: Allow non-ATS devices in IOMMUv2 domains

From: Joerg Roedel With the grouping of multi-function devices a non-ATS capable device might also end up in the same domain as an IOMMUv2 capable device. So handle this situation gracefully and don't consider it a bug anymore. Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 7

Re: [PATCH 0/5] AMD IOMMU Fixes for v4.2-rc4

Hi Joerg, I tested your patches on Kaveri, and while they do fix the initial setup between amdkfd and IOMMU, the kernel crashes when an HSA process tries to do any simple action that involves the kernel, such as to create a compute queue. So while I suppose the above patches should be included, t