[Top][All Lists]

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

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

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
Date: Mon, 09 Nov 2009 14:03:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4

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.

- making QEMUSGList always use 64-bit addresses since it will almost
always be used with devices (which are often 64-bit capable)


- 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 ...


reply via email to

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