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

[Avi Kivity]

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