Hi Eric,
> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: 21 May 2026 14:41
> To: Shameer Kolothum Thodi <[email protected]>; qemu-
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]; Nicolin
> Chen <[email protected]>; Nathan Chen <[email protected]>; Matt
> Ochs <[email protected]>; Jiandi An <[email protected]>; Jason Gunthorpe
> <[email protected]>; [email protected]; Krishnakant Jaju
> <[email protected]>; [email protected]
> Subject: Re: [PATCH v5 20/32] hw/arm/tegra241-cmdqv: Use mmap'd VINTF
> page0 as VCMDQ backing
>
> External email: Use caution opening links or attachments
>
>
> Hi Shameer,
>
> On 5/19/26 12:36 PM, Shameer Kolothum wrote:
> > Introduce tegra241_cmdqv_vintf_ptr() to route VCMDQ Page0 register
> > accesses through the mmap'd VINTF page0 backing once a hardware
> > queue has been allocated.
> >
> > There are two QEMU trapped MMIO apertures for VCMDQ Page0 registers:
> >
> > - Direct VCMDQ Page0 aperture (offset 0x10000)
> > - VINTF Page0 (offset 0x30000)
> >
> > These are hardware aliases: they address the same underlying
> > registers. A subsequent patch maps the VINTF aperture as a
> > guest-direct RAM region; in this patch both remain QEMU-trapped.
> >
> > VCMDQ Page0 accesses operate in one of two mutually exclusive modes,
> > depending on whether a hardware queue (IOMMU_HW_QUEUE_ALLOC)
> has
> > been allocated for the VCMDQ:
> >
> > Pre-alloc: vintf_ptr is NULL. Both apertures use QEMU's register
> do you mean vintf_page0 instead of vintf_ptr.
>
> vintf_page0 is set on mmap, right? and not on hwqueue_alloc
Yeah. I actually meant the ptr returned by tegra241_cmdqv_vintf_ptr()
> Besides pre/post-alloc sounds a bit confusing to me since it can mean
> queue_alloc or mmap.
> If I understand correctly vintf_page0 can be set while hwqueue_alloc has
> not been done yet and conversely, hence the double check below:
The "alloc" is in reference to a vcmdq is "allocated" to a vintf. I think spec
has that usage.
Anyway, I will make it clear.
>
> + if (!cmdqv->vcmdq[index] || !cmdqv->vintf_page0) {
>
>
> > cache. Hardware is not yet engaged.
> >
> > Post-alloc: vintf_ptr is valid. Both QEMU trapped apertures access
> > registers directly via the mmap'd vintf_page0 pointer,
> > bypassing the cache. Hardware is the single source of
> > truth.
> >
> > The pre-to-post-alloc transition is triggered by the IOMMUFD hardware
> so here you mean alloc is hw queue alloc
> > queue allocation. The tegra241_cmdqv_sync_vcmdq() copies any pre-alloc
> > cached writes (CONS_INDX, PROD_INDX, CONFIG, GERRORN) into the
> mmap'd
> > page so the guest's view survives the transition.
> >
> > CMDQV acceleration only becomes active once the guest enables VINTF
> > and the corresponding HW QUEUE is allocated through IOMMUFD. Until
> > then, all VCMDQ accesses are served from the emulated register cache
> > with no real hardware command processing. This matches the CMDQV
> > hardware specification: if the logical CMDQ index does not map to any
> > allocated Virtual CMDQ, "the access is dropped with no Fault/Interrupt".
>
> I still does not realy understand what would be the problem of directly
> mapping the direct cmdqv page0 too - I understand that theoretically the
> direct view is larger than the VINTF one though -. I still think a
> proper explanation is missed in this patch of 22/32
>
> Assuming the guest tries to set up some unmapped vcmdqs in the direct
> cmdqv page and this eventually ends up writing into the VINTF view, what
> would happen and in which terms does it violate the spec?
Ok. Let me try to explain my understanding.
This is my rationale after reading Nicolin's explanation here on the
RFC where we had both direct aperture and vintf page 0 mapped to Guest .
https://lore.kernel.org/qemu-devel/aXkTzRM695oTWFaD@Asurada-Nvidia/
Consider the example:
QEMU advertises 2 VCMDQs (CMDQV_NUM_CMDQ_LOG2=1).
Guest allocates vcmdq0 only, leaves vcmdq1 unallocated, then on the
direct aperture for vcmdq1:
write 0x10 -> A_VCMDQ1_PROD_INDX
read A_VCMDQ1_PROD_INDX
If we aliased the direct aperture to the VINTF mmap, the write
would physically hit VINTF Page 0 in HW at an unmapped logical
slot. And the spec says(p.172):
" If no Virtual CMDQ is mapped to the Guest, or if the logical CMDQ index in
the Virtual Interface being accessed by the software does not map to any Virtual
CMDQ, the access is dropped with no Fault/Interrupt."
So even though guest is using the direct aperture, in turn it ends up
accessing the corresponding vinf page0 and won't see whatever it wrote.
I think this contradicts spec p.176 where it says:
"While the software can program the Virtual CMDQ(s) directly using the
direct VCMDQ aperture (and not through the Virtual Interface), it is
required that the VCMDQ be allocated to a Virtual Interface before it
is used to send commands to the SMMU."
So the spec allows register programming through the direct aperture
without requiring the VCMDQ to be allocated first.
@Nicolin: did I understand your earlier reasoning correctly here?
Thanks,
Shameer
