From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: x86 swiotlb questions Date: Fri, 22 Dec 2006 16:20:28 +0000 Message-ID: <458C13DC.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Herbert Xu List-Id: xen-devel@lists.xenproject.org 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. Jan