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.
The patch here thwarts this by allocating memory from the IOMMU, so that
even if bus != physical address from pci_map_page, that is OK.
Another way to make this work right is to modify the drivers
that use vmalloc_32, with pci_map_[sg|page], is for them to check if the
physical
!= bus address, and if so, remap the virtual address (page_to_vmalloc) to
point to the new bus addresses (and free the "old" page). Obviously this
requires some book-keeping, but it does fix those drivers if they were to move
to
non-x86 architecture. Or on machines where the IOMMU hands out non-physical
addresses.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home