Re: [PATCH v2 10/11] iommu/tegra241-cmdqv: Warn on a VCMDQ base above the 48-bit hardware limit

[Nicolin Chen]

On Sun, Jul 26, 2026 at 01:57:38PM +0100, Will Deacon wrote:
> On Tue, Jul 14, 2026 at 01:55:07PM -0700, Nicolin Chen wrote:
> > tegra241_vcmdq_alloc_smmu_cmdq() allocates the VCMDQ buffer via the common
> > arm_smmu_init_one_queue(), which uses smmu->dev and its coherent DMA mask
> > of DMA_BIT_MASK(smmu->oas). The architectural Q_BASE_ADDR_MASK is 52 bits,
> > but the Tegra241 VCMDQ_BASE holds only 48 (VCMDQ_ADDR), so the masked write
> > "q_base = base_dma & VCMDQ_ADDR" silently drops bits 48 and up.
> > 
> > A real Tegra241 never reports a 52-bit OAS alongside the 48-bit VCMDQ, so
> > this cannot happen on correct hardware, but a buggy or hostile hypervisor
> > could still advertise such an OAS to a guest. The user-VCMDQ path already
> > rejects a base_addr_pa with bits set outside VCMDQ_ADDR; add the same guard
> > to the kernel-allocated path, failing the queue init rather than silently
> > truncating the base. Use dev_warn_once() rather than WARN_ON(): the OAS is
> > hypervisor-controlled, and a WARN_ON() would let it panic a guest that is
> > booted with panic_on_warn.
> 
> So here you talk about "a buggy or hostile hypervisor". Is that really
> part of the threat model?

Yea, existing real chips have a matched 48-bit address field with
OAS=5 (48-bit). The only possible scenario is a buggy VMM exposing
a mismatched OAS value to the VM. Perhaps we could drop "hostile".

> Presumably such a thing could cause havoc in
> a million other ways?

Maybe, it's a defensive play here.

A buggy VMM can absorb the mismatch for the SMMU CMDQ, by reading
the high-order bits of the Q_BASE_ADDR field, since the guest SMMU
driver wouldn't truncate those bits. But, in VCMDQ case, it would
get truncated silently, which can lead to VCMDQ errors (IRQs).

> > @@ -674,6 +674,19 @@ static int tegra241_vcmdq_alloc_smmu_cmdq(struct tegra241_vcmdq *vcmdq)
> >  	if (ret)
> >  		return ret;
> >  
> > +	/*
> > +	 * The q->base_dma is bounded by DMA_BIT_MASK of SMMU's IDR5.OAS. On a
> > +	 * real hardware, VCMDQ_ADDR mask and IDR5.OAS are always aligned. But
> > +	 * a buggy VM might set a mismatched IDR5.OAS for SMMU. Spit a warning
> > +	 * instead of a silent truncation.
> > +	 */
> 
> But then here you talk about "a buggy VM might set a mismatched IDR5.OAS".
> How can a VM write to that?

Oh, this is a typo; it should be "VMM".

Thanks
Nicolin