[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250506154014.GM2260621@ziepe.ca>
Date: Tue, 6 May 2025 12:40:14 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Daniel Mentz <danielmentz@...gle.com>
Cc: iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
Will Deacon <will@...nel.org>, Mostafa Saleh <smostafa@...gle.com>,
Pranjal Shrivastava <praan@...gle.com>
Subject: Re: [PATCH] iommu/io-pgtable-arm: Support contiguous bit in
translation tables
On Wed, Apr 30, 2025 at 11:19:24PM +0000, Daniel Mentz wrote:
> The contiguous bit in translation table entries can be used as a hint to
> SMMU that a group of adjacent translation table entries have consistent
> attributes and point to a contiguous and properly aligned output address
> range. This enables SMMU to predict the properties of the remaining
> translation table entries in the same group without accessing them. It
> also allows an SMMU implementation to make more efficient use of its TLB
> by using a single TLB entry to cover all translation table entries in
> the same group.
>
> In the case of 4KB granule size, there are 16 translation table entries
> in one group.
>
> This change sets the contiguous bit for such groups of entries that are
> completely covered by a single call to map_pages. As it stands, the code
> wouldn't set the contiguous bit if a group of adjacent descriptors is
> completed by separate calls to map_pages.
Nor should it
This seems like a pretty hacky implementation, it doesn't set the
pgsize bitmap to indicate support and it doesn't have a safety check
on unmap to protect against partial unmap of a huge page.
Wouldn't it be better to use the pgsize bit map and rely on the core
code to tell a contig page size is being used and then it can
trivially set the PTE bit without having to do all this extra work?
Jason
Powered by blists - more mailing lists