linux-kernel - Re: [PATCH v8 14/29] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aG68q0Uv+AuIgbvX@Asurada-Nvidia>
Date: Wed, 9 Jul 2025 12:02:03 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Vasant Hegde <vasant.hegde@....com>
CC: <jgg@...dia.com>, <kevin.tian@...el.com>, <corbet@....net>,
	<will@...nel.org>, <bagasdotme@...il.com>, <robin.murphy@....com>,
	<joro@...tes.org>, <thierry.reding@...il.com>, <vdumpa@...dia.com>,
	<jonathanh@...dia.com>, <shuah@...nel.org>, <jsnitsel@...hat.com>,
	<nathan@...nel.org>, <peterz@...radead.org>, <yi.l.liu@...el.com>,
	<mshavit@...gle.com>, <praan@...gle.com>, <zhangzekun11@...wei.com>,
	<iommu@...ts.linux.dev>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-tegra@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<patches@...ts.linux.dev>, <mochs@...dia.com>, <alok.a.tiwari@...cle.com>,
	<dwmw2@...radead.org>, <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v8 14/29] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC
 ioctl

On Mon, Jul 07, 2025 at 01:11:00PM +0530, Vasant Hegde wrote:
> Hi ,
> 
> 
> On 7/5/2025 6:43 AM, Nicolin Chen wrote:
> > Introduce a new IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl for user space to allocate
> > a HW QUEUE object for a vIOMMU specific HW-accelerated queue, e.g.:
> >  - NVIDIA's Virtual Command Queue
> >  - AMD vIOMMU's Command Buffer, Event Log Buffers, and PPR Log Buffers
> > 
> > Since this is introduced with NVIDIA's VCMDQs that access the guest memory
> > in the physical address space, add an iommufd_hw_queue_alloc_phys() helper
> > that will create an access object to the queue memory in the IOAS, to avoid
> > the mappings of the guest memory from being unmapped, during the life cycle
> > of the HW queue object.
> > 
> > AMD's HW will need an hw_queue_init op that is mutually exclusive with the
> > hw_queue_init_phys op, and their case will bypass the access part, i.e. no
> > iommufd_hw_queue_alloc_phys() call.
> 
> Thanks. We will implement hw_queue_init[_iova] to support AMD driver and fixup
> iommufd_hw_queue_alloc_ioctl(). Is that the correct understanding?

Yes. I think just a simple "hw_queue_init" will be good as the
object structure stores "iova" already:

struct iommufd_hw_queue {
	...
	u64 base_addr; /* in guest physical address space */
	...
};

Thanks
Nicolin