linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neo Jia <cjia@nvidia.com>
To: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	"Kirti Wankhede" <kwankhede@nvidia.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed
Date: Tue, 5 Jul 2016 19:18:40 -0700	[thread overview]
Message-ID: <20160706021839.GA9064@nvidia.com> (raw)
In-Reply-To: <577C664E.3080802@linux.intel.com>

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.

May I ask you what the exact issue you have with this interface for Intel to support 
your own GPU virtualization? 

Thanks,
Neo

> 

  reply	other threads:[~2016-07-06  2:18 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 13:01 [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed Paolo Bonzini
2016-06-30 13:01 ` [PATCH 1/2] KVM: MMU: prepare to support mapping of VM_IO and VM_PFNMAP frames Paolo Bonzini
2016-06-30 13:01 ` [PATCH 2/2] KVM: MMU: try to fix up page faults before giving up Paolo Bonzini
2016-06-30 21:59 ` [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed Neo Jia
2016-07-04  6:39 ` Xiao Guangrong
2016-07-04  7:03   ` Neo Jia
2016-07-04  7:37     ` Xiao Guangrong
2016-07-04  7:48       ` Paolo Bonzini
2016-07-04  7:59         ` Xiao Guangrong
2016-07-04  8:14           ` Paolo Bonzini
2016-07-04  8:21             ` Xiao Guangrong
2016-07-04  8:48               ` Paolo Bonzini
2016-07-04  7:53       ` Neo Jia
2016-07-04  8:19         ` Xiao Guangrong
2016-07-04  8:41           ` Neo Jia
2016-07-04  8:45             ` Xiao Guangrong
2016-07-04  8:54               ` Xiao Guangrong
2016-07-04  9:16               ` Neo Jia
2016-07-04 10:16                 ` Xiao Guangrong
2016-07-04 15:33                   ` Neo Jia
2016-07-05  1:19                     ` Xiao Guangrong
2016-07-05  1:35                       ` Neo Jia
2016-07-05  4:02                         ` Xiao Guangrong
2016-07-05  5:16                           ` Neo Jia
2016-07-05  6:26                             ` Xiao Guangrong
2016-07-05  7:30                               ` Neo Jia
2016-07-05  9:02                                 ` Xiao Guangrong
2016-07-05 15:07                                   ` Neo Jia
2016-07-06  2:22                                     ` Xiao Guangrong
2016-07-06  4:01                                       ` Neo Jia
2016-07-04  7:38   ` Paolo Bonzini
2016-07-04  7:40     ` Xiao Guangrong
2016-07-05  5:41 ` Neo Jia
2016-07-05 12:18   ` Paolo Bonzini
2016-07-05 14:02     ` Neo Jia
2016-07-06  2:00     ` Xiao Guangrong
2016-07-06  2:18       ` Neo Jia [this message]
2016-07-06  2:35         ` Xiao Guangrong
2016-07-06  2:57           ` Neo Jia
2016-07-06  4:02             ` Xiao Guangrong
2016-07-06 11:48               ` Paolo Bonzini
2016-07-07  2:36                 ` Xiao Guangrong
2016-07-06  6:05       ` Paolo Bonzini
2016-07-06 15:50         ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160706021839.GA9064@nvidia.com \
    --to=cjia@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=guangrong.xiao@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).