Bug 1436562
| Summary: | [QEMU] scsi-generic: make up opt xfer len if not reported by backend | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Xueqiang Wei <xuwei> |
| Component: | qemu-kvm-rhev | Assignee: | Fam Zheng <famz> |
| Status: | CLOSED ERRATA | QA Contact: | Xueqiang Wei <xuwei> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | chayang, coli, famz, juzhang, knoel, michen, mkalinin, mrezanin, mtessun, royoung, sfroemer, virt-maint |
| Target Milestone: | rc | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-rhev-2.9.0-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-02 04:35:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1436582 | ||
Merged for upstream QEMU 2.9:
commit bed58b4443b001227b953dca80ce76fa76ea0fc1
Author: Fam Zheng <famz>
Date: Mon Mar 27 22:26:25 2017 +0800
scsi-generic: Fill in opt_xfer_len in INQUIRY reply if it is zero
When opt_xfer_len is zero, Linux ignores max_xfer_len erroneously.
While that obviously should be fixed, we do older guests a favor to
always filling in a value.
Signed-off-by: Fam Zheng <famz>
Message-Id: <20170327142625.1249-1-famz>
Signed-off-by: Paolo Bonzini <pbonzini>
Reproducer steps for reference: 1. On host, find a LUN that doesn't set opt_xfer_len in INQUIRY reply (check with "sg_inq -p 0xb0 /dev/sdX"). Such as the Emulex one in comment 0. 2. Passthrough the disk to guest as scsi-block. 3. Check that both max_xfer_len and opt_xfer_len are reported. According to https://bugzilla.redhat.com/show_bug.cgi?id=1418065#c85, verify this bug. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 |
Description of problem: VM gets paused due to 'eother' when a direct lun that is configured as Virtio-SCSI with scsi passthrough enabled and is atached via an Emulex FibreChannel HBA is written to with block sizes greater than 256kb. Version-Release number of selected component (if applicable): Kernel-3.10.0-514.6.1.el7.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.9 libvirt-client-2.0.0-10.el7.x86_64 How reproducible: 5/5 Steps to Reproduce: 1. Create a RHEL7.3.z host that has an Emulex FibreChannel HBA. 2. Configure a VM with a direct lun that is configured for Virtio-SCSI with scsi passthrough enabled. <disk type='block' device='lun' sgio='filtered' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native'/> <source dev='/dev/mapper/360014059b31089df5114cbd830320c2b'/> <backingStore/> <target dev='sdb' bus='scsi'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> 3. Within the guest run 'dd if=/dev/zero of=/dev/sda bs=256k count=1 oflag=direct'. 4. check value of lpfc_sg_seg_cnt Emulex lpfc LUN /sys/block/sdck [root@dhcp40-198 sdck]# cat ./queue/max_segments 64 5. Within the guest run 'dd if=/dev/zero of=/dev/sda bs=512k count=1 oflag=direct'. Actual results: After step 3, the guest is running, no error occurs After step 4, For Emulex lpfc: 64 After step 5, the guest is pause Expected results: After step 3, the guest is running, no error occurs After step 4, For Emulex lpfc, it shoud be 256 (Change to 256 on LPFC) After step 5, the guest is not pause Additional info: