RE: [RFC 14/20] iommu/iommufd: Add iommufd_device_[de]attach_ioasid()

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

 



> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Wednesday, September 22, 2021 8:57 PM
> 
> On Wed, Sep 22, 2021 at 03:53:52AM +0000, Tian, Kevin wrote:
> 
> > Actually this was one open we closed in previous design proposal, but
> > looks you have a different thought now.
> >
> > vfio maintains one ioas per container. Devices in the container
> > can be attached to different domains (e.g. due to snoop format). Every
> > time when the ioas is updated, every attached domain is updated
> > in accordance.
> >
> > You recommended one-ioas-one-domain model instead, i.e. any device
> > with a format incompatible with the one currently used in ioas has to
> > be attached to a new ioas, even if the two ioas's have the same mapping.
> > This leads to compatibility check at attaching time.
> >
> > Now you want returning back to the vfio model?
> 
> Oh, I thought we circled back again.. If we are all OK with one ioas
> one domain then great.

yes, at least I haven't seen a blocking issue with this assumption. Later
when converting vfio type1 into a shim, it could create multiple ioas's
if container would have a list of domains before the shim.

> 
> > > If think sis taking in the iommfd_device then there isn't a logical
> > > place to signal the PCIness
> >
> > can you elaborate?
> 
> I mean just drop it and document it.
> 

got you




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux