From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5KYx-0003YI-RT for qemu-devel@nongnu.org; Sun, 18 Sep 2011 12:49:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5KYw-0005yF-H2 for qemu-devel@nongnu.org; Sun, 18 Sep 2011 12:49:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5KYw-0005yB-6P for qemu-devel@nongnu.org; Sun, 18 Sep 2011 12:49:50 -0400 Message-ID: <4E76212A.20000@redhat.com> Date: Sun, 18 Sep 2011 19:49:46 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E75E7A4.50702@web.de> <4E75E96E.90101@web.de> <4E761051.9000204@redhat.com> <4E76119F.5040004@web.de> <4E761220.3080707@redhat.com> <4E761C20.4040609@web.de> In-Reply-To: <4E761C20.4040609@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] memory: Fix old portio word accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Richard Henderson On 09/18/2011 07:28 PM, Jan Kiszka wrote: > >> > >> This is PIO, limited by the x86 address space to 16 bit. Will add a > >> comment. > > > > x86 PIO is not limited to 16 bits, just ISA, which memory.c knows > > nothing about. > > Confused address and data, the former is limited 16, the latter can be > 32 as well. But I guess only ISA models made use of the core's split up > service, and that's why QEMU limited itself accordingly. Let's not bury such details in the core. > > > > >> > Why not use access_with_adjusted_size()? > >> > >> Because of different accessor prototypes. > >> > > > > Can be thunked. There is a different issue, a_w_a_s() can use small > > accesses to emulate large ones, but not vice versa. It needs fixing > > anyway. > > > > IIRC, that's a feature: Devices not implementing small accesses tend to > refuse them in reality. I don't think this holds for pci; there the bus always generates 32-bit writes with separate byte enables for each lane. The device need not even be aware of a sub-word access, for reads. -- error compiling committee.c: too many arguments to function