[Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

Hello,

Clean XP install cores with SCSI LSI 53C89A disk when copying files. 
Reproduceable.  Driver used is sym_hi. Details are below.

Tried also old versions 1.0, 0.15.1, cores too.

Any ideas?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/

Image created with:
qemu-img create -f qcow2 XP-TEST.qcow2 10G

Command line:
Version: git b5ed4b6f6f0d31e0d8210f4b444ba67bfa5d6de2
/root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64
-drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0
-cdrom ISO/XP.iso
-boot order=cad,menu=on
-m 2048
-k de
-vga vmware
-vnc :0
-bios /root/download/seabios/git/seabios/out/bios.bin
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
-option-rom BIOS/V4.19/8xx_64.rom
-device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile=
-net tap,ifname=tap1,script=no,downscript=no,vlan=1

################################################################################################################################################################
#0  0x00007f66a29e5117 in malloc_consolidate.part.3 () from /lib64/libc.so.6
#1  0x00007f66a29e5e99 in _int_free () from /lib64/libc.so.6
#2  0x00007f66a64a1444 in scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
#3  scsi_req_unref (req=0x7f66a9791f70) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
#4  0x00007f66a64a2445 in scsi_device_purge_requests (sdev=0x7f66a9616160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
#5  0x00007f66a64a2d27 in scsi_disk_reset (dev=0x7f66a9616160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
#6  0x00007f66a643dd60 in lsi_reg_writeb (s=0x7f66a95fa140, offset=<optimized out>, val=<optimized out>)    at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
#7  0x00007f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecbb0, size=1, access_size_min=<optimized out>,    access_size_max=<optimized out>, access=0x7f66a65186c0 <memory_region_write_accessor>, opaque=0x7f66a95fa5a8)    at /root/download/qemu/git/qemu-kvm/memory.c:304
#8  0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66a95fa5a8) at /root/download/qemu/git/qemu-kvm/memory.c:982
#9  io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
#10 0x00007f66a65187a0 in access_with_adjusted_size (addr=1, value=0x7f669f3ecc60, size=1, access_size_min=<optimized out>,    access_size_max=<optimized out>, access=0x7f66a65186c0 <memory_region_write_accessor>, opaque=0x7f669801bae0)    at /root/download/qemu/git/qemu-kvm/memory.c:304
#11 0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f669801bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982
#12 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
#13 0x00007f66a64efe58 in cpu_physical_memory_rw (addr=4273938433, buf=0x7f66a6319028 <Address 0x7f66a6319028 out of bounds>, len=1, is_write=1)    at /root/download/qemu/git/qemu-kvm/exec.c:3594
#14 0x00007f66a650d195 in kvm_cpu_exec (env=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
#15 0x00007f66a64e3201 in qemu_kvm_cpu_thread_fn (arg=0x7f66a8d52900) at /root/download/qemu/git/qemu-kvm/cpus.c:732
#16 0x00007f66a47bbd90 in start_thread () from /lib64/libpthread.so.0
#17 0x00007f66a2a57f5d in clone () from /lib64/libc.so.6
################################################################################################################################################################
(gdb) back
#0  0x00007f66efb81285 in raise () from /lib64/libc.so.6
#1  0x00007f66efb82b9b in abort () from /lib64/libc.so.6
#2  0x00007f66efbc2a7e in __libc_message () from /lib64/libc.so.6
#3  0x00007f66efbc8da6 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f66efbc9279 in malloc_consolidate.part.3 () from /lib64/libc.so.6
#5  0x00007f66efbc9e99 in _int_free () from /lib64/libc.so.6
#6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
#7  scsi_req_unref (req=0x7f66f6db1bc0) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
#8  0x00007f66f3686445 in scsi_device_purge_requests (sdev=0x7f66f6b8e160, sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
#9  0x00007f66f3686d27 in scsi_disk_reset (dev=0x7f66f6b8e160) at /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
#10 0x00007f66f3621d60 in lsi_reg_writeb (s=0x7f66f6b72140, offset=<optimized out>, val=<optimized out>)    at /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
#11 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1, value=0x7f66ec5d0bb0, size=1, access_size_min=<optimized out>,    access_size_max=<optimized out>, access=0x7f66f36fc6c0 <memory_region_write_accessor>, opaque=0x7f66f6b725a8)    at /root/download/qemu/git/qemu-kvm/memory.c:304
#12 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66f6b725a8) at /root/download/qemu/git/qemu-kvm/memory.c:982
#13 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
#14 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1, value=0x7f66ec5d0c60, size=1, access_size_min=<optimized out>,    access_size_max=<optimized out>, access=0x7f66f36fc6c0 <memory_region_write_accessor>, opaque=0x7f66e401bae0)    at /root/download/qemu/git/qemu-kvm/memory.c:304
#15 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8, addr=1, mr=0x7f66e401bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982
#16 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
#17 0x00007f66f36d3e58 in cpu_physical_memory_rw (addr=4273938433, buf=0x7f66f34fd028 <Address 0x7f66f34fd028 out of bounds>, len=1, is_write=1)    at /root/download/qemu/git/qemu-kvm/exec.c:3594
#18 0x00007f66f36f1195 in kvm_cpu_exec (env=0x7f66f62ca900) at /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
#19 0x00007f66f36c7201 in qemu_kvm_cpu_thread_fn (arg=0x7f66f62ca900) at /root/download/qemu/git/qemu-kvm/cpus.c:732
#20 0x00007f66f199fd90 in start_thread () from /lib64/libpthread.so.0
#21 0x00007f66efc3bf5d in clone () from /lib64/libc.so.6

(gdb) frame 6
#6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at 
/root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
1272                req->ops->free_req(req);
(gdb) print req
$1 = (SCSIRequest *) 0x7f66f6db1bc0
(gdb) print req->ops
$2 = (const SCSIReqOps *) 0x7f66f3b032c0
(gdb) print req->ops->free_req
$3 = (void (*)(SCSIRequest *)) 0x7f66f3688ef0 <scsi_free_request>
(gdb) print req->ops->free_req
################################################################################################################################################################

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

Ping. Any comments?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/


On Sun, 4 Mar 2012, Gerhard Wiesinger wrote:

> Hello,
>
> Clean XP install cores with SCSI LSI 53C89A disk when copying files. 
> Reproduceable.  Driver used is sym_hi. Details are below.
>
> Tried also old versions 1.0, 0.15.1, cores too.
>
> Any ideas?
>
> Thnx.
>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/
>
> Image created with:
> qemu-img create -f qcow2 XP-TEST.qcow2 10G
>
> Command line:
> Version: git b5ed4b6f6f0d31e0d8210f4b444ba67bfa5d6de2
> /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64
> -drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0
> -cdrom ISO/XP.iso
> -boot order=cad,menu=on
> -m 2048
> -k de
> -vga vmware
> -vnc :0
> -bios /root/download/seabios/git/seabios/out/bios.bin
> -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
> -option-rom BIOS/V4.19/8xx_64.rom
> -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile=
> -net tap,ifname=tap1,script=no,downscript=no,vlan=1
>
> ################################################################################################################################################################
> #0  0x00007f66a29e5117 in malloc_consolidate.part.3 () from /lib64/libc.so.6
> #1  0x00007f66a29e5e99 in _int_free () from /lib64/libc.so.6
> #2  0x00007f66a64a1444 in scsi_req_unref (req=0x7f66a9791f70) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
> #3  scsi_req_unref (req=0x7f66a9791f70) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
> #4  0x00007f66a64a2445 in scsi_device_purge_requests (sdev=0x7f66a9616160, 
> sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
> #5  0x00007f66a64a2d27 in scsi_disk_reset (dev=0x7f66a9616160) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
> #6  0x00007f66a643dd60 in lsi_reg_writeb (s=0x7f66a95fa140, offset=<optimized 
> out>, val=<optimized out>)    at 
> /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
> #7  0x00007f66a65187a0 in access_with_adjusted_size (addr=1, 
> value=0x7f669f3ecbb0, size=1, access_size_min=<optimized out>, 
> access_size_max=<optimized out>, access=0x7f66a65186c0 
> <memory_region_write_accessor>, opaque=0x7f66a95fa5a8)    at 
> /root/download/qemu/git/qemu-kvm/memory.c:304
> #8  0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, 
> addr=1, mr=0x7f66a95fa5a8) at /root/download/qemu/git/qemu-kvm/memory.c:982
> #9  io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, 
> size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
> #10 0x00007f66a65187a0 in access_with_adjusted_size (addr=1, 
> value=0x7f669f3ecc60, size=1, access_size_min=<optimized out>, 
> access_size_max=<optimized out>, access=0x7f66a65186c0 
> <memory_region_write_accessor>, opaque=0x7f669801bae0)    at 
> /root/download/qemu/git/qemu-kvm/memory.c:304
> #11 0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8, 
> addr=1, mr=0x7f669801bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982
> #12 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, 
> size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
> #13 0x00007f66a64efe58 in cpu_physical_memory_rw (addr=4273938433, 
> buf=0x7f66a6319028 <Address 0x7f66a6319028 out of bounds>, len=1, is_write=1) 
> at /root/download/qemu/git/qemu-kvm/exec.c:3594
> #14 0x00007f66a650d195 in kvm_cpu_exec (env=0x7f66a8d52900) at 
> /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
> #15 0x00007f66a64e3201 in qemu_kvm_cpu_thread_fn (arg=0x7f66a8d52900) at 
> /root/download/qemu/git/qemu-kvm/cpus.c:732
> #16 0x00007f66a47bbd90 in start_thread () from /lib64/libpthread.so.0
> #17 0x00007f66a2a57f5d in clone () from /lib64/libc.so.6
> ################################################################################################################################################################
> (gdb) back
> #0  0x00007f66efb81285 in raise () from /lib64/libc.so.6
> #1  0x00007f66efb82b9b in abort () from /lib64/libc.so.6
> #2  0x00007f66efbc2a7e in __libc_message () from /lib64/libc.so.6
> #3  0x00007f66efbc8da6 in malloc_printerr () from /lib64/libc.so.6
> #4  0x00007f66efbc9279 in malloc_consolidate.part.3 () from /lib64/libc.so.6
> #5  0x00007f66efbc9e99 in _int_free () from /lib64/libc.so.6
> #6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
> #7  scsi_req_unref (req=0x7f66f6db1bc0) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
> #8  0x00007f66f3686445 in scsi_device_purge_requests (sdev=0x7f66f6b8e160, 
> sense=...) at /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
> #9  0x00007f66f3686d27 in scsi_disk_reset (dev=0x7f66f6b8e160) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
> #10 0x00007f66f3621d60 in lsi_reg_writeb (s=0x7f66f6b72140, offset=<optimized 
> out>, val=<optimized out>)    at 
> /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
> #11 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1, 
> value=0x7f66ec5d0bb0, size=1, access_size_min=<optimized out>, 
> access_size_max=<optimized out>, access=0x7f66f36fc6c0 
> <memory_region_write_accessor>, opaque=0x7f66f6b725a8)    at 
> /root/download/qemu/git/qemu-kvm/memory.c:304
> #12 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8, 
> addr=1, mr=0x7f66f6b725a8) at /root/download/qemu/git/qemu-kvm/memory.c:982
> #13 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, 
> size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
> #14 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1, 
> value=0x7f66ec5d0c60, size=1, access_size_min=<optimized out>, 
> access_size_max=<optimized out>, access=0x7f66f36fc6c0 
> <memory_region_write_accessor>, opaque=0x7f66e401bae0)    at 
> /root/download/qemu/git/qemu-kvm/memory.c:304
> #15 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8, 
> addr=1, mr=0x7f66e401bae0) at /root/download/qemu/git/qemu-kvm/memory.c:982
> #16 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized out>, 
> size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
> #17 0x00007f66f36d3e58 in cpu_physical_memory_rw (addr=4273938433, 
> buf=0x7f66f34fd028 <Address 0x7f66f34fd028 out of bounds>, len=1, is_write=1) 
> at /root/download/qemu/git/qemu-kvm/exec.c:3594
> #18 0x00007f66f36f1195 in kvm_cpu_exec (env=0x7f66f62ca900) at 
> /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
> #19 0x00007f66f36c7201 in qemu_kvm_cpu_thread_fn (arg=0x7f66f62ca900) at 
> /root/download/qemu/git/qemu-kvm/cpus.c:732
> #20 0x00007f66f199fd90 in start_thread () from /lib64/libpthread.so.0
> #21 0x00007f66efc3bf5d in clone () from /lib64/libc.so.6
>
> (gdb) frame 6
> #6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at 
> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
> 1272                req->ops->free_req(req);
> (gdb) print req
> $1 = (SCSIRequest *) 0x7f66f6db1bc0
> (gdb) print req->ops
> $2 = (const SCSIReqOps *) 0x7f66f3b032c0
> (gdb) print req->ops->free_req
> $3 = (void (*)(SCSIRequest *)) 0x7f66f3688ef0 <scsi_free_request>
> (gdb) print req->ops->free_req
> ################################################################################################################################################################
>
>

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Brian Jackson]

