On 5/6/2016 5:44 PM, Jike Song wrote: > 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? > > If first access is at start address of mmaped address, fault_addr is vma->vm_start. Then (vm_end - vm_start) is the size mmapped region. req_size should not exceed (vm_end - vm_start). >>> 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? > Yes. >> >> 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. > Calling remap_pfn_range directly from mmap means you would like to remap pfn for whole BAR1 during mmap, right? In that case, don't set validate_map_request() and access start of mmap address, so that on first access it will do remap_pfn_range() for (vm_end - vm_start). Thanks, Kirti >> >> Thanks >> Kevin >> > > -- > Thanks, > Jike > -- 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
