From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMihj-0004Iq-1j for qemu-devel@nongnu.org; Wed, 18 May 2011 11:30:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMihh-0007dx-Sh for qemu-devel@nongnu.org; Wed, 18 May 2011 11:30:31 -0400 Received: from david.siemens.de ([192.35.17.14]:20610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMihh-0007dj-I0 for qemu-devel@nongnu.org; Wed, 18 May 2011 11:30:29 -0400 Message-ID: <4DD3E610.1080201@siemens.com> Date: Wed, 18 May 2011 17:30:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Avi Kivity , qemu-devel On 2011-05-18 17:17, Peter Maydell wrote: > On 18 May 2011 16:11, Jan Kiszka wrote: >> On 2011-05-18 16:36, Avi Kivity wrote: >>> There is nothing we can do with a return code. You can't fail an mmio >>> that causes overlapping physical memory map. >> >> We must fail such requests to make progress with the API. That may >> happen either on caller side or in cpu_register_memory_region itself >> (hwerror). Otherwise the new API will just be a shiny new facade for on >> old and still fragile building. > > If we don't allow overlapping regions, then how do you implement > things like "on startup board maps ROM into lower addresses > over top of devices, but later it is unmapped and you can see > the underlying devices" ? (You can't currently do this AFAIK, > and it would be nice if the new API supported it.) Right, we can't do this properly, and that's why the attempt if the i440fx chipset model is so horribly broken ATM. Just allowing overlapping does not solve this problem either. It does not specify what region is on top and what is below (even worse if multiple regions overlap at the place). We need some managing instance here, and that is e.g. the chipset that provide control over the overlap in reality. It could hook up a PhysMemClient to receive and redirect updates to subregions, or only allow to register them in disabled state. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux