From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1rd-0005yQ-LG for qemu-devel@nongnu.org; Thu, 19 May 2011 07:58:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1rc-0006Br-L7 for qemu-devel@nongnu.org; Thu, 19 May 2011 07:58:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1rc-0006Bn-BI for qemu-devel@nongnu.org; Thu, 19 May 2011 07:58:00 -0400 Message-ID: <4DD505C4.6010604@redhat.com> Date: Thu, 19 May 2011 14:57:56 +0300 From: Avi Kivity 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> In-Reply-To: <20110519115405.GG28399@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , qemu-devel 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). -- error compiling committee.c: too many arguments to function