[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <173462305169.3912600.1369814969067145717.b4-ty@kernel.org>
Date: Thu, 19 Dec 2024 19:47:11 +0000
From: Will Deacon <will@...nel.org>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: catalin.marinas@....com,
kernel-team@...roid.com,
Will Deacon <will@...nel.org>,
robin.murphy@....com,
joro@...tes.org,
thierry.reding@...il.com,
vdumpa@...dia.com,
jonathanh@...dia.com,
linux-kernel@...r.kernel.org,
iommu@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org,
linux-tegra@...r.kernel.org,
patches@...ts.linux.dev,
stable@...r.kernel.org,
ikalinowski@...dia.com,
Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH] iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding
On Wed, 18 Dec 2024 21:14:21 -0800, Nicolin Chen wrote:
> The hardware limitation "max=19" actually comes from SMMU Command Queue.
> So, it'd be more natural for tegra241-cmdqv driver to read it out rather
> than hardcoding it itself.
>
> This is not an issue yet for a kernel on a baremetal system, but a guest
> kernel setting the queue base/size in form of IPA/gPA might result in a
> noncontiguous queue in the physical address space, if underlying physical
> pages backing up the guest RAM aren't contiguous entirely: e.g. 2MB-page
> backed guest RAM cannot guarantee a contiguous queue if it is 8MB (capped
> to VCMDQ_LOG2SIZE_MAX=19). This might lead to command errors when HW does
> linear-read from a noncontiguous queue memory.
>
> [...]
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding
https://git.kernel.org/will/c/e94dc6ddda8d
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
Powered by blists - more mailing lists