On Wed, 07 Mar 2012 00:41:39 -0600, Gerhard Wiesinger  
<lists@wiesinger.com> wrote:

> Ping. Any comments?
>
> Thnx.
>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/
>
>
> On Sun, 4 Mar 2012, Gerhard Wiesinger wrote:
>
>> Hello,
>>
>> Clean XP install cores with SCSI LSI 53C89A disk when copying files.  
>> Reproduceable.  Driver used is sym_hi. Details are below.



I think most people trying to use qemu for anything useful have given
up on if=scsi. Some distros even disable support because they don't
want to QA it. That should be a decent sign that you may want to avoid
it.



>>
>> Tried also old versions 1.0, 0.15.1, cores too.
>>
>> Any ideas?
>>
>> Thnx.
>>
>> Ciao,
>> Gerhard
>>
>> --
>> http://www.wiesinger.com/
>>
>> Image created with:
>> qemu-img create -f qcow2 XP-TEST.qcow2 10G
>>
>> Command line:
>> Version: git b5ed4b6f6f0d31e0d8210f4b444ba67bfa5d6de2
>> /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64
>> -drive file=VM-XP-TEST/XP-TEST.qcow2,media=disk,if=scsi,bus=0,unit=0
>> -cdrom ISO/XP.iso
>> -boot order=cad,menu=on
>> -m 2048
>> -k de
>> -vga vmware
>> -vnc :0
>> -bios /root/download/seabios/git/seabios/out/bios.bin
>> -chardev stdio,id=seabios -device  
>> isa-debugcon,iobase=0x402,chardev=seabios
>> -option-rom BIOS/V4.19/8xx_64.rom
>> -device pcnet,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile=
>> -net tap,ifname=tap1,script=no,downscript=no,vlan=1
>>
>> ################################################################################################################################################################
>> #0  0x00007f66a29e5117 in malloc_consolidate.part.3 () from  
>> /lib64/libc.so.6
>> #1  0x00007f66a29e5e99 in _int_free () from /lib64/libc.so.6
>> #2  0x00007f66a64a1444 in scsi_req_unref (req=0x7f66a9791f70) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
>> #3  scsi_req_unref (req=0x7f66a9791f70) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
>> #4  0x00007f66a64a2445 in scsi_device_purge_requests  
>> (sdev=0x7f66a9616160, sense=...) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
>> #5  0x00007f66a64a2d27 in scsi_disk_reset (dev=0x7f66a9616160) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
>> #6  0x00007f66a643dd60 in lsi_reg_writeb (s=0x7f66a95fa140,  
>> offset=<optimized out>, val=<optimized out>)    at  
>> /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
>> #7  0x00007f66a65187a0 in access_with_adjusted_size (addr=1,  
>> value=0x7f669f3ecbb0, size=1, access_size_min=<optimized out>,  
>> access_size_max=<optimized out>, access=0x7f66a65186c0  
>> <memory_region_write_accessor>, opaque=0x7f66a95fa5a8)    at  
>> /root/download/qemu/git/qemu-kvm/memory.c:304
>> #8  0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8,  
>> addr=1, mr=0x7f66a95fa5a8) at  
>> /root/download/qemu/git/qemu-kvm/memory.c:982
>> #9  io_mem_write (io_index=<optimized out>, addr=1, val=<optimized  
>> out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
>> #10 0x00007f66a65187a0 in access_with_adjusted_size (addr=1,  
>> value=0x7f669f3ecc60, size=1, access_size_min=<optimized out>,  
>> access_size_max=<optimized out>, access=0x7f66a65186c0  
>> <memory_region_write_accessor>, opaque=0x7f669801bae0)    at  
>> /root/download/qemu/git/qemu-kvm/memory.c:304
>> #11 0x00007f66a651d1a0 in memory_region_dispatch_write (size=1, data=8,  
>> addr=1, mr=0x7f669801bae0) at  
>> /root/download/qemu/git/qemu-kvm/memory.c:982
>> #12 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized  
>> out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
>> #13 0x00007f66a64efe58 in cpu_physical_memory_rw (addr=4273938433,  
>> buf=0x7f66a6319028 <Address 0x7f66a6319028 out of bounds>, len=1,  
>> is_write=1) at /root/download/qemu/git/qemu-kvm/exec.c:3594
>> #14 0x00007f66a650d195 in kvm_cpu_exec (env=0x7f66a8d52900) at  
>> /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
>> #15 0x00007f66a64e3201 in qemu_kvm_cpu_thread_fn (arg=0x7f66a8d52900)  
>> at /root/download/qemu/git/qemu-kvm/cpus.c:732
>> #16 0x00007f66a47bbd90 in start_thread () from /lib64/libpthread.so.0
>> #17 0x00007f66a2a57f5d in clone () from /lib64/libc.so.6
>> ################################################################################################################################################################
>> (gdb) back
>> #0  0x00007f66efb81285 in raise () from /lib64/libc.so.6
>> #1  0x00007f66efb82b9b in abort () from /lib64/libc.so.6
>> #2  0x00007f66efbc2a7e in __libc_message () from /lib64/libc.so.6
>> #3  0x00007f66efbc8da6 in malloc_printerr () from /lib64/libc.so.6
>> #4  0x00007f66efbc9279 in malloc_consolidate.part.3 () from  
>> /lib64/libc.so.6
>> #5  0x00007f66efbc9e99 in _int_free () from /lib64/libc.so.6
>> #6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
>> #7  scsi_req_unref (req=0x7f66f6db1bc0) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1268
>> #8  0x00007f66f3686445 in scsi_device_purge_requests  
>> (sdev=0x7f66f6b8e160, sense=...) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1421
>> #9  0x00007f66f3686d27 in scsi_disk_reset (dev=0x7f66f6b8e160) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-disk.c:1498
>> #10 0x00007f66f3621d60 in lsi_reg_writeb (s=0x7f66f6b72140,  
>> offset=<optimized out>, val=<optimized out>)    at  
>> /root/download/qemu/git/qemu-kvm/hw/lsi53c895a.c:1684
>> #11 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1,  
>> value=0x7f66ec5d0bb0, size=1, access_size_min=<optimized out>,  
>> access_size_max=<optimized out>, access=0x7f66f36fc6c0  
>> <memory_region_write_accessor>, opaque=0x7f66f6b725a8)    at  
>> /root/download/qemu/git/qemu-kvm/memory.c:304
>> #12 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8,  
>> addr=1, mr=0x7f66f6b725a8) at  
>> /root/download/qemu/git/qemu-kvm/memory.c:982
>> #13 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized  
>> out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
>> #14 0x00007f66f36fc7a0 in access_with_adjusted_size (addr=1,  
>> value=0x7f66ec5d0c60, size=1, access_size_min=<optimized out>,  
>> access_size_max=<optimized out>, access=0x7f66f36fc6c0  
>> <memory_region_write_accessor>, opaque=0x7f66e401bae0)    at  
>> /root/download/qemu/git/qemu-kvm/memory.c:304
>> #15 0x00007f66f37011a0 in memory_region_dispatch_write (size=1, data=8,  
>> addr=1, mr=0x7f66e401bae0) at  
>> /root/download/qemu/git/qemu-kvm/memory.c:982
>> #16 io_mem_write (io_index=<optimized out>, addr=1, val=<optimized  
>> out>, size=1) at /root/download/qemu/git/qemu-kvm/memory.c:1564
>> #17 0x00007f66f36d3e58 in cpu_physical_memory_rw (addr=4273938433,  
>> buf=0x7f66f34fd028 <Address 0x7f66f34fd028 out of bounds>, len=1,  
>> is_write=1) at /root/download/qemu/git/qemu-kvm/exec.c:3594
>> #18 0x00007f66f36f1195 in kvm_cpu_exec (env=0x7f66f62ca900) at  
>> /root/download/qemu/git/qemu-kvm/kvm-all.c:1192
>> #19 0x00007f66f36c7201 in qemu_kvm_cpu_thread_fn (arg=0x7f66f62ca900)  
>> at /root/download/qemu/git/qemu-kvm/cpus.c:732
>> #20 0x00007f66f199fd90 in start_thread () from /lib64/libpthread.so.0
>> #21 0x00007f66efc3bf5d in clone () from /lib64/libc.so.6
>>
>> (gdb) frame 6
>> #6  0x00007f66f3685444 in scsi_req_unref (req=0x7f66f6db1bc0) at  
>> /root/download/qemu/git/qemu-kvm/hw/scsi-bus.c:1272
>> 1272                req->ops->free_req(req);
>> (gdb) print req
>> $1 = (SCSIRequest *) 0x7f66f6db1bc0
>> (gdb) print req->ops
>> $2 = (const SCSIReqOps *) 0x7f66f3b032c0
>> (gdb) print req->ops->free_req
>> $3 = (void (*)(SCSIRequest *)) 0x7f66f3688ef0 <scsi_free_request>
>> (gdb) print req->ops->free_req
>> ################################################################################################################################################################
>>
>>
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

On Wed, 7 Mar 2012, Brian Jackson wrote:
> I think most people trying to use qemu for anything useful have given
> up on if=scsi. Some distros even disable support because they don't
> want to QA it. That should be a decent sign that you may want to avoid
> it.

OK, but SAS (Serial attached SCSI) is technology in the area of storage interface 
technology where all big storage vendors see future (e.g. they give up: 
FC and SATA drives, SATA drives are replaced by MDL SATA drives (SATA 
7200RPM drives with SAS interface)).

Therefore I don't understand why distros are giving up SAS which is 
also SCSI (of course old legacy SCSI is understandable).

And legacy SCSI is of course technology from yesterday but e.g. LSI53C895A 
has largest OS support ever as far as I know (from DOS, Win95, NT4, W2K, 
XP, Vista, Windows 7, Linux, etc.). Also CPU usage is low.

What's your preferred storage technology on QEMU?
Where do you see future?

BTW: The underlying problem I want to solve: I want to migrate a VMWare 
Server 2.x VM based on Buslogic SCSI controller to QEMU/KVM. And
geometry translation to IDE/SATA doesn't boot up the system ... Any ideas 
to migrate to other storage technology (VM is offline)?

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerd Hoffmann]

On 03/07/12 20:58, Gerhard Wiesinger wrote:
> On Wed, 7 Mar 2012, Brian Jackson wrote:
>> I think most people trying to use qemu for anything useful have given
>> up on if=scsi. Some distros even disable support because they don't
>> want to QA it. That should be a decent sign that you may want to avoid
>> it.
> 
> OK, but SAS (Serial attached SCSI) is technology in the area of storage
> interface technology where all big storage vendors see future (e.g. they
> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
> (SATA 7200RPM drives with SAS interface)).

