Re: [Qemu-devel] [sneak preview] major scsi overhaul

[Avi Kivity <avi@redhat.com>]

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