From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlfMv-0002lh-K4 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:00:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlfMr-0003KI-0Q for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:00:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlfMq-0003J1-PD for qemu-devel@nongnu.org; Tue, 26 Jul 2011 07:00:04 -0400 Message-ID: <4E2E9E2E.7050404@redhat.com> Date: Tue, 26 Jul 2011 13:59:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1311602584-23409-1-git-send-email-avi@redhat.com> <1311602584-23409-17-git-send-email-avi@redhat.com> <4E2DC209.9070103@codemonkey.ws> In-Reply-To: <4E2DC209.9070103@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 16/23] ioport: register ranges by byte aligned addresses always List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/25/2011 10:20 PM, Anthony Liguori wrote: > On 07/25/2011 09:02 AM, Avi Kivity wrote: >> The I/O port space is byte addressable, even for word and long accesses. >> >> An example is the VMware svga card, which has long ports on offsets 0, >> 1, and 2. >> >> Signed-off-by: Avi Kivity > > I've always thought this was odd but didn't know of a specific > circumstance where it broke a device. > > This was a big problem with the old API. Devices don't register their > interest in specific sizes. They may ignore certain size accesses but > that's a device specific behavior. In fact there's on counterexample - 440FX consumes dword accesses on port cf8 but forwards byte and word accesses to the PCI bus. This cannot be implemented with the current API (it requires the opaque to be equal for all word sizes). The new API doesn't support it either; if we need to, we can re-issue the access but using the PCI address space instead of the root I/O address space. (of course this is purely theoretical) -- error compiling committee.c: too many arguments to function