Hi !
I've found a bug in Qemu FPU emulation: conversion of floats to strings fails
in some cases. For example, Ganglia (cluster monitoring software), shows
random values. If I add debug in gmond, I get this:
VALUE =2.G= =2.343750=
VALUE =2.G= =2.343750=
VALUE =9Ö= =93.487236=
VALUE =0.6o=
I managed to compile and use qemu as a shared library for the ii386
user space emulator.
I didn't use -fPIC to compile anything and simply generated the lib by
adding something like this in Makefile.target:
$(CC) -shared -Wl,-soname,libqemu.so.0 -o libqemu.so.0 $(LIBOBJS) -lc
I am not sure it
Paul Brook wrote:
Does anyone know the reason for the removal of the mmap()? I have used
a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
memory access in the guest WinXP was slooow. Does anyone have any
insight on making the hardware MMU function for linux-x86 host to
If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
as most code isn't run by qemu, it's virtualized by the accelerator. qemu
just does the IO emulation.
Paul
OK, so mmap is not the way to increase some speed. What needs to be
done to provide a higher Qemu+KQEMU
I'm also doubtful how much benefit it gave in practice. I'm sure it would
be good for synthetic CPU benchmarks. However using mmap significantly
increases the overhead of context switches/tlb misses.
To get good overall performance I suspect you're going to need closer
cooperation with the
On Fri, 2006-12-15 at 17:20 -0500, Joseph Miller wrote:
I've got a copy of today's CVS, I was just assuming, since this is the
qemu-devel mailing list, that someone on the list who regularly works on
the qemu code would probably know more about this than I do. I have
some assembly
On Friday 15 December 2006 22:20, Joseph Miller wrote:
Paul Brook wrote:
If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
as most code isn't run by qemu, it's virtualized by the accelerator.
qemu just does the IO emulation.
Paul
OK, so mmap is not the way to
On 12/15/06, Paul Brook [EMAIL PROTECTED] wrote:
I've got a copy of today's CVS,
You missed my point entirely. kqemu is a closed source module, there's
absolutely nothing we can do with it.
well, we can use kqemu at least, right? :)
interesting benchmark: I started removing most of the
On Fri, 2006-12-15 at 22:48 +0100, Christian MICHON wrote:
Using kqemu, I see no improvement in calculations, meaning the
graphical part (sdl) is not the main blocking point. Next on my
list of trials is the disk/io (we did some pthread experiment in the
past, I think we can get some more
On Friday 15 December 2006 21:48, Christian MICHON wrote:
On 12/15/06, Paul Brook [EMAIL PROTECTED] wrote:
I've got a copy of today's CVS,
You missed my point entirely. kqemu is a closed source module, there's
absolutely nothing we can do with it.
well, we can use kqemu at least,
On 12/15/06, Paul Brook [EMAIL PROTECTED] wrote:
QEMU is an open source project (and this list is hosted on a site that is
explicitly for open source projects)· Thus any solution that involves
proprietary closed source modules is offtopic.
ok, politically incorrect. point taken :)
yet, what
Is qvm86 still active ? if yes, great. if no, what do you need to restart
it ? (else than dedicated developpers, of course). As far as I can see, no
qvm86 check-in for 15 months now...
Not really. I haven't had chance to do anything with it for a while, and
probably won't in the forseeable
Paul Brook wrote:
OK, so mmap is not the way to increase some speed. What needs to be
done to provide a higher Qemu+KQEMU performance, comparable to
VMPlayer? How does VMPlayer manage to be so much faster than Qemu? Is
this simply an I/O bottleneck? How would I go about finding out
13 matches
Mail list logo
