From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: x86 swiotlb questions Date: Tue, 19 Dec 2006 14:46:41 +0000 Message-ID: References: <458807CE.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: <458807CE.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org One thing is we change the value of PCI_BUS_IS_PHYS (or some similar macro which I can't quite remember the name of) which I believe turns off some bounce-buffer logic contained within the block-device subsystem. So that will mean that we get highmem requests hitting the DMA interfaces, where on native they would have got filtered earlier by the highmem/lowmem bounce buffer logic that is specific to block-device requests. Obviously we want to turn off that lowmem/highmem bounce buffer logic on Xen as it is nonsense when there is no direct correspondence to low/high machine addresses. -- Keir On 19/12/06 14:39, "Jan Beulich" wrote: >>> 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()).