On Thu, Jul 29, 2021 at 09:20:22AM +0200, Christoph Hellwig wrote: > On Wed, Jul 28, 2021 at 02:59:25PM -0300, Jason Gunthorpe wrote: > > On Wed, Jul 28, 2021 at 01:38:58PM +0000, Wang, Zhi A wrote: > > > > > I guess those APIs you were talking about are KVM-only. For other > > > hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not > > > sure if you have already noticed that VFIO is KVM-only right now. > > > > There is very little hard connection between VFIO and KVM, so no, I > > don't think that is completely true. > > The only connection is the SET_KVM notifier as far as I can tell. > Which is used by a total of two drivers, including i915/gvt. That > being said gvt does not only use vfio, but also does quite a few > direct cals to KVM. > > > In an event, an in-tree version of other hypervisor support for GVT > > needs to go through enabling VFIO support so that the existing API > > multiplexers we have can be used properly, not adding a shim layer > > trying to recreate VFIO inside a GPU driver. > > Yes. And if we go back to actually looking at the series a lot of > it just removes entirely pointless indirect calls that go to generic > code and not even the kvm code, or questionable data structure designs. > If we were to support another upstream hypervisor we'd just need to > union a few fields in struct intel_gpu and maybe introduce a few > methods. Preferably in a way that avoids expensive indirect calls > in the fast path. fwiw I concur with the direction of this series. gvt landed 5 years ago, that should have been plenty of time to merge at least one of the other backends that float around. If it didn't happen in 5 years it aint suddenly happening in the next few, and the abstraction layer should be sunset. Also yes structuring it more as a helper layer with some unions/subclassing than full blown backend abstractor layer would be a good idea too I guess (it usually is the right thing to do). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
