From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxG0R-0000jQ-OT for qemu-devel@nongnu.org; Thu, 11 Jul 2013 08:29:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxG0Q-0000X6-F2 for qemu-devel@nongnu.org; Thu, 11 Jul 2013 08:29:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43076 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxG0Q-0000X0-4J for qemu-devel@nongnu.org; Thu, 11 Jul 2013 08:29:54 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alexander Graf In-Reply-To: <51C7E21A.9090005@web.de> Date: Thu, 11 Jul 2013 14:29:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A36D64D-0625-49E1-9E59-391DAEEBD1FC@suse.de> References: <51C75FA6.6080903@reactos.org> <51C7E21A.9090005@web.de> Subject: Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , Liu Ping Fan , =?iso-8859-1?Q?Herv=E9_Poussineau?= , qemu-devel , =?iso-8859-1?Q?Andreas_F=E4rber?= On 24.06.2013, at 08:07, Jan Kiszka wrote: > On 2013-06-23 22:50, Herv=E9 Poussineau wrote: >> Jan Kiszka a =E9crit : >>> From: Jan Kiszka >>>=20 >>> The current ioport dispatcher is a complex beast, mostly due to the >>> need to deal with old portio interface users. But we can overcome it >>> without converting all portio users by embedding the required base >>> address of a MemoryRegionPortio access into that data structure. = That >>> removes the need to have the additional MemoryRegionIORange = structure >>> in the loop on every access. >>>=20 >>> To handle old portio memory ops, we simply install dispatching = handlers >>> for portio memory regions when registering them with the memory = core. >>> This removes the need for the old_portio field. >>>=20 >>> We can drop the additional aliasing of ioport regions and also the >>> special address space listener. cpu_in and cpu_out now simply call >>> address_space_read/write. And we can concentrate portio handling in = a >>> single source file. >>>=20 >>> Signed-off-by: Jan Kiszka >>> --- >>=20 >> ... >>=20 >>> + >>> +static void portio_write(void *opaque, hwaddr addr, uint64_t data, >>> + unsigned size) >>> +{ >>> + MemoryRegionPortioList *mrpio =3D opaque; >>> + const MemoryRegionPortio *mrp =3D find_portio(mrpio, addr, = size, >>> true); >>> + >>> + if (mrp) { >>> + mrp->write(mrpio->portio_opaque, mrp->base + addr, data); >>> + } else if (size =3D=3D 2) { >>> + mrp =3D find_portio(mrpio, addr, 1, true); >>> + assert(mrp); >>> + mrp->write(mrpio->portio_opaque, mrp->base + addr, data & = 0xff); >>> + mrp->write(mrpio->portio_opaque, mrp->base + addr + 1, data >>>>> 8); >>> + } >>> +} >>> + >>> +static const MemoryRegionOps portio_ops =3D { >>> + .read =3D portio_read, >>> + .write =3D portio_write, >>> + .valid.unaligned =3D true, >>> + .impl.unaligned =3D true, >>> +}; >>> + >>=20 >> You need to mark these operations as DEVICE_LITTLE_ENDIAN. >> In portio_write above, you clearly assume that data is in LE format. >=20 > Anything behind PIO is little endian, of course. Will add this. This patch breaks VGA on PPC as it is in master today. Alex >=20 >>=20 >> This fixes PPC PReP emulation, which would otherwise be broken with = this >> patchset. >=20 > Thanks, > Jan >=20 >=20