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 20:30:45 +0000 Message-ID: <20050728203045.GG4224@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 10:35:06PM +0100, Ian Pratt wrote: > > > > http://www.cl.cam.ac.uk/~iap10/temp/xen-summit-2005-07.ppt > > > > The slides show >4g in green, and i'm pretty sure that's not quite the > > > case until we get bounce buffers or iommu working. > > Keir checked some bounce buffer support in a while back > (dma_map_single). It's largely untested, though. I must have missed this. Unless there is something i'm needing to enable, the problem i've been working on with dma being attempted to high addresses still stands. > * 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. > * AMD would test gart support. Should just work... > > Since the vast majority of server platforms have hardware that is >4GB > DMA capable, it might not actually be such a big deal in practice. The > biggest pain is probably dumb SATA controllers. We definitely need more > test coverage. Right, i'm using a sata drive, it must be dumb. sRp -- Scott Parish Signed-off-by: srparish@us.ibm.com