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

[Nicolin Chen via <qemu-arm@nongnu.org>]

On Thu, Feb 12, 2026 at 06:05:58PM +0100, Eric Auger wrote:
> >>> 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.

Yes. And I think it makes more sense by moving cmdqv_init() into
accel_init(), completely transparent to the common smmuv3 module
maybe?

> >>> 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.
> 
> then I think we should endeavour doing that. Regarding the ops, if you
> feel that reset/init can be managed through a simple add-on code I am
> fine with it. Maybe Cédric or Peter will have another opinion though ;-)

I like that on/off/auto depending on the IOMMU_GET_HW_INFO return.

Thanks
Nicolin