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

[Stefano Panella <stefano.panella@xxxxxxxxxx>]

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.

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