[PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE)

Nicolin Chen nicolinc at nvidia.com
Thu Oct 24 23:14:21 PDT 2024


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.

Nicolin



More information about the linux-arm-kernel mailing list