Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl
From: Nicolin Chen <hidden>
Date: 2024-10-01 18:45:42
Also in:
linux-iommu, linux-kselftest, lkml
On Tue, Oct 01, 2024 at 10:46:20AM -0300, Jason Gunthorpe wrote:
On Tue, Oct 01, 2024 at 01:54:05AM -0700, Nicolin Chen wrote:quoted
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
Oh, I think I already have that then:
ictx->xarray: objIds <-> { IOAS|HWPT|VIOMMU|VDEVICE|.. }->objs
viommu->xarray: vRids <-> { VDEVICE } pointers
Thanks
Nicolin