Re: [PATCH v3 15/32] hw/arm/tegra241-cmdqv: Emulate global and VINTF VCMDQ register reads

[Nicolin Chen <nicolinc@nvidia.com>]

On Mon, Mar 09, 2026 at 11:53:59AM -0700, Shameer Kolothum Thodi wrote:
> 
> 
> > -----Original Message-----
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: 09 March 2026 18:41
> > To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> > Cc: eric.auger@redhat.com; qemu-arm@nongnu.org; qemu-
> > devel@nongnu.org; peter.maydell@linaro.org; clg@redhat.com;
> > alex@shazbot.org; Nathan Chen <nathanc@nvidia.com>; Matt Ochs
> > <mochs@nvidia.com>; Jiandi An <jan@nvidia.com>; Jason Gunthorpe
> > <jgg@nvidia.com>; jonathan.cameron@huawei.com;
> > zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; Krishnakant Jaju
> > <kjaju@nvidia.com>; phrdina@redhat.com
> > Subject: Re: [PATCH v3 15/32] hw/arm/tegra241-cmdqv: Emulate global and
> > VINTF VCMDQ register reads
> > 
> > On Mon, Mar 09, 2026 at 11:04:31AM -0700, Shameer Kolothum Thodi
> > wrote:
> > > > > The VI_VCMDQ register ranges are an alias of the global VCMDQ registers
> > > > > and are only meaningful when a VCMDQ is mapped to a VINTF via ioctl
> > > > > IOMMU_HW_QUEUE_ALLOC.
> > 
> > > > If the guest detects he can use a single VMCDQs (I guess he can
> > > > introspect this by reading the SMMU_CMDQ_PARAM_0) how does he
> > know if
> > > > he
> > > > shall access your so-called "Global VCMD regs" at 0x10000 or VI0 regs
> > > > (0x30000-40000). How does the guest know that he is supposed to use
> > VI0?
> > >
> > > The CMDQ registers can be accessed via both the so called "Global VCMDQ
> > registers
> > > Page0" and by "VINTF logical VCMDQ registers Page 0". And they are aliased.
> > >
> > > The difference being(from Nicolin's explanation here[0]):
> > >
> > > "
> > > The global page0 is programmable at any time so long as CMDQV_EN
> > > is enabled.
> > >
> > > The logical page0 is programmable only when SW allocates and maps
> > > global vcmdq(s) to a VINTF. "logical" also means "local" to that
> > > VINTF.
> > > ".
> > >
> > > IIUC, for now a Linux Guest kernel will only use "VINTF logical VCMDQ
> > > registers Page 0".
> > 
> > Yes.
> > 
> > > The question is whether QEMU should also support accesses via the
> > > "Global VCMDQ registers Page 0" if some other guest implementation
> > > chooses to use that path.
> > 
> > Yes.
> > 
> > The point is that we can't reject guest's access to the global MMIO
> > space. So, QEMU has to support both. But guest OS is allowed to do a
> > partial map/alloc, so global MMIO page isn't identical to the VINTF
> > logical page in this case.
> 
> Are there any benefits for a guest implementation making use of the
> "Global VCMDQ registers Page 0"?
> 
> If not, the VINTF-based access path seems preferable from a hardware
> isolation point of view.

Yea. That's why Linux was implemented in that way.

> In that case, would it make sense to restrict
> usage to the VINTF logical page and recommend that guests use that
> interface?

I don't think QEMU can recommend that... Linux kernel made a good
example but it doesn't make a lot of sense to recommend or force
all guest SWs to follow.

From hardware emulation perspective, QEMU should just re-act like
a real HW. It's okay to make it unfunctional v.s. unpredictable.
But it shouldn't reject any MMIO access, since the HW wouldn't.

Nicolin