On Wed, Aug 26, 2009 at 10:22 PM, Avi Kivity<avi@xxxxxxxxxx> wrote: > On 08/24/2009 07:55 AM, Avi Kivity wrote: >> >> On 08/24/2009 12:59 AM, Stephen Donnelly wrote: >>> >>> On Thu, Aug 20, 2009 at 12:14 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >>>> >>>> On 08/13/2009 07:07 AM, Stephen Donnelly wrote: >>>>> >>>>> npages = get_user_pages_fast(addr, 1, 1, page); returns -EFAULT, >>>>> presumably because (vma->vm_flags& (VM_IO | VM_PFNMAP)). >>>>> >>>>> It takes then unlikely branch, and checks the vma, but I don't >>>>> understand what it is doing here: pfn = ((addr - vma->vm_start)>> >>>>> PAGE_SHIFT) + vma->vm_pgoff; >>>> >>>> It's calculating the pfn according to pfnmap rules. >>> >>> From what I understand this will only work when remapping 'main >>> memory', e.g. where the pgoff is equal to the physical page offset? >>> VMAs that remap IO memory will usually set pgoff to 0 for the start of >>> the mapping. >> >> If so, how do they calculate the pfn when mapping pages? kvm needs to be >> able to do the same thing. > > Maybe the simplest thing is to call vma->vm_ops->fault here. Marcelo/Chris? > Context is improving gfn_to_pfn() on the mmio path. If the mapping is made using remap_pfn_range (or io_remap_pfn_range) then there is are vm_ops attached by default. gfn_to_pfn: vma 0xffff88022c50d498 start 0x7f4b0de9f000 pgoff 0x0 flags 0x844fb vm_ops 0x0000000000000000 fault 0x0000000000000000 file 0xffff88022e408000 major 250 minor 32 >From linux/mm.h: #define VM_PFNMAP 0x00000400 /* Page-ranges managed without "struct page", just pure PFN */ Stephen. -- 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
