> From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] > Sent: Thursday, May 05, 2016 8:57 PM > > > On 5/5/2016 5:37 PM, Tian, Kevin wrote: > >> From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] > >> Sent: Thursday, May 05, 2016 6:45 PM > >> > >> > >> On 5/5/2016 2:36 PM, Tian, Kevin wrote: > >>>> From: Kirti Wankhede > >>>> Sent: Wednesday, May 04, 2016 9:32 PM > >>>> > >>>> Thanks Alex. > >>>> > >>>> >> +config VGPU_VFIO > >>>> >> + tristate > >>>> >> + depends on VGPU > >>>> >> + default n > >>>> >> + > >>>> > > >>>> > This is a little bit convoluted, it seems like everything added in this > >>>> > patch is vfio agnostic, it doesn't necessarily care what the consumer > >>>> > is. That makes me think we should only be adding CONFIG_VGPU here and > >>>> > it should not depend on CONFIG_VFIO or be enabling CONFIG_VGPU_VFIO. > >>>> > The middle config entry is also redundant to the first, just move the > >>>> > default line up to the first and remove the rest. > >>>> > >>>> CONFIG_VGPU doesn't directly depend on VFIO. CONFIG_VGPU_VFIO is > >>>> directly dependent on VFIO. But devices created by VGPU core module need > >>>> a driver to manage those devices. CONFIG_VGPU_VFIO is the driver which > >>>> will manage vgpu devices. So I think CONFIG_VGPU_VFIO should be enabled > >>>> by CONFIG_VGPU. > >>>> > >>>> This would look like: > >>>> menuconfig VGPU > >>>> tristate "VGPU driver framework" > >>>> select VGPU_VFIO > >>>> default n > >>>> help > >>>> VGPU provides a framework to virtualize GPU without SR-IOV cap > >>>> See Documentation/vgpu.txt for more details. > >>>> > >>>> If you don't know what do here, say N. > >>>> > >>>> config VGPU_VFIO > >>>> tristate > >>>> depends on VGPU > >>>> depends on VFIO > >>>> default n > >>>> > >>> > >>> There could be multiple drivers operating VGPU. Why do we restrict > >>> it to VFIO here? > >>> > >> > >> VGPU_VFIO uses VFIO APIs, it depends on VFIO. > >> I think since there is no other driver than VGPU_VFIO for VGPU devices, > >> we should keep default selection of VGPU_VFIO on VGPU. May be in future > >> if other driver is add ti operate vGPU devices, then default selection > >> can be removed. > > > > What's your plan to support Xen here? > > > > No plans to support Xen. > Intel will support both KVM and Xen based on this framework. Also, such hard binding between components is better avoided if this framework is designed for multi-drivers (that's why you introduce vgpu_register_driver). Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
