From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dHK-0005rr-Gw for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:48:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5dHE-0002mz-Tq for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:48:54 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:59616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dHE-0002ml-Go for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:48:48 -0400 Message-ID: <4E773A2D.3010407@web.de> Date: Mon, 19 Sep 2011 14:48:45 +0200 From: Jan Kiszka 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> <4E77378E.80204@redhat.com> In-Reply-To: <4E77378E.80204@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7DBBC074C3F097E79DF66AF7" Sender: jan.kiszka@web.de 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: Avi Kivity Cc: qemu-devel , Richard Henderson This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7DBBC074C3F097E79DF66AF7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-09-19 14:37, Avi Kivity wrote: > 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 shou= ld >> >> have documented it... >> > >> > What does "a consistent offset per range" mean? You aren't actuall= y >> > 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."= >=20 >=20 > Ah: >=20 > - /* If we see a hole, break the region. */ > + /* If we see a new offset, break the region. */ >=20 >=20 > But, sorry for being slow, I don't see why it requires a core update > (other for adding mrp->offset). So far we matched accesses in find_portio by considering the portio offset as well. If we want to replace the region offset with the portio one (which confines legacy to a legacy-only place), we need to make the portio offset a pure correction value on handler invocation and exclude it from any range matching. And that means an old_portio memory region can only describe one range starting exactly at MemoryRegion::addr. >=20 >> >> > 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 i= nto >> > 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. >> >=20 > 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. We generally used to convert from APIv to APIv by adding legacy wrappers, rarely removing any of them. This doesn't scale, but - granted - it requires some masochism to make progress. Jan --------------enig7DBBC074C3F097E79DF66AF7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk53Oi0ACgkQitSsb3rl5xRuEgCaA+/TcHY7T8/+7YV5TBPyCuqt fcsAoIAyh2nItjKqLgdIZZz5KLU/2CCC =F4N7 -----END PGP SIGNATURE----- --------------enig7DBBC074C3F097E79DF66AF7--