All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Peter Lieven <pl@dlhnet.de>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop
Date: Thu, 28 Jun 2012 17:22:16 +0200	[thread overview]
Message-ID: <4FEC76A8.6060100@siemens.com> (raw)
In-Reply-To: <4FEC7214.2020900@dlhnet.de>

On 2012-06-28 17:02, Peter Lieven wrote:
> On 28.06.2012 15:25, Jan Kiszka wrote:
>> On 2012-06-28 15:05, Peter Lieven wrote:
>>> Hi,
>>>
>>> i debugged my initial problem further and found out that the problem
>>> happens to be that
>>> the main thread is stuck in pause_all_vcpus() on reset or quit commands
>>> in the monitor
>>> if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modify the
>>> condition from while (ret == 0)
>>> to while ((ret == 0)&&  !env->stop); it works, but is this the right fix?
>>> "Quit" command seems to work, but on "Reset" the VM enterns pause state.
>> Before entering the wait loop in pause_all_vcpus, there are kicks sent
>> to all vcpus. Now we need to find out why some of those kicks apparently
>> don't reach the destination.
> can you explain shot what exactly these kicks do? does these kicks lead
> to leaving the kernel mode and returning to userspace?

Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.

>> Again:
>>   - on which host kernels does this occur, and which change may have
>>     changed it?
> I do not see it in 3.0.0 and have also not seen it in 2.6.38. both
> the mainline 64-bit ubuntu-server kernels (for natty / oneiric 
> respectively).
> If I compile a more recent kvm-kmod 3.3 or 3.4 on these machines,
> it is no longer working.

I was asking for kernel 3.3 or 3.4 without kvm-kmod.

>>   - with which qemu-kvm version is it reproducible, and which commit
>>     introduced or fixed it?
> qemu-kvm-1.0.1 from sourceforge. to get into the scenario it
> is not sufficient to boot from an empty harddisk. to reproduce

Please also try qemu-kvm git to see if something fixed it there.

> i have use a live cd like ubuntu-server 12.04 and choose to
> boot from the first harddisk. i think the isolinux loader does
> not check for a valid bootsector and just executes what is found
> in sector 0. this leads to the mmio reads i posted and 100%
> cpu load (most spent in kernel). at that time the monitor/qmp
> is still responsible. if i sent a command that pauses all vcpus,
> the first cpu is looping in kvm_cpu_exec and the main thread
> is waiting. at that time the monitor stops responding.
> i have also seen this issue on very old windows 2000 servers
> where the system fails to power off and is just halted. maybe
> this is also a busy loop.
> 
> i will try to bisect this asap and let you know, maybe the above
> info helps you already to reproduce.

OK, thanks,

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



  reply	other threads:[~2012-06-28 15:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 13:05 qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop Peter Lieven
2012-06-28 13:25 ` Jan Kiszka
2012-06-28 15:02   ` Peter Lieven
2012-06-28 15:22     ` Jan Kiszka [this message]
2012-06-28 16:29       ` Peter Lieven
2012-06-28 16:32         ` Avi Kivity
2012-06-28 19:27           ` Peter Lieven
2012-07-01  8:19             ` Avi Kivity
2012-07-01  8:19               ` [Qemu-devel] " Avi Kivity
2012-07-01 19:18               ` Peter Lieven
2012-07-01 19:18                 ` [Qemu-devel] " Peter Lieven
2012-07-02  7:05                 ` Jan Kiszka
2012-07-02  7:05                   ` [Qemu-devel] " Jan Kiszka
2012-07-02  8:12                   ` Peter Lieven
2012-07-02  8:12                     ` [Qemu-devel] " Peter Lieven
2012-08-06 15:11 ` Stefan Hajnoczi
2012-08-06 15:11   ` [Qemu-devel] " Stefan Hajnoczi
2012-08-17 13:11   ` Jan Kiszka
2012-08-17 13:11     ` [Qemu-devel] " Jan Kiszka
2012-08-17 14:36     ` Jan Kiszka
2012-08-17 14:36       ` [Qemu-devel] " Jan Kiszka
2012-08-17 14:41       ` Jan Kiszka
2012-08-17 14:41         ` [Qemu-devel] " Jan Kiszka
2012-08-17 15:04         ` Jan Kiszka
2012-08-17 15:04           ` [Qemu-devel] " Jan Kiszka
2012-08-19  9:42           ` Avi Kivity
2012-08-19  9:42             ` [Qemu-devel] " Avi Kivity
2012-08-21  7:21             ` Jan Kiszka
2012-08-21  7:21               ` [Qemu-devel] " Jan Kiszka
2012-08-21  8:23               ` Stefan Hajnoczi
2012-08-21  8:23                 ` [Qemu-devel] " Stefan Hajnoczi
2012-08-22 12:52                 ` Peter Lieven
2012-08-22 12:52                   ` [Qemu-devel] " Peter Lieven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FEC76A8.6060100@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=pl@dlhnet.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.