From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayIqz-0004kf-B2 for qemu-devel@nongnu.org; Thu, 05 May 2016 08:58:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ayIqn-0003eQ-I5 for qemu-devel@nongnu.org; Thu, 05 May 2016 08:57:59 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:9708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayIqn-0003a1-9F for qemu-devel@nongnu.org; Thu, 05 May 2016 08:57:53 -0400 References: <1462214441-3732-1-git-send-email-kwankhede@nvidia.com> <1462214441-3732-2-git-send-email-kwankhede@nvidia.com> <20160503164339.240afec4@t450s.home> <53ce48bc-44e4-3845-0625-67f3a79800b0@nvidia.com> <9c1f6f60-bfa7-dd4e-e56c-21cf819b5202@nvidia.com> From: Kirti Wankhede Message-ID: Date: Thu, 5 May 2016 18:27:25 +0530 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" , Alex Williamson Cc: "pbonzini@redhat.com" , "kraxel@redhat.com" , "cjia@nvidia.com" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Ruan, Shuai" , "Song, Jike" , "Lv, Zhiyuan" On 5/5/2016 5:37 PM, Tian, Kevin wrote: >> From: Kirti Wankhede [mailto:kwankhede@nvidia.com] >> 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