> -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 12 February 2026 15:35 > To: Shameer Kolothum Thodi <[email protected]>; Nicolin Chen > <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; Nathan Chen > <[email protected]>; Matt Ochs <[email protected]>; Jiandi An > <[email protected]>; Jason Gunthorpe <[email protected]>; > [email protected]; [email protected]; > [email protected]; Krishnakant Jaju <[email protected]> > Subject: Re: [PATCH v2 05/24] hw/arm/smmuv3-accel: Introduce CMDQV ops > interface > > External email: Use caution opening links or attachments > > > On 2/12/26 4:05 PM, Shameer Kolothum Thodi wrote: > > > >> -----Original Message----- > >> From: Eric Auger <[email protected]> > >> Sent: 12 February 2026 14:57 > >> To: Shameer Kolothum Thodi <[email protected]>; Nicolin Chen > >> <[email protected]> > >> Cc: [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; Nathan > Chen > >> <[email protected]>; Matt Ochs <[email protected]>; Jiandi An > >> <[email protected]>; Jason Gunthorpe <[email protected]>; > >> [email protected]; [email protected]; > >> [email protected]; Krishnakant Jaju <[email protected]> > >> Subject: Re: [PATCH v2 05/24] hw/arm/smmuv3-accel: Introduce CMDQV > ops > >> interface > >>>> I had > >>>> the impression you reverted to a fallback impl. If there is > >>>> specialization, I still think ops are relevant. Eric > >>> There is no fallback implementation. So just to confirm, you are > >>> suggesting > >>> to remove the ops completely or just keep the ops for reset/init only? > >> Depends on the code to come next. If your reset and init really differs > >> between normal accel SMMU and vcmdq enhanced accel SMMU, to me it is > >> still relevant to have separate implementations in different callbacks. > > It is not an either/or case. > > > > The vCMDQ path does not replace the normal accelerated SMMU init/reset. > > Instead, it requires additional init/reset steps on top of the regular > > accel flow. > > > > if (accel) > > accel_init(); > > > > if (accel && cmdqv) > > cmdqv_init(); > > > > So the vCMDQ logic is an extension of the accelerated mode, not a fallback > > or alternative implementation. > > > > I think the later patches in the series make this clearer. > > Please let me know if you still feel the ops necessary. > > do we have any way to introspect from the kernel what cmdq type we have, > so that we could have a cmdqv option with ON/OFF/AUTO value instead of > duplication cmdq option for each vendor?
Looking at it again, I think we can, by calling IOMMU_GET_HW_INFO with all supported CMDQ types and check which one succeeds. Thanks, Shameer
