Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>, Nicolin Chen <nicolinc@nvidia.com>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] iommu/tegra241-cmdqv: Reject a VCMDQ base above the 48-bit hardware limit
Date: Thu, 6 Aug 2026 11:09:51 -0300	[thread overview]
Message-ID: <20260806140951.GA71449@nvidia.com> (raw)
In-Reply-To: <7e66d67a-f63f-465c-acb0-c1238f534c07@arm.com>

On Thu, Aug 06, 2026 at 02:17:31PM +0100, Robin Murphy wrote:

> But if we really do want to bother sanity-checking emulations, then why
> allow them to still get away with being broken in the case that we do happen
> to allocate queue memory at a sufficiently low PA anyway? Why not actually
> validate smmu->oas itself (plus anything else relevant) in
> __tegra241_cmdqv_probe()?

Yeah, if the VMM has setup the SMMU so it cannot access all of DRAM
then it is going to be really broken across the entire driver. This
just doesn't work at all. No reason to add any special cases to look
for it only in vcmdq.

IMHO the error here is masking the base:

 	q->q_base = q->base_dma & VCMDQ_ADDR;

That's sort of a HW bug to design like that, the base should be a full
64 bit value and programming any base that falls outside the S2 should
always generate the same HW fault forwarded toward the VM. The HW
should have captured the unsupported upper bits and compressed them
into a 'fail all DMA' flag.

Jason


  reply	other threads:[~2026-08-06 14:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 22:03 [PATCH v3] iommu/tegra241-cmdqv: Reject a VCMDQ base above the 48-bit hardware limit Nicolin Chen
2026-08-06 12:47 ` Will Deacon
2026-08-06 13:17   ` Robin Murphy
2026-08-06 14:09     ` Jason Gunthorpe [this message]
2026-08-06 17:22       ` Nicolin Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260806140951.GA71449@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox