]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding
authorNicolin Chen <nicolinc@nvidia.com>
Thu, 19 Dec 2024 05:14:21 +0000 (21:14 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 17 Feb 2025 09:05:31 +0000 (10:05 +0100)
commitdb22b33c7ec9093c2845600bcc3c08f4d612a9da
treedd1a8f6840162fffc7fce40dc7678dc0ead8e67d
parent5f4a0561783d1047c40fe3dc1b7b4921088c3de0
iommu/tegra241-cmdqv: Read SMMU IDR1.CMDQS instead of hardcoding

commit e94dc6ddda8dd3770879a132d577accd2cce25f9 upstream.

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@nvidia.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/20241219051421.1850267-1-nicolinc@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c