[Qemu-devel] [PATCH ] Fix ARM1136, ARM11MPCORE and CORTEXA8 cpuid bug
I found that ARM1136, ARM11MPCore and CortexA8 targets failed to run because of the following copy-and-paste bug. HyeonSeung Jang. --- target-arm/helper.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/target-arm/helper.c b/target-arm/helper.c index 86470db..80ec117 100644 --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -1,3 +1,4 @@ + #include #include #include @@ -61,7 +62,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id) env->vfp.xregs[ARM_VFP_MVFR0] = 0x; env->vfp.xregs[ARM_VFP_MVFR1] = 0x; memcpy(env->cp15.c0_c1, arm1136_cp15_c0_c1, 8 * sizeof(uint32_t)); -memcpy(env->cp15.c0_c1, arm1136_cp15_c0_c2, 8 * sizeof(uint32_t)); +memcpy(env->cp15.c0_c2, arm1136_cp15_c0_c2, 8 * sizeof(uint32_t)); env->cp15.c0_cachetype = 0x1dd20d2; break; case ARM_CPUID_ARM11MPCORE: @@ -73,7 +74,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id) env->vfp.xregs[ARM_VFP_MVFR0] = 0x; env->vfp.xregs[ARM_VFP_MVFR1] = 0x; memcpy(env->cp15.c0_c1, mpcore_cp15_c0_c1, 8 * sizeof(uint32_t)); -memcpy(env->cp15.c0_c1, mpcore_cp15_c0_c2, 8 * sizeof(uint32_t)); +memcpy(env->cp15.c0_c2, mpcore_cp15_c0_c2, 8 * sizeof(uint32_t)); env->cp15.c0_cachetype = 0x1dd20d2; break; case ARM_CPUID_CORTEXA8: @@ -89,7 +90,7 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id) env->vfp.xregs[ARM_VFP_MVFR0] = 0x0222; env->vfp.xregs[ARM_VFP_MVFR1] = 0x00011100; memcpy(env->cp15.c0_c1, cortexa8_cp15_c0_c1, 8 * sizeof(uint32_t)); -memcpy(env->cp15.c0_c1, cortexa8_cp15_c0_c2, 8 * sizeof(uint32_t)); +memcpy(env->cp15.c0_c2, cortexa8_cp15_c0_c2, 8 * sizeof(uint32_t)); env->cp15.c0_cachetype = 0x1dd20d2; break; case ARM_CPUID_CORTEXM3: --
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
> SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I > don't think anything other than Linux runs in QEMU's Sun emulation (or > for that matter, any of the non-PC QEMU emulators). While linux is certainly the most most widely tested, I'm fairly sure both vxWorks and SymbianOS have been run inside qemu ARM emulation. Paul
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
On 19/02/2008, Andrew Warkentin <[EMAIL PROTECTED]> wrote: > SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I > don't think anything other than Linux runs in QEMU's Sun emulation (or > for that matter, any of the non-PC QEMU emulators). PalmOS, NetBSD and OpenBSD run in one and I heard Windows NT runs on another one. -- Please do not print this email unless absolutely necessary. Spread environmental awareness.
Re: [Qemu-devel] More about slow clock in guest OS
Hi.. Just want to reply shortlyI guess you can lead your own research from here since I almost reach my knowledge limit especially dealing with Qemu internals. However, I greatly appreciate your effort and time sharing your discoveries to me and the rest of Qemu's community. keep up the good work! regards, Mulyadi.
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
In message: <[EMAIL PROTECTED]> Andrew Warkentin <[EMAIL PROTECTED]> writes: : Robert Reif wrote: : : > Jan Holzhueter wrote: : > : >> Hi everyone, : >> we are planing to get rid of some old sparc hardware. : >> The problem is that there are applications on it that require : >> sun4m and Solaris 1.1.2 / SunOS 4.1.4. : >> As known qemu-system-sparc is not able to boot the Solaris Kernel at : >> the moment. : >> : >> I get as far as: : >> [sparc] Booting file 'cdrom' with parameters '' : >> Not a bootable ELF image : >> Not a Linux kernel image : >> Not a bootable a.out image : >> Not a bootable ELF image : >> Not a Linux kernel image : >> Loading a.out image... : >> Loaded 7680 bytes : >> entry point is 0x4000 : >> Jumping to entry point... : >> checksum 60746d10 != 86693bac, trying to boot anyway : >> Unhandled Exception 0x0007 : >> PC = 0x002002bc NPC = 0x002002c0 : >> Stopping execution : >> : >> My question is how far away are you form getting it to work : >> and in what time frame could it be done? : >> : >> This is a bigger project for us. So it might even be possible : >> ( nothing confirmed yet I have to check back with some people ) : >> to donate some money to get it to work. : >> It doesn't need to work for all Solaris. We just need Solaris 1.1.2. : >> If someone needs some installation Medium or feedback let me know. : >> : >> Greetings : >> Jan Holzhüter : >> : >> : > This may be an openbios issue. Changing openbios boot.c cdrom : > oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. : > : > : > : > : : SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I : don't think anything other than Linux runs in QEMU's Sun emulation (or : for that matter, any of the non-PC QEMU emulators). OpenFirmware that QEMU implements is somewhat insufficient to boot anything but the hacked up version of Linux. Warner
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
Robert Reif wrote: Jan Holzhueter wrote: Hi everyone, we are planing to get rid of some old sparc hardware. The problem is that there are applications on it that require sun4m and Solaris 1.1.2 / SunOS 4.1.4. As known qemu-system-sparc is not able to boot the Solaris Kernel at the moment. I get as far as: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... checksum 60746d10 != 86693bac, trying to boot anyway Unhandled Exception 0x0007 PC = 0x002002bc NPC = 0x002002c0 Stopping execution My question is how far away are you form getting it to work and in what time frame could it be done? This is a bigger project for us. So it might even be possible ( nothing confirmed yet I have to check back with some people ) to donate some money to get it to work. It doesn't need to work for all Solaris. We just need Solaris 1.1.2. If someone needs some installation Medium or feedback let me know. Greetings Jan Holzhüter This may be an openbios issue. Changing openbios boot.c cdrom oldpath to sd(0,2,0):d gets past this error but it still doesn't boot. SunOS might run in TME (http://people.csail.mit.edu/fredette/tme/). I don't think anything other than Linux runs in QEMU's Sun emulation (or for that matter, any of the non-PC QEMU emulators).
Re: [Qemu-devel] qemu-system-sparc and Solaris 1.1.2 / SunOS 4.1.4
Jan Holzhueter wrote: Hi everyone, we are planing to get rid of some old sparc hardware. The problem is that there are applications on it that require sun4m and Solaris 1.1.2 / SunOS 4.1.4. As known qemu-system-sparc is not able to boot the Solaris Kernel at the moment. I get as far as: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... checksum 60746d10 != 86693bac, trying to boot anyway Unhandled Exception 0x0007 PC = 0x002002bc NPC = 0x002002c0 Stopping execution My question is how far away are you form getting it to work and in what time frame could it be done? This is a bigger project for us. So it might even be possible ( nothing confirmed yet I have to check back with some people ) to donate some money to get it to work. It doesn't need to work for all Solaris. We just need Solaris 1.1.2. If someone needs some installation Medium or feedback let me know. Greetings Jan Holzhüter This may be an openbios issue. Changing openbios boot.c cdrom oldpath to sd(0,2,0):d gets past this error but it still doesn't boot.
[Qemu-devel] [MIPS] Optimize MIPS timer read/write functions
The patch below optimize the MIPS timer read/write functions and
improves its precision.
cpu_mips_update_count() is replaced by cpu_mips_timer_update()
which does not call cpu_mips_store_count() and do fewer things. As
this function is called by the callback function, it is called very
often and thus it is worth optimizing it.
The patch also ensures that env->CP0_Count is not written in normal use
(that is when CP0_Count is not written, and the timer not started or
stopped), so that no ticks are lost.
diff --git a/hw/mips_timer.c b/hw/mips_timer.c
index 3e7d5e3..d912fd5 100644
--- a/hw/mips_timer.c
+++ b/hw/mips_timer.c
@@ -2,6 +2,8 @@
#include "mips.h"
#include "qemu-timer.h"
+#define TIMER_FREQ 100 * 1000 * 1000
+
void cpu_mips_irqctrl_init (void)
{
}
@@ -24,49 +26,41 @@ uint32_t cpu_mips_get_count (CPUState *env)
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 (CPUState *env, uint32_t value)
{
env->CP0_Compare = value;
-cpu_mips_update_count(env, cpu_mips_get_count(env));
-if ((env->CP0_Config0 & (0x7 << CP0C0_AR)) == (1 << CP0C0_AR))
+if (!(env->CP0_Cause & (1 << CP0Ca_DC)))
+cpu_mips_timer_update(env);
+if (env->insn_flags & ISA_MIPS32R2)
env->CP0_Cause &= ~(1 << CP0Ca_TI);
qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
}
@@ -80,7 +74,7 @@ void cpu_mips_stop_count(CPUState *env)
{
/* Store the current value */
env->CP0_Count += (uint32_t)muldiv64(qemu_get_clock(vm_clock),
- 100 * 1000 * 1000, ticks_per_sec);
+ TIMER_FREQ, ticks_per_sec);
}
static void mips_timer_cb (void *opaque)
@@ -97,8 +91,8 @@ static void mips_timer_cb (void *opaque)
if (env->CP0_Cause & (1 << CP0Ca_DC))
return;
-cpu_mips_update_count(env, cpu_mips_get_count(env));
-if ((env->CP0_Config0 & (0x7 << CP0C0_AR)) == (1 << CP0C0_AR))
+cpu_mips_timer_update(env);
+if (env->insn_flags & ISA_MIPS32R2)
env->CP0_Cause |= 1 << CP0Ca_TI;
qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
}
@@ -107,5 +101,5 @@ void cpu_mips_clock_init (CPUState *env)
{
env->timer = qemu_new_timer(vm_clock, &mips_timer_cb, env);
env->CP0_Compare = 0;
-cpu_mips_update_count(env, 1);
+cpu_mips_store_count(env, 1);
}
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] endianness and network emulation for PowerPC
I've been debugging network problems in qemu for a week or two, and there seem to be some pervasive misunderstandings about endianness. I'm trying to use a big-endian target on a big-endian guest, and this has exposed a lot of breakage, including qemu's pci-host.h, isa_mmio.c, rtl8139.c and ne2000.c. Rob, I noticed that you're using Linux's "ne.c" in your PowerPC PReP kernel build for qemu, and to my surprise it actually works for me on a big-endian host! I'm wondering if you chose ne.c because you found the other network drivers to be broken? (Actually I believe this is also working by accident: outsw() in Linux writes big-endian data, which is incorrectly swapped in isa_mmio.c, and then incorrectly swapped again in ne2000.c.) -- Hollis Blanchard IBM Linux Technology Center
Re: [Qemu-devel] Patch for compiling with GCC 4
Alexander Graf wrote: > > On Feb 17, 2008, at 9:22 PM, Christian Roue wrote: > >> Well, I somehow felt like it was a bit brutal and probably fixing the >> symptoms which is apparently the case. >> Looking more carefully, compile fails in : >> sh4-linux-user for function op_cmp_str_T0_T1 >> gcc optimization leads to a ret followed by a last assignement with a >> jump back. >> I guess dyngen hopes to find function epilogue as the last bytes. >> It's apparently the only function where it happens. >> >> I found that adding gcc option "-fno-tree-dominator-opts" for sh4 >> target avoids this (I suppose) unwanted optimization. >> It may be a bit brutal again ( disabling too many optims or wrong >> ones). >> May be the op_cmp_str_T0_T1 function can be rewritten to something >> that avoids this optimization. >> Am I on a better track ? > > This looks like the right approach to the symptoms. The "real fix" would > be to move the sh4 target to TCG, The migration to tcg can be done gradually, fixing the immediate problem shouldn't get too involved. > but for the meantime I believe this is > the way to go. You can already find a lot of these unoptimization flags > autodetected in the configure script, so I guess that'd be the right > place for a patch. I added those as workarounds, they should rather go away than expand to cover even more flags. Thiemo
Re: [Qemu-devel] Patch for compiling with GCC 4
Alex, thanks for the hint. I'll have a look at TCG. Bye Chris. On Feb 18, 2008 1:07 PM, Alexander Graf <[EMAIL PROTECTED]> wrote: > > On Feb 17, 2008, at 9:22 PM, Christian Roue wrote: > > > Well, I somehow felt like it was a bit brutal and probably fixing the > > symptoms which is apparently the case. > > Looking more carefully, compile fails in : > > sh4-linux-user for function op_cmp_str_T0_T1 > > gcc optimization leads to a ret followed by a last assignement with > > a jump back. > > I guess dyngen hopes to find function epilogue as the last bytes. > > It's apparently the only function where it happens. > > > > I found that adding gcc option "-fno-tree-dominator-opts" for sh4 > > target avoids this (I suppose) unwanted optimization. > > It may be a bit brutal again ( disabling too many optims or wrong > > ones). > > May be the op_cmp_str_T0_T1 function can be rewritten to something > > that avoids this optimization. > > Am I on a better track ? > > This looks like the right approach to the symptoms. The "real fix" > would be to move the sh4 target to TCG, but for the meantime I believe > this is the way to go. You can already find a lot of these > unoptimization flags autodetected in the configure script, so I guess > that'd be the right place for a patch. > > I am not sure if anybody with commit right listens, though. > > Regards, > > Alex > > > > > > > > Bye > > Chris. > > > > > > On Feb 16, 2008 9:01 PM, Paul Brook <[EMAIL PROTECTED]> wrote: > >> On Saturday 16 February 2008, Christian Roue wrote: > >>> Hi all, > >>> I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 > >>> using > >>> --disable-gcc-check, I found compile fails as stated in configure > >>> before i > >>> disabled gcc check.. > >>> Error message, points to a problem of dyngen not correctly detecting > >>> function ends on i386 when last instruction is a jump. I applied > >>> following > >>> change and successfully compiled/run qemu i386. This extra test > >>> check for > >>> a relative backward jump to function exit ret, > >>> gcc 4 apparently generates a few of these. > >> > >> You patch is wrong. The dyngen error is correct. > >> > >> Paul > >> > > > > > > > >
Re: [Qemu-devel] Problems with dynticks clock
- Original Message - From: "Victor Shkamerda" <[EMAIL PROTECTED]> To: Sent: 4.02.2008 14:09 Subject: [Qemu-devel] Problems with dynticks clock Any DOS game that I've tried eventually hangs the QEMU. GDB shows that QEMU is running in infinite loop in translated basic block and does not respond to any keyboard or mouse events... If I start QEMU with rtc or unix clock this does not happen, or at least I never managed to trigger it. Looks that I had such problem, but only with rtc and unix clock, not with dynticks. Did You find any solution? Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] More about slow clock in guest OS
- Original Message - From: "Mulyadi Santosa" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: 1.02.2008 4:41 Subject: Re: [Qemu-devel] More about slow clock in guest OS After some investigations I can say that with the latest (2008/01/30) qemu from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works not too good. So, in other words "it works but not so well". may I interpret it as a progress? Yes, now there is a choice: stable but slow (dynticks) and unstable but faster (rtc) Unfortunately, there is no option "stable and correct" yet ;) With "-clock dynticks" clock in OS is very slow - and windows time server can't adjust. Probably due to cost of Qemu timer rearming. And maybe Windows 2003 does certain dyntick by its own...thus enlarging the timer rearming cost. Tests say that in dynticks mode clock in VM is 4-5 times slower than in real world. With "-clock rtc" hung periodically - for up to 5 minutes, 300 seconds. p... too much timers get expired? lock contention somewhere...anybody? I even stop experiments with "rtc" because of instability. Maybe somebody else will find this problem in the future, I'm focusing in testing "dynticks" mode now. Thus..maybe it's Qemu's fault... sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime -cdrom /distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile $DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9 Ehm: 1. can you simply use SDL output instead of VNC? 2. what if you don't use -localtime? just courious... 1. Yes, but main purpose is to run VM on linux server, without X. 2. The only difference is that initial clock is two hours out. Windows always assumes that hardware clock is local. == $ cat /proc/sys/dev/rtc/max-user-freq == 4096 == ehm...I think 1024 is enough for most cases.. There were tests, and this parameter doesn't affect dynticks mode, so now it is in default value, 64. $ uname -a == Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux == is that kernel version of the host? can you upgrade it ? let's say to the latest 2.6.24? I will upgrade it when Debian releases next stable release :) PS: could you try KVM too? but ehm...well, sounds like you don't have VT enabled Intel processor or SVM enabled AMD processor. So, if you indeed have one...try KVM.. At this time I apply some weird combination of standard and self-made tools to keep clock in VM in sync with outer world. May be I will try to compare behaviour of different OSes in qemu and/or KVM. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Patch for compiling with GCC 4
On Feb 17, 2008, at 9:22 PM, Christian Roue wrote: Well, I somehow felt like it was a bit brutal and probably fixing the symptoms which is apparently the case. Looking more carefully, compile fails in : sh4-linux-user for function op_cmp_str_T0_T1 gcc optimization leads to a ret followed by a last assignement with a jump back. I guess dyngen hopes to find function epilogue as the last bytes. It's apparently the only function where it happens. I found that adding gcc option "-fno-tree-dominator-opts" for sh4 target avoids this (I suppose) unwanted optimization. It may be a bit brutal again ( disabling too many optims or wrong ones). May be the op_cmp_str_T0_T1 function can be rewritten to something that avoids this optimization. Am I on a better track ? This looks like the right approach to the symptoms. The "real fix" would be to move the sh4 target to TCG, but for the meantime I believe this is the way to go. You can already find a lot of these unoptimization flags autodetected in the configure script, so I guess that'd be the right place for a patch. I am not sure if anybody with commit right listens, though. Regards, Alex Bye Chris. On Feb 16, 2008 9:01 PM, Paul Brook <[EMAIL PROTECTED]> wrote: On Saturday 16 February 2008, Christian Roue wrote: Hi all, I tried to compile qemu cvs head on my x86_64 linux with gcc 4.1.2 using --disable-gcc-check, I found compile fails as stated in configure before i disabled gcc check.. Error message, points to a problem of dyngen not correctly detecting function ends on i386 when last instruction is a jump. I applied following change and successfully compiled/run qemu i386. This extra test check for a relative backward jump to function exit ret, gcc 4 apparently generates a few of these. You patch is wrong. The dyngen error is correct. Paul
Re: [Qemu-devel] [PATCH] Honor TMPDIR environment variable
Any news about this patch?
Aurelien Jarno a écrit :
> The patch below adds support for the -snapshot option to use the TMPDIR
> environment variable.
>
> ---
> block.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/block.c b/block.c
> index 0f8ad7b..0730954 100644
> --- a/block.c
> +++ b/block.c
> @@ -191,8 +191,12 @@ void get_tmp_filename(char *filename, int size)
> void get_tmp_filename(char *filename, int size)
> {
> int fd;
> +char *tmpdir;
> /* XXX: race condition possible */
> -pstrcpy(filename, size, "/tmp/vl.XX");
> +tmpdir = getenv("TMPDIR");
> +if (!tmpdir)
> +tmpdir = "/tmp";
> +snprintf(filename, size, "%s/vl.XX", tmpdir);
> fd = mkstemp(filename);
> close(fd);
> }
>
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
