Red Hat Bugzilla – Bug 1393322
Guest fails boot up with ivshmem-plain and virtio-pci device
Last modified: 2017-08-01 23:35:00 EDT
Downstream commit 01549028733315a513b1b5fcc1951fd271e8a531 was needed only for 7.3. Seabios 1.10 should not have this issue. To QE: Please check this brew build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=12064444 and give us an OK we on this BZ. Thanks! Marcel
Hi, Please see comment #1. Thanks, Marcel
Hi Marcel and Junyi, I tested with seabios-1.10.0-0.el7.test.x86_64, the guest can boot up and works well. Details: Versions: 3.10.0-520.el7.x86_64 qemu-kvm-rhev-2.6.0-28.el7.x86_64 seabios-bin-1.10.0-0.el7.test.noarch seabios-1.10.0-0.el7.test.x86_64 Steps: 1. Boot guest with ivshmem-plain and virtio-pci, guest works well. # /usr/libexec/qemu-kvm -name rhel7.3 \ -cpu IvyBridge,check -m 4G \ -smp 4,sockets=2,cores=2,threads=1 \ -netdev tap,id=hostnet0 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=22:54:00:5c:77:61,rx_queue_size=256 \ -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16 \ -spice port=5902,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on \ -monitor stdio \ -serial unix:/tmp/monitor,server,nowait \ -qmp tcp:0:5551,server,nowait \ -drive file=/home/pezhang/rhel7.3.qcow2,format=qcow2,if=none,id=drive-virtio-blk0,werror=stop,rerror=stop \ -device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0 \ -usbdevice tablet \ -object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \ -device ivshmem-plain,memdev=mem \ Best Regards, Pei
When testing with seabios fixed version, fail with with latest qemu version (which is the first rebase), but success with old versions. Testing with versions: 3.10.0-539.el7.x86_64 seabios-1.10.1-1.el7.x86_64 qemu-kvm-rhev-2.8.0-1.el7.x86_64 Fail qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 Work qemu-kvm-rhev-2.6.0-28.el7.x86_64 Work Seems this bug is fixed in seabios, however qemu rebase caused regression.
Hi Marcel, Could you please check Comment 8, should QE file a regression bug on qemu-kvm-rhev component? Thanks. Best Regards, Pei
Hi Gerd, Can you have a look? It was supposed to work with SeaBIOS 1.10 . Do you have any idea that may help? Thanks, Marcel
(In reply to Marcel Apfelbaum from comment #15) > Hi Gerd, > > Can you have a look? > It was supposed to work with SeaBIOS 1.10 . > Do you have any idea that may help? > > Thanks, > Marcel 2.7.0 works. 2.8.0 fails, but in kvm mode only, tcg is fine. Doesn't look like a seabios issue, going bisect qemu ...
bisect landed at: commit ad07cd69ecaffbaa015459a46975ab32e50df805 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Fri Oct 21 22:48:10 2016 +0200 virtio-scsi: always use dataplane path if ioeventfd is active Override start_ioeventfd and stop_ioeventfd to start/stop the whole dataplane logic. This has some positive side effects: - no need anymore for virtio_add_queue_aio (i.e. a revert of commit 1c627137c10ee2dcf59e0383ade8a9abfa2d4355) - no need anymore to switch from generic ioeventfd handlers to dataplane It detects some errors better: $ qemu-system-x86_64 -object iothread,id=io \ -device virtio-scsi-pci,ioeventfd=off,iothread=io qemu-system-x86_64: -device virtio-scsi-pci,ioeventfd=off,iothread=io: ioeventfd is required for iothread while previously it would have started just fine. Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(In reply to Gerd Hoffmann from comment #17) > bisect landed at: > > commit ad07cd69ecaffbaa015459a46975ab32e50df805 > Author: Paolo Bonzini <pbonzini@redhat.com> > Date: Fri Oct 21 22:48:10 2016 +0200 > > virtio-scsi: always use dataplane path if ioeventfd is active > > Override start_ioeventfd and stop_ioeventfd to start/stop the > whole dataplane logic. This has some positive side effects: > > - no need anymore for virtio_add_queue_aio (i.e. a revert of > commit 1c627137c10ee2dcf59e0383ade8a9abfa2d4355) > > - no need anymore to switch from generic ioeventfd handlers to > dataplane > > It detects some errors better: > > $ qemu-system-x86_64 -object iothread,id=io \ > -device virtio-scsi-pci,ioeventfd=off,iothread=io > qemu-system-x86_64: -device > virtio-scsi-pci,ioeventfd=off,iothread=io: > ioeventfd is required for iothread > > while previously it would have started just fine. > > Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Hi Paolo, Can you please have a look on what's going on here? It seems like a whole new issue, even if the symptoms are the same. Thanks, Marcel
The commit broke the indirect access registers that are new in virtio 1.0. Adding ivshmem-plain pushes the virtio-blk device above the 4G limit and causes seabios to use indirect access.
*** Bug 1441512 has been marked as a duplicate of this bug. ***
Fixed by commit e49a6618400d11e51e30328dfe8d7cafce82d4bc.
==Verification== Versions: 3.10.0-675.el7.x86_64 qemu-kvm-rhev-2.9.0-7.el7.x86_64 seabios-1.10.2-3.el7.x86_64 seabios-bin-1.10.2-3.el7.noarch Steps: 1. Boot guest with ivshmem-plain and virtio-pci Same With Comment 5. 2. Reboot/shutdown guest several times, guest keeps working well. So this bug has been fixed well. Thanks. Move status of this bug to 'VERIFIED'.
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