From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7TuN-0000LJ-De for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:03:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7TuJ-0000Kx-Ks for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:03:47 -0500 Received: from [199.232.76.173] (port=35898 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7TuJ-0000Kl-Dn for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:03:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60360) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7TuI-0006AF-Ml for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:03:42 -0500 Message-ID: <4AF81329.5030904@redhat.com> Date: Mon, 09 Nov 2009 14:03:37 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <4AF7DC02.2070308@redhat.com> <4AF80CFF.1090607@redhat.com> In-Reply-To: <4AF80CFF.1090607@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: Avi Kivity Cc: Blue Swirl , "qemu-devel@nongnu.org" On 11/09/09 13:37, Avi Kivity wrote: > On 11/09/2009 11:08 AM, Gerd Hoffmann wrote: >> 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) Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this aequivalent to the next option from the scsi point of view), or scsi-disk would have to support both formats. > - making QEMUSGList always use 64-bit addresses since it will almost > always be used with devices (which are often 64-bit capable) Possible. > - making target_phys_addr_t always 64-bit (which loses some performance > with 32-on-32 emulation) Possible too. Has the advantage that more code can be compiled only once, often target_phys_addr_t is the only reason a source file is in Makefile.hw instead of Makefile. Question is how big the performance hit actually is and whenever we are willing to accept that or not ... cheers, Gerd