Re: [PATCH v2 05/24] hw/arm/smmuv3-accel: Introduce CMDQV ops interface

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Feb 10, 2026 at 12:46:01AM -0800, Shameer Kolothum Thodi wrote:
> > On Fri, Feb 06, 2026 at 02:48:04PM +0000, Shameer Kolothum wrote:
> > > CMDQ-Virtualization (CMDQV) is a hardware extension to SMMUv3 that
> > enables
> > > virtualization of multiple command queues (VCMDQs).
> > 
> > Let's mention "NVIDIA", noting it's a non-standard extension.
> 
> The idea of this ops based callback is to make it more generic and not
> NVIDIA specific to start with. This leaves room in case ARM introduces
> a standardised version of something similar in the future, or if another
> vendor provides a similar extension.

That might be a different naming which we have no idea about yet :-/

> > > +    void (*reset)(SMMUv3State *s);
> > > +} SMMUv3AccelCmdqvOps;
> > 
> > Overall, an ops structure feels unnecessary to me. Maybe init and
> > reset are somewhat plausible. But nobody else would reuse this ops
> > structure that is exclusive to Tegra241CMDQV?
> 
> That's true for now, as there is only one implementation today. If this
> abstraction feels over engineered at this stage, we can simplify or defer
> it (and fall back to calling the tegra241-specific functions directly, as in
> the RFC) and revisit once there is a clearer need.
> 
> I'm open to suggestions, and let's wait to hear from others as well.

Well, I'll vote for adding that when someday there is second CMDQV.
There are only a couple of CMDQ-V functions required to export for
SMMUv3 code to call at this moment, which isn't so bad.

Having and naming a structure exclusively for NVIDIA CMDQ-V doesn't
make a lot of sense to me. And if we really want an abstraction ops
maybe "secondary_cmdq" in the kernel driver could be a good choice?

Nicolin