Re: [PATCH v4 19/31] hw/arm/tegra241-cmdqv: Allocate HW VCMDQs on base register programming

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, May 06, 2026 at 01:18:58AM -0700, Shameer Kolothum Thodi wrote:
> > > Not sure I get that completely.
> > >
> > > Spec(p. 176) has:
> > >
> > > "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."
> > >
> > > The spec only restricts sending commands before allocation, not
> > > programming BASE. In our model, the BASE write itself triggers
> > > alloc_hw_queue so there's nothing to fence there.
> > 
> > Our model has an assumption that guest would map a VCMDQ to the
> > VINTF0 first before doing any meaningful programming.
> 
> Yes. And I think by "map" here, you mean the writing to the _ALLOC_MAP
> register. If so, yes, we don't check that.

Yea, map == ALLOC_MAP.

> > My concern here is about the access to the direct/global VCMDQ MMIO
> > space (0x10000 and 0x20000).
> > 
> > So, if this concern is a real case, should we:
> >  1. If the guest maps the VCMDQ to VINTF0 before it writes BASE,
> >     call setup() to allocate hw_queue as our model expects.
> >  2. If the guest writes BASE before it maps VCMDQ to VINTF0, we
> >     need to fence against it.
> > ?
> > 
> > One more thing to check for case (2): after the guest programmed
> > BASE and then maps it to VINTF0, and it never writes BASE again,
> > should we call setup() at map?
> 
> That is a non-spec compliant behaviour I guess:.
> 
> In p.176: "Allocate a VCMDQ to the Virtual Interface", this is
> the order:
> 
> -Program the CMDQV_CMDQ_ALLOC_MAP_X to map CMDQ X to the
>  Logical CMDQ (L) on Virtual Interface (V). Logical CMDQ allocated in the
>  Guest must be in order starting from 0.
> -CMDQ is allocated to be used by the software. Guest can now program
>   the VCMDQ to use it   as described in the "Enabling the Virtual CMDQ"
>   section.
> 
> "Enabling the Virtual CMDQ" (p.175) is where BASE is programmed. So the
> spec explicitly places ALLOC_MAP before BASE.
> 
> Should we support a non-spec compliant Guest is another question.
> IMHO, supporting non-compliant behaviour adds complexity with
> no real benefit.

I read that as a spec recommendation (IOW, a SW guidance) not an
ordering enforcement (IOW, not a HW contract).

The real restriction for BASE registers is, per spec:
    Should be programmed before CMDQEN == 1
and HW behaviour for breaking this restriction is:
    Ignore Writes to the register when the CMDQEN == 1

My reading is that, so long as SW follows this minimal rule, it
can do whatever it wants.

(Btw, seems we haven't applies this restriction into our code?)

The point is about how we are going to simulate the HW. If real
HW allows this (maybe worth hacking the driver to confirm this),
there seems to be no reason for us not to support that?

Nicolin