From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: "Kirti Wankhede" <kwankhede@nvidia.com>,
"Neo Jia" <cjia@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: Mon, 4 Jul 2016 14:39:22 +0800 [thread overview]
Message-ID: <577A049A.4000402@linux.intel.com> (raw)
In-Reply-To: <1467291711-3230-1-git-send-email-pbonzini@redhat.com>
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 the pfn when the fault is triggered rather
than when mmap() is called?
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 memory with MMIO)
IIUC, the kernel assumes that VM_PFNMAP is a continuous memory, e.g, like
current KVM and vaddr_get_pfn() in vfio, but it seems nvdia's patchset
breaks this semantic as ops->validate_map_request() can adjust the physical
address arbitrarily. (again, the name 'validate' should be changed to match
the thing as it is really doing)
next prev parent reply other threads:[~2016-07-04 6:43 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 [this message]
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
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=577A049A.4000402@linux.intel.com \
--to=guangrong.xiao@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=cjia@nvidia.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).