21 messages in com.xensource.lists.xen-develRe: [Xen-devel] Xen 3.0 Status update
FromSent OnAttachments
Ian Pratt27 Jul 2005 16:33 
aq27 Jul 2005 21:28 
Ian Pratt28 Jul 2005 04:52 
Scott Parish28 Jul 2005 13:09 
Scott Parish28 Jul 2005 13:30 
Walker, Bruce J (HP-Labs)28 Jul 2005 14:00 
Ian Pratt28 Jul 2005 14:15 
Ian Pratt28 Jul 2005 14:34 
Scott Parish28 Jul 2005 14:42 
Scott Parish28 Jul 2005 14:55 
Scott Parish28 Jul 2005 14:59 
Ian Pratt28 Jul 2005 15:39 
Mark Williamson28 Jul 2005 15:57 
Ian Pratt28 Jul 2005 16:04 
Ian Pratt28 Jul 2005 16:31 
aq28 Jul 2005 19:30 
Scott Parish28 Jul 2005 19:37.diff
Gerd Knorr29 Jul 2005 02:06 
Keir Fraser29 Jul 2005 03:16 
Ian Pratt29 Jul 2005 04:15 
Gerd Knorr29 Jul 2005 05:57 
Subject:Re: [Xen-devel] Xen 3.0 Status update
From:Gerd Knorr (kra@suse.de)
Date:07/29/2005 02:06:00 AM
List:com.xensource.lists.xen-devel

"Ian Pratt" <m+Ian.@cl.cam.ac.uk> 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 ...

Gerd

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

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