[Xen-devel] Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas

["H. Peter Anvin" <hpa@xxxxxxxxx>]

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 
> MFN
> 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.

        -hpa

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel