| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: ATI radeon fails with "iommu=soft swiotlb=force" (s
On 10/05/09 03:32, Jan Beulich wrote:
> 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.
>
vmalloc_32 is a general problem. The only clean way I can see to make
it work under Xen is to make sure all the pages in the DMA32 zone are
really under 4G in machine addresses. But that doesn't scale very well
if you have more than one domain wanting to use vmalloc_32 for hardware
access (or a few small domains).
I'm wondering if the "proper" fix is to introduce a vmalloc_dma() call
which allocates the pages with the proper DMA API calls them maps them
together in the vmalloc space, and then start migrating drivers over to
this new API (ie as needed when people report Xen problems). That would
be more generally correct, but perhaps it would be a bit more cumbersome
because it would have to return both the vaddr of the vmapping, and the
dma_addr_t array, so that vfree_dma() can make the proper
dma_free_coherent calls.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home