From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: R/W HG memory mappings with kvm? Date: Mon, 31 Aug 2009 11:44:13 +0300 Message-ID: <4A9B8D5D.2070209@redhat.com> References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com> <5f370d430907271432y5283c2cat7673efeed0febe20@mail.gmail.com> <4A6EBCB3.4080804@redhat.com> <5f370d430907281606j77f0c1a6j5feb081daca187ff@mail.gmail.com> <5f370d430908122107j15acd2c7i96d476e69032fadd@mail.gmail.com> <4A8BEC92.6070105@redhat.com> <5f370d430908231459q4c8cfe3j62c49e33a160ab71@mail.gmail.com> <4A921D3C.6020809@redhat.com> <5f370d430908261934m15f39ab9mf54a19bdee1f278f@mail.gmail.com> <4A9606C5.4060607@redhat.com> <5f370d430908301533l1068692j1ed902a268f0ae41@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , "kvm@vger.kernel.org list" To: Stephen Donnelly Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27937 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751848AbZHaIoO (ORCPT ); Mon, 31 Aug 2009 04:44:14 -0400 In-Reply-To: <5f370d430908301533l1068692j1ed902a268f0ae41@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/31/2009 01:33 AM, Stephen Donnelly wrote: > >> We can't duplicate mm/ in kvm. However, mm/memory.c says: >> >> >> * The way we recognize COWed pages within VM_PFNMAP mappings is through the >> * rules set up by "remap_pfn_range()": the vma will have the VM_PFNMAP bit >> * set, and the vm_pgoff will point to the first PFN mapped: thus every >> special >> * mapping will always honor the rule >> * >> * pfn_of_page == vma->vm_pgoff + ((addr - vma->vm_start)>> >> PAGE_SHIFT) >> * >> * And for normal mappings this is false. >> >> So it seems the kvm calculation is right and you should set vm_pgoff in your >> driver. >> > That may be true for COW pages, which are main memory, but I don't > think it is true for device drivers. > No, COW pages have no linear pfn mapping. It's only true for remap_pfn_range). > In a device driver the mmap function receives the vma from the OS. The > vm_pgoff field contains the offset area in the file. For drivers this > is used to determine where to start the map compared to the io base > address. > > If the driver is mapping io memory to user space it calls > io_remap_pfn_range with the pfn for the io memory. The remap_pfn_range > call sets the VM_IO and VM_PFNMAP bits in vm_flags. It does not alter > the vm_pgoff value. > > A simple example is hpet_mmap() in drivers/char/hpet.c, or > mbcs_gscr_mmap() in drivers/char/mbcs.c. > io_remap_pfn_range() is remap_pfn_range(), which has this: if (addr == vma->vm_start && end == vma->vm_end) { vma->vm_pgoff = pfn; vma->vm_flags |= VM_PFN_AT_MMAP; } So remap_pfn_range() will alter the pgoff. >> do_mmap(), but don't use it. Use mmap() from userspace like everyone else. >> > Of course you are right, gfn_to_pfn is in user space. There is already > a mapping of the memory to the process (from qemu_ram_mmap), the > question is how to look it up. > I'm totally confused now. -- error compiling committee.c: too many arguments to function