[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] x86 swiotlb questions
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@xxxxxxxxxx> 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |