[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu becomes unresponsive sometimes

From: Paul Jakma
Subject: Re: [Qemu-devel] qemu becomes unresponsive sometimes
Date: Sun, 28 Nov 2004 11:00:21 +0000 (GMT)

On Sun, 28 Nov 2004, Mulyadi Santosa wrote:

First, let me ask for confirmation, do you run Qemu on Solaris or Linux host? If this is on solaris, maybe my whole assumption would be useless

On Linux, Linux has bridging. I've not tried to run Linux as a qemu instance yet, but i intend to soon (as well as some BSDs).

For me, the problem is easily reproducable by running something very intensive in the "qemud" host, eg openssl speed.

Running strace on binary only change one thing: on every syscall, it will be recorded as mentioned by ptrace behaviour. AFAIK, this recording will make the traced binary (in this case Qemu binary) halt on each syscall invocation and signal receive. (man strace and man ptrace).

And syscall exit.

After that, the parent process (the shell which fork Qemu)

Well, strace in this case. (and an attached strace - not parent).

will continue the execution of Qemu binary by sending signal

With ptrace (PTRACE_CONT, ...) actually, AIUI.

So, my suspicion, somehow Qemu is put into task_interruptible by host kernel (Linux?) no matter how much is the load.

I've no idea unfortunately. I was hoping I could find a clue as to what the problem was by stracing qemu, but seeing as how the problem disappears when i do that... and I dont know anything about qemu internals unfortunately - is there a central scheduler loop somewhere I could add debug instrumentation to?

Also, does qemu make heavy use of signals? From an ltrace of qemu, it looks like it might be up to some trickery with SIG_IO - but that could be SDL. Sadly, I dont know enough of qemu. :(

But, it is possible that it is not the whole Qemu that is unresponsive, maybe it is just the Qemu monitor/display that is put into "sleep"

The whole qemu host, along with qemu monitor and SDL display is unresponsive - my ssh session to the host stop responding, the hosted kernel stops responding to pings - and qemu usually takes 99% CPU, so its up to something, just not to do with servicing the hosted OS or any other external events/IO (AFAICT).

What do you think ? Fabrice any comment? Maybe we need to force waking up the whole Qemu process (SDL output, monitor, VNC perhaps) everytime there is a "CPU" activity inside the guest kernel?

I'd love to have this fixed. If someone were to, I'd reward them with as much Guinness as they could drink in a night ;) (offer redeemable at any decent pub in Dublin city or west Dublin county.)



Paul Jakma address@hidden address@hidden Key ID: 64A2FF6A
Fortune: statistics, n.:
        A system for expressing your political prejudices in convincing
        scientific guise.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]