From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Scott Parish" Subject: Re: Xen 3.0 Status update Date: Thu, 28 Jul 2005 21:43:20 +0000 Message-ID: <20050728214320.GH4224@us.ibm.com> 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 List-Id: xen-devel@lists.xenproject.org On Thu, Jul 28, 2005 at 11:39:46PM +0100, Ian Pratt wrote: > > > > > * Intel would get the standard s/w iommu working (just a case of > > > ensuring we have a machine contiguous aperture beloe 4GB -- > > the Linux > > > code currently uses the boot mem allocator rather than using > > > alloc_coherent, so it will need a little tweaking) > > > > Yeah, i haven't had much luck so far. > > I don't really understand why the aperture is allocated so early. I > suspect its not actually used until the normal bootmem allocator is up. > > The slightly more fundamental problem is that we need a <4GB allocation > zone in Xen, but since allocating the apperture is only currently an > issue for dom0 it won't actually be a problem in practice. (something we > need to address before driver domains come back) I have a patch that introduces zones into xen, and a hypercall to request dmaable memory, which i've made xen_contig_memory() use. 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) If the zones patch would be helpful i could clean it up and post it. sRp -- Scott Parish Signed-off-by: srparish@us.ibm.com