The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
the hardware design which makes it hard to emulate it correctly and #2
that you need a non-redistributable rom file to boot from it.

> Therefore I don't understand why distros are giving up SAS which is also
> SCSI (of course old legacy SCSI is understandable).

Nobody gives up on scsi.  See virtio-scsi merged recently.  There also
is megasas aiming for merge (which shares the boot issue with lsi though).

cheers,
  Gerd

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Michael Tokarev]

On 08.03.2012 11:44, Gerd Hoffmann wrote:
> On 03/07/12 20:58, Gerhard Wiesinger wrote:
>> On Wed, 7 Mar 2012, Brian Jackson wrote:
>>> I think most people trying to use qemu for anything useful have given
>>> up on if=scsi. Some distros even disable support because they don't
>>> want to QA it. That should be a decent sign that you may want to avoid
>>> it.
>>
>> OK, but SAS (Serial attached SCSI) is technology in the area of storage
>> interface technology where all big storage vendors see future (e.g. they
>> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
>> (SATA 7200RPM drives with SAS interface)).
> 
> The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
> the hardware design which makes it hard to emulate it correctly and #2
> that you need a non-redistributable rom file to boot from it.

#2 isn't an issue actually, at least for Debian users --
I just patched extbook back to allow booting from scsi and
to let people some transition time to move from boot=on
syntax which was supported before 1.0 and dropped suddenly
without any warnings in 1.0, breaking people setup.  I
think I'll continue shipping extboot support at least as
long as there's no native support for scsi booting in bios.

