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/
Home Products Support Community News


Re: [Xen-devel] Xen 3.0 Status update

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 3.0 Status update
From: Gerd Knorr <kraxel@xxxxxxx>
Date: 29 Jul 2005 11:06:22 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Scott Parish <srparish@xxxxxxxxxx>
Delivery-date: Fri, 29 Jul 2005 09:08:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D28282C@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: SUSE Labs, Berlin
References: <A95E2296287EAD4EB592B5DEEFCE0E9D28282C@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> writes:

> > Unfortunately, there still seems to be some places where 
> > kmallocs are done for dma buffers. (i tried putting all linux 
> > memory into ZONE_NORMAL and caught a couple of these places)
> Can you give examples? What size are the allocations? Do you know what
> the official position is i.e. is using kmalloc with ZONE_DMA deprecated?

If you do this:

  fd = open("/dev/video0");     // open bttv grabber card
  ioctl(fd, ...);               // configure tvnorm, size, ...
  read(fd, somelargebuf);       // capture a single frame

bttv will try to send the video frame directly to the buffer passed.
Lock pages, kick DMA, wait until finished, unlock pages, done.  And
bttv has no control at all about how these pages are allocated.

DMA memory really can be almost anything.  There is no way around
having a swiotlb-like bounce buffer mechanism hooked into the dma
mapping API as fallback.

At the moment the linux kernel provides no way to hint that you want
to use the specific piece of memory you are asking for for 32-bit PCI
DMA.  ZONE_DMA is historical stuff, 16MB only for ISA DMA IIRC, not
really useful.  Maybe Andy finally finds some time to polish & submit
the ZONE_DMA32 patch.

bttv tries to allocate buffers from ZONE_NORMAL (i.e. avoid highmem)
in case it has control over the allocations, which is far from being
perfect.  Works reliable only on 32 bit, doesn't work on 64-bit
without iommu and >4GB for example ...


panic("it works"); /* avoid being flooded with debug messages */

Xen-devel mailing list