[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] linux: GFP_DMA/GFP_DMA32


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 04 Apr 2007 08:11:18 +0100
  • Delivery-date: Wed, 04 Apr 2007 00:09:09 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acd2iHCYrxA9BuJ7EduKZAAWy6hiGQ==
  • Thread-topic: [Xen-devel] linux: GFP_DMA/GFP_DMA32

How many callers rely on GFP_DMA32? We gave up on GFP_DMA because no halfway
modern hardware relies on it and we can't currently satisfy requests for
memory below 16MB anyway.

As for solutions, either we have to hook the memory allocator somehow to get
a call out to allocate memory of the correct type, or callers do indeed need
fixing one by one.

 -- Keir

On 3/4/07 15:34, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> While I have a patch queued to address related issues in intel-agp, a quick
> scan
> of the Linux tree seems to reveal several more cases where assumptions are
> being made on GFP_DMA{,32} allocations - either the result (even properly
> passed through virt_to_bus()) is put into hardware registers (with no
> guarantee that it fits the width required by those registers or fields
> thereof),
> or page-crossing arithmetic is being done (explicitly or implicitly). All this
> is set
> to cause data corruption.
> 
> Are there any ideas, other than either suppressing such components or fixing
> them one by one, how to address this problem?



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.