[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |