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>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] x86 swiotlb questions
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 15 Dec 2006 13:35:55 +0000
Delivery-date: Fri, 15 Dec 2006 05:36:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4582A833.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: AccgTfIeMNoL5IxBEduKHAAX8io7RQ==
Thread-topic: [Xen-devel] x86 swiotlb questions
User-agent: Microsoft-Entourage/11.2.5.060620
On 15/12/06 12:50, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I'm not certain when this code was changed significantly from what I remember,
> but
> 
> - What is the purpose of using alloc_bootmem_low variants here? I.e., where is
> the dependency on physical addresses being below 4G here (machine addresses
are
> being restricted after the allocation anyway)? The panic message text after
> the
> failed allocation is confusing me additionally.

This is how it's always been since we took ia64's swiotlb.c.

> - While I can see the idea behind the overflow buffer, it doesn't seem to
> prevent
> data corruption, and if I understand it correctly it doesn't even prevent
> memory
> corruption (since its machine address doesn't get restricted anywhere, so the
> fall
> back return value would not necessarily meet the device requirements).

Same here. We didn't implement this. It doesn't seem to make that much
sense. Sync'ing with lib/swiotb.c and throwing away our special one would be
very nice. :-)

> - With various parameters now being command line configurable, if any of these
> get set inconsistently or incorrectly the user would probably get a cryptic
> crash
> (from the BUG_ON() following the call to xen_create_contiguous_region()).

True. Best know what you're doing if you mess with these.

> - The default bit width for DMA (also in Xen itself) was now changed to 30,
> just
> because of a single device (b44). Shouldn't it, with the settings being
> customizable now, rather be 32 (and those who own such ill devices need to
> make use of the option)?

Arguable. Depends how common 31- and 30-bit limitations are. Limiting the
swiotlb to 1GB of memory doesn't seem that harsh -- how much swiotlb memory
are you likely to want, system wide?

> - The DMA bit widths can be set to different values in Xen and kernel, which
> can
> lead to surprising results, I would think. Shouldn't the kernel rather obtain
> Xen's
> value, so they are consistent?

We would like to generalise Xen's heap allocator so that it keeps separate
heaps for different bit widths. Then there would be no 'DMA width' or 'DMA
pool' in Xen.

 -- Keir


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