[Qemu-devel] qemu becomes unresponsive sometimes

[Qemu-devel] qemu becomes unresponsive sometimes

[Paul Jakma]

Hi,

Qemu sometimes becomes unresponsive for periods of time. You cant 
grab the screen, the monitor (with stdio) is unresponsive.

Usually it will come back. However, sometimes not. Eg, I just tried 
"openssl speed" on Solaris on Qemu, and it never came back - just 
using 99% CPU for over an hour.

Is this a known problem?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
You have an ability to sense and know higher truth.

[Qemu-devel] Qemu network.

[Nando]

Hi,

does anyone have or know where i might fetch a floppy image with the 
network configured?
I'm using MSDOS to try this, but could be another free dos.
I can load some network drivers, but i don't get real traffic. And i 
really wanted to try this.

Thank you,

Nando

Re: [Qemu-devel] qemu becomes unresponsive sometimes

[Paul Jakma]

On Thu, 11 Nov 2004, Paul Jakma wrote:

> Qemu sometimes becomes unresponsive for periods of time. You cant grab the 
> screen, the monitor (with stdio) is unresponsive.
>
> Usually it will come back. However, sometimes not. Eg, I just tried "openssl 
> speed" on Solaris on Qemu, and it never came back - just using 99% CPU for 
> over an hour.

In trying to debug this problem and try find vaguely wherein qemu the 
problem lies, I've observed that strace'ing the spinning qemu'ing 
will cause it to become responsive again.

I've actually taken to running my more important qemu instances with 
a backgrounded strace attached, with strace output directed to 
/dev/null.

Anyone know why qemu sometimes become unresponsive, and why does 
stracing qemu make it become responsive again? (for me, typically 
when stressing qemu, eg running 'openssl speed' or some big java 
application). Am I the only one who experiences this?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Argue for your limitations, and sure enough, they're yours.
 		-- Messiah's Handbook : Reminders for the Advanced Soul

Re: [Qemu-devel] qemu becomes unresponsive sometimes

[Mulyadi Santosa]

Hello Paul :-)

> In trying to debug this problem and try find vaguely wherein qemu the
> problem lies, I've observed that strace'ing the spinning qemu'ing
> will cause it to become responsive again.

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

> I've actually taken to running my more important qemu instances with
> a backgrounded strace attached, with strace output directed to
> /dev/null.

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). After that, the parent 
process (the shell which fork Qemu) will continue the execution of Qemu 
binary by sending signal

So, my suspicion, somehow Qemu is put into task_interruptible by host kernel 
(Linux?) no matter how much is the load. 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"

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? 

regards

Mulyadi

Re: [Qemu-devel] qemu becomes unresponsive sometimes

[Paul Jakma]

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.)

> regards
>
> Mulyadi

regards,
-- 
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune: 
statistics, n.:
 	A system for expressing your political prejudices in convincing
 	scientific guise.

[Qemu-devel] Block chaining question

[Shivkumar Shivaji]

Hi,
      I have done a quick perusal of the code. I was wondering if block 
chaining is performed for conditional jumps? If I want to implement 
such a feature would it have to be done in dyngen? I saw references to 
__op_jmp and cond_jump. However, there does not seem to be chaining 
based on conditional jumps. Am I right?

Thanks, Shivkumar Shivaji

Re: [Qemu-devel] Block chaining question

[Fabrice Bellard]

Shivkumar Shivaji wrote:
> Hi,
>      I have done a quick perusal of the code. I was wondering if block 
> chaining is performed for conditional jumps? If I want to implement such 
> a feature would it have to be done in dyngen? I saw references to 
> __op_jmp and cond_jump. However, there does not seem to be chaining 
> based on conditional jumps. Am I right?

Block chaining is done on conditional jumps too, but it could be more 
optimised with more host specific assembly code.

Fabrice.

Re: [Qemu-devel] Block chaining question

[Shivkumar Shivaji]

Where is conditional block chaining done? Which files? Thought it would 
be easier to ask!

Thanks, Shivkumar Shivaji


On 30-Nov-04, at 2:40 PM, Fabrice Bellard wrote:

> Shivkumar Shivaji wrote:
>> Hi,
>>      I have done a quick perusal of the code. I was wondering if 
>> block chaining is performed for conditional jumps? If I want to 
>> implement such a feature would it have to be done in dyngen? I saw 
>> references to __op_jmp and cond_jump. However, there does not seem to 
>> be chaining based on conditional jumps. Am I right?
>
> Block chaining is done on conditional jumps too, but it could be more 
> optimised with more host specific assembly code.
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel