Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (seen on RV730/RV740 and RS780/RS800)

[Alex Deucher <alexdeucher@xxxxxxxxx>]

On Mon, Oct 5, 2009 at 10:49 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Oct 05, 2009 at 10:41:04AM -0400, Alex Deucher wrote:
>> On Mon, Oct 5, 2009 at 10:01 AM, Konrad Rzeszutek Wilk
>> <konrad.wilk@xxxxxxxxxx> wrote:
>> > On Mon, Oct 05, 2009 at 11:32:31AM +0100, Jan Beulich wrote:
>> >> >>> 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.
>> >
>> > I was chatting with Jeremy about this, and I realized that in some
>> > sense the radeon driver assumes that physical != bus addresses. Which is
>> > OK on x86, but if this card was ever moved to a Sun box it would fail.
>> >
>>
>> FWIW, the radeon drm has been working fine on both sparc and ppc for years.
>
> Thank you for keeping me honest!
>
> I thought that the IOMMU on those boxes would return physical != bus 
> addresses?
> Maybe those days are long gone?
>

Not sure off hand.  I'm not particularly familiar with either arch.

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