Windows10 dvd passthrough slow read

[fourierules]

Im looking for some help troublshooting a windows 10 vm that I am trying to passthrough a physical dvd drive to. My issue is at the moment reading files from the dvd. Files below ~800k copy immediately but anything above that takes up to 30 minutes or more depending on the file size. So far I haven't found any issues on the host side indicating errors on the scsi device and booting the guest to a live dvd works fine. Is there any particular configuration issues that I may have missed?

Im running virtio scsi version 100.75.104.14500

Rhel 7.4 host with qemu-kvm 1.5.3 3.10.0-693 kernel

[vrozenfe]

Build 145 is quite old ( Dec 2017). Can I ask you to give a try to a more recent version? It also will be helpful if you can provide the qemu command line to let us reproduce the problem.

Thanks, Vadim.

[fourierules]

I just got 100.80.104.17300 from fedoras latest builds installed. No difference. I have noticed cdrom warnings appearing every three minutes or so in the windows system logs. The error is 51, error detected during paging operation.

As for the cmdline, best i can do is what i can type by hand since the machines are disconnected from the world.

-realtime Mlock=off -smp 4,sockets=2,cores=2,threads=1 -device virtio-scsi-pci,id=scsi0,bus=pci.0, addr=0x8 -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-hostdev0,id=hostdev0

Thanks

[vrozenfe]

Thanks. We will try to reproduce the problem. Will keep you updated. Vadim.

[fourierules]

Missed a piece -device file=/dev/sg2,if=none,id=drive-hostdev0

[fourierules]

I started playing with the scsi log levels and reading through sg.c (scsi generic kernel driver) found this when I start a file copy: once the error starts is just spams the console with the same -22 (EINVAL) sg_ioctl: cmd=0x2285 (SG_IO) sg_common_write: scsi opcode=0x00, cmd_size=6 sg_start_req: dxfer: dxfer_len=0 sg_cmd_done: pack_id=0, res=0x0 sg_remove_scat: k_use_sg=0 sg_ioctl: cmd=0x2285 (SG_IO) sg_common_write: scsi opcode=0x28, cmd_size=10 sg_start_req: dxfer: dxfer_len=266240 sg_build_indirect: buff_size=266240, blk_size=266240 sg_common_write: start_req err -22 sg_finish_rem_req: res_used=0 sg_remove_scat: k_use_sg=9

[fourierules]

Hopefully I'm not spamming you. Additional information: the scsi generic driver is getting EINVAL from a call to blk_rq_map_user() in sg_start_req(). The requested length dxfer_len is greater than (q.limits.max_hw_sectors << 9) looks something like 266240 > (256 << 9) I believe.

[vrozenfe]

Yuur inputs are extremely helpful.
I think I can reproduce the problems when trying to copy the entire DVD contents from virtio-scsi attached DVD device to to system (ide) volume. Can you please run Event Viewer inside of your Windows VM, go to Windows Log -> System and check if there are Event ID 129 comming from vioscsi ?

Thanks, Vadim.

[fourierules]

I do see them. Reset to device. I only have 3 over the last day or so and this is after I modified the sg driver to limit io map requests to q.limits.max_hw_sectors<<9.

Any thoughts as to whom would be allocating 4096 *(64+1) bytes for the dxfer_len?

[vrozenfe]

Then we might be hitting different problems. I can see a bunch of Event ID 129 (bus reset events), that Windows normally issues when SCSI request can not be completed in time and Window treats such events as HBA/LUN malfunction.

4096 *(64+1) bytes looks as maximum transfer length ((64 physical breaks + 1 more) * PAGE_SIZE) vioscsi driver defines it as a maximum transfer size that it can handle at one request (SRB -SCSI request block).

[peixiu]

I reproduced this issue on RHEL7.4 host with qemu qemu-kvm-1.5.3-141.el7.x86_64 and qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64.

On win10-64 guest vm, copy a 1.53M file is so slowly, similar as upstream bug comment#0 description, tried both vioscsi build 173 and 180 version, both reproduced.

On RHEL8.2.0 guest vm, cannot hit cp slow issue, but hit error message when copy a 76M file, errors as follows:

[ 140.883275] sr 0:0:0:0: [sr0] tag#105 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 140.883940] sr 0:0:0:0: [sr0] tag#105 Sense Key : Aborted Command [current] [ 140.884420] sr 0:0:0:0: [sr0] tag#105 Add. Sense: I/O process terminated [ 140.884889] sr 0:0:0:0: [sr0] tag#105 CDB: Read(10) 28 00 00 00 00 42 00 00 3e 00 [ 140.885384] blk_update_request: I/O error, dev sr0, sector 264 op 0x0:(READ) flags 0x0 phys_seg 31 prio class 0 [ 141.053286] sr 0:0:0:0: [sr0] tag#108 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 141.053924] sr 0:0:0:0: [sr0] tag#108 Sense Key : Aborted Command [current] [ 141.054945] sr 0:0:0:0: [sr0] tag#108 Add. Sense: I/O process terminated [ 141.055878] sr 0:0:0:0: [sr0] tag#108 CDB: Read(10) 28 00 00 00 00 82 00 00 7e 00 [ 141.056818] blk_update_request: I/O error, dev sr0, sector 520 op 0x0:(READ) flags 0x0 phys_seg 63 prio class 0

Used version: kernel-3.10.0-693.el7.x86_64 qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64 seabios-bin-1.10.2-3.el7.noarch virtio-win-prewhql-173/180

qemu cli: -device virtio-scsi-pci,id=scsi0,bus=pci.0
-drive file=/dev/sg2,if=none,media=cdrom,readonly=on,format=raw,id=drive-hostdev0
-device scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-hostdev0,id=hostdev0 \

And I also tested on RHEL8.2.0 host, both tried on win10-64 and win2016 vm, reproduced this issue. And has file a bug on bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1823990 Used versions: kernel-4.18.0-193.el8.x86_64 qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64 seabios-bin-1.11.1-4.module+el8.1.0+4066+0f1aadab.noarch virtio-win-prewhql-173/180

Best Regards~ Peixiu

[fourierules]

I found the Linux guest will hit the same maximum size request but immediately shrink it after it fails. Am I looking at this wrong or is the windows driver expected to change the size of the request? That doesn't sound like a natural behavior unless the device was supposed to specify its hardware limit?? I'm still learning about the scsi v3 protocol.

[vrozenfe]

This is quite interesting. And maybe you just nailed the problem. on my testing host system max_sectors_kb is twice bigger then maximum transfer size reported vioscsi by default [vrozenfe@huan ~]$ cat /sys/block/sr0/queue/max_sectors_kb 128 vs 256 (64*4K)

I hope, it should be some simple way around this problem. Maybe changing max_sectors_kb to 256, or trying to limit virtio queue size to 64 or try playing with Block Limits VPD page 0xB0 tpo limit maximum and optimal lransfer size.

Best, Vadim.