From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Donnelly <sfdonnelly@gmail.com>
Subject: Re: R/W HG memory mappings with kvm?
Date: Thu, 27 Aug 2009 14:39:22 +1200
Message-ID: <5f370d430908261939t362e2edfh1365063ab0ea22cc@mail.gmail.com>
References: <5f370d430907051541o752d3dbag80d5cb251e5e4d00@mail.gmail.com>
	 <4A6DBE54.3080609@cs.ualberta.ca>
	 <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> <4A950CEE.1080402@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Cam Macdonell <cam@cs.ualberta.ca>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Chris Wright <chrisw@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-fx0-f217.google.com ([209.85.220.217]:56168 "EHLO
	mail-fx0-f217.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932103AbZH0CjW convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Wed, 26 Aug 2009 22:39:22 -0400
Received: by fxm17 with SMTP id 17so585649fxm.37
        for <kvm@vger.kernel.org>; Wed, 26 Aug 2009 19:39:23 -0700 (PDT)
In-Reply-To: <4A950CEE.1080402@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Aug 26, 2009 at 10:22 PM, Avi Kivity<avi@redhat.com> 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@redhat.com> =A0wro=
te:
>>>>
>>>> On 08/13/2009 07:07 AM, Stephen Donnelly wrote:
>>>>>
>>>>> npages =3D get_user_pages_fast(addr, 1, 1, page); returns -EFAULT=
,
>>>>> presumably because (vma->vm_flags& =A0 =A0(VM_IO | VM_PFNMAP)).
>>>>>
>>>>> It takes then unlikely branch, and checks the vma, but I don't
>>>>> understand what it is doing here: pfn =3D ((addr - vma->vm_start)=
>>
>>>>> PAGE_SHIFT) + vma->vm_pgoff;
>>>>
>>>> It's calculating the pfn according to pfnmap rules.
>>>
>>> =A0From 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? =A0kvm need=
s to be
>> able to do the same thing.
>
> Maybe the simplest thing is to call vma->vm_ops->fault here. =A0Marce=
lo/Chris?
> =A0Context 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

=46rom linux/mm.h:

#define VM_PFNMAP	0x00000400	/* Page-ranges managed without "struct
page", just pure PFN */

Stephen.