Received-SPF: pass (google.com: domain of linux-kernel+bounces-86942-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Michael Kelley <mhklinux@outlook.com>
To: Christoph Hellwig <hch@lst.de>
CC: Will Deacon <will@kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, Petr Tesarik
	<petr.tesarik1@huawei-partners.com>, "kernel-team@android.com"
	<kernel-team@android.com>, "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy
	<robin.murphy@arm.com>, Dexuan Cui <decui@microsoft.com>, Nicolin Chen
	<nicolinc@nvidia.com>
Subject: RE: [PATCH v5 6/6] swiotlb: Remove pointless stride adjustment for
 allocations >= PAGE_SIZE
Thread-Topic: [PATCH v5 6/6] swiotlb: Remove pointless stride adjustment for
 allocations >= PAGE_SIZE
Thread-Index: AQHaakuep9s0mIf3eE+om+sQlmyZtbEg06/QgAAR1sCAAG26AIAAIlEw
Date: Thu, 29 Feb 2024 15:44:11 +0000
Message-ID:
 <SN6PR02MB4157314F142D05E279B7991ED45F2@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240228133930.15400-1-will@kernel.org>
 <20240228133930.15400-7-will@kernel.org>
 <SN6PR02MB4157A62353559DA8DB8BC4ADD45F2@SN6PR02MB4157.namprd02.prod.outlook.com>
 <SN6PR02MB41577D09E97B1D9645369D58D45F2@SN6PR02MB4157.namprd02.prod.outlook.com>
 <20240229133346.GA7177@lst.de>
In-Reply-To: <20240229133346.GA7177@lst.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?ZT4I8DVdHEFTvkjZhjwkPNGmGMITOhvjgWjUhIDTZzxWndhQDELTx8wYtAEs?=
 =?us-ascii?Q?fQWW+Jh1F/zuLYuyQs83TMHeGAZ5r9Ezwu2Nx4SOgsD1IolWXCrfc5u0ONYh?=
 =?us-ascii?Q?iJeSx2j1dhNBvtQghZq9VJ9h4UZViN3q35jKyYvlJjWuI1F9UgNvCMbxCxME?=
 =?us-ascii?Q?F0r8EqTCF4iFSk6G6XVaWF9Him4ZxoaQxhd3NyabhpxCxLQskuDt6BUaKr+I?=
 =?us-ascii?Q?knUl2bdm7OJgthwxI1wCbXNs7Vc+EyoURc2sLfITdzUSdVenn2EjsWtGkpwh?=
 =?us-ascii?Q?/Gp/hrOBZPifFjQZUVqxQYYivV7P8XmOZn9WX8vWn5mcgMS08BfgjSf5TqOY?=
 =?us-ascii?Q?5KqTNZRw953pBb3aKCKCUaU2FSLPVjhJKofLvVp4VSwOgN08oU+CJfcFZ7oB?=
 =?us-ascii?Q?ZVAqfgaTzIrOuf2yCb7HKzSSjSEA9sSfGfX8Wdk34rtlE9+XB2jVPf17KoQf?=
 =?us-ascii?Q?aJzc/kxxpIZN5U2RHhT8eqNmAW5TYK2O8n40keOJsKCLyJFNKbwRHVd6F5i2?=
 =?us-ascii?Q?jgK3vcLc4ZKutVT++Vc6ooOTCC27YNexoIKI0HcImirxKAxF5wcrPJI24G/f?=
 =?us-ascii?Q?boDWY19ZvdAdhsjYvy0FjsiJg+B4KI5zlsoqjAMUSWONb/s0EOCbL49z4ByC?=
 =?us-ascii?Q?s54AkUziwWSb1w8yolV5yds55HkJTKxT8Em9zx54hv7JQrZV2irhy8qA4LXx?=
 =?us-ascii?Q?QMemd6XYhaPDcRwcRA4A3Egkjeu5MOKmrliZ0hllJsqUdQqWiI7dVSK8BnzC?=
 =?us-ascii?Q?ZAHlR2m9riqogT4ihhQoBpn8fYlbd64LFqCD0cX/C3o6zaf2PrmNilV9MBSN?=
 =?us-ascii?Q?9TdCBoSivYNnzd+90BntUd/0ALk6WD2hr294bVAzeAuM7UUFIcBLPKosyvNq?=
 =?us-ascii?Q?OFh62/HDTKbGi8rYxPzDtzdyjZ7P5gmCjR81JUlnl40Hne7Z1T4gJLoyfdQL?=
 =?us-ascii?Q?gbZ8AfdFRWvHUmX8V/Isas2UusASLY8weyKzAFmVxoJsyIhT0EuhMSaiBfqW?=
 =?us-ascii?Q?GOV0Og46iPmyJQCEVLgiG24yjdXdrAI4SMxVkQO7LIO9vh7OzVHq6yqDRUOc?=
 =?us-ascii?Q?twg+p8tD0mI2UYXC4Ym7gHEafMf1WiCzg9S6RIHe5pZCY1GdGLjjRTBqoERJ?=
 =?us-ascii?Q?mbSSQCyIMifHKIlVlWVPXeB51QnTprj9j26kGakjPCULpHyN7w3hZE5K9/3B?=
 =?us-ascii?Q?3mYhJKGaJJGr6qoIsxz50aLKstJHhKHFqH5W2Q=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: 3f685fc2-588d-44d9-31a8-08dc393d467f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2024 15:44:11.7865
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR02MB10142

From: Christoph Hellwig <hch@lst.de> Sent: Thursday, February 29, 2024 5:34=
 AM
>=20
> On Thu, Feb 29, 2024 at 07:36:05AM +0000, Michael Kelley wrote:
> > If there *is* a requirement for page alignment of page-size-or-greater
> > requests, even when alloc_align_mask and min_align_mask are zero,
> > we need to think about how to do that correctly, as that requirement
> > is no longer met after Patch 1 of this series.
>=20
> It has been historical behavior that all dma allocations are page
> aligned (including in fact smaller than page sized ones that get
> rounded up to a page size).  The documentation actually (incorretly)
> states an even stronger guarantee:
>=20
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size.  This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."

Any thoughts on how that historical behavior should apply if
the DMA min_align_mask is non-zero, or the alloc_align_mask
parameter to swiotbl_tbl_map_single() is non-zero? As currently
used, alloc_align_mask is page aligned if the IOMMU granule is
>=3D PAGE_SIZE. But a non-zero min_align_mask could mandate
returning a buffer that is not page aligned. Perhaps do the
historical behavior only if alloc_align_mask and min_align_mask
are both zero?

Michael