Re: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704

, Sunil; Akula, Geethasowjanya; Chalamarla, Tirumalesh; Kapoor, Prasun; Tomasz Nowicki Subject: [PATCH 1/1] iommu/arm-smmu: Fix for ThunderX erratum #27704 The goal of erratum #27704 workaround was to make sure that ASIDs and VMIDs are unique across all SMMU instances on affected Cavium systems

Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

On 5/10/16, 12:34 AM, "Eric Auger" wrote: >Hi Chalamarla, >> On 5/9/16, 12:48 AM, "Eric Auger" wrote: >> >>> Hi Chalarmala, >>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: >>>> Hi Eric, >>>> >>&g

Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

On 5/9/16, 12:48 AM, "Eric Auger" wrote: >Hi Chalarmala, >On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: >> Hi Eric, >> >> Does this series supports gicv3-its emulation? >> Do we have a tree with all the dependent patches >GICv3 ITS emu

Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain

On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger" wrote: >On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted >by the msi controller. vfio_safe_irq_domain allows to check whether >interrupts are "safe" for a given device. They are if the device does >not

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

On 5/4/16, 4:54 AM, "linux-arm-kernel on behalf of Eric Auger" wrote: >The user is allowed to register a reserved MSI IOVA range by using the >DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. >This region is stored in the vfio_dma rb tree. At that point the iova >r

Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes

Hi Eric, Does this series supports gicv3-its emulation? Do we have a tree with all the dependent patches Thanks, Tirumalesh. On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger" wrote: >This series implements the MSI address mapping/unmapping in the MSI layer. >IOMMU binding hap

Re: [PATCH 2/7] iommu/arm-smmu: Convert ThunderX workaround to new method

On 4/13/16, 10:12 AM, "Robin Murphy" wrote: >With a framework for implementation-specific funtionality in place, the >currently-FDT-dependent ThunderX workaround gets to be the first user. > >Signed-off-by: Robin Murphy >--- > drivers/iommu/arm-smmu.c | 27 ++- > 1 fi

Re: [PATCH 1/7] iommu/arm-smmu: Differentiate specific implementations

On 4/13/16, 10:12 AM, "Robin Murphy" wrote: >As the inevitable reality of implementation-specific errata workarounds >begin to accrue alongside our integration quirk handling, it's about >time the driver had a decent way of keeping track. Extend the per-SMMU >data so we can identify specific

Re: [PATCH V4] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

Thanks. On 3/24/16, 10:51 AM, "Will Deacon" wrote: >On Thu, Mar 24, 2016 at 05:36:39PM +0000, Chalamarla, Tirumalesh wrote: >> Do you want me to resend it with path version number change? > >Shouldn't be any need. I've queued this locally, and will push o

Re: [PATCH V4] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

Hi Will, Do you want me to resend it with path version number change? Thanks, Tirumalesh. On 3/4/16, 1:56 PM, "Chalamarla, Tirumalesh" wrote: >Due to Errata#27704 CN88xx SMMUv2,supports only shared ASID and VMID >namespaces; specifically within a given node SMMU0 and

Re: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

On 3/1/16, 7:07 PM, "Will Deacon" wrote: >On Wed, Feb 24, 2016 at 01:13:53PM -0800, Tirumalesh Chalamarla wrote: >> Due to Errata#27704 CN88xx SMMUv2,supports only shared ASID and VMID >> namespaces; specifically within a given node SMMU0 and SMMU1 share, >> as does SMMU2 and SMMU3. >> >>

Re: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

On 2/24/16, 3:32 AM, "Mark Rutland" wrote: >On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote: >> in Summary, >> >> if i change asid-base to cavium,asid-base and still use DT for >> supplying base value, is this a solution that will be accepted, > >No. The property is _

Re: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

On 2/9/16, 3:52 AM, "Robin Murphy" wrote: >On 05/02/16 18:47, tchalama...@caviumnetworks.com wrote: >> From: Tirumalesh Chalamarla >> >> An issue exists whereby the Linux kernel requires that ASIDs are a >> unique namespace per SMMU. > >I too tend to consider the SMMUv2 architecture an "iss

Re: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

On 2/5/16, 12:02 PM, "Mark Rutland" wrote: >On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalama...@caviumnetworks.com wrote: >> From: Tirumalesh Chalamarla >> >> An issue exists whereby the Linux kernel requires that ASIDs are a >> unique namespace per SMMU. > >The SMMU architecture requi

Re: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704

On 2/5/16, 12:15 PM, "Mark Rutland" wrote: >On Fri, Feb 05, 2016 at 08:02:09PM +, Mark Rutland wrote: >> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalama...@caviumnetworks.com >> wrote: >> > From: Tirumalesh Chalamarla >> > >> > An issue exists whereby the Linux kernel requires that

Re: iommu/arm-smmu-v2 ASID/VMID calculation

On 1/26/16, 3:54 AM, "Will Deacon" wrote: >On Tue, Jan 26, 2016 at 03:11:27AM +0000, Chalamarla, Tirumalesh wrote: >> one my colleague points out, ASIDPNE also implementation defined. > >It looks pretty well defined to me, despite being a hint: > > This AS

Re: iommu/arm-smmu-v2 ASID/VMID calculation

