From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN4DN-0000kP-Rg for qemu-devel@nongnu.org; Thu, 19 May 2011 10:28:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN4DM-000861-Px for qemu-devel@nongnu.org; Thu, 19 May 2011 10:28:37 -0400 Received: from goliath.siemens.de ([192.35.17.28]:19439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN4DM-00085s-ER for qemu-devel@nongnu.org; Thu, 19 May 2011 10:28:36 -0400 Message-ID: <4DD52910.4080106@siemens.com> Date: Thu, 19 May 2011 16:28:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E47F.9060104@redhat.com> <4DD3E782.8090208@siemens.com> <4DD3E8D6.6090807@redhat.com> <20110519090851.GD28399@redhat.com> <4DD4DE8E.8030402@redhat.com> <20110519091404.GE28399@redhat.com> <4DD5029D.6000700@redhat.com> <20110519115405.GG28399@redhat.com> <4DD505C4.6010604@redhat.com> <4DD50B17.7000205@siemens.com> <4DD511FB.3080901@redhat.com> <4DD51413.1050202@siemens.com> <4DD51468.7050509@redhat.com> <4DD51531.7000701@siemens.com> <4DD515F9.1020902@redhat.com> <4DD51A82.7060205@siemens.com> <4DD51B64.8000306@redhat.com> <4DD51FDA.3010107@codemonkey.ws> <4DD520ED.8010606@redhat.com> <4DD5260A.1080309@codemonkey.ws> <4DD5272F.5000003@siemens.com> <4DD52848.6030102@codemonkey.ws> In-Reply-To: <4DD52848.6030102@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Avi Kivity , Gleb Natapov , qemu-devel On 2011-05-19 16:25, Anthony Liguori wrote: > On 05/19/2011 09:20 AM, Jan Kiszka wrote: >> On 2011-05-19 16:15, Anthony Liguori wrote: >>> On 05/19/2011 08:53 AM, Avi Kivity wrote: >>>> On 05/19/2011 04:49 PM, Anthony Liguori wrote: >>>>> On 05/19/2011 08:30 AM, Avi Kivity wrote: >>>>>> On 05/19/2011 04:26 PM, Jan Kiszka wrote: >>>>>>> On 2011-05-19 15:07, Avi Kivity wrote: >>>>> >>>>>>> And when introducing hierarchical registration, we will have to go >>>>>>> through all of this once again. Plus the API may have to be changed >>>>>>> again if it does not fulfill all requirements of the hierarchical >>>>>>> region >>>>>>> management. And we have no proof that it allows an efficient core >>>>>>> implementation. >>>>>> >>>>>> This API *is* hierarchical registration. v2 will (hopefully) prove that >>>>>> it can be done efficiently. >>>>> >>>>> We also need hierarchical dispatch. Priorities are just a weak attempt >>>>> to emulate hierarchical dispatch but I don't think there's an >>>>> improvement over a single dispatch table. >>>>> >>>>> Hierarchical dispatch is simpler. You just need a simple list at each >>>>> bus. >>>>> >>>> >>>> The API itself says nothing about whether the hierarchy is evaluated at >>>> run-time or registration time. >>> >>> Except for priorities. >>> >>> If you've got a hierarchy like: >>> >>> - CPU:0 >>> - i440fx:1 >>> - PIIX3:2 >>> - ISA:3 >>> - DeviceA >>> - PCI:2 >>> - DeviceB >>> >>> In your model, the default priorities are as shown, but nothing stops >>> DeviceB from registering with a priority of 0 which means it can >>> intercept accesses that would normally go to the i440fx. >> >> Priorities would be local, so the normal tree would look like this: >> >> - CPU:0 >> - i440fx:0 >> - PIIX3:0 >> - DeviceA >> - PCI-DeviceB:0 >> >> If the i440fx would like to map something different over DeviceA (or >> parts of it), it would create a region of prio 1 or higher. > > If it's local, then you need a local dispatch table, no? Not working for the coalescing reason pointed out before. It's also more handy to rely on the core to do the proper dispatching then write your own logic over and over again. The core has to deal with overlapping anyway. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux