Received-SPF: pass (google.com: domain of linux-kernel+bounces-111921-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: Will Deacon <will@kernel.org>, Petr Tesarik <petrtesarik@huaweicloud.com>
CC: Christoph Hellwig <hch@lst.de>, Marek Szyprowski
	<m.szyprowski@samsung.com>, Robin Murphy <robin.murphy@arm.com>, Petr Tesarik
	<petr.tesarik1@huawei-partners.com>, open list
	<linux-kernel@vger.kernel.org>, "open list:DMA MAPPING HELPERS"
	<iommu@lists.linux.dev>, Roberto Sassu <roberto.sassu@huaweicloud.com>, Petr
 Tesarik <petr@tesarici.cz>
Subject: RE: [PATCH v3 0/2] swiotlb: allocate padding slots if necessary
Thread-Topic: [PATCH v3 0/2] swiotlb: allocate padding slots if necessary
Thread-Index: AQHae7Pv4SNgrMIt8ky2VYTC2f59Y7FD3oWAgAAqOwA=
Date: Fri, 22 Mar 2024 18:11:50 +0000
Message-ID:
 <SN6PR02MB41574F4837E875F3D158B329D4312@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240321171902.85-1-petrtesarik@huaweicloud.com>
 <20240322150941.GA5634@willie-the-truck>
In-Reply-To: <20240322150941.GA5634@willie-the-truck>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?iShP3LE8mZfp8+FO6QJPouqCjfJkbqIZyGs34gzKyd96GC+AkrdkjSWexyTz?=
 =?us-ascii?Q?ukHz7jx6XkrkiqcuOGa78qB6oAFntqYIxmt0VD+H/jhrcRvA90nlTFQMDi7G?=
 =?us-ascii?Q?XNpzfxw05590mWkWJMC9DHV22v2f39Lv1abc4uq+bME414iXF440/xmhdD2j?=
 =?us-ascii?Q?yMK4fyMJvZNF2Wpn9g1/buclher6pSWsT9wasQeMUsgfRTsO5+wE7SNbQ3jt?=
 =?us-ascii?Q?msFrbPu5op5I9drMFr5n6Hsp6FJfXzpGoURBa7rIpbpHH4LT0XxjJXhcPr2p?=
 =?us-ascii?Q?ohcrNe/VQkj6uIrU1vfr+om5Y/l3tSmn175FIlbpR00TuC7TFGPv8dYM4GK7?=
 =?us-ascii?Q?X35P23jV/lw8U/WKi8fPmq+xqbTJKmXLWp8vqCIYxCXpqFjdMjAhL5Fpr5H6?=
 =?us-ascii?Q?VAkL7/bnJJNXOkcb7tTLw1R5BfdyF9oXtJc3hSrD3sATuMsV88liiPE6v71X?=
 =?us-ascii?Q?BYEw3KWOfc9n4OQgy0xfJAFT4SDLQnv6LQmdODZjsvkhFO68e5rgBEPGv/aH?=
 =?us-ascii?Q?wtz7skUng0i42dFSh3zn0ThwxH7kH2I6fvSZdufuWJZ0bjEDjwVkFfRQnjjq?=
 =?us-ascii?Q?tyH7z/Llx0nUaVDC54NjpHZN+RXlMWAmds8IN+dVOAP0nOhALdsJvLRz2lAc?=
 =?us-ascii?Q?aRgEZs7TkLtctAw7Wl+5yNg4F6RAsEXaXKDWXHnWvrqWwvy5bw6coslkEfm6?=
 =?us-ascii?Q?LLn8qBHBqOYNI+OGiISEmVr9omjF0M1B4VDHdp6dcg1wj3y7ufUViVamUP5t?=
 =?us-ascii?Q?FshK2/5YCcVFtmptEfE/MEI5IQSnSRvEmHLQU6jvy1wGKxiU6G2KO4PMSjwO?=
 =?us-ascii?Q?vKHlCt51acZ32VtUqm4k0h3m/iT1OsC+9sF2ukrxBNwIL0hW2VrmHNCE6dtq?=
 =?us-ascii?Q?oSJy0y3aI4eVLzc4WCSTng1uvV0MfbZ7kTAX1AdnmWbh713+/j5yenegRvm1?=
 =?us-ascii?Q?e4lejrFRIvOG7nFysSWay3HIWRDAmmBNTPsvLCuqnh8206w8qeoj6ApbhNdF?=
 =?us-ascii?Q?umguan7eAKNAuEwG6j+JYtfoYaTgPaCNDD4n+KVL+fNp4uHCacpYKfPE906s?=
 =?us-ascii?Q?lFcY0G8WUf+7P6QrkgB0HislKnpKFAVG4yUQv7/sPRkKQ1MLIrV+k1cgnDVo?=
 =?us-ascii?Q?/XK6vPaeWidHzRuRD1Nq8L7794j2jUD0RRD/r5wD/bvAeT5cWAn4V99Qclts?=
 =?us-ascii?Q?GTk23h4rUOkHxXc5WIoeqQIa+Hua+2QdarrZZA=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: 99a20e44-2544-43e2-5cda-08dc4a9b8bab
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 18:11:50.3402
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN3PEPF00013E2A

From: Will Deacon <will@kernel.org> Sent: Friday, March 22, 2024 8:10 AM
>=20
> Hi Petr,
>=20
> On Thu, Mar 21, 2024 at 06:19:00PM +0100, Petr Tesarik wrote:
> > From: Petr Tesarik <petr.tesarik1@huawei-partners.com>
> >
> > If the allocation alignment is bigger than IO_TLB_SIZE and min_align_ma=
sk
> > covers some bits in the original address between IO_TLB_SIZE and
> > alloc_align_mask, preserve these bits by allocating additional padding
> > slots before the actual swiotlb buffer.
>=20
> Thanks for fixing this! I was out at a conference last week, so I didn't
> get very far with it myself, but I ended up in a pickle trying to avoid
> extending 'struct io_tlb_slot'. Your solution is much better than the
> crazy avenue I started going down...
>=20
> With your changes, can we now simplify swiotlb_align_offset() to ignore
> dma_get_min_align_mask() altogether and just:
>=20
> 	return addr & (IO_TLB_SIZE - 1);
>=20
> ?
>=20

I don't think such a change is correct, since we want to allow the
DMA min_align_mask to work if it is set to 0x3FF or 0x1FF or
something else smaller than IO_TLB_SIZE - 1.

Petr's new offset calculation in swiotlb_tbl_map_single() is this:

offset =3D orig_addr & dma_get_min_align_mask(dev) &
                (alloc_align_mask | (IO_TLB_SIZE - 1));

In the normal stream mapping case, where alloc_align_mask is
zero, Petr's new statement is equivalent to swiotlb_align_offset().
And I think it needs to continue to be equivalent so that
swiotlb_search_pool_area(), swiotlb_bounce()  and
swiotlb_release_slots() calculate the same offset as
swiotlb_tbl_map_single() uses after it separately processes
the padding slots.

Perhaps a better approach to maintaining the equivalence is
to modify swiotlb_align_offset() to be Petr's new calculation,
with alloc_align_mask passed as an argument.
swiotlb_search_pool_area(), swiotlb_bounce(), and
swiotlb_release_slots() would all pass 0 as the alloc_align_mask
argument.

Michael