Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver

[Tian, Kevin]

> From: Kirti Wankhede [mailto:address@hidden
> Sent: Thursday, May 05, 2016 8:57 PM
> 
> 
> On 5/5/2016 5:37 PM, Tian, Kevin wrote:
> >> From: Kirti Wankhede [mailto:address@hidden
> >> 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