Re: [PATCH v4 20/31] hw/arm/tegra241-cmdqv: Use mmap'd VINTF page0 as VCMDQ backing

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, May 06, 2026 at 01:13:53PM -0700, Shameer Kolothum Thodi wrote:
> > -----Original Message-----
> > On Wed, May 06, 2026 at 06:16:00AM -0700, Shameer Kolothum Thodi wrote:
> > > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > > Could this be a case:
> > > >  - Write the PROD_INDX/ CONS_INDX with a consistent value (0xf)
> > > >  - Program the VIRT_CMDQ_BASE
> > > >  - Read the PROD_INDX/CONS_INDX, expecting 0xf
> > > >  - Write the PROD_INDX/ CONS_INDX with 0x0
> > > >  - Program the VIRT_CMDQ_CONFIG to enable the CMDQ
> > >
> > > Yes, if Guest is not spec compliant then this can be any order.
> > >
> > > However,
> > >
> > > >  - Program the VIRT_CMDQ_BASE -- suppose we call setup_vcmdq()
> > 
> > > then kernel will reset PROD/CONS, right?
> > 
> > But I don't have an impression that QEMU only supports Guest to run
> > Linux...
> 
> Oh no, I was referring to host kernel behaviour on IOMMU_HW_QUEUE_ALLOC
> IOCTL. It seems to reset PROD/CONS to zero in that path and I thought
> it was following spec in that case.

Ah, it was fixing a kernel bug, where the VCMDQ registers never got
cleared even after a host reset (IIRC). And the solution is to clear
them before handing over to the guest.

Once QEMU allocates the hw_queue that ALLOC_MAPs it to the VINTF, it
should probably sync what the register caches were programmed by the
guest.

> This scenario writes PROD_INDX before BASE, which is explicitly
> non-spec-compliant — TRM p.175 "Enabling the Virtual CMDQ"
> mandates BASE as the first step, with PROD_INDX/CONS_INDX
> initialization following. For a spec-compliant guest, PROD_INDX
> is only written after BASE, at which point vintf_ptr() is
> valid and writes go directly to hardware with no discard
> involved.

I think the goal of VMM is that a guest VM cannot distinguish
between real HW and emulated HW. If we just follow the minimal
"spec compliant" flow, it fails to do so. So, "spec compliant"
itself doesn't make a lot of sense to me.

With that being said, if QEMU is okay with the minimal support
for "spec compliant" flow only, I certainly won't be against
submitting it (for the initial version maybe?).

> 2) But then after some prompt it says:
> 
> Looking at SMMUv3's register write handlers, QEMU doesn't enforce
> any programming order there either —   registers are written to cache
> unconditionally. CMDQV should follow the same convention. Will fix by
> replaying cached PROD_INDX/CONS_INDX values to hardware after
> alloc_hw_queue succeeds, making the pre-to-post-alloc transition
> transparent to the guest.

Yes. We are indeed missing a few details in the implementation.

> 3) But it changes position again if you ask in a different way:
> 
> SMMUv3 has no equivalent transition point where hardware takes over.
> In CMDQV, the BASE write is a fundamental transition — before it,
> there is no hardware queue; after it, hardware owns the registers.
> The BASE write is a fundamental transition point — before it, no
> hardware queue exists; after it, hardware owns the Page0 registers.
> Pre-alloc writes to PROD_INDX/CONS_INDX are undefined behavior by
> spec, and "discard" at transition is the   correct consequence.
> There's nothing to "preserve across" in the SMMUv3 case.

Ask it to do a deeper research before answer any question, or
to pinpoint where spec declares that "undefined behaviour" for
example.

> I think the spec is vague and doesn’t demand a strict order.
> So may be better to sync the registers after the alloc.

Agreed.

Nicolin