From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7U7t-0005Hy-JH for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:17:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7U7o-0005CQ-Lj for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:17:45 -0500 Received: from [199.232.76.173] (port=33696 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7U7o-0005CC-Hr for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:17:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62732) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N7U7o-0008N4-5K for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:17:40 -0500 Message-ID: <4AF81670.6040500@redhat.com> Date: Mon, 09 Nov 2009 15:17:36 +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> <4AF80CFF.1090607@redhat.com> <4AF81329.5030904@redhat.com> In-Reply-To: <4AF81329.5030904@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 03:03 PM, Gerd Hoffmann wrote: > 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. A device or device set which is always 64-bit would always use QEMUSG64List. A device which is always 32-bit would use QEMUSG32List. > >> - making QEMUSGList always use 64-bit addresses since it will almost >> always be used with devices (which are often 64-bit capable) > > Possible. This is my preferred option btw. There's no performance impact since actual device emulation will dwarf an 64-bit impact. >> - 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 ... > Probably unmeasurable, but the qemu-devel thread size will be very measurable so not worth it. Note platform-independent devices (like pci) shouldn't depend on target_phys_addr_t anyway; QEMSG64List is one part of this. -- error compiling committee.c: too many arguments to function