From: Marc Zyngier <marc.zyngier@arm.com> To: Robin Murphy <robin.murphy@arm.com>, Linu Cherian <linuc.decode@gmail.com>, Neil Leeder <nleeder@codeaurora.org> Cc: Will Deacon <will.deacon@arm.com>, Mark Rutland <mark.rutland@arm.com>, Mark Langsdorf <mlangsdo@redhat.com>, Jon Masters <jcm@redhat.com>, Timur Tabi <timur@codeaurora.org>, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>, Mark Salter <msalter@redhat.com>, linux-arm-kernel@lists.infradead.org, linu.cherian@cavium.com, Sunil.Goutham@cavium.com, ynorov@caviumnetworks.com Subject: Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Date: Mon, 18 Dec 2017 15:39:22 +0000 [thread overview] Message-ID: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com> (raw) In-Reply-To: <999b7132-2de8-2872-1067-fc7e02cbc57a@arm.com> Thanks for putting me in the loop Robin. On 18/12/17 14:48, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: >> Hi, >> >> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >>> This adds a driver for the SMMUv3 PMU into the perf framework. >>> It includes an IORT update to support PM Counter Groups. >>> >> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way >> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. >> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks >> are managed by two independent drivers. >> >> The problem arises when we want to alloc/free MSIs for these devices >> using the APIs, platform_msi_domain_alloc/free_irqs. >> Platform bus id being same for these two hardware blocks, they end up sharing the same >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management >> of this shared ITT becomes a problem when they are managed by two independent >> drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Understatement of the day! ;-) Yes, it is a massive headache, and will either result in a temporary loss of interrupts (at some point you have to unmap the ITT), or with spurious interrupts (you generate interrupts for all the MSIs you've blackholed when unmapping the ITT). > >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors >> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs >> function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named components or > root complexes (rather than directly with SMMU instances). We certainly > don't want to end up spraying similar PMCG DevID logic around all manner > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > will be expected to have distinct IDs from their host devices, they > could reasonably still overlap with other PMCGs/SMMUs). > >> Would like to know your expert opinion on what would be the right approach >> to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ I can revive the hack I once wrote for that (and that was hoping to forever forget), but that's pretty disgusting, and subject to the above caveat. Thanks, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Date: Mon, 18 Dec 2017 15:39:22 +0000 [thread overview] Message-ID: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com> (raw) In-Reply-To: <999b7132-2de8-2872-1067-fc7e02cbc57a@arm.com> Thanks for putting me in the loop Robin. On 18/12/17 14:48, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: >> Hi, >> >> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: >>> This adds a driver for the SMMUv3 PMU into the perf framework. >>> It includes an IORT update to support PM Counter Groups. >>> >> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way >> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU. >> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks >> are managed by two independent drivers. >> >> The problem arises when we want to alloc/free MSIs for these devices >> using the APIs, platform_msi_domain_alloc/free_irqs. >> Platform bus id being same for these two hardware blocks, they end up sharing the same >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management >> of this shared ITT becomes a problem when they are managed by two independent >> drivers. > > What is the problem exactly? IIRC resizing a possibly-live ITT is a > right pain in the bum to do - is it just that? Understatement of the day! ;-) Yes, it is a massive headache, and will either result in a temporary loss of interrupts (at some point you have to unmap the ITT), or with spurious interrupts (you generate interrupts for all the MSIs you've blackholed when unmapping the ITT). > >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors >> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs >> function call for all devices that share the platform bus id. > > I'm not sure how scalable that approach would be, since it's not > entirely obvious how to handle PMCGs associated with named components or > root complexes (rather than directly with SMMU instances). We certainly > don't want to end up spraying similar PMCG DevID logic around all manner > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs > will be expected to have distinct IDs from their host devices, they > could reasonably still overlap with other PMCGs/SMMUs). > >> Would like to know your expert opinion on what would be the right approach >> to handle this case ? > > My gut feeling says the way to deal with this properly is in the ITS > code, but I appreciate that that's a lot easier said than done :/ I can revive the hack I once wrote for that (and that was hoping to forever forget), but that's pretty disgusting, and subject to the above caveat. Thanks, M. -- Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2017-12-18 15:39 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-04 19:59 [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-04 19:59 ` [PATCH 1/2] acpi: arm64: add iort support for PMCG Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-07 11:17 ` Robin Murphy 2017-08-07 11:17 ` Robin Murphy 2017-08-07 20:52 ` Leeder, Neil 2017-08-07 20:52 ` Leeder, Neil 2017-08-07 16:44 ` Lorenzo Pieralisi 2017-08-07 16:44 ` Lorenzo Pieralisi 2017-08-07 21:00 ` Leeder, Neil 2017-08-07 21:00 ` Leeder, Neil 2018-01-30 10:39 ` Shameerali Kolothum Thodi 2018-01-30 10:39 ` Shameerali Kolothum Thodi 2018-01-30 18:00 ` Lorenzo Pieralisi 2018-01-30 18:00 ` Lorenzo Pieralisi 2018-01-31 12:10 ` Shameerali Kolothum Thodi 2018-01-31 12:10 ` Shameerali Kolothum Thodi 2018-01-31 12:34 ` Lorenzo Pieralisi 2018-01-31 12:34 ` Lorenzo Pieralisi 2017-08-04 19:59 ` [PATCH 2/2] perf: add arm64 smmuv3 pmu driver Neil Leeder 2017-08-04 19:59 ` Neil Leeder 2017-08-07 14:31 ` Robin Murphy 2017-08-07 14:31 ` Robin Murphy 2017-08-07 21:18 ` Leeder, Neil 2017-08-07 21:18 ` Leeder, Neil 2017-12-05 5:01 ` Linu Cherian 2017-12-05 5:01 ` Linu Cherian 2018-03-29 7:03 ` Yisheng Xie 2018-03-29 7:03 ` Yisheng Xie [not found] ` <e55ab4404143ea0b3cc4795a93e37480@codeaurora.org> 2018-04-01 5:44 ` Neil Leeder 2018-04-01 5:44 ` Neil Leeder 2018-04-02 6:37 ` Yisheng Xie 2018-04-02 6:37 ` Yisheng Xie 2018-04-02 14:24 ` Hanjun Guo 2018-04-02 14:24 ` Hanjun Guo 2018-04-02 17:59 ` Neil Leeder 2018-04-02 17:59 ` Neil Leeder 2018-04-03 1:15 ` Hanjun Guo 2018-04-03 1:15 ` Hanjun Guo 2018-04-04 11:35 ` Lorenzo Pieralisi 2018-04-04 11:35 ` Lorenzo Pieralisi 2018-05-02 14:20 ` Agustin Vega-Frias 2018-05-02 14:20 ` Agustin Vega-Frias 2018-05-03 9:22 ` Shameerali Kolothum Thodi 2018-05-03 9:22 ` Shameerali Kolothum Thodi 2018-04-18 11:05 ` Shameerali Kolothum Thodi 2018-04-18 11:05 ` Shameerali Kolothum Thodi 2018-04-19 1:17 ` Yisheng Xie 2018-04-19 1:17 ` Yisheng Xie 2017-08-09 7:56 ` [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support Hanjun Guo 2017-08-09 7:56 ` Hanjun Guo 2017-08-09 15:48 ` Leeder, Neil 2017-08-09 15:48 ` Leeder, Neil 2017-08-10 1:26 ` Hanjun Guo 2017-08-10 1:26 ` Hanjun Guo 2017-08-11 3:28 ` Leeder, Neil 2017-08-11 3:28 ` Leeder, Neil 2017-10-12 10:58 ` Hanjun Guo 2017-10-12 10:58 ` Hanjun Guo 2017-10-12 11:05 ` Lorenzo Pieralisi 2017-10-12 11:05 ` Lorenzo Pieralisi 2017-10-12 11:11 ` Hanjun Guo 2017-10-12 11:11 ` Hanjun Guo 2017-10-31 23:33 ` Yury Norov 2017-10-31 23:33 ` Yury Norov 2017-11-02 20:38 ` Leeder, Neil 2017-11-02 20:38 ` Leeder, Neil 2017-12-10 2:35 ` Linu Cherian 2017-12-10 2:35 ` Linu Cherian 2017-12-18 14:48 ` Robin Murphy 2017-12-18 14:48 ` Robin Murphy 2017-12-18 15:39 ` Marc Zyngier [this message] 2017-12-18 15:39 ` Marc Zyngier 2017-12-19 6:55 ` Linu Cherian 2017-12-19 6:55 ` Linu Cherian 2017-12-19 12:11 ` Marc Zyngier 2017-12-19 12:11 ` Marc Zyngier 2017-12-19 6:36 ` Linu Cherian 2017-12-19 6:36 ` Linu Cherian
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=7312293d-8897-95d8-9045-9e97a6c150eb@arm.com \ --to=marc.zyngier@arm.com \ --cc=Sunil.Goutham@cavium.com \ --cc=broonie@kernel.org \ --cc=jcm@redhat.com \ --cc=linu.cherian@cavium.com \ --cc=linuc.decode@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mlangsdo@redhat.com \ --cc=msalter@redhat.com \ --cc=nleeder@codeaurora.org \ --cc=robin.murphy@arm.com \ --cc=timur@codeaurora.org \ --cc=will.deacon@arm.com \ --cc=ynorov@caviumnetworks.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.