Hi!
David Abrahams wrote:
[...]
>>What happens if you hide the qemu window below another one, e.g. your
>>favorite web browser?
>
>
> It seems to make progress. I can play internet radio in the VM and I
> keep hearing it (glitchy, but it doesn't stop).
What about the load?
By the way, how is your DISPLAY variable set? It should be ":0", not
"localhost:0" or "hostname:0". Otherwise video output will slow down
(and you'll probably see a lot of network load on the lo device).
>>>In fact, kvm doesn't seem to make any progress at all :(. I'm
>>>currently going through the "microsoft update" dance on a VM there,
>>>and I literally left for an hour during which there was no progress
>>>because the QEMU window wasn't visible.
>>>
>>>Even stranger, if I minimize the QEMU window and then switch
>>>workspaces, it gets plenty of cycles.
>>
>>I guess that's a qemu and/or SDL issue.
>
>
> SDL?
Simple Directmedia Layer (see www.libsdl.org).
It's a library that Qemu uses for video output.
>>Ideally, the screen should only be updated when the window is mapped
>>(via XMapWindow) *and* visible (that is, neither fully obscured nor
>>moved outside the visible part of the screen). Since "fully obscured" is
>>hard to test for, this usually translates to "mapped and not off-screen".
>
>
> Yeah, but I don't care about the window being updated. I want the
> virtual CPU to make progress. Switching workspaces is literally like
> suspending the VM!
Maybe the qemu process is waiting for something (like an expose event
from the X server - which will never happen as long as the window is
invisible). What does ps/top report?
>>When a window is minimized ("iconified"), it usually is unmapped and
>>another one (the "icon window") is mapped instead. When switching
>>workspaces, however, some window managers just move the window away (say
>>to x=10000,y=10000) but keep it mapped. If there is no test for
>>visibility (or if the test doesn't work correctly), SDL may happily
>>continue updating the window's contents - and that will burn a lot of
>>cycles.
>>
>>IMO, there's a lot of room for improvement here. But it has nothing to
>>do with kvm in the first place (unless you consider qemu an integral
>>part of kvm, which I don't).
>
>
> I don't either, but it's not 100% clear to me yet that this is a qemu
> problem. Maybe I'll report it in a QEMU forum as well.
Since it's related to screen output, it's likely to be a qemu/SDL
problem. The kvm module itself doesn't do any screen i/o.
Does qemu behave differently if you use -no-kvm?
--
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
