[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZvxNo8ZWeyBOBU8b@Asurada-Nvidia>
Date: Tue, 1 Oct 2024 12:29:39 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Yang Shi <yang@...amperecomputing.com>
CC: <jgg@...pe.ca>, <will@...nel.org>, <robin.murphy@....com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iommu/arm-smmu-v3: Fix L1 stream table index calculation
for AmpereOne
On Tue, Oct 01, 2024 at 12:09:03PM -0700, Yang Shi wrote:
> On 10/1/24 11:27 AM, Nicolin Chen wrote:
> > On Tue, Oct 01, 2024 at 11:03:46AM -0700, Yang Shi wrote:
> > > Using 64 bit immediate when doing shift can solve the problem. The
> > > disssembly after the fix looks like:
> > [...]
> >
> > > unsigned int last_sid_idx =
> > > - arm_smmu_strtab_l1_idx((1 << smmu->sid_bits) - 1);
> > > + arm_smmu_strtab_l1_idx((1UL << smmu->sid_bits) - 1);
> > Could a 32-bit build be a corner case where UL is no longer a
> > "64 bit" stated in the commit message?
>
> It shouldn't. Because smmu v3 depends on ARM64.
>
> config ARM_SMMU_V3
> tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
> depends on ARM64
ARM64 can have aarch32 support. I am not sure if ARM64 running a
32-bit OS can be a case though, (and not confined to AmpereOne).
> > Then, can ssid_bits/s1cdmax be a concern similarly?
>
> IIUC, ssid_bits is determined by IDR1_SSIDSIZE. It is GENMASK(10, 6). So
> it shouldn't be 32. IDR1_SIDSIZE is GENMASK(5, 0).
Rechecked the RM. Yea, max sid can be 32 but max ssid is 20 at
this moment, so we should be safe.
Thanks
Nicolin
Powered by blists - more mailing lists