From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzrTT-0006rn-M6 for qemu-devel@nongnu.org; Fri, 01 May 2009 08:04:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzrTO-0006ko-Vu for qemu-devel@nongnu.org; Fri, 01 May 2009 08:04:15 -0400 Received: from [199.232.76.173] (port=43533 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzrTO-0006kY-PB for qemu-devel@nongnu.org; Fri, 01 May 2009 08:04:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:65358) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LzrTO-0002qo-D5 for qemu-devel@nongnu.org; Fri, 01 May 2009 08:04:10 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzrTN-0002rA-9q for qemu-devel@nongnu.org; Fri, 01 May 2009 08:04:09 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7 Date: Fri, 1 May 2009 13:03:50 +0100 References: <49EDB109.5010009@earthlink.net> In-Reply-To: <49EDB109.5010009@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905011303.50885.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Robert Reif > The old array function call is supported so no existing drivers need > to be modified. They can continue to do 2 32 bit accesses because 2 > helper functions have been added to break up the accesses automatically. > However, the helper functions should only be used until all drivers are > converted to use the structure and then can be removed along > with the old array functions api. The replacement of the arrays with > structures in the drivers is very straightforward for drivers that don't > do 64 bit I/O and the few that do can be cleaned up to remove the > work arounds for the lack of true 64 bit I/O by their maintainers. This is going to be a bit of a pain, and a lot of duplication. My expectat= ion=20 is that most devices don't know/care about 64-bit accesses and want them to= =20 be automatically split into a pair of 32-bit accesses. I suggest pushing th= is=20 down into the lower level dispatch routines. By my reading your mem_writeq= =20 helpers are broken if we happen to have multiple regions with the same opaq= ue=20 value (this effects at least lsi53c895a.c). In the interests of avoiding duplication, I'd also implement=20 cpu_register_io_memory in terms of cpu_register_io_memory64. > + =A0 =A0return ((CPUReadMemoryFunc64*)(*mmio->mem_read[idx][3])) > (mmio->opaque[idx][0][3], addr + mmio->region_offset[idx][0][3]); Eww. It would be a good idea to fix this at the same time. Paul