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.