On 1/26/16, 3:48 AM, "Robin Murphy" wrote: >On 26/01/16 03:11, Chalamarla, Tirumalesh wrote: >> one my colleague points out, ASIDPNE also implementation defined. > >ASIDPNE only covers whether the SMMU's TLBs may ignore broadcast >_invalidation_ or not, n

Re: iommu/arm-smmu-v2 ASID/VMID calculation

one my colleague points out, ASIDPNE also implementation defined. Thanks, Tirumalesh. On 1/25/16, 4:48 PM, "linux-arm-kernel on behalf of Chalamarla, Tirumalesh" wrote: >I don’t think it followed spec. > >The SMMU spec (IHI0062C) says (section 2.2): > > - The

Re: iommu/arm-smmu-v2 ASID/VMID calculation

gt;On Thu, Jan 21, 2016 at 06:52:34PM +, Chalamarla, Tirumalesh wrote: >> Hi Will, > >Hello, > >> Current ASID/VMID calculation logic makes lot of assumption about internal >> TLB >> implementation of SMMU, > >Not really. It makes assumptions that the ha

iommu/arm-smmu-v2 ASID/VMID calculation

Hi Will, Current ASID/VMID calculation logic makes lot of assumption about internal TLB implementation of SMMU, Systems like ThunderX have more than one smmu in the system and it can use same TLBs with more than one of them and expects ASID to be unique Current logic #define ARM_SMMU_CB_ASID(c

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

M_SMMU_CB_ATS1PR_HI); + u64 reg = iova & ~0xfff; + smmu_writeq(reg, cb_base + ARM_SMMU_CB_ATS1PR_LO); } if (readl_poll_timeout_atomic(cb_base + ARM_SMMU_CB_ATSR, tmp, ~ On Jul 30, 2015, at 12:07 PM, Chalamarla, Tirumalesh mailto:tchalama...@caviumnetworks.c

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 2/3] Docs: dt: Add PCI MSI map bindings

looks good. possible to describe the chip we have. > On Jul 23, 2015, at 9:52 AM, Mark Rutland wrote: > > Currently msi-parent is used by a few bindings to describe the > relationship between a PCI root complex and a single MSI controller, but > this property does not have a generic binding docum

Re: Master-aware devices and sideband ID data

any update on this? On Jun 10, 2015, at 1:11 AM, Will Deacon mailto:will.dea...@arm.com>> wrote: On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote: On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote: On Thu, Jun 04, 2015 at 11:19:30PM +0100, Chalamarla, Tirumalesh wro

Re: Master-aware devices and sideband ID data

> On Jun 1, 2015, at 3:22 AM, Mark Rutland wrote: > > On Fri, May 29, 2015 at 06:46:07PM +0100, Chalamarla, Tirumalesh wrote: >> >>> On May 27, 2015, at 10:39 AM, Mark Rutland wrote: >>> >>> On Tue, May 26, 2015 at 11:20:59PM +0100, Chalamarla, Ti

Re: Master-aware devices and sideband ID data

> On May 27, 2015, at 10:39 AM, Mark Rutland wrote: > > On Tue, May 26, 2015 at 11:20:59PM +0100, Chalamarla, Tirumalesh wrote: >> This is some thing we also like to see in ITS and SMMU drivers. >>> On Mar 24, 2015, at 8:50 AM, Mark Rutland wrote: >>> >

Re: Master-aware devices and sideband ID data

This is some thing we also like to see in ITS and SMMU drivers. > On Mar 24, 2015, at 8:50 AM, Mark Rutland wrote: > > Hi all, > > For some devices, identification of particular masters is critical to > their operation (e.g. IOMMUs, MSI controllers). The identity of masters > is determined from

RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

When I say emulating ITS, I mean translating guest ITS commands to physical ITS commands and placing them in physical queue. Regards, Tirumalesh. -Original Message- From: kvmarm-boun...@lists.cs.columbia.edu [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Chalamarla

RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

Sorry there was a type, The question is: How is VFIO restricting software from writing to MSI/MSI-X vectors of the device. -Original Message- From: Chalamarla, Tirumalesh Sent: Thursday, June 26, 2014 11:16 AM To: Chalamarla, Tirumalesh; Joerg Roedel; Will Deacon Cc: k

RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

[mailto:will.dea...@arm.com] Sent: Friday, June 27, 2014 1:47 AM To: Alex Williamson Cc: Chalamarla, Tirumalesh; Joerg Roedel; k...@vger.kernel.org; open list; stuart.yo...@freescale.com; iommu@lists.linux-foundation.org; t...@virtualopensystems.com; kvm...@lists.cs.columbia.edu; moderated

RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

ssage- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Thursday, June 26, 2014 12:00 PM To: Chalamarla, Tirumalesh Cc: Joerg Roedel; Will Deacon; k...@vger.kernel.org; open list; stuart.yo...@freescale.com; iommu@lists.linux-foundation.org; t...@virtualopensystems.com

RE: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

Forgive me if this discussion is not relative here, but I thought it is. How is VFIO restricting devices from writing to MSI/MSI-X, Is all the vector area is mapped by VFIO to trap the accesses. I am asking this because we might need to emulate ITS somewhere either in KVM or VFIO to provide