This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_I

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Fri, 22 Oct 2010 12:20:47 -0700
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Fri, 22 Oct 2010 12:21:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CC1E0B6.3070303@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4CC0C14E.5080205@xxxxxxxx> <4CC0C318.90401@xxxxxxxxx> <4CC0CA07.3000306@xxxxxxxx> <4CC0DEB8.1060309@xxxxxxxxx> <20101022150826.GA23325@xxxxxxxxxxxx> <4CC1BF58.9020001@xxxxxxxxx> <4CC1E0B6.3070303@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Thunderbird/3.1.4
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...


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Xen-devel mailing list