[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250102164711.GC5556@nvidia.com>
Date: Thu, 2 Jan 2025 12:47:11 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: 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
Subject: Re: [PATCH] iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of
hardcoding
On Wed, Dec 18, 2024 at 09:14:21PM -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.
>
> Adding this extra IDR1.CMDQS cap (in the guest kernel) allows VMM to set
> SMMU's IDR1.CMDQS=17 for the case mentioned above, so a guest-level queue
> will be capped to maximum 2MB, ensuring a contiguous queue memory.
>
> Fixes: a3799717b881 ("iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift")
> Reported-by: Ian Kalinowski <ikalinowski@...dia.com>
> Cc: <stable@...r.kernel.org>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@...dia.com>
Jason
Powered by blists - more mailing lists