disk error when guest boot up via qcow2 image

[Yongjie Ren]

Host OS (ia32/ia32e/IA64): ia32e
Guest OS (ia32/ia32e/IA64): ia32e
Guest OS Type (Linux/Windows): Linux(rhel6u1)
kvm.git Commit: 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0
qemu-kvm Commit: e54f008ef8f968cfc2f3ecab78491d180fa31efc
Host Kernel Version:3.4.0-rc7
Hardware: WSM-EP, Romley-EP

Bug detailed description:
--------------------------
If I boot up a guest using qcow2 image, the guest show “disk read error”. If you press some key to continue, after being automatically repaired, the guest can boot up.

This should be a qemu-kvm regression.
kvm + qemu-kvm = result
51bfd299 + e54f008e = bad
51bfd299 + b320b8b7 = good

Note:
1. guest rhel6u1, guest show “disk error”
   guest rhel6u2, guest show black screen
   this phenomenon occurs at the first time to create guest
2. create guest with raw image, this phenomenon doesn’t appear.

Reproduce steps:
----------------
1.start up a host with kvm (commit: 51bfd299) and use qemu-kvm (commit:e54f008e)
2.qemu-img create –b /share/ia32e_rhel6u1.img –f qcow2
/root/rhel6u1.qcow
3.qemu-system-x86_64 -mem 1024 –hda /root/rhel6u1.qcow

Current result:
----------------
Guest console shows:
error 25:Disk read error
Prss any key to continue...

Expected result:
----------------
Guest boot up correctly

[Yongjie Ren (yongjie-ren)]

Latest commit 3fd9fedb in qemu-kvm master tree still has this issue.

[Yongjie Ren (yongjie-ren)]

after reverting bef0fd59 in qemu-kvm, this issue doesn't exist.

[Jan Kiszka (jan-kiszka)]

Hmm, it might be related if the error happens during early boot: Could you try if

http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92036

makes a difference in your scenario?

[Michael Tokarev (mjt+launchpad-tls)]

I can't reproduce it no matter how I try

[Yongjie Ren (yongjie-ren)]

reply to Jan Kiszka:

I looked at the patch in uq/master branch in qemu-kvm.git as you mentioned.
There's another issue in uq/master branch, so I can't conclude whether your patch will make a difference.

The issue is Windows(e.g. win7) will get a BSOD with a message "STOP: ox0000005D".
RAW Windows image or qcow image will have the same BSOD issue.
And Linux guest also has similar issue with uq/master branch.

You can use the following commit in uq/master branch to have a try.
commit: d3d3bef0a (before your patch "i8254: Fix conversion of in-kernel to userspace state")
latest commit: 0cdd3d14 (already included your pathch)

And, qemu-kvm.git master branch (18b01275) doesn't have the BSOD issue.

[Yongjie Ren (yongjie-ren)]

reply to Michael Tokarev:
    Windows qcow2 image will be more easier for reproducing the issue I reported. And there's a great chance to reproduce it when you do the first try after rebooting the system.

[Yongjie Ren (yongjie-ren)]

Re-tested against latest qemu-kvm master branch with commit 0a948cbb. And found this issue has gone.
Jan Kiszka's following patch fixed this bug.

commit 0cdd3d14447da1a04e778c219c77db8b96f9cf33
Author: Jan Kiszka
Date: Wed Jun 6 16:28:42 2012 +0200

    kvm: i8254: Fix conversion of in-kernel to userspace state

    Due to a offset between the clock used to generate the in-kernel
    count_load_time (CLOCK_MONOTONIC) and the clock used for processing this
    in userspace (vm_clock), reading back the output of PIT channel 2 via
    port 0x61 was broken. One use cases that suffered from it was the CPU
    frequency calibration of SeaBIOS, which also affected IDE/AHCI timeouts.

    This fixes it by calibrating the offset between both clocks on
    kvm_pit_get and adjusting the kernel value before saving it in the
    userspace state. As the calibration only works while the vm_clock is
    running, we cache the in-kernel state across stopped phases.

    Signed-off-by: Jan Kiszka