From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7TUv-0007Pa-Ht for qemu-devel@nongnu.org; Mon, 09 Nov 2009 07:37:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7TUq-0007Ku-Pr for qemu-devel@nongnu.org; Mon, 09 Nov 2009 07:37:28 -0500 Received: from [199.232.76.173] (port=35593 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7TUq-0007Km-GF for qemu-devel@nongnu.org; Mon, 09 Nov 2009 07:37:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9266) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7TUq-0001ex-1Z for qemu-devel@nongnu.org; Mon, 09 Nov 2009 07:37:24 -0500 Message-ID: <4AF80CFF.1090607@redhat.com> Date: Mon, 09 Nov 2009 14:37:19 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <4AF7DC02.2070308@redhat.com> In-Reply-To: <4AF7DC02.2070308@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Blue Swirl , "qemu-devel@nongnu.org" On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: > >> You are also moving the compilation to Makefile.hw, which is not >> exactly an improvement. Is this needed because of the QEMUIOVector >> stuff? > > Almost correct ;) > > It is because of QEMUSGList which drags in a target_phys_addr_t > dependency. As Michael notes, devices have physical address sizes independent of the target platform; a PCI device that supports 64-bit addresses can be plugged into a motherboard that supports 32-bit address bus processors. We can fix this in several ways: - creating QEMUSG64List and QEMUSG32List (and typedefing PCISGList to the former) - making QEMUSGList always use 64-bit addresses since it will almost always be used with devices (which are often 64-bit capable) - making target_phys_addr_t always 64-bit (which loses some performance with 32-on-32 emulation) - others? -- error compiling committee.c: too many arguments to function