Description of problem: After performing suspend to disk to rhel5.4, boot guest with same cmd, got error "Guest moved used index from 6479 to 25579" and qemu quit. Version-Release number of selected component (if applicable): 83-105 How reproducible: 100% Steps to Reproduce: 1.boot guest by; /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 8 -net nic,macaddr=20:20:20:90:80:65,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:80:66,model=e1000,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -vnc :5& 2.#cd /sys/power/ 3.#echo disk > state 4.after suspend finish, restart guest by the same cmd. Actual results: # Guest moved used index from 6479 to 25579 [1]+ Exit 1 /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 8 -net nic,macaddr=20:20:20:90:80:65,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:80:66,model=e1000,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -vnc :5 Expected results: Additional info: rhel5.4 with ide block does not have this problem.
This bug can be reproduced on kvm-83-83 and kvm-83-94
bug #497504 had a similar error
Also happened to me: KVM 112, Windows 2008 R2, with 2 vCPUs, after resume, with virtio-net (and IDE). Raised severity and priority a bit.
Yan and Yuri analysed it as an issue of missing device reset call when the pci status register sets its RST bit.
We posted kvm rpm to Yaniv. Any news?
(In reply to comment #6) > We posted kvm rpm to Yaniv. Any news? The guest is no longer crashes. But there are test hangs in the device path verified with PNP test. Probably our driver bug.
*** This bug has been marked as a duplicate of bug 521829 ***
Not sure that this bug is duplicated. The symptom seams the same as for https://bugzilla.redhat.com/show_bug.cgi?id=521829 but I think it worth checking if the solution also applicable here
(In reply to comment #5) > Yan and Yuri analysed it as an issue of missing device reset call when the pci > status register sets its RST bit. AFAIK PCI status does not have a reset bit. Yan, Yuri, please document your findings somewhere.
(In reply to comment #11) > (In reply to comment #5) > > Yan and Yuri analysed it as an issue of missing device reset call when the pci > > status register sets its RST bit. > > AFAIK PCI status does not have a reset bit. > Yan, Yuri, please document your findings somewhere. We never said it was RST bit , it is probably Dor's mistake when he described the bug. As you also can see from the sources we are talking about command register and bus master bit (0x04 D:2)
Could you please document your findings here? Do you see a value written into the device control register? What is this value? Also, Yaniv reports that with new drivers and fixed qemu memory corruption bug, the issue does not happen anymore. Do you still think there's an issue that needs to be fixed? If yes, could you check what happens with the control register write after qemu is fixed, please?
(In reply to comment #4) > Also happened to me: > KVM 112, Windows 2008 R2, with 2 vCPUs, after resume, with virtio-net (and > IDE). > Raised severity and priority a bit. Seems like an unrelated issue.
Could this be tested with new patch from https://bugzilla.redhat.com/show_bug.cgi?id=524557 ? If does not help, can also try testing with old patch from same bug, just as an additional datapoint.
This bug has no any connection or similarity to 524557. The is likely bug in virtio-blk guest driver WRT suspend (bug report states that the problem doesn't happen with IDE, but it will be good to reproduce without virtio-net to completely rule it out). Somebody familiar with guest driver should look at it.
can you retest with virtio-disk but without virtio-net?
(In reply to comment #18) > can you retest with virtio-disk but without virtio-net? retest with virtio block but without virtio-net in kvm-83-105.el5_4.4, this problem can be reproduced. cmd: Steps to Reproduce: 1.boot guest by; /usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -drive file=rhel-5.4-64-block.raw,if=virtio,boot=on -cpu qemu64,+sse2 -m 8G -smp 4 -net nic,macaddr=20:20:20:11:44:99,model=e1000,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -vnc :5& 2.#cd /sys/power/ 3.#echo disk > state 4.after suspend finish, restart guest by the same cmd. Actual results: # Guest moved used index from 5627 to 0
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Suspend to disk of guest with virtio block does not work. Some logic is missing both in the driver and the device layers
Dor, we are talking here about: 1. *Internal* guest suspend to disk - not QEMU's migration to file, right? 2. With all virtio devices? I've had something similar with Win2K8 and virtio-net - or is it a different issue? We need to be more clear on the release notes.
Yaniv, yes.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Suspend to disk of guest with virtio block does not work. Some logic is missing both in the driver and the device layers+Guests cannot presently use suspend to disk options with the para-virtualized block drivers. Presently, some required functionality for suspending is missing both in the driver and the device layers.
*** Bug 657182 has been marked as a duplicate of this bug. ***