public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
Date: Fri, 22 Oct 2010 12:36:43 -0700	[thread overview]
Message-ID: <4CC1E7CB.8090106@goop.org> (raw)
In-Reply-To: <4CC1E40F.60708@zytor.com>

 On 10/22/2010 12:20 PM, H. Peter Anvin wrote:
> On 10/22/2010 12:06 PM, Jeremy Fitzhardinge wrote:
>> Well, if you want to map a normal memory page, you'd use, say,
>> pfn_pte(pfn, PAGE_KERNEL) to generate the pte.  The pfn is a
>> domain-local pseudo-physical address.  When it ends up in
>> xen_make_pte(), it will translate the the pfn into a machine-global mfn
>> to generate a pte_t which can be inserted into a pagetable.  (And when
>> that pagetable starts being used as such, Xen will validate that the mfn
>> is actually one the domain is allowed to address.)
>>
>> However, if you're doing an ioremap(), then the mapped address is a
>> hardware one.  In that case, we construct the pte with
>> pfn_pte(device_pfn, PAGE_KERNEL_IO), which sets the _PAGE_IOMAP flag in
>> the pte flags.  When it gets to xen_make_pte(), it sees _PAGE_IOMAP and
>> constructs a pte_t containing the literal untranslated device_pfn
>> (really an mfn).  (And again, Xen will check that the domain has access
>> to that mfn before allowing the mapping to be used.)
>>
> When you're doing an ioremap(), then the mapped address is *both* a PFN
> and an MFN, right?  So why do your need a flag?  That is the part I
> don't get...

Xen always needs an mfn, so for memory the pfn needs to be converted to
an mfn, but for devices the frame number is already an mfn.  You could
look at it as having two distinct frame number address spaces, and the
_PAGE_IOMAP flag tells the lower levels which address space the frame
number is in.  Both memory and device mappings use the same interface -
__pte() - to convert a (pfn,prot) tuple into a pte_t, so we use a bit in
prot to distinguish them.

In the kernel, the places where device mappings vs memory mappings are
quite well delineated.  There used to be a few places which could be
either depending on context, but they've since been cleaned up by other
efforts (the PAT/pageattr work did a lot of them, I think).

    J


      reply	other threads:[~2010-10-22 19:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 22:40 [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas Jeremy Fitzhardinge
2010-10-21 22:47 ` H. Peter Anvin
2010-10-21 23:17   ` Jeremy Fitzhardinge
2010-10-22  0:45     ` H. Peter Anvin
2010-10-22 15:08       ` Konrad Rzeszutek Wilk
2010-10-22 16:44         ` H. Peter Anvin
2010-10-22 18:02           ` Konrad Rzeszutek Wilk
2010-10-22 18:05             ` Konrad Rzeszutek Wilk
2010-10-22 19:06             ` H. Peter Anvin
2010-10-22 19:11               ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-10-22 19:06           ` Jeremy Fitzhardinge
2010-10-22 19:20             ` H. Peter Anvin
2010-10-22 19:36               ` Jeremy Fitzhardinge [this message]

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=4CC1E7CB.8090106@goop.org \
    --to=jeremy@goop.org \
    --cc=Xen-devel@lists.xensource.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /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