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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux