From: Jason Gunthorpe <jgg@ziepe.ca>
To: Yang Shi <yang@os.amperecomputing.com>
Cc: Daniel Mentz <danielmentz@google.com>,
nicolinc@nvidia.com, james.morse@arm.com, will@kernel.org,
robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [v3 PATCH] iommu/arm-smmu-v3: Fix L1 stream table index calculation for 32-bit sid size
Date: Mon, 7 Oct 2024 14:50:32 -0300 [thread overview]
Message-ID: <20241007175032.GA762027@ziepe.ca> (raw)
In-Reply-To: <faf12f39-0048-4e47-b600-e686cf82afe1@os.amperecomputing.com>
On Fri, Oct 04, 2024 at 06:53:25PM -0700, Yang Shi wrote:
> Yes, SIZE_MAX is ~(size_t)0, but size_t is unsigned long on ARM64. So the
> check actually doesn't do what I expect it should do. U32_MAX should be
> used.
SIZE_MAX is right:
static inline void *dmam_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp)
It is up to dmam_alloc_coherent() to not truncate it's arguments, when
you pass the u64 bounded to SIZE_MAX you guarentee that size will be a
valid value.
> > I think it should be capped to STRTAB_MAX_L1_ENTRIES
>
> I'm not expert on SMMU. Does the linear stream table have the same cap as
> 2-level stream table? Is this defined by the hardware spec? If it is not,
> why should we pick this value?
Well, the way the driver works is in the 2 level mode it caps the
whole table to STRTAB_MAX_L1_ENTRIES * STRTAB_NUM_L2_STES total SIDs
which is 0x2000000 or 26 bits
I guess there is a reasonable argument that linear or 2 level should
have the same software enforced max size. Though would put it at a max
2G linear STE which is still larger than Linux can allocate, so it
doesn't really make any practical difference compared to SIZE_MAX.
Jason
next prev parent reply other threads:[~2024-10-07 17:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 18:04 [v3 PATCH] iommu/arm-smmu-v3: Fix L1 stream table index calculation for 32-bit sid size Yang Shi
2024-10-04 21:14 ` Daniel Mentz
2024-10-04 21:47 ` Yang Shi
2024-10-05 1:03 ` Daniel Mentz
2024-10-05 1:53 ` Yang Shi
2024-10-07 16:36 ` Daniel Mentz
2024-10-07 17:49 ` Yang Shi
2024-10-07 17:50 ` Jason Gunthorpe [this message]
2024-10-07 18:43 ` Yang Shi
2024-10-08 13:34 ` Will Deacon
2024-10-08 15:15 ` Jason Gunthorpe
2024-10-08 17:04 ` Yang Shi
2024-10-08 17:41 ` Will Deacon
2024-10-08 17:42 ` Will Deacon
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=20241007175032.GA762027@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=danielmentz@google.com \
--cc=iommu@lists.linux.dev \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.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: link
Be 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.