From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7hKe-0001Tb-JA for qemu-devel@nongnu.org; Fri, 09 Aug 2013 03:42:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7hKY-0000wY-Gf for qemu-devel@nongnu.org; Fri, 09 Aug 2013 03:41:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7hKY-0000wJ-8g for qemu-devel@nongnu.org; Fri, 09 Aug 2013 03:41:50 -0400 Message-ID: <52049D1B.1080103@redhat.com> Date: Fri, 09 Aug 2013 09:41:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <51FCBFCD.5020608@web.de> <5203BC8A.8040605@siemens.com> In-Reply-To: <5203BC8A.8040605@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] memory: Provide separate handling of unassigned io ports accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , qemu-devel Il 08/08/2013 17:43, Jan Kiszka ha scritto: > On 2013-08-08 17:33, Peter Maydell wrote: >> On 3 August 2013 09:31, Jan Kiszka wrote: >>> --- a/ioport.c >>> +++ b/ioport.c >>> @@ -44,6 +44,22 @@ typedef struct MemoryRegionPortioList { >>> MemoryRegionPortio ports[]; >>> } MemoryRegionPortioList; >>> >>> +static uint64_t unassigned_io_read(void *opaque, hwaddr addr, unsigned size) >>> +{ >>> + return -1UL; >> >> This should probably be "-1ULL", otherwise we'll return >> different values on 32 bit and 64 bit hosts. (Actually >> managing a 64 bit read of the i/o space is pretty >> unlikely, though possibly alpha memory-mapped via the >> PCI space might let you do it.) > > No problem with changing this - but wouldn't 64-bit i/o accesses be a > bug? It's not allowed according to PCI, no device can handle it > (officially), so no arch should forward such requests from mmio, rather > break them up first. Yes, the impl.max_access_size should never be 8. Though 1ULL would be clearer perhaps. Paolo