From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JATK9-0001PI-TB for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:53:41 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JATK9-0001PA-6a for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:53:41 -0500 Received: from mx1.polytechnique.org ([129.104.30.34]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JATK8-0006fv-SZ for qemu-devel@nongnu.org; Thu, 03 Jan 2008 11:53:41 -0500 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id F04823317E for ; Thu, 3 Jan 2008 17:53:29 +0100 (CET) Message-ID: <477D1309.6000200@bellard.org> Date: Thu, 03 Jan 2008 17:53:29 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c References: <200801021718.06316.paul@codesourcery.com> <200801030118.59970.paul@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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? > > 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. As I said earlier, the only correct way to handle memory accesses is to be able to consider a memory range and its associated I/O callbacks as an object which can be installed _and_ removed. It implies that there is a priority system close to what you described. It is essential to correct long standing PCI bugs for example. Regards, Fabrice.