Re: RE : Re: [Qemu-devel] Bounce message
2006/12/14, Sylvain Petreolle <[EMAIL PROTECTED]>: I am getting bounce messages from Rebecca Langley too, this is becoming annoying. > Who is the list owner of qemu-devel and can remove > Rebecca Langley from the subscriber list? [EMAIL PROTECTED] I already mailed them M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About performance of qemu-system-arm
2006/12/13, Martin Guy <[EMAIL PROTECTED]>: 2006/12/13, PianoPan <[EMAIL PROTECTED]>: > performance of Linux in Qemu is too slow. It > uses about one hour to boot GUI system. During development work this summer at one point I experienced an immense slowdown of QEMU - from 63 bogomips to 1 or 2 Sorry I forgot to say, that was with qemu-system-arm 0.8.2 The sort of performance you should be seeing is, for example, a 2GHz AMD or a 4GHz Intel giving the same realtime speed as a 100-200MHz ARM. M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About performance of qemu-system-arm
2006/12/13, PianoPan <[EMAIL PROTECTED]>: performance of Linux in Qemu is too slow. It uses about one hour to boot GUI system. During development work this summer at one point I experienced an immense slowdown of QEMU - from 63 bogomips to 1 or 2 on a 400MHz Pentium. The problem went away when I upgraded the ARM linux kernel that QEMU was running from 2.6.16 to 2.6.16-rc3 and the problem has not come back with later versions (.17 .18) M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: NBD server for QEMU images
- write tons of data to nbd device, data ends up in pagecache
- memory gets low, kswapd wakes up, calls nbd device to actually write
the data
- nbd issues a request, which ends up on the nbd server on the same machine
- the nbd server allocates memory
- memory allocation hangs waiting for kswapd
In other words, it can deadlock only if you are swapping to an nbd
device that is served by nbd-server running on the same machine and
kernel. In the case of a qemu system swapping over nbd to a server on
the host machine, it is the guest kernel that waits on the host kernel
paging the nbd server in from the host's separate swap space, so no
deadlock is possible.
Practice bears this out; if you wanna stress-test it, here's a program
that creates a low memory condition by saturating the VM.
Of course, this has nothing to do with the original patch, which just
lets nbd-server interpret qemu image files ;)
M
/*
* thrash.c
*
* A standalone Unix command-line program to
* make the machine thrash, ie go into permanent swapping,
* by using VM >= RAM size and accessing all pages repeatedly
*
* Usage: thrash size
* where "size" is the number of megabytes to thrash
* A good choice for N is the number of megabytes of physical RAM
* that the machine has.
*
* Reason:
* to force a machine to use its swap space,
* to flush all unused pages out to swap and so free RAM for other purposes
* or to see how a system behaves under extreme duress.
*
* It currently *writes* to all pages, but could be made to read them
* as an alternative, or as well.
*
* Martin Guy, 9 November 2006
*/
#include /* for exit() */
#include
#include /* for system calls */
main(int argc, char **argv)
{
int megabytes = 0; /* MB of VM to thrash, from command-line argument.
* 0 means uninitialised */
char *buf; /* Huge VM buffer */
intptr_t bufsize; /* Size of buffer in bytes */
long pagesize; /* size of VM page */
int i; /* index into argv */
int verbose = 0; /* Print a dot for every pass through VM? */
pagesize = getpagesize();
for (i=1; i0; p+=pagesize, i--)
*p=(char) i;
if (verbose) { putchar('.'); fflush(stdout); }
}
/* NOTREACHED */
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] NBD server for QEMU images
The patch available from http://qemu-forum.ipi.fi/viewtopic.php?t=2718 adds a new utility, qemu-nbds, that implements a NBD server I have been using nbd volumes mounted from inside qemu for filestore and for swap, both read-write, served from files and from partitions, with the unmodified standard nbd-server (debian testing version) for intensive work and it has been faster and more reliable than NFS (not that that's saying much). The only thing that doesn't work is the -swap option, which just hangs, but that proves not to be necessary when swapping onto nbd host volume from qemu-land, even when stress-testing it. What problem is solved by a specially modified nbd server? M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
Then again, if someone needed it... it's not as if I have to use it... M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
This patch adds support for slowing down qemu and saving cpu load. P! if you're using the right kernel, QEMU will sleep while there is nothing to be done. Otherwise just nice -10 it. Voto contra M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix char signedness
gcc on ARM systems default to unsigned. The C standard specifically
states that char is either signed or unsigned at the whim of the
implementor
Or, more to the point, at the behest of the machine architecture.
Having to generate code to sign-extend the hard way every time you do
char-integer promotion if the hardware doesn't do it automatically
would be long and inefficient, specially since it happens all the
time.
This has been a problem since the "All the world's a VAX" days, the
classic boob being
char c;
while ((c = getchar()) != EOF) {
...
}
of course, 255 always != -1 so it loops forever.
Check how many of your C primers get this wrong!
The flipside of that boob is that on a signed char architecture, the
loop will exit prematurely when it meets a 255 character.
These days instead, all the world's a 386 and anything different is broken...
24-bit integers, anyone? :)
M
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vs gcc4
Now, gcc4 can produce code with several return instructions (with no option to turn that of, as far as I understand). You cannot cut them out, and therefore you cannot chain the simple functions. ...unless you also map return instructions within the generated functions into branches to the soon-to-be-dropped final "return"? Not that I know anything about qemu internals mind u... M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
VMWare's config file style is really simple ethernet0.present = "TRUE" ethernet0.virtualDev = "e1000" e1000bios.filename = "path/etherboot-for-E1000" and it would be possible to use VMWare's files with few or no changes. Would that be enough to be able to move the emulated system description into config files rather than having the set of hard-coded machine alternatives we have at present? If so it would be a boon to anyone wanting to emulate, frinstance, any ARM board other than those manufactured by ARM Corp. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Question about target port
How can I change target CPU to Atmel's AVR and don't care about host. i.e:host CPU is X86(PC),target CPU is Atmel's AVR. Hi Atmel AVR is a different processor from the ones that QEMU emulates. You would need to implement an entire new emulation inside QEMU; that is a LOT of work in C programming. It is also an 8-bit processor, while all the ones that qemu currently emulates are 32-bit, so you may need to restructure the code as well to support 8-bit. M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu-arm user mode does not work with ARM EABI
2006/9/26, Martin Guy <[EMAIL PROTECTED]>: Ever since QEMU 0.8.1, qemu-arm-system mode works fine with ARM EABI kernel and rootfs, but qemu-arm single-process mode is broken with EABI, failing with "Unknown system call 0xf0005". Fixed for simple cases by pbrook's preliminary patches mentioned at http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html These patches do not apply cleanly using "patch" (it can't find most of the files to patch), so I've repackaged them and put the trouble-free version (cd qemu-0.8.2; patch -p1 < ../patch*mg1) under http://freaknet.org/martin/QEMU Bless M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
There are some statistics at freaknet.org/martin/QEMU for various are in cluster.aleph1.co.uk/~martin/qemu.html (please ignore the other Sorry, that first page is bogus. I meant the second. M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
> If I run qemu for i386 without kqemu it uses soft-mmu, so it operates as > another architetture as ppc or mips right? > So... are the performace of qemu the same if I use i386 or mips or something > change deeply? > Example: if I run the same program on i386 emulation without kqemu or on > mips are the performance circa the same? Would you expect qemu to perform the same on an AMD 4600X2 as a 400 Mhz MIPS? There are some statistics at freaknet.org/martin/QEMU for various types of x86 processor, but giving only BogoMIPS, which are way overrated. I presume this is cos QEMU translates the kernel speed test loop once then runs it as x86 code, while "real" tasks need to be translated all the time. The only concrete figures I have are from when I timed the running of bash's configure script, which causes a lot of program execution as well as compiling and running lots of short test programs. The results are in cluster.aleph1.co.uk/~martin/qemu.html (please ignore the other garbage on that page!) M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm user mode does not work with ARM EABI
Summary:
Ever since QEMU 0.8.1, qemu-arm-system mode works fine with ARM EABI
kernel and rootfs, but qemu-arm single-process mode is broken with
EABI, failing with "Unknown system call 0xf0005".
This is ARM private system call "set_tls", called from both the
linuxthreads and the NPTL pthread implementations in glibc-2.4, and
unimplemented in QEMU.
It is important that this mode work because scratchbox needs it to
be able to cross-compile Debian packages for the forthcoming
EABI-based Debian architecture.
Detail:
I have three kinds of ARM root filesystem:
- standard Debian ARM sarge using old-ABI: (glibc-2.3.6, linuxthreads)
- Voipio's "eabi-rootfs" which I gather uses EABI internally and glibc
shims to convert the system calls to old-ABI just before they hit the
kernel (glibc-2.3.4)
- Koen's EABI-toolchain-rootfs (from the Angstrom distro of
OpenEmbedded) which uses pure EABI (glibc-2.4,nptl)
# Here they are
martin:~/tftpboot$ ls
EABI-toolchain-rootfs/ debian-sarge-arm/ eabi-rootfs/
In qemu-system-arm (softmmu target) all three run fine (given
appropriate kernels) but qemu-arm fails on the second two.
# Even qemu-arm 0.8.1 works on old ABI
martin:~/tftpboot$ /usr/bin/qemu-arm -L `pwd`/deb* deb*/bin/echo hi
hi
martin:~/tftpboot$
# Both of the EABI scenarios fail the same way.
# With Debian QEMU (0.8.1):
martin:~/tftpboot$ /usr/bin/qemu-arm -L `pwd`/EABI* EABI*/bin/echo hi
Error: f0005
qemu: uncaught target signal 6 (Aborted) - exiting
martin:~/tftpboot$
# With qemu-arm 0.8.2 compiled from source (using gcc-3.4 of course):
martin:~/tftpboot$ /usr/local/bin/qemu-arm -L `pwd`/EABI* EABI*/bin/echo hi
qemu: Unsupported syscall: 983045
cannot set up thread-local storage: unknown error
martin:~/tftpboot$ echo 'obase=16; 983045' | bc
F0005
martin:~/tftpboot$
This is not a case of the new EABI picking up old ABI system calls,
which were encoded as SWI #(0x90 + n).
A couple of debugging printfs show that with the pure EABI rootfs, the
system call number is picked up by QEMU from r7 as it should, and when
executing a simple binary it correctly picks up about 20 system calls
starting with 'brk; uname; access; open; fstat64; mmap2' and ending
with 'close; mmap2; [F0005]; truncate; io_submit; [fail]'.
Using the intermediate glibc-shims version, the same bogus system call
number is received via the old-ABI system call mechanism.
The Linux kernel source, while decoding ARM system calls says
in arch/arm/kernel/traps.c
* 0x9f - 0x9f are some more esoteric system calls
and if we subtract the old syscall offset of 0x90 from this we get
our symptom of 0xf000* The extra __ARM_NR_* system call numbers run
from __NR_SYSCALL_BASE+__ARM_NR_BASE (0x90 + 0xf) and are
defined in include/asm-arm/unistd.h as:
1 __ARM_NR_breakpoint
2 __ARM_NR_cacheflush
3 __ARM_NR_usr26
4 __ARM_NR_usr32
5 __ARM_NR_set_tls <--- this one
This is glibc-2.4 using the internal ARM system call set_tls to
initialise(?) the thread local storage (something which the shims for
glibc-2.3.4 also evidently do). It is called from the macro:
glibc-2.4/ports/sysdeps/arm/{linuxthreads,nptl}/tls.h:
/* Code to initially initialize the thread pointer. This might need
special attention since 'errno' is not yet available and if the
operation can cause a failure 'errno' must not be touched. */
# define TLS_INIT_TP(TCBP, SECONDCALL) \
({ INTERNAL_SYSCALL_DECL (err); \
long result_var; \
result_var = INTERNAL_SYSCALL_ARM (set_tls, err, 1, (TCBP)); \
INTERNAL_SYSCALL_ERROR_P (result_var, err) \
? "unknown error" : NULL; })
And this is what the Linux kernel does with that:
linux-2.6.17/arch/arm/kernel/traps.c:
case NR(set_tls):
thread->tp_value = regs->ARM_r0;
#if defined(CONFIG_HAS_TLS_REG)
asm ("mcr p15, 0, %0, c13, c0, 3" : : "r" (regs->ARM_r0) );
#elif !defined(CONFIG_TLS_REG_EMUL)
/*
* User space must never try to access this directly.
* Expect your app to break eventually if you do so.
* The user helper at 0x0fe0 must be used instead.
* (see entry-armv.S for details)
*/
*((unsigned int *)0x0ff0) = regs->ARM_r0;
#endif
return 0;
Quite what that really means, and what QEMU should do about it, are
unclear to me. I've tried ignoring the f0005 system call, and the ARM
program segfaults straight away, so I guess *something* is necessary.
The 32-bit parameter ARM_r0 is always in the 0x7e* and 0x7f* range and
is different at each execution. Does this call set the area used for
thread-local storage?
Any ideas?
M
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm
On Wed, Sep 06, 2006 at 12:14:44PM +0200, Aurelien Jarno wrote: I have setup a debian arm (unstable) under QEMU, until now using version 0.8.1 and a root on NFS. I wanted to use the new SCSI card emulation introduced in QEMU 0.8.2, but it fails to boot (still with root on NFS). It freeze, the last message being: INIT: version 2.86 booting I think I have found the problem. Actually the system is not frozen, but just very slow. I now get while booting the kernel: Calibrating delay loop... 12.16 BogoMIPS (lpj=60800) instead of Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024) I suffered the same exact symptom, except that in my case it was caused by a kernel upgrade and fixed by using a kernel that was 2.6.16-rc3 or later while vanilla 2.6.16 gave this incredible slowdown. That may or may not be relevant... M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