/mjt

>> Therefore I don't understand why distros are giving up SAS which is also
>> SCSI (of course old legacy SCSI is understandable).
> 
> Nobody gives up on scsi.  See virtio-scsi merged recently.  There also
> is megasas aiming for merge (which shares the boot issue with lsi though).
> 

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerd Hoffmann]

On 03/08/12 09:54, Michael Tokarev wrote:
> On 08.03.2012 11:44, Gerd Hoffmann wrote:
>>> OK, but SAS (Serial attached SCSI) is technology in the area of storage
>>> interface technology where all big storage vendors see future (e.g. they
>>> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
>>> (SATA 7200RPM drives with SAS interface)).
>>
>> The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
>> the hardware design which makes it hard to emulate it correctly and #2
>> that you need a non-redistributable rom file to boot from it.
> 
> #2 isn't an issue actually, at least for Debian users --

Well, it is, to some degree.  Because vanilla upstream doesn't support
booting from lsi it has alot less users and alot less regression testing
(like autotest runs of lsi-scsi installs), which sums up to more bugs
staying unnoticed like the one which triggered this thread.

cheers,
  Gerd

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

On Thu, 8 Mar 2012, Gerd Hoffmann wrote:

> On 03/08/12 09:54, Michael Tokarev wrote:
>> On 08.03.2012 11:44, Gerd Hoffmann wrote:
>>>> OK, but SAS (Serial attached SCSI) is technology in the area of storage
>>>> interface technology where all big storage vendors see future (e.g. they
>>>> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
>>>> (SATA 7200RPM drives with SAS interface)).
>>>
>>> The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
>>> the hardware design which makes it hard to emulate it correctly and #2
>>> that you need a non-redistributable rom file to boot from it.
>>
>> #2 isn't an issue actually, at least for Debian users --
>
> Well, it is, to some degree.  Because vanilla upstream doesn't support
> booting from lsi it has alot less users and alot less regression testing
> (like autotest runs of lsi-scsi installs), which sums up to more bugs
> staying unnoticed like the one which triggered this thread.

What's the holdup to integrate it into QEMU?

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerd Hoffmann]

  Hi,

>>> #2 isn't an issue actually, at least for Debian users --
>>
>> Well, it is, to some degree.  Because vanilla upstream doesn't support
>> booting from lsi it has alot less users and alot less regression testing
>> (like autotest runs of lsi-scsi installs), which sums up to more bugs
>> staying unnoticed like the one which triggered this thread.
> 
> What's the holdup to integrate it into QEMU?

Extboot is considered obsolete and thus several attempts to merge it
into upstream qemu failed.  It started its life as hack to allow
qemu-kvm boot from virtio-blk devices, which happened to work for lsi
too.  virtio-blk is supported by seabios natively these days.

Adding lsi support to seabios shouldn't be that hard.  Paolo paved the
way by restructing the existing scsi disk/cdrom bits in seabios so they
work for both usb-storage and virtio-scsi.  Adding support for yet
another scsi hba should be easy, all the support bits for handling disks
and booting from cdrom are there already.

It just needs someone to sit down for a week or two and hack it up.

cheers,
  Gerd

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

On Fri, 9 Mar 2012, Gerd Hoffmann wrote:

>  Hi,
>
>>>> #2 isn't an issue actually, at least for Debian users --
>>>
>>> Well, it is, to some degree.  Because vanilla upstream doesn't support
>>> booting from lsi it has alot less users and alot less regression testing
>>> (like autotest runs of lsi-scsi installs), which sums up to more bugs
>>> staying unnoticed like the one which triggered this thread.
>>
>> What's the holdup to integrate it into QEMU?
>
> Extboot is considered obsolete and thus several attempts to merge it
> into upstream qemu failed.  It started its life as hack to allow
> qemu-kvm boot from virtio-blk devices, which happened to work for lsi
> too.  virtio-blk is supported by seabios natively these days.
>
> Adding lsi support to seabios shouldn't be that hard.  Paolo paved the
> way by restructing the existing scsi disk/cdrom bits in seabios so they
> work for both usb-storage and virtio-scsi.  Adding support for yet
> another scsi hba should be easy, all the support bits for handling disks
> and booting from cdrom are there already.
>
> It just needs someone to sit down for a week or two and hack it up.

@Paolo: Would that be easily possible?

BTW: What do you think anout that:
Handling INT13h always directly through virtio-scsi regardless of selected 
SCSI adapter, or when OS driver is loaded through SCSI adapter, so just 
have 2 ways to the disks:
1.) Through INT13h to virtio-scsi and then to the disks
2.) Through SCSI adapter and then to the disks (OS driver loaded)

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Paolo Bonzini]

Il 09/03/2012 08:46, Gerhard Wiesinger ha scritto:
> On Fri, 9 Mar 2012, Gerd Hoffmann wrote:
> 
>>  Hi,
>>
>>>>> #2 isn't an issue actually, at least for Debian users --
>>>>
>>>> Well, it is, to some degree.  Because vanilla upstream doesn't support
>>>> booting from lsi it has alot less users and alot less regression
>>>> testing
>>>> (like autotest runs of lsi-scsi installs), which sums up to more bugs
>>>> staying unnoticed like the one which triggered this thread.
>>>
>>> What's the holdup to integrate it into QEMU?
>>
>> Extboot is considered obsolete and thus several attempts to merge it
>> into upstream qemu failed.  It started its life as hack to allow
>> qemu-kvm boot from virtio-blk devices, which happened to work for lsi
>> too.  virtio-blk is supported by seabios natively these days.
>>
>> Adding lsi support to seabios shouldn't be that hard.  Paolo paved the
>> way by restructing the existing scsi disk/cdrom bits in seabios so they
>> work for both usb-storage and virtio-scsi.  Adding support for yet
>> another scsi hba should be easy, all the support bits for handling disks
>> and booting from cdrom are there already.
>>
>> It just needs someone to sit down for a week or two and hack it up.
> 
> @Paolo: Would that be easily possible?

