On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
> On 31/08/12 10:57, Stefano Panella wrote:
> > When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
> > DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
> >
> > This caused for example not working sound on a system with 4 GB and a 64-bit
> > compatible sound-card with sets the DMA-mask to 64bit.
> >
> > On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a
> > coherent
> > DMA-memory is always allocated inside the 32-bit address-range by calling
> > dma_alloc_coherent_mask.
>
> We should have the same behaviour under Xen as bare metal so:
>
> Acked-By: David Vrabel <david.vra...@citrix.com>
>
> This does limit the DMA mask to 32-bits by passing it through an
> unsigned long, which seems a bit sneaky...
so is the issue that we are not casting it from 'u64' to 'u32'
(unsigned long) on 32-bit?
>
> Presumably the sound card is capable of handling 64 bit physical
> addresses (or it would break under 64-bit kernels) so it's not clear why
> this sound driver requires this restriction.
>
> Is there a bug in the sound driver or sound subsystem where it's
> truncating a dma_addr_t by assigning it to an unsigned long or similar?
>
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
> > size,
> > return ret;
> >
> > if (hwdev && hwdev->coherent_dma_mask)
> > - dma_mask = hwdev->coherent_dma_mask;
> > + dma_mask = dma_alloc_coherent_mask(hwdev, flags);
>
> Suggest
>
> if (hwdev)
> dma_mask = dma_alloc_coherent_mask(hwdev, flags)
Isn't that code just doing this:
atic inline unsigned long dma_alloc_coherent_mask(struct device *dev,
gfp_t gfp)
{
unsigned long dma_mask = 0;
dma_mask = dev->coherent_dma_mask;
if (!dma_mask)
dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) :
DMA_BIT_MASK(32);
return dma_mask;
}
and in our code, the dma_mask by default is DMA_BIT_MASK(32):
u64 dma_mask = DMA_BIT_MASK(32);
So what I am missing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
