[Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
Guys, If I run Linux kernel 2.6.24.3 and then start a qemu virtual machine running Windows XP as the guest operating system the CPU usage is high, always close to 100%, and the virtual machine slower than normal. Once I am able to log in to windows, task manager shows the CPU usage permanently at 100%, even when Windows should be idle, and higher than normal usage from the csrss process. I attach a screen shot of task manager showing this. Looking at the CPU usage from Linux when windows is idle it is notable that most of the CPU usage is user-mode. By comparison, with exactly the same virtual hard disk image and the same version of qemu (and kqemu) and kernel 2.6.23.12 the CPU usage is much lower and windows runs faster. When windows is idle the CPU usage is low and when Windows is active the CPU usage is approximately 2/3 user and 1/3 system. The qemu versions concerned are as follows: qemu 0.9.0 kqmeu 1.3.0pre11 The hardware is an AMD64 processor and 1GB RAM. The problem with 2.6.24 seems only to occur with kqemu and also appears in dependant of whether dynamic ticks is enabled. A couple of timings should illustrate the difference. From VM start to login prompt: no kqemu=2m0s, 2.6.23=1m2s, 2.6.24=1m27s. From login to last systray icon: no kqemu=6m25s, 2.6.23=1m47s, 2.6.24=4m46s Does anyone have any insight as to what may be happening or what tools I could use to gather enough information to help you guys diagnose the problem? Regards, Steve. attachment: taskmg.png
Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On Thu, Mar 6, 2008 at 11:58 AM, Steve Fosdick [EMAIL PROTECTED] wrote: The hardware is an AMD64 processor and 1GB RAM. The problem with 2.6.24 seems only to occur with kqemu and also appears in dependant of whether dynamic ticks is enabled. A couple of timings should illustrate the difference. From VM start to login prompt: no kqemu=2m0s, 2.6.23=1m2s, 2.6.24=1m27s. From login to last systray icon: no kqemu=6m25s, 2.6.23=1m47s, 2.6.24=4m46s Does anyone have any insight as to what may be happening or what tools I could use to gather enough information to help you guys diagnose the problem? did you compile both kernels yourself, with similar/compatible config/compilers ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 08/03/06 16:13:51 Modified files: target-sparc : translate.c Log message: Fix microSPARC II SFSR mask (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.96r2=1.97
[Qemu-devel] qemu/target-sparc cpu.h exec.h helper.h op.c tr...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 08/03/06 20:09:54 Modified files: target-sparc : cpu.h exec.h helper.h op.c translate.c Log message: Convert exception ops to TCG CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemur1=1.65r2=1.66 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/exec.h?cvsroot=qemur1=1.26r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/helper.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.53r2=1.54 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.97r2=1.98
[Qemu-devel] qemu/hw vmware_vga.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 08/03/06 20:28:49 Modified files: hw : vmware_vga.c Log message: Register VMware SVGA's memory io region with PCI framework. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vmware_vga.c?cvsroot=qemur1=1.7r2=1.8
[Qemu-devel] qemu/hw vmware_vga.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 08/03/06 20:43:34 Modified files: hw : vmware_vga.c Log message: Check for out of range update regions (original patch from Anthony Liguori). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vmware_vga.c?cvsroot=qemur1=1.8r2=1.9
[Qemu-devel] qemu Makefile.target hw/omap.h hw/omap1.c hw/om...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 08/03/06 21:07:38 Modified files: . : Makefile.target hw : omap.h Added files: hw : omap1.c omap_clk.c omap_dma.c Removed files: hw : omap.c omap1_clk.c Log message: Split OMAP DMA out to a file apart. Rename omap files to better reflect OMAP1-specific parts. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.247r2=1.248 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.h?cvsroot=qemur1=1.22r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap1.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_clk.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap_dma.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.35r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap1_clk.c?cvsroot=qemur1=1.4r2=0
Re: [Qemu-devel] [PATCH] Support redirect -curses over a character driver
Avi Kivity wrote: Anthony Liguori wrote: Yes. I was actually thinking of tunneling the curses data but another option would be a more proper character-based encoding. The advantage of that is that you could also send over fonts. curses is very un-vnc-like, it's a single stream an you need all of it to get something meaningful. Much more in the spirit of vnc is to encode 'character tiles', and to allow coalesced updates like the regular vnc protocol. Yes, my main interest in curses was to avoid having to deal with character mapping. I was planning on just using vte terminal to render the data. Maybe doing a proper encoding is the right thing to do though. Ah, CGA as in color graphics adapter. Why not add the encoding to vnc and use the regular -vnc option? if both viewer and server support the feature, and if the display is in text mode, it would be used automatically. Yes, this is what I want. I still want to be able to connect to it via telnet though independent of VNC. Regards, Anthony Liguori
[Qemu-devel] PATCH: allow i386 debugging when segment offset != 0
Hi all,
This patch makes QEMU's gdb debugging stub and CPU breakpoints work when
the segment offset is not 0.
Previously, the debugging stub assumed the segment offset was 0, leading
to very odd behavior.
This patch assumes that the code segment and data segment have the same
offset. This is a reasonable assumption. Making the code work for
different code and data offsets would be more invasive.
Please accept this patch (this is a resend.)
Eddie Kohler
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.62
diff -u -r1.62 helper2.c
--- target-i386/helper2.c 24 Dec 2007 14:04:06 - 1.62
+++ target-i386/helper2.c 6 Mar 2008 22:46:46 -
@@ -1081,6 +1081,7 @@
{
uint32_t pde_addr, pte_addr;
uint32_t pde, pte, paddr, page_offset, page_size;
+addr += env-segs[R_DS].base;
if (env-cr[4] CR4_PAE_MASK) {
uint32_t pdpe_addr, pde_addr, pte_addr;
Index: target-i386/translate.c
===
RCS file: /sources/qemu/qemu/target-i386/translate.c,v
retrieving revision 1.79
diff -u -r1.79 translate.c
--- target-i386/translate.c 24 Feb 2008 07:45:42 - 1.79
+++ target-i386/translate.c 6 Mar 2008 22:46:46 -
@@ -6740,7 +6740,7 @@
for(;;) {
if (env-nb_breakpoints 0) {
for(j = 0; j env-nb_breakpoints; j++) {
-if (env-breakpoints[j] == pc_ptr) {
+if (env-breakpoints[j] == pc_ptr - dc-cs_base) {
gen_debug(dc, pc_ptr - dc-cs_base);
break;
}
