linux-kernel - Re: [PATCH v14 5/6] iommu/arm-smmu: add ACTLR data and support for SC7280

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240827124714.GB4772@willie-the-truck>
Date: Tue, 27 Aug 2024 13:47:15 +0100
From: Will Deacon <will@...nel.org>
To: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
Cc: robdclark@...il.com, robin.murphy@....com, joro@...tes.org,
	jgg@...pe.ca, jsnitsel@...hat.com, robh@...nel.org,
	krzysztof.kozlowski@...aro.org, quic_c_gdjako@...cinc.com,
	dmitry.baryshkov@...aro.org, konrad.dybcio@...aro.org,
	iommu@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v14 5/6] iommu/arm-smmu: add ACTLR data and support for
 SC7280

On Mon, Aug 26, 2024 at 04:33:24PM +0530, Bibek Kumar Patro wrote:
> 
> 
> On 8/23/2024 9:29 PM, Will Deacon wrote:
> > On Fri, Aug 16, 2024 at 11:12:58PM +0530, Bibek Kumar Patro wrote:
> > > Add ACTLR data table for SC7280 along with support for
> > > same including SC7280 specific implementation operations.
> > > 
> > > Signed-off-by: Bibek Kumar Patro <quic_bibekkum@...cinc.com>
> > > ---
> > >   drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 58 +++++++++++++++++++++-
> > >   1 file changed, 57 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > index dc143b250704..a776c7906c76 100644
> > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> > > @@ -31,6 +31,55 @@
> > >   #define PREFETCH_MODERATE	(2 << PREFETCH_SHIFT)
> > >   #define PREFETCH_DEEP		(3 << PREFETCH_SHIFT)
> > > 
> > > +static const struct actlr_config sc7280_apps_actlr_cfg[] = {
> > > +	{ 0x0800, 0x04e0, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x0900, 0x0402, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x0901, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x0d01, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x1181, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1182, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1183, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1184, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1185, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1186, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1187, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1188, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x1189, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x118b, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x118c, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x118d, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x118e, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x118f, 0x0420, PREFETCH_DEEP | CPRE | CMTLB },
> > > +	{ 0x2000, 0x0020, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2040, 0x0000, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2062, 0x0000, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2080, 0x0020, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x20c0, 0x0020, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2100, 0x0020, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2140, 0x0000, PREFETCH_DEFAULT | CMTLB },
> > > +	{ 0x2180, 0x0020, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x2181, 0x0004, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x2183, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x2184, 0x0020, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +	{ 0x2187, 0x0000, PREFETCH_SHALLOW | CPRE | CMTLB },
> > > +};
> > > +
> > > +static const struct actlr_config sc7280_gfx_actlr_cfg[] = {
> > > +	{ 0x0000, 0x07ff, PREFETCH_DEEP | CPRE | CMTLB },
> > > +};
> > 
> > It's Will "stuck record" Deacon here again to say that I don't think
> > this data belongs in the driver.
> > 
> 
> Hi Will,
> 
> It will be difficult to reach a consensus here, with Robin and the DT folks
> okay to keep it in the driver, while you believe it doesn't belong there.
> 
> Robin, Rob, could you please share your thoughts on concluding the placement
> of this prefetch data?
> 
> As discussed earlier [1], the prefetch value for each client doesn’t define
> the hardware topology and is implementation-defined register writes used by
> the software driver.

It does reflect the hardware topology though, doesn't it? Those magic hex
masks above refer to stream ids, so the table is hard-coding the prefetch
values for particular matches. If I run on a different SoC configuration
with the same table, then the prefetch settings will be applied to the
wrong devices. How is that not hardware topology?

WIll