linux-kernel - Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV

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: <20241004201746.GK1365916@nvidia.com>
Date: Fri, 4 Oct 2024 17:17:46 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Alexey Kardashevskiy <aik@....com>, kevin.tian@...el.com,
	will@...nel.org, joro@...tes.org, suravee.suthikulpanit@....com,
	robin.murphy@....com, dwmw2@...radead.org, baolu.lu@...ux.intel.com,
	shuah@...nel.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kselftest@...r.kernel.org, eric.auger@...hat.com,
	jean-philippe@...aro.org, mdf@...nel.org, mshavit@...gle.com,
	shameerali.kolothum.thodi@...wei.com, smostafa@...gle.com,
	yi.l.liu@...el.com
Subject: Re: [PATCH v2 06/19] iommufd/viommu: Add
 IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl

On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:

> With that, I wonder what is better for the initial version of
> this structure, a generic virtual ID or a driver-named ID like
> "Stream ID"? The latter might be more understandable/flexible, 
> so we won't need to justify a generic virtual ID along the way
> if something changes in the nature?

I think the name could be a bit more specific "viommu_device_id"
maybe? And elaborate in the kdoc that this is about the identifier
that the iommu HW itself uses.
> That sounds wider than what I defined it for in my patch:
>  * struct iommu_vdevice_alloc - ioctl(IOMMU_VDEVICE_ALLOC)
>  * ...
>  * Allocate a virtual device instance (for a physical device) against a vIOMMU.
>  * This instance holds the device's information in a VM, related to its vIOMMU.
> 
> Would you please help rephrase it? It'd be also helpful for me
> to update the doc.

I think that is still OK for the moment.

> Though I feel slightly odd if we define it wider than "vIOMMU"
> since this is an iommufd header...

The notion I have is that vIOMMU would expand to encompass not just
the physical hypervisor controled vIOMMU but also the vIOMMU
controlled by the trusted "lowervisor" in a pkvm/cc/whatever world.

Alexey is working on vIOMMU support in CC which has the trusted world
do some of the trusted vIOMMU components. I'm hoping the other people
in this area will look at his design and make it fit nicely to
everyone.

Jason