From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAVzp-0001CB-Fa for qemu-devel@nongnu.org; Thu, 03 Jan 2008 14:44:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAVzn-0001Af-Gk for qemu-devel@nongnu.org; Thu, 03 Jan 2008 14:44:52 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAVzn-0001AX-88 for qemu-devel@nongnu.org; Thu, 03 Jan 2008 14:44:51 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JAVzm-000093-L1 for qemu-devel@nongnu.org; Thu, 03 Jan 2008 14:44:50 -0500 Received: by nf-out-0910.google.com with SMTP id 30so470021nfu.12 for ; Thu, 03 Jan 2008 11:44:48 -0800 (PST) Message-ID: Date: Thu, 3 Jan 2008 21:44:48 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] qemu cpu-all.h exec.c In-Reply-To: <477D1309.6000200@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801021718.06316.paul@codesourcery.com> <200801030118.59970.paul@codesourcery.com> <477D1309.6000200@bellard.org> 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 On 1/3/08, Fabrice Bellard wrote: > 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. This should be feasible, though raises a few questions. Does this mean another API for stacked registration, or should stacking happen automatically with current API? A new function is needed for removal. What could be the API for setting priorities? How would multiple layers be enabled for multiple devices at same location? How can a higher level handler pass the request to lower one? Do we need a status return for access handler? A few use cases: Partial width device > unassigned ROM > RAM > unassigned SBus controller > EBus controller > Device > unassigned Other direction (for future expansion): Device > DMA controller > SBus controller > IOMMU > RAM > unassigned