Re: [Xen-devel] [PATCH] xen: swiotlb: handle sizeof(dma_addr_t) != sizeof(phys_addr_t)

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 22 Jan 2014, Ian Campbell wrote:
> On Tue, 2014-01-21 at 17:03 -0500, Konrad Rzeszutek Wilk wrote:
> 
> (nb: I posted a v3 at
> http://article.gmane.org/gmane.linux.ports.arm.kernel/295594
> )
> 
> > On Fri, Jan 17, 2014 at 05:24:53PM +0000, Ian Campbell wrote:
> > > The use of phys_to_machine and machine_to_phys in the phys<=>bus 
> > > conversions
> > > causes us to lose the top bits of the DMA address if the size of a DMA 
> > > address is not the same as the size of the phyiscal address.
> > > 
> > > This can happen in practice on ARM where foreign pages can be above 4GB 
> > > even
> > > though the local kernel does not have LPAE page tables enabled (which is
> > > totally reasonable if the guest does not itself have >4GB of RAM). In this
> > > case the kernel still maps the foreign pages at a phys addr below 4G (as 
> > > it
> > > must) but the resulting DMA address (returned by the grant map operation) 
> > > is
> > > much higher.
> > > 
> > > This is analogous to a hardware device which has its view of RAM mapped up
> > > high for some reason.
> > > 
> > > This patch makes I/O to foreign pages (specifically blkif) work on 32-bit 
> > > ARM
> > > systems with more than 4GB of RAM.
> > 
> > There was another patch posted by somebody from Citrix for a fix on 
> > 32-bit x86 dom0 with more than 4GB of RAM (for x86 platforms).
> > 
> > Their fix was in the generic parts of code. Changing most of the 'unsigned'
> > to 'phys_addr_t' or such. Is his patch better or will this patch replace 
> > his?
> 
> I believe they are orthogonal, or at least I'm not (yet) hitting the
> same issue as Stefano P, the alloc cohoerent code paths are not involved
> in the issue I'm seeing because it involves foreign pages whose
> MFN/dma_addr is very high, not DMA to devices which are up high.

Yes, the two issues are orthogonal.
It is worth noting that the problem reported by StefanoP is not fatal:
it should just cause more bouncing on the swiotlb buffer than it is
strictly necessary (dma_mask gets truncated).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel