From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxGvY-0000BQ-TU for qemu-devel@nongnu.org; Thu, 11 Jul 2013 09:28:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxGvX-0003li-GW for qemu-devel@nongnu.org; Thu, 11 Jul 2013 09:28:56 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alexander Graf In-Reply-To: <3FAA7DE1-06A0-45C5-885C-0433BCC0CFE8@suse.de> Date: Thu, 11 Jul 2013 15:28:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D205309-1154-4730-902E-BF07F5D3B4EB@suse.de> References: <51C75FA6.6080903@reactos.org> <51C7E21A.9090005@web.de> <8A36D64D-0625-49E1-9E59-391DAEEBD1FC@suse.de> <51DEA91B.40903@suse.de> <3FAA7DE1-06A0-45C5-885C-0433BCC0CFE8@suse.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: =?iso-8859-1?Q?Andreas_F=E4rber?= Cc: Liu Ping Fan , Jan Kiszka , qemu-devel Developers , "qemu-ppc@nongnu.org list:PowerPC" , Paolo Bonzini , =?iso-8859-1?Q?Herv=E9_Poussineau?= On 11.07.2013, at 14:48, Alexander Graf wrote: >=20 > On 11.07.2013, at 14:46, Andreas F=E4rber wrote: >=20 >> Am 11.07.2013 14:34, schrieb Alexander Graf: >>>=20 >>> On 11.07.2013, at 14:29, Alexander Graf wrote: >>>=20 >>>>=20 >>>> On 24.06.2013, at 08:07, Jan Kiszka wrote: >>>>=20 >>>>> 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. >>>>=20 >>>> This patch breaks VGA on PPC as it is in master today. >>>=20 >>> If I don't mark portio as little endian it works as expected. = There's probably someone swapping things twice. >>=20 >> sPAPR has its MemoryRegion marked Little Endian: >=20 > sPAPR works, it's only the Mac machines that break. So IIUC before cpu_inw and inl were doing portio accesses in host native = endianness. Now with this change they do little endian accesses. All = sensible callers of cpu_inX assume that data is passed in native = endianness though and already do the little endian conversion = themselves. Semantically having your PCI host bridge do the endianness conversion is = the correct way of handling it, as that's where the conversion happens. = If it makes life easier to do it in the isa bridging code, that's fine = for me too though. But then we'll have to get rid of all endianness = swaps that already happen in PCI bridges. Alex