Skip to contentSkip to conversation

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

Bug 98741 [email protected] 1 participant 1 message May 21, 2015 KVM

lore
Share & tools
lore
#0 lore raw

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: [email protected]
Reporter: [email protected]
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

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.