From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN2Dd-0006R2-LA for qemu-devel@nongnu.org; Thu, 19 May 2011 08:20:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN2Dc-0001oR-J1 for qemu-devel@nongnu.org; Thu, 19 May 2011 08:20:45 -0400 Received: from david.siemens.de ([192.35.17.14]:23623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN2Dc-0001fY-6V for qemu-devel@nongnu.org; Thu, 19 May 2011 08:20:44 -0400 Message-ID: <4DD50B17.7000205@siemens.com> Date: Thu, 19 May 2011 14:20:39 +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> In-Reply-To: <4DD505C4.6010604@redhat.com> 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: Avi Kivity Cc: qemu-devel , Gleb Natapov On 2011-05-19 13:57, Avi Kivity wrote: > On 05/19/2011 02:54 PM, Gleb Natapov wrote: >>> >>> In this case the device would call a chipset function, passing the >>> memory region as a parameter, and the chipset would call >>> m_r_add_subregion(). >> But then chipset can resolve all overlapping by itself and register only >> regions that are actually accessible by a guest software. > > Sure it can (and it does now), but it's hard. This API centralizes the > logic, leaving the devices/chipsets to specify what they want. > > For a PC, we have at least two such cases, the ISA bus and the PCI bus. > >> Also there are >> devices that on some architectures are accessed through a chipset and on >> other they resides directly on a system bus. If they will need to call >> different memory registration api depending on how they are instantiated >> the code can become messy. > > An example is ne2000-isa and ne2000-pci. There's no getting around some > glue logic, but I think this API minimizes it (you can declare > everything about your memory region in common code, the only thing that > is different is registration). If devices register against the corresponding qbus (I expect we'll have multiple ones in the future), not even that need to be different. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux