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

ux-ker...@vger.kernel.org; Goutham, 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 ins

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" <eric.au...@linaro.org> wrote: >Hi Chalamarla, >> On 5/9/16, 12:48 AM, "Eric Auger" <eric.au...@linaro.org> wrote: >> >>> Hi Chalarmala, >>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh w

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" <eric.au...@linaro.org> 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 depend

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 >--- >

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

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

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

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

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, >

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. >

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 >> > >> >

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 >>

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

On 1/26/16, 3:54 AM, "Will Deacon" <will.dea...@arm.com> wrote: >On Tue, Jan 26, 2016 at 03:11:27AM +, Chalamarla, Tirumalesh wrote: >> one my colleague points out, ASIDPNE also implementation defined. > >It looks pretty well defined to me, despite

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

On 1/26/16, 3:48 AM, "Robin Murphy" <robin.mur...@arm.com> 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 >

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

l.dea...@arm.com> wrote: >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

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" <linux-arm-kernel-boun...@lists.infradead.org on behalf of tirumalesh.chalama...@caviumnetworks.com> wrote:

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

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

(cb_base + ARM_SMMU_CB_ATSR, tmp, ~ On Jul 30, 2015, at 12:07 PM, Chalamarla, Tirumalesh tchalama...@caviumnetworks.commailto:tchalama...@caviumnetworks.com wrote: On Jul 30, 2015, at 11:45 AM, Will Deacon will.dea...@arm.commailto:will.dea...@arm.com wrote: Hello, On Thu, Jul 30, 2015 at 06:55

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 mark.rutl...@arm.com 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

Re: Master-aware devices and sideband ID data

any update on this? On Jun 10, 2015, at 1:11 AM, Will Deacon will.dea...@arm.commailto: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

Re: Master-aware devices and sideband ID data

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

Re: Master-aware devices and sideband ID data

On May 27, 2015, at 10:39 AM, Mark Rutland mark.rutl...@arm.com 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 mark.rutl...@arm.com wrote: Hi all

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 mark.rutl...@arm.com 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

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

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