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

[Stefano Panella <stefano.panella@citrix.com>]

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.