WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] x86 swiotlb questions

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] x86 swiotlb questions
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 19 Dec 2006 14:46:41 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 19 Dec 2006 06:46:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <458807CE.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccjfH6VvVVqBY9vEduUXAAX8io7RQ==
Thread-topic: [Xen-devel] x86 swiotlb questions
User-agent: Microsoft-Entourage/11.2.5.060620
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" <jbeulich@xxxxxxxxxx> 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()).


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel