> -----Original Message-----
> From: Eric Auger <[email protected]>
> Sent: 21 May 2026 09:00
> 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/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?

Not quite. QEMU exposes one VINTF (VINTF0) with two VCMDQs to the
guest. The guest decides how many of them to enable. A Linux guest
enables both:
...
arm-smmu-v3 arm-smmu-v3.0.auto: allocated 524288 entries for vcmdq0
arm-smmu-v3 arm-smmu-v3.0.auto: allocated 524288 entries for vcmdq1
...

Thanks,
Shameer

Reply via email to