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, Stefano Panella wrote:
> On 01/22/2014 12:11 PM, Stefano Stabellini wrote:
> > 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).
> I agree it is not fatal, but would it be worth not truncating the dma_mask for
> devices capable of using this?
> I was under the impression that the memory returned (<4GB) if we truncate that
> is limited and should be used for PCI devices not capable of 64bit addressing.

Yeah, Linux should certainly not truncate the dma_mask.

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