Sure.

You could expect the SeaBIOS driver to be 700-100 lines of code:

$ wc lsi53c895a.c virtio-scsi.c usb-msd.c # in QEMU
 2150  6959 62694 lsi53c895a.c
  617  1537 18463 virtio-scsi.c
  677  1847 18465 usb-msd.c

$ wc virtio-scsi.c usb-msc.c # in SeaBIOS
 177  517 4711 virtio-scsi.c
 174  499 4935 usb-msc.c

As Gerd said, the SCSI layer is entirely abstracted (the only piece
missing to abstract is discovery, which is why virtio-scsi will only
boot from LUN0).  The driver only needs to provide a way to execute CDBs.

> BTW: What do you think anout that:
> Handling INT13h always directly through virtio-scsi regardless of
> selected SCSI adapter, or when OS driver is loaded through SCSI adapter,
> so just have 2 ways to the disks:
> 1.) Through INT13h to virtio-scsi and then to the disks
> 2.) Through SCSI adapter and then to the disks (OS driver loaded)

Interesting idea. :)  That would work, I guess.

By the way, you said the lsi53c is buslogic in VMWare and hence libvirt?

Paolo

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

On Thu, 8 Mar 2012, Michael Tokarev wrote:

> On 08.03.2012 11:44, Gerd Hoffmann wrote:
>> On 03/07/12 20:58, Gerhard Wiesinger wrote:
>>> On Wed, 7 Mar 2012, Brian Jackson wrote:
>>>> I think most people trying to use qemu for anything useful have given
>>>> up on if=scsi. Some distros even disable support because they don't
>>>> want to QA it. That should be a decent sign that you may want to avoid
>>>> it.
>>>
>>> OK, but SAS (Serial attached SCSI) is technology in the area of storage
>>> interface technology where all big storage vendors see future (e.g. they
>>> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
>>> (SATA 7200RPM drives with SAS interface)).
>>
>> The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
>> the hardware design which makes it hard to emulate it correctly and #2
>> that you need a non-redistributable rom file to boot from it.
>
> #2 isn't an issue actually, at least for Debian users --
> I just patched extbook back to allow booting from scsi and
> to let people some transition time to move from boot=on
> syntax which was supported before 1.0 and dropped suddenly
> without any warnings in 1.0, breaking people setup.  I
> think I'll continue shipping extboot support at least as
> long as there's no native support for scsi booting in bios.

What's extbook? Can you please explain a little bit the concept? Links?
Or is it extboot option ROM? But currently not any more in qemu?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerhard Wiesinger]

On Thu, 8 Mar 2012, Gerd Hoffmann wrote:

> On 03/07/12 20:58, Gerhard Wiesinger wrote:
>> On Wed, 7 Mar 2012, Brian Jackson wrote:
>>> I think most people trying to use qemu for anything useful have given
>>> up on if=scsi. Some distros even disable support because they don't
>>> want to QA it. That should be a decent sign that you may want to avoid
>>> it.
>>
>> OK, but SAS (Serial attached SCSI) is technology in the area of storage
>> interface technology where all big storage vendors see future (e.g. they
>> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives
>> (SATA 7200RPM drives with SAS interface)).
>
> The problem isn't scsi.  The problem is the lsi adapter.  Problem #1 is
> the hardware design which makes it hard to emulate it correctly and #2
> that you need a non-redistributable rom file to boot from it.

Advantages of LSI 53C895A over others:
1.) OS support is great, even for legacy systems: DOS, Win 3.1, Win95, NT 
4, W2K, XP, Vista, Win7, Linux, etc. I don't know any adapter with such 
wide range of OS support. Also tested up to 2TB of LUNs.
2.) OS support out of the box without additional drivers for a lot of 
newer OSes
3.) Migration from VMWare SCSI is easy
4.) Works well here for about 1 year for legacy VMs for DOS and NT 4
5.) BIOS geometry translation is correct, also according to 
partition table (doesn't work correctly on MEGASAS,
INT13 geometry interrupts are not correct, already reported to 
Hannes)
7.) LSI SCSI DMA technology is fast. I'm getting /dev/null performance 
over 500MB/s ..., optimized for parallel IOPS, etc.
8.) Faster ROM init than MEGASAS

Disadvantages:
1.) ROM non distributable
2.) non complete implementation
3.) 2TB limit
4.) Slower ROM INIT than without any Option ROM

Megasas also needs a ROM rom to boot from it.
Not to forget iSCSI which is also current/future SCSI technology ...

Even if it is hard but I think the goal of qemu should be to implement all 
supported hardware pieces as good as possible (e.g. LSI 53C895A). I know 
it is not an easy task (see my thread about rtl8139) but I think together 
we can manage it.

