From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN2Eg-0007sD-PF for qemu-devel@nongnu.org; Thu, 19 May 2011 08:21:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN2Ef-0002Ed-Dn for qemu-devel@nongnu.org; Thu, 19 May 2011 08:21:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN2Ef-0002EW-0n for qemu-devel@nongnu.org; Thu, 19 May 2011 08:21:49 -0400 Date: Thu, 19 May 2011 15:21:47 +0300 From: Gleb Natapov Message-ID: <20110519122147.GI28399@redhat.com> References: <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> <4DD5059B.3070907@siemens.com> <20110519115858.GH28399@redhat.com> <4DD506C1.3040703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD506C1.3040703@redhat.com> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , qemu-devel On Thu, May 19, 2011 at 03:02:09PM +0300, Avi Kivity wrote: > On 05/19/2011 02:58 PM, Gleb Natapov wrote: > >> > >> Devices shall register their regions with the bus. Every device is on > >> some bus, so that's not a problem. And we can then provide registration > >> handlers at bus level that either implement specific logic or just > >> forward the request to the next hierarchy level (default handler). > >> > >Yes, I agree with that. I just don't see the need for "priority" parameter > >in this model. > > Priority allows you to register RAM from 0-EOM and overlay it with > the ROM and VGA windows as necessary. It also allows PCI to > override RAM (or vice versa, however we decide). > > Sure, you can let the caller chop the various regions manually in > the first case, but it's just extra work that can be done in common > code. And it cannot be done at all for the second case, if RAM > overrides PCI (the PCI bus doesn't know how to chop BARs). > In the model described by Jan no device or bus (except system bus) will call memory API directly. Instead each device will call memory registration function of its bus and the bus will call memory registration function of a device that provides the bus and so on up to the system bus (maps nicely to qdev!). Each level knows by itself (and only it really knows!) how to solve the overlapping, but it can't provide meaningful priority to the layer above since only layer above knows what are relative priority between siblings (e.g only chipset knows that it will forward access to particular address to RAM and not PCI, no matter that PCI bus asked for priority 100 and RAM asked for 0). So it boils down to this: since chopping will have to happen at each level of the hierarchy I do not see why the lowest level of the hierarchy should be made special. -- Gleb.