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: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
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 09:44:08 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Fri, 22 Oct 2010 09:45:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101022150826.GA23325@xxxxxxxxxxxx>
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>
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 08:08 AM, Konrad Rzeszutek Wilk wrote:
>> Okay, could you clarify this part a bit?  Why does the kernel need to
>> know the difference between "pseudo-physical" and "machine addresses" at
>> all?  If they overlap, there is a problem, and if they don't overlap, it
>> will be a 1:1 mapping anyway...
> The flag (_PAGE_IOMAP) is used when we set the PTE so that the MFN value is
> used instead of the PFN. We need that b/c when a driver does page_to_pfn()
> it ends up using the PFN as bus address to write out registers data.
> Without this patch, the page->virt->PFN value is used and the PFN != to real 
> so we end up writing in a memory address that the PCI device has no idea 
> about.
> By setting the PTE with the MFN, the virt->PFN gets the real MFN value.
> The drivers I am talking about are mostly, if not all, located in drivers/gpu
> and it looks that we are missing two more patches to utilize the patch
> that Jeremy posted.
> Please note that I am _not_ suggesting that the two patches
> below should go out - I still need to post them on drm mailing list.

I'm still seriously confused.  If I understand this correctly, we're
talking about DMA addresses here (as opposed to PIO addresses, i.e.
BARs), right?

It's the bimodality that really bothers me.  I understand of course that
Xen imposes yet another address remapping layer, but I'm having a hard
time understanding any conditions under with we would need that layer to
go away, as long as DMA addresses are translated via the DMA APIs -- and
if they aren't, then iommus will break, too.

As such, I don't grok this page flag and what it does, and why it's
needed.  I'm not saying it's *wrong*, I'm saying the design is opaque to
me and I'm not sure it is the right solution.


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

Xen-devel mailing list