Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On Sun, 2008-03-09 at 01:14 +, Steve Fosdick wrote: > > kqemu works correctly, whereas with: > > CONFIG_HIGH_RES_TIMERS=y > > the problem appears. Any idea why that causes a problem? Is it a > bug? > > Anyway, at least for now I have a solution. Thanks for your help. While I don't know exactly why it bothers kqemu, it really helps running with kvm. The reason is that the config options takes care that the qemu alarm clock (that all qemu timers) will run with minimal jitter. Another option is to use -clock=rtc or -clock=hpet that will do the same effect. > > Steve.
[Qemu-devel] qemu block-vvfat.c vl.c darwin-user/qemu.h darw...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/03/09 06:59:01 Modified files: . : block-vvfat.c vl.c darwin-user: qemu.h syscall.c hw : alpha_palcode.c target-i386: helper.c svm.h Log message: Fix some functions declared () rather than (void) (Ian Jackson) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-vvfat.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.407&r2=1.408 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/qemu.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/syscall.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/alpha_palcode.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.101&r2=1.102 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/svm.h?cvsroot=qemu&r1=1.1&r2=1.2
Re: [Qemu-devel] High CPU Usage with Linux 2.6.24 and Windows XP Guest (but not with 2.6.23)
On Fri, 7 Mar 2008 10:58:39 +0100 "Christian MICHON" <[EMAIL PROTECTED]> wrote: > it's really a lot of differences... could you find a minimal kernel > config (which could be almost identical for 2.6.23 and 2.6.24) showing > the slowdown? I have found a single config change that causes the problem. With: # CONFIG_HIGH_RES_TIMERS is not set kqemu works correctly, whereas with: CONFIG_HIGH_RES_TIMERS=y the problem appears. Any idea why that causes a problem? Is it a bug? Anyway, at least for now I have a solution. Thanks for your help. Steve.
[Qemu-devel] qemu/target-sparc op.c translate.c fbranch_temp...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/03/08 21:36:50 Modified files: target-sparc : op.c translate.c Removed files: target-sparc : fbranch_template.h Log message: Convert branches and conditional moves to TCG CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemu&r1=1.54&r2=1.55 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.98&r2=1.99 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/fbranch_template.h?cvsroot=qemu&r1=1.1&r2=0
[Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Sat, 2008-03-08 at 14:59 +0100, Aurelien Jarno wrote:
> On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> > On Tue, 04 Mar 2008 01:30:15 +0100, Aurelien Jarno wrote:
> >
> > > This patches fixes endianness issues in the e1000 nic emulation, which
> > > currently only works on little endian hosts with little endian targets.
> > >
> > > Byte swapping is only needed on big endian targets, as PCI is always
> > > little endian. cpu_to_le32 and le32_to_cpu functions do not work in that
> > > case as they refer to the host endianness and not the target one.
> > >
> > > I have tested it on both little and big endian targets (mipsel and mips)
> > > on both little and big endian hosts (amd64 and powerpc using a
> > > backported version of e1000.c on top of 0.9.1).
> > >
> > > Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> ---
> > > hw/e1000.c | 23 --- 1 files changed, 16
> > > insertions(+), 7 deletions(-)
> > >
> > > diff --git a/hw/e1000.c b/hw/e1000.c
> > > index 943f25f..d8419ce 100644
> > > --- a/hw/e1000.c
> > > +++ b/hw/e1000.c
> > > @@ -720,8 +720,11 @@ e1000_mmio_writel(void *opaque, target_phys_addr_t
> > > addr, uint32_t val)
> > > E1000State *s = opaque;
> > > unsigned int index = ((addr - s->mmio_base) & 0x1) >> 2;
> > >
> > > +#ifdef TARGET_WORDS_BIGENDIAN
> > > +val = bswap32(val);
> > > +#endif
> > ...
> >
> > I cannot explain your successful testing results without further
> > investigation. (More than likely, there is another qemu emulation layer
> > that is also incorrectly swapping, canceling this out.) However, almost
> > all code using TARGET_WORDS_BIGENDIAN is wrong. Yes, I know there's a
> > lot of it, and it's all wrong.
> >
>
> The problem is actually that the GT64xxx is able to byteswap PCI
> accesses depending on a configuration bit, which is enabled by the Linux
> kernel. That means that those TARGET_WORDS_BIGENDIAN are indeed wrong
> and only a workaround for that case.
>
> To fix the problem, we need to be able to register byteswapped memory
> regions. Does someone have an idea how to do that?
That is an interesting situation.
I don't know qemu internals enough, but from what I've seen this is not
currently possible.
If I were going to add such a thing, I would add an "address space"
argument to cpu_register_physical_memory(), and PCI devices would
specify the address space of the PCI controller. (Note: this would also
help solve qemu's "can't relocate PCI controller BARs" limitation.)
With this system, the PCI controller would register a callback for its
entire physical address space in the "root" IO table. In the gt64xxx
case, that callback would check the config bit and perform whatever
swapping is appropriate, then dispatch to the device callback via a
second IO table.
> > Below is a patch I'm using to fix rtl8139.c for PowerPC/PowerPC
> > target/host combination. It works enough for the target to send a DHCP
> > request and get a response from slirp, but other unrelated bugs prevent
> > me from testing it more thoroughly. (I'm only sending it now at
> > Aurelien's request.) Other code that I know is broken (because I've
> > tried to use it) include isa_mmio.c and pci_host.h, but I don't have
> > patches for these at this time.
>
>
>
>
> > Fix endianness conversion in rtl8139.c.
> >
> > PCI data is always in LE format, so convert from LE at the interface to
> > "qemu endianness" internally, then convert again on the way back out.
> >
> > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> >
> > diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
> > --- a/qemu/hw/rtl8139.c
> > +++ b/qemu/hw/rtl8139.c
> > @@ -2735,13 +2735,8 @@ static void rtl8139_io_writew(void *opaq
> > default:
> > DEBUG_PRINT(("RTL8139: ioport write(w) addr=0x%x val=0x%04x
> > via write(b)\n", addr, val));
> >
> > -#ifdef TARGET_WORDS_BIGENDIAN
> > -rtl8139_io_writeb(opaque, addr, (val >> 8) & 0xff);
> > -rtl8139_io_writeb(opaque, addr + 1, val & 0xff);
> > -#else
> > rtl8139_io_writeb(opaque, addr, val & 0xff);
> > rtl8139_io_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> > -#endif
> > break;
> > }
> > }
> > @@ -2802,17 +2797,10 @@ static void rtl8139_io_writel(void *opaq
> >
> > default:
> > DEBUG_PRINT(("RTL8139: ioport write(l) addr=0x%x val=0x%08x
> > via write(b)\n", addr, val));
> > -#ifdef TARGET_WORDS_BIGENDIAN
> > -rtl8139_io_writeb(opaque, addr, (val >> 24) & 0xff);
> > -rtl8139_io_writeb(opaque, addr + 1, (val >> 16) & 0xff);
> > -rtl8139_io_writeb(opaque, addr + 2, (val >> 8) & 0xff);
> > -rtl8139_io_writeb(opaque, addr + 3, val & 0xff);
> > -#else
> > rtl8139_io_writeb(opaque, addr, val & 0xff);
> > rtl8139_io_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> > rtl8139_io_writeb(opaque, addr + 2, (val >> 16) &
Re: [Qemu-devel] Questions/comments on TCG
On 3/7/08, Blue Swirl <[EMAIL PROTECTED]> wrote:
> On 3/7/08, Stuart Brady <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 07, 2008 at 08:47:03PM +0200, Blue Swirl wrote:
> > > On 3/7/08, Stuart Brady <[EMAIL PROTECTED]> wrote:
> >
> > > > tcg_target_reg_alloc_order[] has 32 elements, but only 14 are used.
> > > > The rest hold 0, specifying TCG_REG_G0.
> > >
> > > I see. That could be asking for trouble.
> >
> >
> > Possibly not, as g0 is marked as reserved, but it looks to me like bug,
> > regardless of whether it causes any harm, so I've submitted a patch.
> >
> >
> > > > I don't understand -- o7 is required when returning in exit_tb, so if
> it
> > > > is used, it must be saved and restored.
> > >
> > > Not exit_tb, but call.
> >
> >
> > Right, op_call does need to link, and that clobbers the link register,
> > so it must be restored -- but I've a feeling that this isn't happening.
> > I expect you could copy o7 to/from i5 before/after the call (or jmpl)...
> > although I'm not sure if you'd also need to save the frame pointer.
>
>
> Another possibility is to add function epilogue with save and add
> restore to ret (or use v9 return).
I added the save and restore instructions, because if the generated
code made any calls, the registers were overwritten.
Currently on Sparc64 host a small helloworld program executes until
the system call, then Qemu dies with illegal instruction. It looks
like this is caused by setjmp/longjmp register mangling bugs in Linux
glibc, my workaround does not help. I'd be interested to hear if this
works any better on Solaris/Sparc or *BSD/Sparc. On Sparc32 TB linking
does not work, so Qemu dies on TB switch.
#define __KERNEL__
#include
static int errno;
static __inline__ _syscall1(void,exit,int,exitval)
static inline _syscall3(int,write,int,fd,const char *,buf,long,count)
int _start()
{
write(2, "Hello World!\n", sizeof("Hello World!\n"));
exit(0);
}
helloworld.sparc32
Description: Binary data
[Qemu-devel] Re: [PATCH] e1000: fix endianness issues
On Fri, Mar 07, 2008 at 11:23:51AM -0600, Hollis Blanchard wrote:
> On Tue, 04 Mar 2008 01:30:15 +0100, Aurelien Jarno wrote:
>
> > This patches fixes endianness issues in the e1000 nic emulation, which
> > currently only works on little endian hosts with little endian targets.
> >
> > Byte swapping is only needed on big endian targets, as PCI is always
> > little endian. cpu_to_le32 and le32_to_cpu functions do not work in that
> > case as they refer to the host endianness and not the target one.
> >
> > I have tested it on both little and big endian targets (mipsel and mips)
> > on both little and big endian hosts (amd64 and powerpc using a
> > backported version of e1000.c on top of 0.9.1).
> >
> > Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> ---
> > hw/e1000.c | 23 --- 1 files changed, 16
> > insertions(+), 7 deletions(-)
> >
> > diff --git a/hw/e1000.c b/hw/e1000.c
> > index 943f25f..d8419ce 100644
> > --- a/hw/e1000.c
> > +++ b/hw/e1000.c
> > @@ -720,8 +720,11 @@ e1000_mmio_writel(void *opaque, target_phys_addr_t
> > addr, uint32_t val)
> > E1000State *s = opaque;
> > unsigned int index = ((addr - s->mmio_base) & 0x1) >> 2;
> >
> > +#ifdef TARGET_WORDS_BIGENDIAN
> > +val = bswap32(val);
> > +#endif
> ...
>
> I cannot explain your successful testing results without further
> investigation. (More than likely, there is another qemu emulation layer
> that is also incorrectly swapping, canceling this out.) However, almost
> all code using TARGET_WORDS_BIGENDIAN is wrong. Yes, I know there's a
> lot of it, and it's all wrong.
>
The problem is actually that the GT64xxx is able to byteswap PCI
accesses depending on a configuration bit, which is enabled by the Linux
kernel. That means that those TARGET_WORDS_BIGENDIAN are indeed wrong
and only a workaround for that case.
To fix the problem, we need to be able to register byteswapped memory
regions. Does someone have an idea how to do that?
[snip]
>
> Below is a patch I'm using to fix rtl8139.c for PowerPC/PowerPC
> target/host combination. It works enough for the target to send a DHCP
> request and get a response from slirp, but other unrelated bugs prevent
> me from testing it more thoroughly. (I'm only sending it now at
> Aurelien's request.) Other code that I know is broken (because I've
> tried to use it) include isa_mmio.c and pci_host.h, but I don't have
> patches for these at this time.
> Fix endianness conversion in rtl8139.c.
>
> PCI data is always in LE format, so convert from LE at the interface to
> "qemu endianness" internally, then convert again on the way back out.
>
> Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
>
> diff --git a/qemu/hw/rtl8139.c b/qemu/hw/rtl8139.c
> --- a/qemu/hw/rtl8139.c
> +++ b/qemu/hw/rtl8139.c
> @@ -2735,13 +2735,8 @@ static void rtl8139_io_writew(void *opaq
> default:
> DEBUG_PRINT(("RTL8139: ioport write(w) addr=0x%x val=0x%04x via
> write(b)\n", addr, val));
>
> -#ifdef TARGET_WORDS_BIGENDIAN
> -rtl8139_io_writeb(opaque, addr, (val >> 8) & 0xff);
> -rtl8139_io_writeb(opaque, addr + 1, val & 0xff);
> -#else
> rtl8139_io_writeb(opaque, addr, val & 0xff);
> rtl8139_io_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> -#endif
> break;
> }
> }
> @@ -2802,17 +2797,10 @@ static void rtl8139_io_writel(void *opaq
>
> default:
> DEBUG_PRINT(("RTL8139: ioport write(l) addr=0x%x val=0x%08x via
> write(b)\n", addr, val));
> -#ifdef TARGET_WORDS_BIGENDIAN
> -rtl8139_io_writeb(opaque, addr, (val >> 24) & 0xff);
> -rtl8139_io_writeb(opaque, addr + 1, (val >> 16) & 0xff);
> -rtl8139_io_writeb(opaque, addr + 2, (val >> 8) & 0xff);
> -rtl8139_io_writeb(opaque, addr + 3, val & 0xff);
> -#else
> rtl8139_io_writeb(opaque, addr, val & 0xff);
> rtl8139_io_writeb(opaque, addr + 1, (val >> 8) & 0xff);
> rtl8139_io_writeb(opaque, addr + 2, (val >> 16) & 0xff);
> rtl8139_io_writeb(opaque, addr + 3, (val >> 24) & 0xff);
> -#endif
> break;
> }
> }
> @@ -2958,13 +2946,8 @@ static uint32_t rtl8139_io_readw(void *o
> default:
> DEBUG_PRINT(("RTL8139: ioport read(w) addr=0x%x via read(b)\n",
> addr));
>
> -#ifdef TARGET_WORDS_BIGENDIAN
> -ret = rtl8139_io_readb(opaque, addr) << 8;
> -ret |= rtl8139_io_readb(opaque, addr + 1);
> -#else
> ret = rtl8139_io_readb(opaque, addr);
> ret |= rtl8139_io_readb(opaque, addr + 1) << 8;
> -#endif
>
> DEBUG_PRINT(("RTL8139: ioport read(w) addr=0x%x val=0x%04x\n",
> addr, ret));
> break;
> @@ -3031,17 +3014,10 @@ static uint32_t rtl8139_io_readl(void *o
> default:
> DEBUG_PRINT(("RTL8139: ioport read(l) addr=0x%x via read(b)\n",
> addr));
>
> -#ifdef TARGET_WORDS_BIGENDIAN
> -
[Qemu-devel] qemu/tcg tcg.c sparc/tcg-target.c sparc/tcg-tar...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/03/08 13:33:42 Modified files: tcg: tcg.c tcg/sparc : tcg-target.c tcg-target.h Log message: Add function prologue, fix pointer load on Sparc64 host CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/sparc/tcg-target.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/sparc/tcg-target.h?cvsroot=qemu&r1=1.1&r2=1.2
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 12:58 PM, Steve Fosdick <[EMAIL PROTECTED]> wrote: > 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. It may be bug, but I'd go with simpler possibilities. 4x slowdown is about the one you get when going from virtualization to emulation. In other words, your new kernel may not have kqemu compiled. The slowdown may make the usage of csrss more obvious. The Client/Server Runtime Server Subsystem is usual target of multiple viruses and trojans, so check your windows and the network activities.
