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:
> > 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
