Bug 1393322

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>
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.com>
    Signed-off-by: Paolo Bonzini <pbonzini>
    Reviewed-by: Michael S. Tsirkin <mst>
    Signed-off-by: Michael S. Tsirkin <mst>

(In reply to Gerd Hoffmann from comment #17)
> bisect landed at:
> 
> commit ad07cd69ecaffbaa015459a46975ab32e50df805
> Author: Paolo Bonzini <pbonzini>
> 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.com>
>     Signed-off-by: Paolo Bonzini <pbonzini>
>     Reviewed-by: Michael S. Tsirkin <mst>
>     Signed-off-by: Michael S. Tsirkin <mst>

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

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

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

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

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

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