WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (se

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 05 Oct 2009 11:32:31 +0100
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 05 Oct 2009 03:32:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AC649B0.5090700@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <41093.83224.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4AC649B0.5090700@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 02.10.09 20:42 >>>
>On 10/02/09 10:23, Boris Derzhavets wrote:
>> Jeremy,
>> Please,  be aware of bugzilla.xensource.com [1519]  the most recent
>> entries :-
>>
>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1519 
>>
>
>Ah, OK.  I pushed a variant of Konrad's patches.  Could you try them out?

Are you really convinced fixing this in DRM is the right thing to do? To
me, the use of vmalloc_32() in drivers/ieee1394/ seems to make similar
assumptions (pci_map_sg() not modifying the buffer addresses), and
who knows where else such assumptions exist. After all, vmalloc_32()
is *defined* to have the property assumed by both of the users, and
other than for most kmalloc() cases using GFP_DMA{,32} we're talking
about double buffering generally large amounts of data here even in
the cases where the DMA API is being used properly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>