Re: x86 swiotlb questions

[Keir Fraser <Keir.Fraser@cl.cam.ac.uk>]

Firstly, I think we should wait and see if the patches are acceptable
upstream in their current form before switching to using them.

As for dma_alloc_coherent() -- yes it makes sense to make an allocation
request with the device's specified bit width. And we could be opportunistic
about the bit width we advertise from swiotlb if we happen to get lower
memory than we asked for. *but*:
 1. Our swiotlb is made up of separately allocated strides, so the swiotlb
is not contiguous in machine memory. That needs to be kept in mind when
calculating the bit width as it'll be max over all strides.
 2. Also because of this, the existing swiotlb_dma_supported() cannot work
as is. Firstly it would need to use virt_to_machine(), and even then it
doesn't take into account that the aperture is not contiguous in machine
memory.

And as I said before, dma_bits will disappear from Xen in due course when
the dma pool goes away and is replaced with something more flexible. The
plan is to leave it (or a similarly-named parameter) in Linux, at least as a
guide to the swiotlb pre-allocation (even if no longer used for
dma_alloc_coherent).

 -- Keir

On 22/12/06 4:20 pm, "Jan Beulich" <jbeulich@novell.com> wrote:

> One more thing: Is it really necessary to restrict dma_alloc_coherent() to
> dma_bits?
> I.e., couldn't we, once the bit-level page allocator is merged, use the real
> bit width
> needed for the requesting device here? If not, this would then permit using
> the
> original implementation of swiotlb_dma_supported() (as dma_alloc_coherent()
> then
> no longer depends on dma_bits), and perhaps even auto-setting dma_bits based
> on what memory we can get out of Xen in swiotlb_init(), making the mismatching
> of
> command line options (between Xen and kernel) impossible (the kernel simply
> wouldn't have one anymore).
> 
> As a nice side effect, using the original implementation of
> swiotlb_dma_supported()
> would require slightly less tweaking of lib/swiotlb.c, hence slightly raising
> the
> chances of the changes getting accepted into mainline. And clearly, if the
> kernel
> manages to allocate the swiotlb at an address with less than dma_bits bits,
> there
> seems to be no reason to refuse use of I/O devices that the actual buffer
> fits, but
> dma_bits doesn't.