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 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
patches should fix this.
Hi Paolo,
I have tested your patches with the mediated passthru patchset that is being
reviewed in KVM and QEMU mailing list.
The fault handler gets called successfully and the previously mapped memory gets
unmmaped correctly via unmap_mapping_range.
Great, then I'll include them in 4.8.
Code is okay, but i still suspect if this implementation, fetch mmio pages in fault
handler, is needed. We'd better include these patches after the design of vfio
framework is decided.
Hi Guangrong,
I disagree. The design of VFIO framework has been actively discussed in the KVM
and QEMU mailing for a while and the fault handler is agreed upon to provide the
flexibility for different driver vendors' implementation. With that said, I am
still open to discuss with you and anybody else about this framework as the goal
is to allow multiple vendor to plugin into this framework to support their
mediated device virtualization scheme, such as Intel, IBM and us.
The discussion is still going on. And current vfio patchset we reviewed is still
problematic.
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.
i didn’t mean to offend you, i just want to make sure if this complexity is really
needed and inspect if this framework is safe enough and think it over if we have
a better implementation.
--
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
