On 07/06/2016 07:48 PM, Paolo Bonzini wrote:
On 06/07/2016 06:02, Xiao Guangrong wrote:
May I ask you what the exact issue you have with this interface for
Intel to support
your own GPU virtualization?
Intel's vGPU can work with this framework. We really appreciate your
/ nvidia's
contr
On Wed, 6 Jul 2016 08:05:15 +0200
Paolo Bonzini wrote:
> On 06/07/2016 04:00, Xiao Guangrong wrote:
> >
> >
> > On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
> >>
> >>
> >> On 05/07/2016 07:41, Neo Jia wrote:
> >>> On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> The v
On 06/07/2016 06:02, Xiao Guangrong wrote:
>>>
May I ask you what the exact issue you have with this interface for
Intel to support
your own GPU virtualization?
>>>
>>> Intel's vGPU can work with this framework. We really appreciate your
>>> / nvidia's
>>> contribution.
>>
>>
On 06/07/2016 04:00, Xiao Guangrong wrote:
>
>
> On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
>>
>>
>> On 05/07/2016 07:41, Neo Jia wrote:
>>> On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops o
On Wed, Jul 06, 2016 at 10:22:59AM +0800, Xiao Guangrong wrote:
>
>
> On 07/05/2016 11:07 PM, Neo Jia wrote:
> >This is kept there in case the validate_map_request() is not provided by
> >vendor
> >driver then by default assume 1:1 mapping. So if validate_map_request() is
> >not
> >provided, fa
On 07/06/2016 10:57 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote:
On 07/06/2016 10:18 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia wrote
On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote:
>
>
> On 07/06/2016 10:18 AM, Neo Jia wrote:
> >On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
> >>>
> >>>
> >>>On 05/07/2016 07:41, Neo Jia wrote:
> On
On 07/06/2016 10:18 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia wrote:
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
The vGPU folks would like to trap the fi
On 07/05/2016 11:07 PM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 05:02:46PM +0800, Xiao Guangrong wrote:
It is physically contiguous but it is done during the runtime, physically
contiguous doesn't mean
static partition at boot time. And only during runtime, the proper HW resource
will be r
On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
>
>
> On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
> >
> >
> >On 05/07/2016 07:41, Neo Jia wrote:
> >>On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> >>>The vGPU folks would like to trap the first access to a BAR by
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia wrote:
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
th
On Tue, Jul 05, 2016 at 05:02:46PM +0800, Xiao Guangrong wrote:
>
> >
> >It is physically contiguous but it is done during the runtime, physically
> >contiguous doesn't mean
> >static partition at boot time. And only during runtime, the proper HW
> >resource will be requested therefore
> >the ri
On Tue, Jul 05, 2016 at 02:18:28PM +0200, Paolo Bonzini wrote:
>
>
> On 05/07/2016 07:41, Neo Jia wrote:
> > On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> >> The vGPU folks would like to trap the first access to a BAR by setting
> >> vm_ops on the VMAs produced by mmap-ing a VF
On 05/07/2016 07:41, Neo Jia wrote:
> On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
>> The vGPU folks would like to trap the first access to a BAR by setting
>> vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
>> then can use remap_pfn_range to place some
On 07/05/2016 03:30 PM, Neo Jia wrote:
(Just for completeness, if you really want to use a device in above example as
VFIO passthru, the second step is not completely handled in userspace, it is
actually the guest
driver who will allocate and setup the proper hw resource which will later re
On Tue, Jul 05, 2016 at 02:26:46PM +0800, Xiao Guangrong wrote:
>
>
> On 07/05/2016 01:16 PM, Neo Jia wrote:
> >On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/05/2016 09:35 AM, Neo Jia wrote:
> >>>On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
On 07/05/2016 01:16 PM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
On 07/05/2016 09:35 AM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the "allocation
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> The vGPU folks would like to trap the first access to a BAR by setting
> vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
> then can use remap_pfn_range to place some non-reserved pages in the VMA.
>
> KVM la
On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
>
>
> On 07/05/2016 09:35 AM, Neo Jia wrote:
> >On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 11:33 PM, Neo Jia wrote:
> >>
> >
> >Sorry, I think I misread the "allocation" as "ma
On 07/05/2016 09:35 AM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the "allocation" as "mapping". We only delay the
cpu mapping, not the allocation.
So how to understand your statement:
"
On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
>
>
> On 07/04/2016 11:33 PM, Neo Jia wrote:
>
> >>>
> >>>Sorry, I think I misread the "allocation" as "mapping". We only delay the
> >>>cpu mapping, not the allocation.
> >>
> >>So how to understand your statement:
> >>"at that mom
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the "allocation" as "mapping". We only delay the
cpu mapping, not the allocation.
So how to understand your statement:
"at that moment nobody has any knowledge about how the physical mmio gets
virtualized"
The resource, physi
On Mon, Jul 04, 2016 at 06:16:46PM +0800, Xiao Guangrong wrote:
>
>
> On 07/04/2016 05:16 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 04:45:05PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 04:41 PM, Neo Jia wrote:
> >>>On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 05:16 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:45:05PM +0800, Xiao Guangrong wrote:
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800,
On Mon, Jul 04, 2016 at 04:45:05PM +0800, Xiao Guangrong wrote:
>
>
> On 07/04/2016 04:41 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 03:53 PM, Neo Jia wrote:
> >>>On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 04:45 PM, Xiao Guangrong wrote:
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia w
On 04/07/2016 10:21, Xiao Guangrong wrote:
>>
>> /*
>> * In case the VMA has VM_MIXEDMAP set, whoever called
>> remap_pfn_range
>> * is also going to call e.g. unmap_mapping_range before the
>> underlying
>> * non-reserved pages are freed, which will then call our MMU
>> notifi
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800,
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
>
>
> On 07/04/2016 03:53 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 07/04/2016 03:03 PM, Neo Jia wrote:
> >>>On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
On 07/04/2016 04:14 PM, Paolo Bonzini wrote:
On 04/07/2016 09:59, Xiao Guangrong wrote:
But apart from this, it's much more obvious to consider the refcount.
The x86 MMU code doesn't care if the page is reserved or not;
mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
hv
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap th
On 04/07/2016 09:59, Xiao Guangrong wrote:
>
>> But apart from this, it's much more obvious to consider the refcount.
>> The x86 MMU code doesn't care if the page is reserved or not;
>> mmu_set_spte does a kvm_release_pfn_clean, hence it makes sense for
>> hva_to_pfn_remapped to try doing a get_
On 07/04/2016 03:48 PM, Paolo Bonzini wrote:
On 04/07/2016 09:37, Xiao Guangrong wrote:
It actually is a portion of the physical mmio which is set by vfio mmap.
So i do not think we need to care its refcount, i,e, we can consider it
as reserved_pfn,
Paolo?
nVidia provided me (offlist)
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
>
>
> On 07/04/2016 03:03 PM, Neo Jia wrote:
> >On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >>>The vGPU folks would like to trap the first access to a B
On 04/07/2016 09:37, Xiao Guangrong wrote:
>>>
>>
>> It actually is a portion of the physical mmio which is set by vfio mmap.
>
> So i do not think we need to care its refcount, i,e, we can consider it
> as reserved_pfn,
> Paolo?
nVidia provided me (offlist) with a simple patch that modified VF
On 07/04/2016 03:38 PM, Paolo Bonzini wrote:
On 04/07/2016 08:39, Xiao Guangrong wrote:
Why the memory mapped by this mmap() is not a portion of MMIO from
underlayer physical device? If it is a valid system memory, is this
interface
really needed to implemented in vfio? (you at least need to
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handle
On 04/07/2016 08:39, Xiao Guangrong wrote:
> Why the memory mapped by this mmap() is not a portion of MMIO from
> underlayer physical device? If it is a valid system memory, is this
> interface
> really needed to implemented in vfio? (you at least need to set VM_MIXEDMAP
> if it mixed system memo
On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
>
>
> On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
> >The vGPU folks would like to trap the first access to a BAR by setting
> >vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
> >then can use remap_pfn_range
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.
Why does it require fetching
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
> The vGPU folks would like to trap the first access to a BAR by setting
> vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
> then can use remap_pfn_range to place some non-reserved pages in the VMA.
Hi Paolo,
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.
KVM lacks support for this kind of non-linear VM_PFNMAP mapping, and these
patc
42 matches
Mail list logo
