Hi Eric,
> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: 20 May 2026 13:54
> 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 17/32] hw/arm/tegra241-cmdqv: mmap VINTF Page0
> for CMDQV
>
> External email: Use caution opening links or attachments
>
>
> Hi Shameer,
>
> On 5/19/26 12:36 PM, Shameer Kolothum wrote:
> > From: Nicolin Chen <[email protected]>
> >
> > The CMDQ-V CMDQ pages provide a VM wide view of all VCMDQs, while the
> s/CMDQ pages/VCMDQ pages - yeah that's all very confusing ;-) -
> > VINTF pages expose a logical view local to a given VINTF. Although real
> > hardware may support multiple VINTFs, the kernel currently exposes a
> > single VINTF per VM.
> >
> > The kernel provides an mmap offset for the VINTF Page0 region during
> for the host VINTF page0 allocated for the VM
>
> Actually is the whole host passthrough principle is not really explained
> anywhere. At least that's my feeling. It would be nice to have a summary
> for it, in the coverletter and in individual patch. Or maybe we can link
> to another doc. Reading the kernel uapi does not really provide the full
> picture, at least that's my own feeling.
Fair point. A summary of operation is useful. I am thinking of adding
it at the top of hw/arm/tegra241-cmdqv.c:
/*
* Tegra241 CMDQV - overview
* ---------------------------------------
*...
*/
I will populate the details and share it for review before v6.
>
> when a VM allocates a VIOMMU for the CMDQV, the kernel allocates this
> and this resource that is then given for exclusive usage of the VM ...
> How does it guarantee security between VMs, etc...
Isolation is enforced by the kernel and the CMDQV hardware.
I think the key points here are:
- Each VM has its own iommufd FD. All iommufd objects (VINTF, hw
queues, mmap regions) belong to that FD; one VM cannot reach
another VM's IDs.
- Each FD gets its own VINTF, allocated by IOMMU_VIOMMU_ALLOC. The
kernel writes the VM's VMID into the VINTF and the host CMDQV
hardware checks it on every command.
- The kernel allocates the VINTF with HYP_OWN = 0, which restricts
the guest to a safe subset of commands.
- Per VINTF, the kernel programs SID_MATCH and SID_REPLACE so only
the VM's own vfio-pci devices can issue commands; other SIDs are
rejected by the hardware.
- IOMMU_HW_QUEUE_ALLOC binds each VCMDQ to one specific VINTF, so a
guest cannot reach a VCMDQ that belongs to another VM.
> Furthermore, what is not straightforward in this description is the
> sequence that will be executed
> - viommu_alloc done on which trap event?
> - hw_queue_alloc on which trap event?
> - mmap on guest VINT enable
> > vIOMMU allocation. However, the logical-to-physical association between
> > VCMDQs and a VINTF is only established after HW_QUEUE allocation. Prior
> > to that, the mapped Page0 does not back any real VCMDQ state.
Ok. Will capture the sequence of operations and the surrounding behaviour
in the same top of file comment in hw/arm/tegra241-cmdqv.c.
Thanks,
Shameer
