From: David Vrabel <email@example.com> To: Stefano Panella <firstname.lastname@example.org> Cc: David Vrabel <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Konrad Rzeszutek Wilk <firstname.lastname@example.org> Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in xen_swiotlb_alloc_coherent. Date: Tue, 4 Sep 2012 17:44:46 +0100 [thread overview] Message-ID: <50462FFE.email@example.com> (raw) In-Reply-To: <50461A59.firstname.lastname@example.org> 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. David
next prev parent reply other threads:[~2012-09-04 16:44 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 [this message] 2012-09-04 16:40 ` Konrad Rzeszutek Wilk 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=50462FFE.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).