[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
Date: Mon, 09 Nov 2009 15:17:36 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

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

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)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]