Re: [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem

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

 



On Mon, Jan 25, 2021 at 08:34:29PM -0700, Alex Williamson wrote:

> > someting like this was already tried in May and didn't go anywhere -
> > are you surprised that we are reluctant to commit alot of resources
> > doing a complete job just to have it go nowhere again?
> 
> That's not really what I'm getting from your feedback, indicating
> vfio-pci is essentially done, the mlx stub driver should be enough to
> see the direction, and additional concerns can be handled with TODO
> comments. 

I think we are looking at this RFC in different ways. I see it as
largely "done" showing the general design of few big ideas:

 - new vfio drivers will be creating treating VFIO PCI as a "VFIO bus
   driver" library
 - These new drivers are PCI devices bound via driver core as peers to
   vfio-pci, vs sub drivers of vfio-pci
 - It uses the subsystem -> driver -> library pattern for composing drivers
   instead of the subsystem -> midlayer -> driver pattern mdev/platform use
 - It will have some driver facing API from vfio-pci-core that is
   close to what is shown in the RFC
 - The drivers can "double bind" in the driver core to access the PF
   resources via aux devices from the VF VFIO driver.

The point of a RFC discussion is to try to come to some community
understanding on a general high level direction.

It is not a perfectly polished illustration of things that shouldn't
be contentious or technically hard. There are alot of things that can
be polished here, this illustration has lots of stuff in vfio-pci-core
that really should be in vfio-pci - it will take time and effort to
properly split things up and do a great job here.

> Sorry if this is not construed as actual feedback, I think both
> Connie and I are making an effort to understand this and being
> hampered by lack of a clear api or a vendor driver that's anything
> more than vfio-pci plus an aux bus interface.  Thanks,

I appreciate the effort, and there is a lot to understand here. Most
of this stuff is very new technology and not backed by industry
standards bodies.

I really do think this simplified RFC will help the process - I've
seen the internal prototype and it is a mass of opaque device specific
code. Max's V2 should flesh things out more.

Thanks,
Jason



[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