On Tue, Jun 09, 2026 at 12:25:40PM +0100, Shameer Kolothum wrote:
> Introduce tegra241_cmdqv_vintf_lvcmdq_ptr() to route VCMDQ Page 0
> register accesses through the mmap'd host VINTF Page 0 backing once a
> hardware queue has been allocated for the VCMDQ.
>
> The two QEMU-trapped Page 0 apertures (direct at 0x10000, VINTF at
> 0x30000) are hardware aliases of the same underlying registers. A
> subsequent patch installs the VINTF aperture as a RAM-device into
> guest MMIO; in this patch both remain QEMU-trapped.
>
> The direct VCMDQ aperture stays QEMU-trapped (rather than aliased
> to the VINTF mmap) so that writes to an unallocated VCMDQ remain
> well-defined. The CMDQV architecture allows software to program a
> VCMDQ through the direct aperture without first allocating it to a
> VINTF; aliasing to the VINTF mmap would route those writes into
> unallocated logical slots where the hardware silently drops them.
>
> A VCMDQ Page 0 access is served from one of two sources:
>
> - Cache-backed: no hw_queue is allocated for the VCMDQ
> (HW_QUEUE_ALLOC has not yet succeeded). Both apertures use
> QEMU's register cache.
>
> - HW-backed: HW_QUEUE_ALLOC has succeeded. Both apertures access
> the registers directly through the mmap'd host VINTF Page 0.
>
> tegra241_cmdqv_sync_vcmdq() copies any cached writes (CONS_INDX,
> PROD_INDX, CONFIG, GERRORN) into the mmap'd page on the cache-to-HW
> transition so the guest's earlier register state survives. Freeing a
> VCMDQ clears the cached Page0 registers.
>
> Tested-by: Nicolin Chen <[email protected]>
> Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Nicolin Chen <[email protected]>
