qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver


From: Jike Song
Subject: Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver
Date: Fri, 06 May 2016 20:14:56 +0800
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]