> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: 20 May 2026 13:08
> To: Shameer Kolothum Thodi <[email protected]>; qemu-
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]; [email protected]; Nicolin
> Chen <[email protected]>; Nathan Chen <[email protected]>; Matt
> Ochs <[email protected]>; Jiandi An <[email protected]>; Jason Gunthorpe
> <[email protected]>; [email protected]; Krishnakant Jaju
> <[email protected]>; [email protected]
> Subject: Re: [PATCH v5 16/32] hw/arm/tegra241-cmdqv: Emulate VCMDQ
> register writes
[...]
> >>> + case A_VCMDQ0_BASE_H:
> >>> + if (tegra241_vcmdq_enabled(cmdqv, index)) {
> >> where is it documented in the spec? I don't see this restriction in
> >> the reg doc. Then "Enabling the virtual CMDQ" paragraph describes a
> >> std setup but does not say - afaics- that it should be ignored -
> >> worth commenting
> > Right. I don’t think it is explicitly there in the spec.
> >
> > However, Nicolin mentioned about such a restriction during v4 discussion:
> > https://lore.kernel.org/qemu-devel/[email protected]/
> >
> > AFAICS, it looks like an implied assumption based on the "Enabling the
> > virtual CMDQ" sequence or I missed it.
> >
> > I will double check.
> OK
I did a hack to the host kernel driver to see how the HW behaves if we
reprogram the BASE after the VCMDQ is enabled:
+ /* HACK: re-write BASE after VCMDQ_EN */
+ {
+ u64 orig = vcmdq->cmdq.q.q_base;
+
+ printk("%s: Shameer: re writing base after vcmdq enable..\n",
__func__);
+ writeq_relaxed(0, REG_VCMDQ_PAGE1(vcmdq, BASE));
+ pr_info("Base : wrote 0, readback=0x%llx GERROR=0x%x
STATUS=0x%x\n",
+ readq_relaxed(REG_VCMDQ_PAGE1(vcmdq, BASE)),
+ readl_relaxed(REG_VCMDQ_PAGE0(vcmdq, GERROR)),
+ readl_relaxed(REG_VCMDQ_PAGE0(vcmdq, STATUS)));
+
+ /* Put it back before something tries to use it */
+ writeq_relaxed(orig, REG_VCMDQ_PAGE1(vcmdq, BASE));
+ pr_info("base: restored, readback=0x%llx\n",
+ readq_relaxed(REG_VCMDQ_PAGE1(vcmdq, BASE)));
+ }
+
From the boot logs, the HW accepted the BASE rewrite:
[ 1.504735] tegra241_vcmdq_hw_init: Shameer: re writing base after vcmdq
enable..
[ 1.504737] Base : wrote 0, readback=0x0 GERROR=0x0 STATUS=0x1
[ 1.504739] base: restored, readback=0xfa000013
So writes to BASE after enable are not ignored at the register level.
But I don't think command processing will work if we change
BASE on a live queue.
From the QEMU side, the current setup_vcmdq() frees the existing
hw_queue before calling IOMMU_HW_QUEUE_ALLOC again, otherwise the
kernel returns -EEXIST. So if we allow BASE rewrite while the VCMDQ
is enabled, it will trigger a destroy+alloc cycle in the host driver.
I tried removing the tegra241_vcmdq_enabled(cmdqv, index) restriction
and rewriting BASE triggering a setup_vcmdq() again, and the guest
ended up with:
arm-smmu-v3 arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000023 [hwprod
0x00000023, hwcons 0x00000000]
arm-smmu-v3 arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000025 [hwprod
0x00000025, hwcons 0x00000000]
I think it is probably better to keep this behaviour (let the rewrite
go through and surface as a CMD_SYNC timeout) than to silently ignore
the BASE reprogram.
@Nicolin, thoughts?
Thanks,
Shameer
