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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>On Wed, 2014-01-22 at 16:01 -0500, Konrad Rzeszutek Wilk wrote:
>> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> > index 1eac073..b626c79 100644
>> > --- a/drivers/xen/swiotlb-xen.c
>> > +++ b/drivers/xen/swiotlb-xen.c
>> > @@ -77,12 +77,22 @@ static u64 start_dma_addr;
>> >  
>> >  static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
>> >  {
>> > -  return phys_to_machine(XPADDR(paddr)).maddr;
>> 
>> Why not change 'phys_addr_t' to be unsigned long? Wouldn't
>> that solve the problem as well?
>
>It would, but it is fundamentally the wrong thing to do.
>
>If the kernel is configured without LPAE (ARM's PAE extensions) then it
>is configured for a 32-bit physical address space, throughout its page
>table handling and else where. Pretending that physical addresses are
>64-bits would have all sorts of knock on effects both in terms of type
>mismatches and the space used by data structures doubling etc
>
>Enabling LPAE would also solve this issue but we don't want to force
>that constraint onto Xen guests or dom0. Not least because of the knock
>on affect on distro installers etc.
>
>There is nothing fundamentally wrong with 32-bit phys addr with 64-bit
>dma addr and it is the correct solution to this configuration.

Right. 

And I presume dma_addr_t is 64bit regardless of PAE and non-PAE?
 (Sorry I am on my phone and its hard to do SSH and cscope).

Based on your explanation I believe the patch is fine though I have to work out 
carefully the casting it does in my mind.

>
>> 
>> Or make 'xmaddr_t' and 'xpaddr_t' use 'unsigned long' instead
>> of phys_addr_t?
>
>phys_addr_t is unsigned long already, so that won't help. And you don't
>want to expand those for the same reasons you don't want to expand
>phys_addr_t.
>
>Ian.



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