Thread (149 messages) 149 messages, 7 authors, 2025-05-12

Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl

From: Jason Gunthorpe <jgg@nvidia.com>
Date: 2024-10-01 13:46:25
Also in: linux-iommu, linux-kselftest, lkml

On Tue, Oct 01, 2024 at 01:54:05AM -0700, Nicolin Chen wrote:
On Thu, Sep 05, 2024 at 10:38:23AM -0700, Nicolin Chen wrote:
quoted
On Thu, Sep 05, 2024 at 01:03:53PM -0300, Jason Gunthorpe wrote:
quoted
On Tue, Aug 27, 2024 at 09:59:43AM -0700, Nicolin Chen wrote:
quoted
Introduce a pair of new ioctls to set/unset a per-viommu virtual device id
that should be linked to a physical device id via an idev pointer.
Given some of the other discussions around CC I suspect we should
rename these to 'create/destroy virtual device' with an eye that
eventually they would be extended like other ops with per-CC platform
data.

ie this would be the interface to tell the CC trusted world that a
secure device is being added to a VM with some additional flags..

Right now it only conveys the vRID parameter of the virtual device
being created.

A following question is if these objects should have their own IDs in
the iommufd space too, and then unset is not unset but just a normal
destroy object. If so then the thing you put in the ids xarray would
also just be a normal object struct.
I found that adding it as a new object makes things a lot of easier
since a vdevice can take refcounts of both viommu and idev. So both
destroy() callbacks wouldn't be bothered.

While confirming if I am missing something from the review comments,
I am not quite sure what is "the thing you put in the ids xarray"..
I only added a vRID xarray per viommu, yet that doesn't seem to be
able to merge into the normal object struct. Mind elaborating?
I would think to point the vRID xarray directly to the new iommufd
vdevice object

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help