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
