From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5d6S-0003Ev-Pr for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:37:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5d6R-00086B-9z for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:37:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5d6R-00085K-0b for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:37:39 -0400 Message-ID: <4E77378E.80204@redhat.com> Date: Mon, 19 Sep 2011 15:37:34 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E75EA08.4090809@web.de> <4E7614CC.4000206@redhat.com> <4E761C66.9010208@web.de> <4E762064.6010108@redhat.com> <4E7640C8.8040600@web.de> <4E77322B.2040008@redhat.com> <4E7735B4.1030903@web.de> In-Reply-To: <4E7735B4.1030903@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] isa: Avoid using obsolete memory_region_set_offset for old portio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Richard Henderson On 09/19/2011 03:29 PM, Jan Kiszka wrote: > On 2011-09-19 14:14, Avi Kivity wrote: > > On 09/18/2011 10:04 PM, Jan Kiszka wrote: > >> > > >> > If you make the core patch add both mr->offset and mrp->offset, then > >> > change isa to drop memory_region_set_offset(), instead adding the > >> delta > >> > to mrp->offset, does that not work out? > >> > >> Nope. The old API accepted arbitrary portio lists per memory region, the > >> new requires one region with a consistent offset per range. I should > >> have documented it... > > > > What does "a consistent offset per range" mean? You aren't actually > > changing the caller's ranges. > > I'm changing the way isa_register_portio_1 registers portios with the > core: only one per offset. The new commit log says: > > "This implies that MemoryRegionPortio::offset is no longer used as > offset within the memory region but just as a correction value for the > offset passed to legacy handlers that expect absolute port addresses." Ah: - /* If we see a hole, break the region. */ + /* If we see a new offset, break the region. */ But, sorry for being slow, I don't see why it requires a core update (other for adding mrp->offset). > > > They all use the same handler, so you need to split e.g. > > sh7750_io_memory into six MemoryRegionsOps. Or use tricks with aliases - > > have one giant 4G region with one handler, and map six 4k aliases into > > the system address space. > > Looks more like 3 regions with one alias each. But we likely need to > disentangle all that logic first. I would be surprised if there wasn't a > more readable way to express it via the memory API. > Depends if you subscribe to the "blindly make it work exactly the same way" or "understand the details and rewrite it cleanly" brands of masochism. -- error compiling committee.c: too many arguments to function