Received-SPF: pass (google.com: domain of linux-kernel+bounces-110924-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Michael Kelley <mhklinux@outlook.com>
To: Petr Tesarik <petrtesarik@huaweicloud.com>, Christoph Hellwig
	<hch@lst.de>, Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy
	<robin.murphy@arm.com>, Petr Tesarik <petr.tesarik1@huawei-partners.com>,
	Will Deacon <will@kernel.org>, open list <linux-kernel@vger.kernel.org>,
	"open list:DMA MAPPING HELPERS" <iommu@lists.linux.dev>
CC: Roberto Sassu <roberto.sassu@huaweicloud.com>, Petr Tesarik
	<petr@tesarici.cz>
Subject: RE: [PATCH v3 1/2] swiotlb: extend buffer pre-padding to
 alloc_align_mask if necessary
Thread-Topic: [PATCH v3 1/2] swiotlb: extend buffer pre-padding to
 alloc_align_mask if necessary
Thread-Index: AQHae7P1v9J3nfpwTEKyNy18gy4LeLFDKKig
Date: Fri, 22 Mar 2024 04:29:14 +0000
Message-ID:
 <SN6PR02MB4157AC19CFB8B800EA9748B3D4312@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240321171902.85-1-petrtesarik@huaweicloud.com>
 <20240321171902.85-2-petrtesarik@huaweicloud.com>
In-Reply-To: <20240321171902.85-2-petrtesarik@huaweicloud.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?E2MC81VjILT59ZfTEj7vfvMU9NyLRihGthb6chejX/On0kPegeKrFvsIz2g0?=
 =?us-ascii?Q?hbtr5IAtqXHGQahBp9hDn1n35kiHP8KeXTgo76LCLzbd32XnhpJUBDgEszTW?=
 =?us-ascii?Q?LUkEJ0tVtykwFBbDe4Oclmz4KAt4iR0fZZgB9+QiSvaNPxP6YPIoLp/WIRV4?=
 =?us-ascii?Q?0G8KfDtVidLhdFiNjy2lGQsqM0GnzYpAJw+LWABXYwLXnJ/ZfK8Tde6xYcND?=
 =?us-ascii?Q?IdsvxYM1EHiXHVxnMUWIhdfbE8vOR77rBtqiWPj4e7wkIAv3L0sWkTDEMYcJ?=
 =?us-ascii?Q?MnrKel2NDqZRGPZUqES+UmZ8BeSkfMRWiyEXGP6vHdkdbVJ88hy8QR34x2w5?=
 =?us-ascii?Q?RhHinA3/lQKWW8KnAFkvF4rBwqQwNS7Md9sMvxubP0/J9UXhylTSSvKLWLOB?=
 =?us-ascii?Q?AypR+Odv9GZiITEJHZGA8DRVoJafFZwAFgqLGyXjKXjw8gkHrqZs1+tNrwkg?=
 =?us-ascii?Q?8SZyRXIDF0rQ7om8uRMn/+Ka97o/uCy3ODrQqNaOVNQD7Rk4shB7CLD+6pKz?=
 =?us-ascii?Q?Cz75UsTZXnCG8yaInu8JeG9XdUEX3pS3uDZmnMvlBN/aQMmmtNd7QhzIFsnN?=
 =?us-ascii?Q?o/N1ZWRBXxXZ1wt75o54OBV6uEBVrcf28yiqDDnT22FC8h6LXvY/cjDAMd1i?=
 =?us-ascii?Q?dzmvKHpDf1Uf+/VWDHwgOryv2DNmYJzU1Sy1NbwYxGiIc8cyk/KYAkMyJB+J?=
 =?us-ascii?Q?PxCqblJYjCz+o5khRemwUEe71/EyG6Sbl9HQy1mxVMUhHB4xtBKXE0XGl0xJ?=
 =?us-ascii?Q?8h6prEHNm0jxdE9v6gb+stiINCjZ0g9++HXYzzX31TIk77Zhazjwgiw97EJe?=
 =?us-ascii?Q?lK7tOgALvH6a5lYc0eRQUGSz1ORUxVmDSPpEiAac367IuyHZ4EXlot8WT4oz?=
 =?us-ascii?Q?Q9/5Fv8HnNqvwzcw8iAEU/T2kPP+nTINxSAqDLvhE4Pga3KqpQhXC5KdXPVh?=
 =?us-ascii?Q?g86llAbHziIQMerJYKll7O5bMrCxmdeReVLt5lKHQ/VLjY+Nqp76YWYeCaUO?=
 =?us-ascii?Q?01OHxnUzhyejfG4/rsfWwh6Crn6B41dgi7eGWgoBuF4fcIxkCcmwppIpR7B6?=
 =?us-ascii?Q?R5rrYtiW5UCjRWPtP8mI9ywfxO4SFfmxm+qst9QTxfN2J+XJ0R07GJM/5VXb?=
 =?us-ascii?Q?5ICq70d/8wjDBfM7jJsiKByJTsb+QTTaL3IM1HkKNfStevAffgPg3Pe4RG0R?=
 =?us-ascii?Q?bC1uQJfFYerMvSOKXtNxyOlxup4u1CFKd8OGEQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ace95a29-a6f0-4b27-9211-08dc4a28a181
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 04:29:14.8450
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR02MB10336

From: Petr Tesarik <petrtesarik@huaweicloud.com> Sent: Thursday, March 21, =
2024 10:19 AM
>=20
> Allow a buffer pre-padding of up to alloc_align_mask. If the allocation
> alignment is bigger than IO_TLB_SIZE and min_align_mask covers any non-ze=
ro
> bits in the original address between IO_TLB_SIZE and alloc_align_mask,
> these bits are not preserved in the swiotlb buffer address.
>=20
> To fix this case, increase the allocation size and use a larger offset
> within the allocated buffer. As a result, extra padding slots may be
> allocated before the mapping start address.
>=20
> Leave orig_addr in these padding slots initialized to INVALID_PHYS_ADDR.
> These slots do not correspond to any CPU buffer, so attempts to sync the
> data should be ignored.
>=20
> The padding slots should be automatically released when the buffer is
> unmapped. However, swiotlb_tbl_unmap_single() takes only the address of t=
he
> DMA buffer slot, not the first padding slot. Save the number of padding
> slots in struct io_tlb_slot and use it to adjust the slot index in
> swiotlb_release_slots(), so all allocated slots are properly freed.
>=20
> Fixes: 2fd4fa5d3fb5 ("swiotlb: Fix alignment checks when both allocation =
and DMA masks are present")
> Link: https://lore.kernel.org/linux-iommu/20240311210507.217daf8b@meshula=
m.tesarici.cz/
> Signed-off-by: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> ---
>  kernel/dma/swiotlb.c | 35 +++++++++++++++++++++++++++++------
>  1 file changed, 29 insertions(+), 6 deletions(-)
>=20
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 86fe172b5958..3779a48eec9b 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -69,11 +69,14 @@
>   * @alloc_size:	Size of the allocated buffer.
>   * @list:	The free list describing the number of free entries available
>   *		from each index.
> + * @pad_slots:	Number of preceding padding slots. Valid only in the firs=
t
> + *		allocated non-padding slot.
>   */
>  struct io_tlb_slot {
>  	phys_addr_t orig_addr;
>  	size_t alloc_size;
> -	unsigned int list;
> +	unsigned short list;
> +	unsigned short pad_slots;
>  };
>=20
>  static bool swiotlb_force_bounce;
> @@ -287,6 +290,7 @@ static void swiotlb_init_io_tlb_pool(struct io_tlb_po=
ol *mem, phys_addr_t start,
>  					 mem->nslabs - i);
>  		mem->slots[i].orig_addr =3D INVALID_PHYS_ADDR;
>  		mem->slots[i].alloc_size =3D 0;
> +		mem->slots[i].pad_slots =3D 0;
>  	}
>=20
>  	memset(vaddr, 0, bytes);
> @@ -1328,11 +1332,12 @@ phys_addr_t swiotlb_tbl_map_single(struct device =
*dev, phys_addr_t orig_addr,
>  		unsigned long attrs)
>  {
>  	struct io_tlb_mem *mem =3D dev->dma_io_tlb_mem;
> -	unsigned int offset =3D swiotlb_align_offset(dev, orig_addr);
> +	unsigned int offset;
>  	struct io_tlb_pool *pool;
>  	unsigned int i;
>  	int index;
>  	phys_addr_t tlb_addr;
> +	unsigned short pad_slots;
>=20
>  	if (!mem || !mem->nslabs) {
>  		dev_warn_ratelimited(dev,
> @@ -1349,6 +1354,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *=
dev, phys_addr_t orig_addr,
>  		return (phys_addr_t)DMA_MAPPING_ERROR;
>  	}
>=20
> +	/*
> +	 * Calculate buffer pre-padding within the allocated space. Use it to
> +	 * preserve the low bits of the original address according to device's
> +	 * min_align_mask. Limit the padding to alloc_align_mask or slot size
> +	 * (whichever is bigger); higher bits of the original address are
> +	 * preserved by selecting a suitable IO TLB slot.
> +	 */
> +	offset =3D orig_addr & dma_get_min_align_mask(dev) &
> +		(alloc_align_mask | (IO_TLB_SIZE - 1));
>  	index =3D swiotlb_find_slots(dev, orig_addr,
>  				   alloc_size + offset, alloc_align_mask, &pool);
>  	if (index =3D=3D -1) {
> @@ -1364,6 +1378,10 @@ phys_addr_t swiotlb_tbl_map_single(struct device *=
dev, phys_addr_t orig_addr,
>  	 * This is needed when we sync the memory.  Then we sync the buffer if
>  	 * needed.
>  	 */
> +	pad_slots =3D offset / IO_TLB_SIZE;
> +	offset %=3D IO_TLB_SIZE;
> +	index +=3D pad_slots;
> +	pool->slots[index].pad_slots =3D pad_slots;
>  	for (i =3D 0; i < nr_slots(alloc_size + offset); i++)
>  		pool->slots[index + i].orig_addr =3D slot_addr(orig_addr, i);
>  	tlb_addr =3D slot_addr(pool->start, index) + offset;
> @@ -1385,12 +1403,16 @@ static void swiotlb_release_slots(struct device *=
dev, phys_addr_t tlb_addr)
>  	struct io_tlb_pool *mem =3D swiotlb_find_pool(dev, tlb_addr);
>  	unsigned long flags;
>  	unsigned int offset =3D swiotlb_align_offset(dev, tlb_addr);
> -	int index =3D (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
> -	int nslots =3D nr_slots(mem->slots[index].alloc_size + offset);
> -	int aindex =3D index / mem->area_nslabs;
> -	struct io_tlb_area *area =3D &mem->areas[aindex];
> +	int index, nslots, aindex;
> +	struct io_tlb_area *area;
>  	int count, i;
>=20
> +	index =3D (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
> +	index -=3D mem->slots[index].pad_slots;
> +	nslots =3D nr_slots(mem->slots[index].alloc_size + offset);
> +	aindex =3D index / mem->area_nslabs;
> +	area =3D &mem->areas[aindex];
> +
>  	/*
>  	 * Return the buffer to the free list by setting the corresponding
>  	 * entries to indicate the number of contiguous entries available.
> @@ -1413,6 +1435,7 @@ static void swiotlb_release_slots(struct device *de=
v, phys_addr_t tlb_addr)
>  		mem->slots[i].list =3D ++count;
>  		mem->slots[i].orig_addr =3D INVALID_PHYS_ADDR;
>  		mem->slots[i].alloc_size =3D 0;
> +		mem->slots[i].pad_slots =3D 0;
>  	}
>=20
>  	/*
> --
> 2.34.1

I've tested this patch in conjunction with Will's series of 6 patches, and
all looks good.  I tested on x86/x64 w/4K page size and on arm64
w/64K page size and a variety of min_align_mask values, alloc_align_mask
values, mapping size values, and orig_addr low order bits.  The tests are
doing disk I/O through the bounce buffers, and they verify that the data
written can be read back correctly.  So the bouncing is working correctly
with the slots that are being set up.

I'm not able to test with min_align_mask less than 4K, because my
synthetic disk driver doesn't work if that alignment isn't maintained.
But min_align_mask values of 8K, 16K, and 64K work correctly.  I've
seen up to 5 padding slots be allocated.

I have not tried any 32-bit builds.

Overall, it looks solid to me.

Tested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>