Are there any LSI 53C895A known bugs or incomplete implementation issues 
which are known? 
Any hints on the core dump?

>> Therefore I don't understand why distros are giving up SAS which is also
>> SCSI (of course old legacy SCSI is understandable).
>
> Nobody gives up on scsi.  See virtio-scsi merged recently.  There also
> is megasas aiming for merge (which shares the boot issue with lsi though).

Disadvantage of virtio-scsi is that drivers are needed.
Is INT13h supported for legacy OS and to boot? Future? But as far as I saw 
implemented in seabios, right?
What BIOS translation is used? Buslogic? LSI logic? Partition guessing?

BTW: I've found out how LSI logic BIOS geometry translation works with 
(guessing) and without existing partition table. That might be an option
for Seabios to implement.
@Kevin: What do you think?

Ciao,
Gerhard

--
http://www.wiesinger.com/

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Gerd Hoffmann]

  Hi,

> Advantages of LSI 53C895A over others:
> 1.) OS support is great, even for legacy systems: DOS, Win 3.1, Win95,
> NT 4, W2K, XP, Vista, Win7, Linux, etc. I don't know any adapter with
> such wide range of OS support. Also tested up to 2TB of LUNs.

Hmm?  win7 here?  At least the 64bit versions don't ship lsi drivers
(also other oldish hardware such as ac97 sound).  Not sure about the
32bit versions.

legacy systems is *the* strong argument for lsi.

> 2.) OS support out of the box without additional drivers for a lot of
> newer OSes

recent windows systems stopped shipping lsi drivers.
linux systems will ship with virtio-scsi support soon.

> 7.) LSI SCSI DMA technology is fast. I'm getting /dev/null performance
> over 500MB/s ..., optimized for parallel IOPS, etc.

Well, you can't do zerocopy because that is next to impossible to
emulate correctly.  Which puts lsi behind other solutions
performance-wise.  But to keep legacy systems alive performance isn't
the #1 issue.  Likewise the 2T limit ;)

> Not to forget iSCSI which is also current/future SCSI technology ...

Oh, booting from iscsi is supported just fine by iPXE.  It is more a
problem that the guest OS must be able to handle this too ...

cheers,
  Gerd

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Paolo Bonzini]

Il 09/03/2012 08:35, Gerd Hoffmann ha scritto:
> Is INT13h supported for legacy OS and to boot? Future? But as far as
> I saw implemented in seabios, right?

Yes, Kevin (O' Connor, not Wolf) integrated the patch this week.  It
will also be in Fedora 17.

> What BIOS translation is used? Buslogic? LSI logic? Partition guessing? 

Whatever QEMU does for IDE.  It is passed down via mode page 04h and
retrieved by SeaBIOS.

Paolo

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Kevin O'Connor]

On Fri, Mar 09, 2012 at 07:18:38AM +0100, Gerhard Wiesinger wrote:
> BTW: I've found out how LSI logic BIOS geometry translation works
> with (guessing) and without existing partition table. That might be
> an option
> for Seabios to implement.
> @Kevin: What do you think?

SeaBIOS has an algorithm for guessing the virtual disk geometry (see
src/block.c:get_translation).  If you have an improvement to that
algorithm, please send a patch.

Note that the physical disk geometry is obtained from the drive itself
(where possible).

-Kevin

Re: [Qemu-devel] XP install cores with SCSI LSI 53C895A disks

[Brian Jackson]

On Wed, 07 Mar 2012 13:58:21 -0600, Gerhard Wiesinger  
<lists@wiesinger.com> wrote:

> On Wed, 7 Mar 2012, Brian Jackson wrote:
>> I think most people trying to use qemu for anything useful have given
>> up on if=scsi. Some distros even disable support because they don't
>> want to QA it. That should be a decent sign that you may want to avoid
>> it.
>
> OK, but SAS (Serial attached SCSI) is technology in the area of storage  
> interface technology where all big storage vendors see future (e.g. they  
> give up: FC and SATA drives, SATA drives are replaced by MDL SATA drives  
> (SATA 7200RPM drives with SAS interface)).
>
> Therefore I don't understand why distros are giving up SAS which is also  
> SCSI (of course old legacy SCSI is understandable).
>
> And legacy SCSI is of course technology from yesterday but e.g.  
> LSI53C895A has largest OS support ever as far as I know (from DOS,  
> Win95, NT4, W2K, XP, Vista, Windows 7, Linux, etc.). Also CPU usage is  
> low.


I would imagine IDE would, but I'm not as familiar with hardware support  
of Windows < XP.



>
> What's your preferred storage technology on QEMU?


virtio > ahci > ide



> Where do you see future?


Hopefully, Hannes' Megaraid work gets merged. That along with the other  
options above should cover most bases pretty well.


>
> BTW: The underlying problem I want to solve: I want to migrate a VMWare  
> Server 2.x VM based on Buslogic SCSI controller to QEMU/KVM. And
> geometry translation to IDE/SATA doesn't boot up the system ... Any  
> ideas to migrate to other storage technology (VM is offline)?


If you could boot it, I'd say you could try mergeide (I'm assuming it's  
Windows since Linux should just work).



>
> Ciao,
> Gerhard
>
> --
> http://www.wiesinger.com/