From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uxj8Q-00040l-SH for qemu-devel@nongnu.org; Fri, 12 Jul 2013 15:36:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uxj8P-0001br-Pc for qemu-devel@nongnu.org; Fri, 12 Jul 2013 15:36:06 -0400 Received: from mail-yh0-f45.google.com ([209.85.213.45]:51450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uxj8P-0001bh-LH for qemu-devel@nongnu.org; Fri, 12 Jul 2013 15:36:05 -0400 Received: by mail-yh0-f45.google.com with SMTP id b20so3853928yha.18 for ; Fri, 12 Jul 2013 12:36:05 -0700 (PDT) From: Anthony Liguori In-Reply-To: <51C75FA6.6080903@reactos.org> References: <51C75FA6.6080903@reactos.org> Date: Fri, 12 Jul 2013 14:36:02 -0500 Message-ID: <87ip0f3719.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: =?utf-8?Q?Herv=C3=A9?= Poussineau , Jan Kiszka Cc: Paolo Bonzini , Liu Ping Fan , qemu-devel , Andreas =?utf-8?Q?F=C3=A4rber?= , Jan Kiszka Herv=C3=A9 Poussineau writes: > Jan Kiszka a =C3=A9crit : >> 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 >> --- > > ... > >> + >> +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, tr= ue); >> + >> + 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, >> +}; >> + > > You need to mark these operations as DEVICE_LITTLE_ENDIAN. > In portio_write above, you clearly assume that data is in LE format. > > This fixes PPC PReP emulation, which would otherwise be broken with this= =20 > patchset. Did you actually test that as this is how the code behaved previously? Regards, Anthony Liguori > > Herv=C3=A9