From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Panella Subject: Re: [PATCH] xen: swiotlb: handle sizeof(dma_addr_t) != sizeof(phys_addr_t) Date: Wed, 22 Jan 2014 14:47:54 +0000 Message-ID: <52DFDA1A.6000009@citrix.com> References: <1389979493-22670-1-git-send-email-ian.campbell@citrix.com> <20140121220355.GA6557@phenom.dumpdata.com> <1390384248.32519.30.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel@lists.xen.org, Ian Campbell List-Id: xen-devel@lists.xenproject.org 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.