Received-SPF: pass (google.com: domain of linux-kernel+bounces-100134-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 12 Mar 2024 11:44:06 +0100
From: Petr =?UTF-8?B?VGVzYcWZw61r?= <petr@tesarici.cz>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Michael Kelley <mhklinux@outlook.com>, Will Deacon <will@kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "kernel-team@android.com" <kernel-team@android.com>,
 "iommu@lists.linux.dev" <iommu@lists.linux.dev>, Christoph Hellwig
 <hch@lst.de>, Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy
 <robin.murphy@arm.com>, Petr Tesarik <petr.tesarik1@huawei-partners.com>,
 Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATCH v6 4/6] swiotlb: Fix alignment checks when both
 allocation and DMA masks are present
Message-ID: <20240312114406.792cc8f9@meshulam.tesarici.cz>
In-Reply-To: <Ze+nT+4Radnd/iyw@Asurada-Nvidia>
References: <20240308152829.25754-1-will@kernel.org>
	<20240308152829.25754-5-will@kernel.org>
	<20240311210507.217daf8b@meshulam.tesarici.cz>
	<SN6PR02MB41576E58DDF5A56FC6FC1EB6D4242@SN6PR02MB4157.namprd02.prod.outlook.com>
	<Ze+nT+4Radnd/iyw@Asurada-Nvidia>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 11 Mar 2024 17:52:31 -0700
Nicolin Chen <nicolinc@nvidia.com> wrote:

> On Mon, Mar 11, 2024 at 09:36:10PM +0000, Michael Kelley wrote:
> > From: Petr Tesa=C5=99=C3=ADk <petr@tesarici.cz> =20
> > > I find it somewhat surprising that NVMe does not
> > > in fact require that the NVME_CTRL_PAGE_SHIFT low bits are preserved,
> > > as suggested by Nicolin's successful testing.
> > >
> > > Why is that? =20
> >=20
> > I saw only one stack trace from Nicolin, and it was file system buffer
> > flushing code that initiated the I/O.  In such cases, it's very likely =
that the
> > original address is at least 4K aligned.  Hence the offset is zero and
> > the low bits will typically be correct. =20
>=20
> Though I didn't dig any deeper here, I do see some unaligned
> original addresses passed in at the top level:
>        fsck.ext4-286     [004] .....     2.594190: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be750600
>        fsck.ext4-286     [004] .....     2.613032: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be780400
>        fsck.ext4-286     [004] .....     2.614096: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be7c0600
>        fsck.ext4-286     [004] .....     2.614103: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be7e0400
>            mount-288     [005] .....     2.615157: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be800400
>       multipathd-405     [003] .....     3.062878: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: bda40218
>       multipathd-502     [002] .....     3.231721: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: bd3107b8
>            mount-525     [002] .....     3.250281: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: bd340200
>       multipathd-529     [004] .....     3.259053: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be620478
>       multipathd-571     [005] .....     3.292893: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be900328
>       multipathd-580     [005] .....     3.318832: iommu_dma_map_page: ca=
lling swiotlb_tbl_map_single with phys: be9207c8

Thank you. Indeed, bit 11 of the physical address was zero in all the
above calls, and that's why it works.

Petr T