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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

> 
> 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