From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayegH-0004iu-9G for qemu-devel@nongnu.org; Fri, 06 May 2016 08:16:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ayeg5-00075S-Gs for qemu-devel@nongnu.org; Fri, 06 May 2016 08:16:23 -0400 Received: from mga14.intel.com ([192.55.52.115]:41928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ayeg5-00070G-AD for qemu-devel@nongnu.org; Fri, 06 May 2016 08:16:17 -0400 Message-ID: <572C8AC0.4070602@intel.com> Date: Fri, 06 May 2016 20:14:56 +0800 From: Jike Song MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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" Cc: Kirti Wankhede , Alex Williamson , "pbonzini@redhat.com" , "kraxel@redhat.com" , "cjia@nvidia.com" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Ruan, Shuai" , "Lv, Zhiyuan" On 05/05/2016 05:06 PM, Tian, Kevin wrote: >> From: Kirti Wankhede >> >> >> + * @validate_map_request: Validate remap pfn request >> >> + * @vdev: vgpu device structure >> >> + * @virtaddr: target user address to start at >> >> + * @pfn: physical address of kernel memory, GPU >> >> + * driver can change if required. >> >> + * @size: size of map area, GPU driver can change >> >> + * the size of map area if desired. >> >> + * @prot: page protection flags for this mapping, >> >> + * GPU driver can change, if required. >> >> + * Returns integer: success (0) or error (< 0) >> > >> > Was not at all clear to me what this did until I got to patch 2, this >> > is actually providing the fault handling for mmap'ing a vGPU mmio BAR. >> > Needs a better name or better description. >> > >> >> If say VMM mmap whole BAR1 of GPU, say 128MB, so fault would occur when >> BAR1 is tried to access then the size is calculated as: >> req_size = vma->vm_end - virtaddr Hi Kirti, virtaddr is the faulted one, vma->vm_end the vaddr of the mmap-ed 128MB BAR1? Would you elaborate why (vm_end - fault_addr) results the requested size? >> Since GPU is being shared by multiple vGPUs, GPU driver might not remap >> whole BAR1 for only one vGPU device, so would prefer, say map one page >> at a time. GPU driver returns PAGE_SIZE. This is used by >> remap_pfn_range(). Now on next access to BAR1 other than that page, we >> will again get a fault(). >> As the name says this call is to validate from GPU driver for the size >> and prot of map area. GPU driver can change size and prot for this map area. If I understand correctly, you are trying to share a physical BAR among multiple vGPUs, by mapping a single pfn each time, when fault happens? > > Currently we don't require such interface for Intel vGPU. Need to think about > its rationale carefully (still not clear to me). Jike, do you have any thought on > this? We need the mmap method of vgpu_device to be implemented, but I was expecting something else, like calling remap_pfn_range() directly from the mmap. > > Thanks > Kevin > -- Thanks, Jike