archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <>
To: David Vrabel <>
Cc: Stefano Panella <>,
	"" <>,
	"" <>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc_coherent.
Date: Tue, 4 Sep 2012 12:40:28 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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
 * 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>");

static int __init dump_dma_init(void)
	return 0;

static void __exit dump_dma_exit(void)

> David

  reply	other threads:[~2012-09-04 16:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-31  9:57 [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc_coherent Stefano Panella
2012-08-31 12:47 ` [Xen-devel] " David Vrabel
2012-08-31 16:40   ` Konrad Rzeszutek Wilk
2012-09-04 14:07     ` Stefano Panella
2012-09-04 14:37       ` Konrad Rzeszutek Wilk
2012-09-04 14:55         ` David Vrabel
2012-09-04 15:12           ` Stefano Panella
2012-09-04 16:44             ` David Vrabel
2012-09-04 16:40               ` Konrad Rzeszutek Wilk [this message]
2012-09-05 13:13                 ` Stefano Panella
2012-09-05 14:33       ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).