RE: [PATCH v4 10/23] iommufd/viommu: Introduce IOMMUFD_OBJ_HW_QUEUE and its related struct

Tian, Kevin
2025-05-16T03:00:14Z

> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Friday, May 16, 2025 10:30 AM
>
> On Thu, May 15, 2025 at 05:58:41AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > Sent: Friday, May 9, 2025 11:03 AM
> > >
> > > Add IOMMUFD_OBJ_HW_QUEUE with an iommufd_hw_queue structure,
> > > representing
> > > a HW-accelerated queue type of IOMMU's physical queue that can be
> passed
> > > through to a user space VM for direct hardware control, such as:
> > > - NVIDIA's Virtual Command Queue
> > > - AMD vIOMMU's Command Buffer, Event Log Buffer, and PPR Log Buffer
> > >
> > > Introduce an allocator iommufd_hw_queue_alloc(). And add a pair of
> > > viommu
> > > ops for iommufd to forward user space ioctls to IOMMU drivers.
> > >
> > > Given that the first user of this HW QUEUE (tegra241-cmdqv) will need to
> > > ensure the queue memory to be physically contiguous, add a flag
> property
> > > in iommufd_viommu_ops and
> > > IOMMUFD_VIOMMU_FLAG_HW_QUEUE_READS_PA to allow
> > > driver to flag it so that the core will validate the physical pages of a
> > > given guest queue.
> >
> > 'READS' is confusing here. What about xxx_CONTIG_PAS?
>
> Combining Jason's first comments here:
> https://lore.kernel.org/linux-
> iommu/20250515160620.GJ382960@nvidia.com/
>
> So, pinning should be optional too. And I think there would be
> unlikely a case where HW needs contiguous physical pages while
> not requiring to pin the pages, right?
>
> So, we need an flag that could indicate to do both tests. Yet,
> "xxx_CONTIG_PAS" doesn't sound very fitting, compared to this
> "IOMMUFD_VIOMMU_FLAG_HW_QUEUE_READS_PA".
>
> Perhaps, we should just add some comments to clarify a bit. Or
> do you have some better naming?
>

let's wait until that open is closed, i.e. whether we still let the core
manage it and whether AMD requires pinning even when IOVA
is used.