From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5cpJ-0007dS-HE for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:19:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5cpE-0004YY-UV for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:19:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5cpE-0004YT-Ia for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:19:52 -0400 Message-ID: <4E773365.9010008@redhat.com> Date: Mon, 19 Sep 2011 15:19:49 +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> <4E76212A.20000@redhat.com> <4E764185.8020500@web.de> In-Reply-To: <4E764185.8020500@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 10:07 PM, Jan Kiszka wrote: > On 2011-09-18 18:49, Avi Kivity wrote: > > 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. > > It's already in the core (ioport), and would refrain from changing it in > this fix. That's the bad old core we're trying to get away from. > > > > 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. > > The problem is that once we "enhance" the core with such a support to > potentially help one use case, we need to validate all users again if > they depend on the old behavior. That's tricky as breakage may only show > up with odd guests that issue invalid but so far harmless requests. It's opt-in. If a device sets MemoryRegionOps::impl.{min,max}_access_size = 1, it will only be fed byte accesses (the core will take care of breaking apart larger writes). If it sets MemoryRegionOps::impl.{min,max}_access_size = 4, it will only get long accesses (and the core will/should shift/mask or RMW). Refusing illegal access sizes is done using MemoryRegionOps::valid. Most of this is unimplemented unfortunately. -- error compiling committee.c: too many arguments to function