linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
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: <20120904164028.GJ23361@phenom.dumpdata.com> (raw)
In-Reply-To: <50462FFE.7070100@citrix.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

  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 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20120904164028.GJ23361@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefano.panella@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --subject='Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc_coherent.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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