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 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?
Hi Guangrong,
as such mapping information between virtual mmio to physical mmio is only available
at runtime.
Sorry, i do not know what the different between mmap() and the time VM actually
accesses the memory for your case. Could you please more detail?
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)
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?
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)
The vgpu api will allow you to adjust the target mmio address and the size via
validate_map_request, but it is still physical contiguous as <start_pfn, size>.
Okay, the interface confused us, maybe this interface need to be cooked to reflect
to this fact.
Thanks!
--
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
