From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JASg9-0001oq-8W for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:12:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JASg7-0001mi-DJ for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:12:20 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JASg7-0001ma-7k for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:12:19 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JASg6-0005CX-RB for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:12:19 -0500 From: Paul Brook Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c Date: Thu, 3 Jan 2008 16:12:14 +0000 References: <200801030118.59970.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801031612.14804.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On Thursday 03 January 2008, Blue Swirl wrote: > On 1/3/08, Paul Brook wrote: > > On Wednesday 02 January 2008, Blue Swirl wrote: > > > On 1/2/08, Paul Brook wrote: > > > > > Also the opaque parameter may need to be different for each > > > > > function, it just didn't matter for the unassigned memory case. > > > > > > > > Do you really have systems where independent devices need to respond > > > > to different sized accesses to the same address? > > > > > > I don't think so. But one day unassigned or even normal RAM memory > > > access may need an opaque parameter, so passing the device's opaque to > > > unassigned memory handler is wrong. > > > > I'm not convinced. Your current implementation seems to introduce an > > extra level of indirection without any plausible benefit. > > > > If you're treating unassigned memory differently it needs to be handled > > much earlier that so you can raise CPU exceptions. > > Earlier, where's that? Probably when populating the TLB entry. IIRC by the time we get to the IO callbacks we don't have enough information to generate a CPU exception. > Another approach could be conditional stacked handlers, where a higher > level handler could pass the access request to lower one (possibly > modifying it in flight) or handle completely. Maybe this solves the > longstanding generic DMA issue if taken to the device to memory > direction. I'm not so sure. RAM is special because it's direct mapped by the TLB rather than going through the (much slower) MMIO handling routines. Paul