On Thu, Oct 24, 2024 at 11:14:21PM -0700, Nicolin Chen wrote:
On Fri, Oct 25, 2024 at 04:58:33PM +1100, Alexey Kardashevskiy wrote:
Is there any real example of a .vdevice_alloc hook, besides the selftests? It is not in iommufd_viommu_p2-v4-with-rmr, hence the question. I am trying to sketch something with this new machinery and less guessing would be nice. Thanks,
No, I am actually dropping that one, and moving the vdevice struct to the private header, as there seems to be no use case:
Why keep it then?
We need that structure to store per-vIOMMU virtual ID. Hiding it in the core only means we need to provide another vIOMMU APIs for drivers to look up the ID, v.s. exposing it for drivers to access directly.
Sorry I lost you here. If we need it, then there should be an example of .vdevice_alloc() somewhere but you say they is not one. How do you test this, with just selftests? :) Thanks,
A vDEVICE object will be core-allocated and core-managed, while the vdevice_alloc is for driver-allocated purpose for which there is no use case (at least with this series). You can check the vdev ioctl in this version that has two pathways to allocate a vDEVICE object.
A vdev_id is used to index viommu's xarray for a driver to convert the id to a dev pointer via a vIOMMU API. Dropping .vdevice_alloc just means the driver only lost its direct access.
I think the point here is this has to go in stages at the present moment the iommu drivers don't need to hook the vdevice object, so Nicolin should take it out of this series.
I would expect CC to need to be in this path, so we should bring it back in the CC series.
For CC I'm broadly expecting that creating the CC type vIOMMU will call a CC implementation, and then creating a vdevice against the vIOMMU will also call the CC implementation. The two callbacks would ask the secure world to create the relevant VM visible objects.
Jason