[Qemu-devel] Qemu-mips
Hi, What part of the QEMU source code generates translation blocks for mips user emulation? Thanks,
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Ralf Baechle wrote: > On Mon, Oct 15, 2007 at 04:05:14PM +0100, Thiemo Seufer wrote: > > > I found Qemu/MIPS locks up in the emulated kernel's calibrate_delay > > function. Switching the kernel option off works around the problem. > > I still haven't patched up the issue which was causing the problem for > Aurel. Is the slow execution of the emulator also the cause of what > you're seeing? I haven't analysed it further. Thiemo
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
On Mon, Oct 15, 2007 at 04:05:14PM +0100, Thiemo Seufer wrote: > I found Qemu/MIPS locks up in the emulated kernel's calibrate_delay > function. Switching the kernel option off works around the problem. I still haven't patched up the issue which was causing the problem for Aurel. Is the slow execution of the emulator also the cause of what you're seeing? Ralf
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Aurelien Jarno wrote: > Hi, > > As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a > try on QEMU/MIPS, and unfortunately it doesn't work correctly. > > In some cases the kernel schedules an event very near in the future, > which means the timer is scheduled a few cycles only from its current > value. Unfortunately under QEMU, the timer runs too fast compared to the > speed at which instructions are execution. This causes a lockup of the > kernel. This can be triggered by running hwclock --hctosys in the guest > (which is run at boot time by most distributions). Until now, I haven't > found any other way to trigger the bug. I found Qemu/MIPS locks up in the emulated kernel's calibrate_delay function. Switching the kernel option off works around the problem. > The problematic code in the kernel from arch/mips/kernel/time.c is the > following: > > cnt = read_c0_count(); > cnt += delta; > write_c0_compare(cnt); > res = ((long)(read_c0_count() - cnt ) > 0) ? -ETIME : 0; > > Note that there is a minimum value for delta (currently set to 48) to > avoid lockup. > > In QEMU, the emulated kernel runs at 100 MHz, ie very fast, which means > that more than 48 timer cycles happen between the two calls of > read_c0_count(). The code returns -ETIME, and the routine is called > again with 48 and so on. > > I have tried to reduce the speed of the timer, the problem disappears > when running at 1MHz (on my machine). > > Here are a few proposed ways to fix the problem (they are not exclusive): > > 1) Improve the emulation speed for timer instructions. This is what I > did with the attached patch. I see no obvious reason of stopping the > translation after a write to CP0_Compare, so I removed that part. The write could trigger an exception. Thiemo
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Paul Brook wrote: There seem to have specific problems when using dynticks in Qemu. What I can see is that it makes the PowerPC emulation quite unusable, at least on my PC, which is an amd64 (with a fix CPU frequency), no matter if I run 32 or 64 bits mode. I'd expect to see the same problems running a non-dynticks qemu on a heavily loaded host, or a host that did not have /dev/rtc available. IIRC vanilla amd64-linux does not yet use the new kernel high resolution timer infrastructure, so posix timers (as used by dynticks) have a fairly high jitter+latency compared to /dev/rtc. As of linux 2.6.24 there is dyn-tick kernel support for 64 bits. Expect for dyn-tick there is also the hpet option. The tradeoff is that on hosts that do implement high resolution timers (e.g. i386) you get lower overhead and/or more accurate emulation. I don't think there's any deterministic way of figuring out which is best. It may be feasible to switch mechanisms dynamically if it's obvious one is sucking, but I'm not sure how well that would work in practice. The only reliable solution is to isolate qemu from the host realtime characteristics, though that has its own set of issues. I hope to have this implemented fairly soon. Paul
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
> There seem to have specific problems when using dynticks in Qemu. What I > can see is that it makes the PowerPC emulation quite unusable, at least > on my PC, which is an amd64 (with a fix CPU frequency), no matter if I > run 32 or 64 bits mode. I'd expect to see the same problems running a non-dynticks qemu on a heavily loaded host, or a host that did not have /dev/rtc available. IIRC vanilla amd64-linux does not yet use the new kernel high resolution timer infrastructure, so posix timers (as used by dynticks) have a fairly high jitter+latency compared to /dev/rtc. The tradeoff is that on hosts that do implement high resolution timers (e.g. i386) you get lower overhead and/or more accurate emulation. I don't think there's any deterministic way of figuring out which is best. It may be feasible to switch mechanisms dynamically if it's obvious one is sucking, but I'm not sure how well that would work in practice. The only reliable solution is to isolate qemu from the host realtime characteristics, though that has its own set of issues. I hope to have this implemented fairly soon. Paul
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
On Thu, Oct 04, 2007 at 03:59:42AM +0200, J. Mayer wrote: > > As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a > > try on QEMU/MIPS, and unfortunately it doesn't work correctly. Aurelien is talking about a kernel option... > I tried to disactivate dynticks, just commenting the entry in > alarm_timers structure. Since then, I can notice that the emulated ... and I think you're talking about a qemu option with the same name. -- Daniel Jacobowitz CodeSourcery
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
On Tue, 2007-10-02 at 22:06 +0200, Aurelien Jarno wrote: > Hi, Hi, > As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a > try on QEMU/MIPS, and unfortunately it doesn't work correctly. > > In some cases the kernel schedules an event very near in the future, > which means the timer is scheduled a few cycles only from its current > value. Unfortunately under QEMU, the timer runs too fast compared to the > speed at which instructions are execution. This causes a lockup of the > kernel. This can be triggered by running hwclock --hctosys in the guest > (which is run at boot time by most distributions). Until now, I haven't > found any other way to trigger the bug. [] There seem to have specific problems when using dynticks in Qemu. What I can see is that it makes the PowerPC emulation quite unusable, at least on my PC, which is an amd64 (with a fix CPU frequency), no matter if I run 32 or 64 bits mode. What I can see is that the emulated timer frequency seem to be completely random: the system time, as seen from the target CPU, is running from half of the real time to twice of the real time speed, randomly; launching Qemu twice in the same conditions, on the same machine, will give different speed for the emulated system timer. I also experiment a lot of Qemu freezes: I cannot run the emulated target more than a few minutes before it freezes; sometimes it runs less than 1 second, even not get out of the firmware. It's not the same issue than yours, as the firmware uses no timer and as it's a complete Qemu freeze: even the monitor is frozen. I tried to disactivate dynticks, just commenting the entry in alarm_timers structure. Since then, I can notice that the emulated system clock seems always to be running at the same speed as the host one (not a single second of difference after 2 hours of compilation in the target system...) and that I never had any Qemu freeze anymore since then. Which convinces me that dynticks is the source of the problems... Then, I feel like dynticks in Qemu is an experimental feature that should not be activated as default, as it seems not to be really usable as it is now. I got no idea of what's going wrong in that code, I saw nothing awfull at first sight (I only gave a quick look...) but it makes Qemu unreliable and quite unusable, as far as I can see. [...] -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
On Tue, Oct 02, 2007 at 10:57:24PM +0200, Aurelien Jarno wrote: > From: Aurelien Jarno <[EMAIL PROTECTED]> > Date: Tue, 02 Oct 2007 22:57:24 +0200 > To: Alan Cox <[EMAIL PROTECTED]> > CC: qemu-devel@nongnu.org, [EMAIL PROTECTED] > Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel > Content-Type: text/plain; charset=ISO-8859-1 > > Alan Cox a écrit : > >> Well on real hardware, the instruction rate and the timer are linked: > >> the timer run at half the speed of the CPU. As the corresponding > >> assembly code is very small, only uses registers and is run in kernel > >> mode, you know for sure that 48 cycles is more than enough. > > > > What happens on NMI or if you take an ECC exception and scrubbing stall > > off the memory controller while loading part of that cache line of code > > into memory ? > > > > The code returns -ETIME, and the function is run again with the minimum > delay. > > So as long as you don't have an exception every time, the code works. The current setting should be safe on real hardware - but a value of just 48 cycles for max_delta_ns is probably lower than the lowest useful value, so I don't mind raising it. This number really is a tunable. Ralf
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
> Well on real hardware, the instruction rate and the timer are linked: > the timer run at half the speed of the CPU. As the corresponding > assembly code is very small, only uses registers and is run in kernel > mode, you know for sure that 48 cycles is more than enough. What happens on NMI or if you take an ECC exception and scrubbing stall off the memory controller while loading part of that cache line of code into memory ? Alan
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Alan Cox a écrit : >> Well on real hardware, the instruction rate and the timer are linked: >> the timer run at half the speed of the CPU. As the corresponding >> assembly code is very small, only uses registers and is run in kernel >> mode, you know for sure that 48 cycles is more than enough. > > What happens on NMI or if you take an ECC exception and scrubbing stall > off the memory controller while loading part of that cache line of code > into memory ? > The code returns -ETIME, and the function is run again with the minimum delay. So as long as you don't have an exception every time, the code works. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Avi Kivity a écrit : > Aurelien Jarno wrote: >> Hi, >> >> As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a >> try on QEMU/MIPS, and unfortunately it doesn't work correctly. >> >> In some cases the kernel schedules an event very near in the future, >> which means the timer is scheduled a few cycles only from its current >> value. Unfortunately under QEMU, the timer runs too fast compared to the >> speed at which instructions are execution. > > Sounds like a kernel bug. Can't there conceivably exist real hardware > (or a real timeout) that exhibits the same timing? > > Especially today with variable clock frequencies, I don't see how the > kernel can rely on exact timing. > Well on real hardware, the instruction rate and the timer are linked: the timer run at half the speed of the CPU. As the corresponding assembly code is very small, only uses registers and is run in kernel mode, you know for sure that 48 cycles is more than enough. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Aurelien Jarno wrote: Hi, As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a try on QEMU/MIPS, and unfortunately it doesn't work correctly. In some cases the kernel schedules an event very near in the future, which means the timer is scheduled a few cycles only from its current value. Unfortunately under QEMU, the timer runs too fast compared to the speed at which instructions are execution. Sounds like a kernel bug. Can't there conceivably exist real hardware (or a real timeout) that exhibits the same timing? Especially today with variable clock frequencies, I don't see how the kernel can rely on exact timing. -- Any sufficiently difficult bug is indistinguishable from a feature.
[Qemu-devel] QEMU/MIPS & dyntick kernel
Hi,
As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a
try on QEMU/MIPS, and unfortunately it doesn't work correctly.
In some cases the kernel schedules an event very near in the future,
which means the timer is scheduled a few cycles only from its current
value. Unfortunately under QEMU, the timer runs too fast compared to the
speed at which instructions are execution. This causes a lockup of the
kernel. This can be triggered by running hwclock --hctosys in the guest
(which is run at boot time by most distributions). Until now, I haven't
found any other way to trigger the bug.
The problematic code in the kernel from arch/mips/kernel/time.c is the
following:
cnt = read_c0_count();
cnt += delta;
write_c0_compare(cnt);
res = ((long)(read_c0_count() - cnt ) > 0) ? -ETIME : 0;
Note that there is a minimum value for delta (currently set to 48) to
avoid lockup.
In QEMU, the emulated kernel runs at 100 MHz, ie very fast, which means
that more than 48 timer cycles happen between the two calls of
read_c0_count(). The code returns -ETIME, and the routine is called
again with 48 and so on.
I have tried to reduce the speed of the timer, the problem disappears
when running at 1MHz (on my machine).
Here are a few proposed ways to fix the problem (they are not exclusive):
1) Improve the emulation speed for timer instructions. This is what I
did with the attached patch. I see no obvious reason of stopping the
translation after a write to CP0_Compare, so I removed that part. I also
reduced the code that emulates timer accesses.
That helps but that is clearly not enough. With this patch the maximum
timer speed is 5MHz.
2) Increase the minimum value for delta. For a 100MHz timer 48 cycles
means 480ns. On the other side a kernel running at 250Hz (default on
MIPS) is scheduling tasks with a 4ms resolution.
Increasing it to about 10 microseconds should have no impact on the
scheduling, even on real hardware.
3) Reduce the timer speed. As the timer is supposed to run at half the
speed of the CPU, that would mean the kernel would see a 2 to 10MHz
CPU.
4) Add a hack to QEMU to make the timer slower within a translation
block (like increasing it by 1 at each access), without changing the
overall speed. This might break other parts or other OSeS.
Any thoughts or other ideas?
Bye,
Aurelien
[1] http://www.linux-mips.org/archives/linux-mips/2007-09/msg00372.html
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Index: hw/mips_timer.c
===
RCS file: /sources/qemu/qemu/hw/mips_timer.c,v
retrieving revision 1.8
diff -u -d -p -r1.8 mips_timer.c
--- hw/mips_timer.c 25 Sep 2007 16:53:15 - 1.8
+++ hw/mips_timer.c 2 Oct 2007 10:20:37 -
@@ -1,5 +1,7 @@
#include "vl.h"
+#define TIMER_FREQ 100 * 1000 * 1000
+
void cpu_mips_irqctrl_init (void)
{
}
@@ -22,49 +24,41 @@ uint32_t cpu_mips_get_count (CPUState *e
else
return env->CP0_Count +
(uint32_t)muldiv64(qemu_get_clock(vm_clock),
- 100 * 1000 * 1000, ticks_per_sec);
+ TIMER_FREQ, ticks_per_sec);
}
-void cpu_mips_store_count (CPUState *env, uint32_t count)
+static void cpu_mips_timer_update(CPUState *env)
{
uint64_t now, next;
-uint32_t tmp;
-uint32_t compare = env->CP0_Compare;
+uint32_t wait;
-tmp = count;
-if (count == compare)
-tmp++;
now = qemu_get_clock(vm_clock);
-next = now + muldiv64(compare - tmp, ticks_per_sec, 100 * 1000 * 1000);
-if (next == now)
- next++;
-#if 0
-if (logfile) {
-fprintf(logfile, "%s: 0x%08" PRIx64 " %08x %08x => 0x%08" PRIx64 "\n",
-__func__, now, count, compare, next - now);
-}
-#endif
-/* Store new count and compare registers */
-env->CP0_Compare = compare;
-env->CP0_Count =
-count - (uint32_t)muldiv64(now, 100 * 1000 * 1000, ticks_per_sec);
-/* Adjust timer */
+wait = env->CP0_Compare - env->CP0_Count -
+ (uint32_t)muldiv64(now, TIMER_FREQ, ticks_per_sec);
+next = now + muldiv64(wait, ticks_per_sec, TIMER_FREQ);
qemu_mod_timer(env->timer, next);
}
-static void cpu_mips_update_count (CPUState *env, uint32_t count)
+void cpu_mips_store_count (CPUState *env, uint32_t count)
{
if (env->CP0_Cause & (1 << CP0Ca_DC))
-return;
-
-cpu_mips_store_count(env, count);
+env->CP0_Count = count;
+else {
+/* Store new count register */
+env->CP0_Count =
+count - (uint32_t)muldiv64(qemu_get_clock(vm_clock),
+ TIMER_FREQ, ticks_per_sec);
+/* Update timer timer */
+cpu_mips_timer_update(env);
+}
}
void cpu_mips_store_compare
[Qemu-devel] qemu mips-dis.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/14 23:39:33 Modified files: . : mips-dis.c Log message: MIPS disassembler update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/mips-dis.c?cvsroot=qemu&r1=1.5&r2=1.6
[Qemu-devel] qemu mips-dis.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/28 13:40:10 Modified files: . : mips-dis.c Log message: MIPS disassembler update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/mips-dis.c?cvsroot=qemu&r1=1.4&r2=1.5
[Qemu-devel] qemu-mips on x86: stat() broken in 0.8.2
Hi,
I think emulation of stat() on qemu-mips (big-endian) hosted on x86
is broken. Or more generally, probably either-endian mips on the
opposite-endian host.
In linux-user/syscall.c around line 2892 in the 0.8.2 release, it uses
tswapl() for ppc, and tswap16() for all other targets. But target_stat.t_mode
is 32-bit on both mips and ppc, and so I think mips also needs a 32-bit
swap.My local fix is just to change
#if defined(TARGET_PPC)
to
#if defined(TARGET_PPC) || defined(TARGET_MIPS)
and that seems to fix the problem I was seeing. A slightly more
general test might be
if (sizeof(target_st->st_mode) == 4) {
... tswapl();
} else {
... tswap16();
}
but I'll leave that up to you.
I was confused about why the busybox executable in the prebuilt tests
seemed to work, and worked the same with both the original executable
and my modified version, but it uses fstat64() rather than stat(), and
that of course is a different code path. (fstat64() uses the put_user
macro which automatically senses the width of the target. Any particular
reason for the difference ?)
Another small change I have locally is to suppress warnings about
unimplemented mips system call 4147 (cache flush). Since qemu handles
self-modifying code transparently (in effect, a coherent cache, or
no cache at all), the flush can be implemented as a no-op.
In fact, it might be mildly interesting if the detection of
self-modifying code was turned off for non-x86 targets, and
cache-flush calls were required to discarded generated code, since
that would make it possible to detect missed calls to cache-flush on
programs with self-modifying code. But perhaps I have a different
agenda from other users in this area ;-)
diff below
dd
--
Dave Denholm <[EMAIL PROTECTED]> http://www.esmertec.com
$ diff --unified syscall.c.~1~ syscall.c
--- syscall.c.~1~ 2006-07-22 18:23:34.0 +0100
+++ syscall.c 2006-10-10 13:00:56.695069058 +0100
@@ -2889,7 +2889,7 @@
lock_user_struct(target_st, arg2, 0);
target_st->st_dev = tswap16(st.st_dev);
target_st->st_ino = tswapl(st.st_ino);
-#if defined(TARGET_PPC)
+#if defined(TARGET_PPC) || defined(TARGET_MIPS)
target_st->st_mode = tswapl(st.st_mode); /* XXX: check this */
target_st->st_uid = tswap32(st.st_uid);
target_st->st_gid = tswap32(st.st_gid);
@@ -3785,6 +3785,12 @@
break;
}
#endif
+#ifdef TARGET_NR_cacheflush
+case TARGET_NR_cacheflush:
+/* self-modifying code is handled automatically, so nothing needed */
+ret = 0;
+break;
+#endif
#ifdef TARGET_NR_security
case TARGET_NR_security:
goto unimplemented;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu mips-dis.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/05/22 22:05:04 Modified files: . : mips-dis.c Log message: dump all mips insn (Thiemo Seufer) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/mips-dis.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu mips-dis.c
CVSROOT:/cvsroot/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 05/07/02 14:45:34 Added files: . : mips-dis.c Log message: MIPS disas support CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/mips-dis.c?rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
