Bug 1467811
| Summary: | Guest OS will down when disk enable the IOMMU for virtio-scsi | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jingjing Shao <jishao> | |
| Component: | seabios | Assignee: | jason wang <jasowang> | |
| Status: | CLOSED ERRATA | QA Contact: | FuXiangChun <xfu> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 7.4 | CC: | ailan, chayang, coli, dyuan, jasowang, jsuchane, juzhang, lmiksik, michen, mtessun, virt-maint, wainersm, xfu, xuzhang, yalzhang | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | seabios-1.10.2-4.el7 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1482387 (view as bug list) | Environment: | ||
| Last Closed: | 2018-04-10 14:26:48 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: | 1482387 | |||
Fixed in seabios-1.10.2-4.el7 Reproduced bug with seabios-1.10.2-3.el7.x86_64 & qemu-kvm-rhev-2.10.0-7.el7.x86_64 & kernel-3.10.0-798.el7.x86_64 result: The guest OS will report "No bootable device" Verified bug with seabios-1.11.0-1.el7.x86_64 & qemu-kvm-rhev-2.10.0-7.el7.x86_64 & kernel-3.10.0-798.el7.x86_64 Guest works well. Steps: For q35 1. In host, add "iommu=pt intel_iommu=on" to kernel line 2. Add "intel_iommu=on" to kernel line of q35 guest 3. iommu_platform=on,ats=on to "-device virtio-blk-pci...." 4. key qemu command -machine pc-q35-rhel7.5.0 -device virtio-scsi-pci,id=scsi0,bus=pci.3,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pcie.0,addr=0x5 -drive file=/home/seabio-new-system-disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,bus=pci.4,addr=0x0,id=drive-virtio-disk01,id=virtio-disk0,iommu_platform=on,ats=on -device scsi-hd,drive=drive-virtio-disk0,bootindex=1 5. For pc /usr/libexec/qemu-kvm -name guest=q35-seabios,debug-threads=on -machine pc -cpu SandyBridge,vmx=on -m 8192 -realtime mlock=off -smp 4,sockets=2,cores=2,threads=1 -drive file=/home/seabio-new-system-disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-scsi-pci,id=drive-virtio-disk01,id=virtio-disk0,iommu_platform=on,ats=on,disable-legacy=on,disable-modern=off -device scsi-hd,drive=drive-virtio-disk0,bootindex=1 -vnc :2 -monitor stdio 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/RHBA-2018:0814 |
Description of problem: Guest OS will down when scsi controller enable the IOMMU for Virtio Version-Release number of selected component (if applicable): qemu-kvm-rhev-2.9.0-14.el7.x86_64 host kernel: 3.10.0-691.el7.x86_64 guest kernel : 3.10.0-691.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. In host, add "iommu=pt intel_iommu=on" to kernel line 2. Add "intel_iommu=on" to kernel line of q35 guest 3. Add the xml as below in the guest <features> <ioapic driver='qemu'/> </features> ... <iommu model='intel'> <driver intremap='on' iotlb='on'/> </iommu> 4. Add the iommu='on' ats='on' to scsi controller and change the disk bus to scsi. .... <controller type='scsi' index='0' model='virtio-scsi'> <driver iommu='on' ats='on'/> </controller> .... <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none iommu='on' ats='on'/> <source file='/nfs/rhel7.3-q35.qcow2'/> <target dev='vda' bus='scsi'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> 5. Start the guest and find the guest can not be accessed. Actual results: As the step 5 shows. Expected results: The guest can be accessed successfully Additional info: N/A