From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: Xen 3.0 Status update Date: Fri, 29 Jul 2005 14:58:07 +0200 Message-ID: <20050729125807.GA4327@bytesex> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com, Scott Parish List-Id: xen-devel@lists.xenproject.org > However, for the long-lived control regions used by some devices (e.g. > for descriptor rings etc) it probably makes sense to try and allocate > them in memory they can access directly. Some of these have daft > restrictions, such as the aacraid device only being able to use memory > below 2GB for its control program. > Most of these regions are bigger than a page so have to be created with > dma_alloc_coherent, hence we have an opportunity to allocate them in a > region they can directly access. Yep, for the control structures it should be easy to sort as dma_alloc_coherent() must be used for them (Documentation/DMA-mapping.txt is pretty clear here) and so we have a opportunity to hook in and make sure it's DMA-able memory. Linux device drivers can pass a address mask telling the kernel which range the device in question can handle (pci_set_dma_mask), it's probably a good idea to pass that down to xen. That should catch corner cases like the 2G limit on some raid controller mentioned here recently without extra work I think. Gerd -- panic("it works"); /* avoid being flooded with debug messages */