From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UogDL-0008GX-98 for qemu-devel@nongnu.org; Mon, 17 Jun 2013 16:39:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UogDI-0004uI-BD for qemu-devel@nongnu.org; Mon, 17 Jun 2013 16:39:47 -0400 Received: from smtp1-g21.free.fr ([2a01:e0c:1:1599::10]:36776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UogDH-0004tB-P8 for qemu-devel@nongnu.org; Mon, 17 Jun 2013 16:39:44 -0400 Message-ID: <51BF73FD.6070103@reactos.org> Date: Mon, 17 Jun 2013 22:39:25 +0200 From: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= MIME-Version: 1.0 References: <1370713446-9460-1-git-send-email-hpoussin@reactos.org> <51BE01D3.1050709@reactos.org> <51BEBB83.7050207@redhat.com> <51BEBE28.4010004@siemens.com> In-Reply-To: <51BEBE28.4010004@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 0/8] memory: remove old_portio usage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , "qemu-devel@nongnu.org" Jan Kiszka a =C3=A9crit : > On 2013-06-17 09:32, Paolo Bonzini wrote: >> Il 16/06/2013 20:20, Herv=C3=A9 Poussineau ha scritto: >>> Herv=C3=A9 Poussineau a =C3=A9crit : >>>> These proposed patches aim at removing the .old_portio member of >>>> MemoryRegionOps structure, and replacing their usage by .read/.write >>>> handlers. >>> Ping. >> Jan has patches that do something similar, so I was hoping he'd look a= t it. >> >> Jan, are you back from vacation? :) >=20 > Yes, and that is the problem. ;) >=20 >>>From a quick glance, I'm a bit skeptical, Herv=C3=A9, that your patches= are > addressing all corner cases like mine. Did you see > http://thread.gmane.org/gmane.comp.emulators.qemu/210188? >=20 > Jan >=20 My patches are less intrusive than yours, because they are probably less=20 complex. They don't change subpage handling, they don't remove the=20 register_ioport_*, and they don't move ioport handling to memory core. However, my patches do not add a new base address field in MemoryRegion,=20 and also simplify cpu_in/out to be simply a call to=20 address_space_read/write (like yours). I don't really care whatever way is chosen. I'm only interested to be=20 able to put I/O address space into memory space, so I can improve PReP=20 emulation. Herv=C3=A9