qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

qemu 1.1.0 waits for a keypress at boot. Please don't ever do this.

Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard.

Removing -nographic fixes the problem.

Using virtio-scsi instead of virtio-blk fixes the problem.

[Richard W.M. Jones (rich-annexia)]

Also affects upstream qemu from git.

[Richard W.M. Jones (rich-annexia)]

Using -device sga fixes the problem, but also means I cannot see what it's trying to wait for.

[Anthony Liguori (anthony-codemonkey)]

I don't see this problem. Are you sure you're not using the bios from Fedora? Perhaps it's configured incorrectly.

[Richard W.M. Jones (rich-annexia)]

Yes, I tested it again and it does look like it's loading a Fedora ROM. Dammit ...

[Michael Tokarev (mjt+launchpad-tls)]

This is a bit more interesting. I've got a bugreport in debian about the same thing, and verified it in debian qemu-kvm package - indeed, with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without an extra keypress, but only when kernel_irqchip is enabled. Ie, the following requires keypress:

  qemu -machine pc,accel=kvm,kernel_irqchip=on -nographics
  qemu-kvm -nographics

and the following does not:

  qemu -machine pc,accel=kvm -nographics
  qemu-kvm -no-kvm-irqchip -nographics

Thanks,

/mjt

[Richard W.M. Jones (rich-annexia)]

Well that's very interesting because one of the patches we have added in Fedora is:

http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-Add-missing-default-machine-options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD

[Michael Tokarev (mjt+launchpad-tls)]

when the guest is waiting for the keypress, it is sitting in KVM_RUN ioctl and eating 100% CPU. When enabling Seabios debugging, the last lines before the stall is this:

Returned 57344 bytes of ZoneHigh
e820 map has 7 items:
  0: 0000000000000000 - 000000000009dc00 = 1 RAM
  1: 000000000009dc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 000000001fffe000 = 1 RAM
  4: 000000001fffe000 - 0000000020000000 = 2 RESERVED
  5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED
  6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED
enter handle_19:
  NULL
Booting from Hard Disk...
_

So far it only happens when "booting" from a VIRTIO hard disk. With IDE disk it boots fine.

So, in order for it to actually stall,

  qemu -machine pc,accel=kvm,kernel_irqchip=on -drive file=foo,if=virtio -nographics

is needed.

Thanks,

/mjt

[Michael Tokarev (mjt+launchpad-tls)]

Jamie Heilman (the debian bug #680719 reporter) bisected this issue to this commit:

7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini <email address hidden>
Date: Fri Apr 13 19:35:04 2012 +0100

    main_loop_wait: block indefinitely

    - remove qemu_calculate_timeout;

    - explicitly size timeout to uint32_t;

    - introduce slirp_update_timeout;

    - pass NULL as timeout argument to select in case timeout is the maximum
    value;

    Signed-off-by: Stefano Stabellini <email address hidden>
    Acked-by: Paul Brook <email address hidden>
    Signed-off-by: Anthony Liguori <email address hidden>

[Georg Hopp (w-reorg-h)]

I encountered the same thing and created a patch that fixes the problem for me.

This is not a real fix. All i have done is the following:
- Clone the repo.
- Get a reverse diff for the commit in question "git diff 7c7db75..4ffd16f >foo1.patch".
- Try to apply this on master "patch <foo1.patch" and skip all files that could not be found.
- And finally do a "git diff >remove-7c7db75.patch"

As i am a gentoo user i applied this patch within my ebuild and

[Michael Tokarev (mjt+launchpad-tls)]

This is definitely a wrong way to "fix" this issue.

[Paolo Bonzini (bonzini)]

The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to the select() arguments), but I and Avi disagreed on whether ioeventfd=off works. :)

Jamie/Richard/Georg, can you test your respective reproducers without any patch but with -global virtio-blk-pci.ioeventfd=off?

[Thomas Huth (th-huth)]

Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays?

[Richard Jones (rjones-redhat)]

No this refers to a very old version of qemu. This bug should be closed.