From owner-freebsd-arch Mon Feb 5 14:51:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9DADF37B67D; Mon, 5 Feb 2001 14:50:59 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA05261; Mon, 5 Feb 2001 14:50:07 -0800 Date: Mon, 5 Feb 2001 14:50:04 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Chuck Paterson Cc: "Justin T. Gibbs" , Poul-Henning Kamp , Alfred Perlstein , Randell Jesup , Matt Dillon , Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: <200102052234.f15MYfW96817@grendel.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Feb 2001, Chuck Paterson wrote: > In the discussions I noticed someone mentioned some > of the issues with architectures like Sparc. I haven't noticed > anyone discuss the need to deal with the limited DVMA space. You > really need to have some reservation policy on the buffer before > you send them down to a driver, or at least have the > driver do a call to get a reservatioin commitment before > actually doing the map ins. If not you could have problems > like two drivers trying to map there io buffer, both having them > half mapped and unable to get the resouces to finish the mapping. True enough- but this is true for a single process that needs to map more than any specific limited resource- so it isn't just two processes getting deadlocked. That's specifically why a 'mapping window' approach was added to the Solaris DDI DMA model- this allowed one to do a dma transfer for darn near all of physical memory as long as you had a device that could shift the mapping window as needed during the transfer (yes, I actually did test it- it was *wierd* doing 28MB 'single' dma transfers on a Sparc2). From a more or less practical point of view, the newer Ultra machines have a programmable iommu that allows you to pretty much map up to a gig of memory. Then it becomes a very very interesting dance using full, uh, 36 bit I think, physical address and some undefined stuff about I/O coherencey in that case. I'll assert that FreeBSD, should it do a sparc port, shouldn't have the slightest interest in anything less than this class of machines. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message