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: Nicolin Chen <hidden>
Date: 2024-10-04 18:14:08
Also in: linux-iommu, linux-kselftest, lkml

On Fri, Oct 04, 2024 at 08:41:47AM -0300, Jason Gunthorpe wrote:
On Fri, Oct 04, 2024 at 02:32:28PM +1000, Alexey Kardashevskiy wrote:
quoted
For my SEV-TIO exercise ("trusted IO"), I am looking for a kernel interface
to pass the guest's BDFs for a specific host device (which is passed
through) and nothing in the kernel has any knowledge of it atm, is this the
right place, or another ioctl() is needed here?
We probably need to add the vRID as well to this struct for that
reason.
"vRID"/"vBDF" doesn't sound very generic to me to put in this
structure, though PCI devices are and very likely will be the
only users of this Virtual Device for a while. Any good idea?

Also, I am wondering if the uAPI structure of Virtual Device
should have a driver-specific data structure. And the vdev_id
should be in the driver-specific struct. So, it could stay in
corresponding naming, "Stream ID", "Device ID" or "Context ID"
v.s. a generic "Virtual ID" in the top-level structure? Then,
other info like CCA can be put in the driver-level structure
of SMMU's.
The vdev_id is the iommu handle, and there is a platform specific
transformation between Bus/Device/Function and the iommu handle. In
some cases this is math, in some cases it is ACPI/DT tables or
something.
So I think the kernel should not make an assumption about the
relationship.
Agreed. That also implies that a vRID is quite independent to
the IOMMU right? So, I think that the reason of adding a vRID
to the virtual deivce uAPI/structure should be IOMMU requiring
it?

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