Re: x86 swiotlb questions

[Keir Fraser <keir@xensource.com>]

On 15/12/06 12:50, "Jan Beulich" <jbeulich@novell.com> 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