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.
Thanks,
Kirti
--
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
