Hi Shameer, On 5/20/26 5:47 PM, Shameer Kolothum Thodi wrote: > 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 s/writes/configures > 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. at the moment a single VCMDQ is used by VM, is that a correct understanding?
Yes this general principle explanation sound very useful to me to help the reader understand the passthrough principle. > >> 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 > Thanks Eric
