From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5ckD-0005vD-17 for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:14:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5ckB-0003ZT-SP for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:14:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5ckB-0003ZP-LF for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:14:39 -0400 Message-ID: <4E77322B.2040008@redhat.com> Date: Mon, 19 Sep 2011 15:14:35 +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> In-Reply-To: <4E7640C8.8040600@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/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. > > > > >> > And I > >> > don't want to remove memory_region_set_offset() until everything (that > >> > can potentially use it, at least) has been converted. > >> > >> IMO it's easier to fix those potential users before converting them. You > >> need to review them anyway to decide if an offset might be needed, and > >> which one precisely. > >> > >> Are you aware of any candidates? For PIO, there should be none now. > > > > For pio, none, but mmio has some: > > > > hw/sh7750.c: cpu_register_physical_memory_offset(0x1f000000, 0x1000, > > hw/sh7750.c: cpu_register_physical_memory_offset(0xff000000, 0x1000, > > hw/sh7750.c: cpu_register_physical_memory_offset(0x1f800000, 0x1000, > > hw/sh7750.c: cpu_register_physical_memory_offset(0xff800000, 0x1000, > > hw/sh7750.c: cpu_register_physical_memory_offset(0x1fc00000, 0x1000, > > hw/sh7750.c: cpu_register_physical_memory_offset(0xffc00000, 0x1000, > > hw/sh_intc.c: > > cpu_register_physical_memory_offset(P4ADDR(address), 4, > > hw/sh_intc.c: > > cpu_register_physical_memory_offset(A7ADDR(address), 4, > > Cool, that's all. Trivial to fix, just push the offset math into those > few handler. Then we can drop cpu_register_physical_memory_offset as well. 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. -- error compiling committee.c: too many arguments to function