[Bug 98741] New: Cannot boot into kvm guest with kernel >= 3.18.x on el6.6 qemu-kvm host with virtio-blk-pci.x-data-plane=on and virtio-blk-pci.ioeventfd=on

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=98741

            Bug ID: 98741
           Summary: Cannot boot into kvm guest with kernel >= 3.18.x on
                    el6.6 qemu-kvm host with
                    virtio-blk-pci.x-data-plane=on and
                    virtio-blk-pci.ioeventfd=on
           Product: Virtualization
           Version: unspecified
    Kernel Version: 3.18.x, 3.19.x, 4.0.x
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: kvm
          Assignee: virtualization_kvm@kernel-bugs.osdl.org
          Reporter: jaroslav.pulchart@gooddata.com
        Regression: No

Hello,

I'm experiencing problem with latest kernel during testing of new features in
virtual guests running at EL6.6 host in KVM with Virtio PV drivers and enabled
datapalane (virtio-blk-pci.x-data-plane=on) feature to provide best IO
performance.

The issue cause that qemu-kvm process is stopped during quest boot. 

Host log:
----------------------------------
qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/hw/msix.c:645:
msix_set_mask_notifier: Assertion `!dev->msix_mask_notifier' failed.
2015-05-18 08:45:48.102+0000: shutting down
-----------------------------------
Guest log:
-----------------------------------
...
initcall virtio_pci_driver_init+0x0/0x1000 [virtio_pci] returned 0 after 82556
usecs
calling  ata_init+0x0/0x5d [libata] @ 204
libata version 3.00 loaded.
initcall ata_init+0x0/0x5d [libata] returned 0 after 11641 usecs
[drm:drm_framebuffer_reference] ffff8800da0c5ea0: FB ID: 21 (2)
[drm:drm_framebuffer_unreference] ffff8800da0c5ea0: FB ID: 21 (3)
calling  ata_generic_pci_driver_init+0x0/0x1000 [ata_generic] @ 204
initcall ata_generic_pci_driver_init+0x0/0x1000 [ata_generic] returned 0 after
146 usecs
calling  init+0x0/0x1000 [virtio_blk] @ 250
virtio-pci 0000:00:04.0: irq 24 for MSI/MSI-X
virtio-pci 0000:00:04.0: irq 25 for MSI/MSI-X
... <<END>> ...
-----------------------------------

* Reproducible with this setup:
  Quest kernel versions: kernel 3.18, 3.19, 4.0
  qemu-kvm: virtio-blk-pci.x-data-plane=on, virtio-blk-pci.ioeventfd=on

* Not reproducible:
  Quest kernel versions: kernel 3.17 or older

* Not reproducible:
  Quest kernel versions: kernel 3.18, 3.19, 4.0
  qemu-kvm: virtio-blk-pci.x-data-plane=on + virtio-blk-pci.ioeventfd=off
            virtio-blk-pci.x-data-plane=off + virtio-blk-pci.ioeventfd=on

I found this:
1/ "shutting down" is triggered by reentrancy into of qemu's
"virtio_blk_data_plane_start()" function (see RedHat's bug #1222574),
2/ commits which introduced this issue are 
      virtio_blk: enable VQs early on restore
(6d62c37f1991aafc872f8d8be8ac60e57ede8605) 
      virtio_net: enable VQs early on restore
(e53fbd11e983e896adaabef2d2f1695d6e0af829)
      virtio_blk: enable VQs early (7a11370e5e6c26566904bb7f08281093a3002ff2)
      virtio_net: enable VQs early (4baf1e33d0842c9673fef4af207d4b74da8d0126) 
   found by deep drive into git history of virtio drivers and several rebuilds
with commits reverts (from 3.17->3.18) 

kernel 3.18.x build with reverted mentioned commits can successfully boot and
run without issues.

Best regards,
Jaroslav

-- 
You are receiving this mail because:
You are watching the assignee of the bug.