Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc_coherent.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Sep 04, 2012 at 05:44:46PM +0100, David Vrabel wrote:
> On 04/09/12 16:12, Stefano Panella wrote:
> > On 09/04/2012 03:55 PM, David Vrabel wrote:
> >> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> >>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
> >>>> dma_mask will
> >>>> be u64 set to 0xffffffffffffffff even if we set it to
> >>>> DMA_BIT_MASK(32) previously.
> >>> That is what I was missing. Let me include that in the git commit and
> >>> also
> >>> put this patch on the stable tree.
> >> Note that this appears to be a work around for a bug in the sound system
> >> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
> >> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
> >> truncated it still works.
> >>
> >> David
> > Sorry David, I am not completely sure I understand your argument in
> > favour of a bug in the
> > sound system or Intel HDA device driver. Could you please elaborate more
> > in detail about this?
> 
> The HDA driver claims to support 64-bit DMA addresses, so it should be
> perfectly fine for the Xen DMA mapping/allocation functions to return
> DMA addresses > 4 GiB.  For most devices this seems to work just fine.
> 
> I think that somewhere between the buffer being mapped or allocated and
> the address being programmed into the hardware, the 64-bit dma_addr_t
> value is being truncated to 32 bits giving an invalid DMA address.
> 
> The patch would avoid this by setting the DMA mask to 32-bit and only
> returning DMA address < 4 GiB which can quite happily be stuffed into a
> u32 without losing bits.
> 
> I think it would be useful (without the patch applied) to print the DMA
> addresses returned by the allocate/mapping functions and the address
> programmed into the hardware.  It will be easily to spot if it got
> truncated or not.

Just enable DMA debug API (CONFIG_DEBUG_DMA_API) and use this fancy module:


/*
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License v2.0 as published by
 * the Free Software Foundation
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 */

#include <linux/module.h>
#include <linux/string.h>
#include <linux/types.h>
#include <linux/init.h>
#include <linux/stat.h>
#include <linux/err.h>
#include <linux/ctype.h>
#include <linux/slab.h>
#include <linux/limits.h>
#include <linux/device.h>
#include <linux/pci.h>
#include <linux/blkdev.h>
#include <linux/device.h>

#include <linux/init.h>
#include <linux/mm.h>
#include <linux/fcntl.h>
#include <linux/slab.h>
#include <linux/kmod.h>
#include <linux/major.h>
#include <linux/highmem.h>
#include <linux/blkdev.h>
#include <linux/module.h>
#include <linux/blkpg.h>
#include <linux/buffer_head.h>
#include <linux/mpage.h>
#include <linux/mount.h>
#include <linux/uio.h>
#include <linux/namei.h>
#include <asm/uaccess.h>

#include <linux/pagemap.h>
#include <linux/pagevec.h>

#include <linux/dma-debug.h>

#define DUMP_DMA_FUN  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@virtualiron>");
MODULE_DESCRIPTION("dump dma");
MODULE_LICENSE("GPL");
MODULE_VERSION(DUMP_DMA_FUN);

static int __init dump_dma_init(void)
{
	debug_dma_dump_mappings(NULL);
	return 0;
}

static void __exit dump_dma_exit(void)
{
}

module_init(dump_dma_init);
module_exit(dump_dma_exit);
> 
> David