From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: x86 swiotlb questions Date: Tue, 19 Dec 2006 14:39:58 +0000 Message-ID: <458807CE.76E4.0078.0@novell.com> References: <4587EDA3.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 19.12.06 15:14 >>> >On 19/12/06 12:48, "Jan Beulich" wrote: > >>> Do we merge okay with lib/swiotlb.c then? >> >> Not yet - because of the highmem handling needed for i386. I wonder, however, >> how native Linux gets away with not handling this through swiotlb, and why >> nevertheless Xen needs to special case this. Any ideas? > >Probably because GFP_KERNEL and GFP_DMA allocations are guaranteed to be >DMAable by 30-bit-capable devices on native, but not on Xen. Not sure I understand your thinking here. Nothing prevents user pages (or anything else that I/O may happen against) to come from highmem, hence the bounce logic in mm/highmem.c needs to control this anyway (as I understand it). And since all we're talking about here are physical addresses (and their translations to virtual ones), I would rather conclude that we'll never see a page in the I/O path that page_address() would return NULL for, but if that's the case, then there's no need to kmap such pages or to favor page_to_bus() over virt_to_bus(page_address()). Jan