[Qemu-devel] Re: QEMU keyboard issue with Gujin-2.2

2007-09-24 Thread Alexander E. Patrakov

Stefan Weil wrote:

Hello,

could you try this file (when Berlios servers are online again):
http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/ps2.c?op=file

I had a similar problem, and the patched version of ps2.c helped...


Unfortunately, it doesn't help. But it repeats the following line over 
and over again in the qemu output:


/home/patrakov/qemu/qemu-snapshot-2007-09-24_05/hw/ps2.c:250 
ps2_keyboard_set_translation(1)


--
Alexander E. Patrakov




[Qemu-devel] [PATCH] linux-user sigaltstack() syscall

2007-09-24 Thread Thayne Harbaugh
This patch adds the sigaltstack() syscall for linux-user.
Index: qemu/linux-user/signal.c
===
--- qemu.orig/linux-user/signal.c	2007-09-24 22:45:48.0 -0600
+++ qemu/linux-user/signal.c	2007-09-24 22:56:18.0 -0600
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include "target_signal.h"
 #include "qemu.h"
 
 /*
@@ -51,6 +52,12 @@
  first signal, we put it here */
 };
 
+struct target_sigaltstack target_sigaltstack_used = {
+.ss_sp = 0,
+.ss_size = 0,
+.ss_flags = TARGET_SS_DISABLE,
+};
+
 static struct emulated_sigaction sigact_table[TARGET_NSIG];
 static struct sigqueue sigqueue_table[MAX_SIGQUEUE_SIZE]; /* siginfo queue */
 static struct sigqueue *first_free; /* first free siginfo queue entry */
@@ -98,6 +105,18 @@
 };
 static uint8_t target_to_host_signal_table[65];
 
+static inline int on_sig_stack(unsigned long sp)
+{
+return (sp - target_sigaltstack_used.ss_sp
+< target_sigaltstack_used.ss_size);
+}
+
+static inline int sas_ss_flags(unsigned long sp)
+{
+return (target_sigaltstack_used.ss_size == 0 ? SS_DISABLE
+: on_sig_stack(sp) ? SS_ONSTACK : 0);
+}
+
 static inline int host_to_target_signal(int sig)
 {
 return host_to_target_signal_table[sig];
@@ -420,6 +439,66 @@
 }
 }
 
+int do_sigaltstack(const struct target_sigaltstack *uss,
+   struct target_sigaltstack *uoss,
+   target_ulong sp)
+{
+int ret;
+struct target_sigaltstack oss;
+
+/* XXX: test errors */
+if(uoss)
+{
+oss.ss_sp = tswap32(target_sigaltstack_used.ss_sp);
+oss.ss_size = tswap32(target_sigaltstack_used.ss_size);
+oss.ss_flags = tswap32(sas_ss_flags(sp));
+}
+
+if(uss)
+{
+	struct target_sigaltstack ss;
+
+	ret = -EFAULT;
+	if (!access_ok(VERIFY_READ, uss, sizeof(*uss))
+	|| __get_user(ss.ss_sp, &uss->ss_sp)
+	|| __get_user(ss.ss_size, &uss->ss_size)
+	|| __get_user(ss.ss_flags, &uss->ss_flags))
+goto out;
+
+	ret = -EPERM;
+	if (on_sig_stack(sp))
+goto out;
+
+	ret = -EINVAL;
+	if (ss.ss_flags != TARGET_SS_DISABLE
+&& ss.ss_flags != TARGET_SS_ONSTACK
+&& ss.ss_flags != 0)
+goto out;
+
+	if (ss.ss_flags == TARGET_SS_DISABLE) {
+ss.ss_size = 0;
+ss.ss_sp = 0;
+	} else {
+ret = -ENOMEM;
+if (ss.ss_size < MINSIGSTKSZ)
+goto out;
+	}
+
+target_sigaltstack_used.ss_sp = ss.ss_sp;
+target_sigaltstack_used.ss_size = ss.ss_size;
+}
+
+if (uoss) {
+ret = -EFAULT;
+if (copy_to_user(uoss, &oss, sizeof(oss)))
+goto out;
+}
+
+ret = 0;
+out:
+return ret;
+}
+
 int do_sigaction(int sig, const struct target_sigaction *act,
  struct target_sigaction *oact)
 {
@@ -550,12 +629,6 @@
 	target_ulong cr2;
 };
 
-typedef struct target_sigaltstack {
-	target_ulong ss_sp;
-	int ss_flags;
-	target_ulong ss_size;
-} target_stack_t;
-
 struct target_ucontext {
 target_ulong	  tuc_flags;
 	target_ulong  tuc_link;
@@ -639,16 +712,14 @@
 
 	/* Default to using normal stack */
 	esp = env->regs[R_ESP];
-#if 0
 	/* This is the X/Open sanctioned signal stack switching.  */
-	if (ka->sa.sa_flags & SA_ONSTACK) {
-		if (sas_ss_flags(esp) == 0)
-			esp = current->sas_ss_sp + current->sas_ss_size;
-	}
+if (ka->sa.sa_flags & TARGET_SA_ONSTACK) {
+if (sas_ss_flags(esp) == 0)
+esp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
+}
 
 	/* This is the legacy signal stack switching. */
 	else
-#endif
 if ((env->segs[R_SS].selector & 0x) != __USER_DS &&
 !(ka->sa.sa_flags & TARGET_SA_RESTORER) &&
 ka->sa.sa_restorer) {
@@ -749,11 +820,11 @@
 	/* Create the ucontext.  */
 	err |= __put_user(0, &frame->uc.tuc_flags);
 	err |= __put_user(0, &frame->uc.tuc_link);
-	err |= __put_user(/*current->sas_ss_sp*/ 0,
+	err |= __put_user(target_sigaltstack_used.ss_sp,
 			  &frame->uc.tuc_stack.ss_sp);
-	err |= __put_user(/* sas_ss_flags(regs->esp) */ 0,
+	err |= __put_user(sas_ss_flags(get_sp_from_cpustate(env)),
 			  &frame->uc.tuc_stack.ss_flags);
-	err |= __put_user(/* current->sas_ss_size */ 0,
+	err |= __put_user(target_sigaltstack_used.ss_size,
 			  &frame->uc.tuc_stack.ss_size);
 	err |= setup_sigcontext(&frame->uc.tuc_mcontext, &frame->fpstate,
 			env, set->sig[0]);
@@ -877,7 +948,6 @@
 {
 	struct rt_sigframe *frame = (struct rt_sigframe *)g2h(env->regs[R_ESP] - 4);
 sigset_t set;
-//	stack_t st;
 	int eax;
 
 #if 0
@@ -890,13 +960,9 @@
 	if (restore_sigcontext(env, &frame->uc.tuc_mcontext, &eax))
 		goto badframe;
 
-#if 0
-	if (__copy_from_user(&st, &frame->uc.tuc_stack, sizeof(st)))
+	if (do_sigaltstack(&frame->uc.tuc_stack, NULL, get_sp_from_cpustate(env)) == -EFAULT)
 		goto badframe;
-	/* It i

Re: [Qemu-devel] Updated RFC: linux user problems]]

2007-09-24 Thread Thayne Harbaugh
I've often wondered why there isn't a tswap_target_ulong().  Seems like
using tswap32() is asking for trouble.





Re: [Qemu-devel] Re: [PATCH] linux-user utimensat() syscall

2007-09-24 Thread Thayne Harbaugh
On Mon, 2007-09-24 at 13:45 -0600, Thayne Harbaugh wrote:
> On Sun, 2007-09-23 at 12:58 -0400, Stuart Anderson wrote:
> > On Sun, 23 Sep 2007, Thiemo Seufer wrote:
> > 
> > > Thayne Harbaugh wrote:
> > >> This patch adds the utimensat syscall to linux-user
> 
> Oops!
> 
> > > Doesn't build:
> > >
> > > gcc-3.4 -g  -Wl,-T,/home/ths/qemu/qemu-work/ppc.ld   -o qemu-arm main.o 
> > > syscall.o mmap.o signal.o path.o osdep.o thunk.o elfload.o linuxload.o 
> > > flatload.o nwfpe/fpa11.o nwfpe/fpa11_cpdo.o nwfpe/fpa11_cpdt.o 
> > > nwfpe/fpa11_cprt.o nwfpe/fpopcode.o nwfpe/single_cpdo.o 
> > > nwfpe/double_cpdo.o nwfpe/extended_cpdo.o arm-semi.o libqemu.a gdbstub.o  
> > >  -lm -lrt
> > > syscall.o: In function `do_syscall':
> > > /home/ths/qemu/qemu-work/linux-user/syscall.c:4665: undefined reference 
> > > to `copy_from_user_timespec'
> > > /home/ths/qemu/qemu-work/linux-user/syscall.c:4665: undefined reference 
> > > to `copy_from_user_timespec'
> > 
> > It's looking for something that is in the EFAULT patch.
> 
> Yeah, I guess I had the EFAULT patch applied.  I'll work up a patch for
> utimensat() without the EFAULT patch.

Try this patch for utimensat() that doesn't depend on the EFAULT patch.
Index: qemu/linux-user/arm/syscall_nr.h
===
--- qemu.orig/linux-user/arm/syscall_nr.h	2007-09-24 15:22:35.0 -0600
+++ qemu/linux-user/arm/syscall_nr.h	2007-09-24 15:22:58.0 -0600
@@ -325,3 +325,4 @@
 #define TARGET_NR_mbind			319
 #define TARGET_NR_get_mempolicy		320
 #define TARGET_NR_set_mempolicy		321
+#define TARGET_NR_utimensat			348
Index: qemu/linux-user/i386/syscall_nr.h
===
--- qemu.orig/linux-user/i386/syscall_nr.h	2007-09-24 15:22:42.0 -0600
+++ qemu/linux-user/i386/syscall_nr.h	2007-09-24 15:22:58.0 -0600
@@ -275,3 +275,5 @@
 #define TARGET_NR_utimes		271
 
 #define TARGET_NR_set_robust_list	311
+
+#define TARGET_NR_utimensat		320
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c	2007-09-24 15:22:50.0 -0600
+++ qemu/linux-user/syscall.c	2007-09-24 15:41:51.0 -0600
@@ -146,6 +146,7 @@
 #define __NR_sys_syslog __NR_syslog
 #define __NR_sys_tgkill __NR_tgkill
 #define __NR_sys_tkill __NR_tkill
+#define __NR_sys_utimensat __NR_utimensat
 
 #if defined(__alpha__) || defined (__ia64__) || defined(__x86_64__)
 #define __NR__llseek __NR_lseek
@@ -180,6 +181,10 @@
 #if defined(TARGET_NR_set_tid_address) && defined(__NR_set_tid_address)
 _syscall1(int,set_tid_address,int *,tidptr)
 #endif
+#if defined(TARGET_NR_utimensat) && defined(__NR_utimensat)
+_syscall4(int,sys_utimensat,int,dirfd,const char *,pathname,
+  const struct timespec *,tsp,int,flags)
+#endif
 
 extern int personality(int);
 extern int flock(int, int);
@@ -4653,6 +4658,27 @@
 	goto unimplemented_nowarn;
 #endif
 
+#if defined(TARGET_NR_utimensat) && defined(__NR_utimensat)
+case TARGET_NR_utimensat:
+{
+struct timespec ts[2];
+target_to_host_timespec(ts, arg3);
+target_to_host_timespec(ts+1, arg3+sizeof(struct target_timespec));
+if (!arg2)
+ret = get_errno(sys_utimensat(arg1, NULL, ts, arg4));
+else {
+p = lock_user_string(arg2);
+if (!access_ok(VERIFY_READ, p, 1))
+ret = -EFAULT;
+else
+ret = get_errno(sys_utimensat(arg1, path(p), ts, arg4));
+if (p)
+unlock_user(p, arg2, 0);
+}
+}
+	break;
+#endif
+
 default:
 unimplemented:
 gemu_log("qemu: Unsupported syscall: %d\n", num);


Re: [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-24 Thread andrzej zaborowski
Hi,

On 24/09/2007, Dan Kenigsberg <[EMAIL PROTECTED]> wrote:
> As with previous "Takes" of this patch, its purpose is to expose host
> CPU features to guests. It proved rather helpful to KVM in various
> benchmarks, and it should similarly speed kqemu up. Note that it does
> not extend the set of emulated opcodes, only exposes what's supported by
> the host CPU.
>
> Another purpose for "Take 2" is to add the -cpu option to the x86
> architecture, similarly to that of other architectures.
> -cpu 486, pentium, pentium2 and pentium3 are supported in addition to
> finer-grained features such as -cpu pentium,-mmx . As in Take 1,
> -cpu host exposes host features to guest.
>
> This patch exposes the requested CPU also right after RESET command, and
> not only in CPUID.
>
> Please let me know if you have more suggestions,
>
> Dan.
>
> ===
>
> Index: vl.c
> ===
> RCS file: /sources/qemu/qemu/vl.c,v
> retrieving revision 1.342
> diff -u -p -r1.342 vl.c
> --- vl.c17 Sep 2007 21:25:20 -  1.342
> +++ vl.c24 Sep 2007 16:53:29 -
> @@ -7694,6 +7694,8 @@ int main(int argc, char **argv)
>  mips_cpu_list(stdout, &fprintf);
>  #elif defined(TARGET_SPARC)
>  sparc_cpu_list(stdout, &fprintf);
> +#elif defined(TARGET_I386)
> +x86_cpu_list(stdout, &fprintf);
>  #endif
>  exit(0);
>  } else {
> Index: hw/pc.c
> ===
> RCS file: /sources/qemu/qemu/hw/pc.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 pc.c
> --- hw/pc.c 17 Sep 2007 08:09:47 -  1.85
> +++ hw/pc.c 24 Sep 2007 16:53:29 -
> @@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
>   DisplayState *ds, const char **fd_filename, int 
> snapshot,
>   const char *kernel_filename, const char *kernel_cmdline,
>   const char *initrd_filename,
> - int pci_enabled)
> + int pci_enabled, const char *cpu_model)
>  {
>  char buf[1024];
>  int ret, linux_boot, i;
> @@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
>  linux_boot = (kernel_filename != NULL);
>
>  /* init CPUs */
> +if (cpu_model == NULL)
> +cpu_model = "basic";
> +
> +if (x86_find_cpu_by_name(cpu_model)) {
> +fprintf(stderr, "Unable to find x86 CPU definition\n");
> +exit(1);
> +}
>  for(i = 0; i < smp_cpus; i++) {
>  env = cpu_init();
>  if (i != 0)
> @@ -948,7 +955,7 @@ static void pc_init_pci(int ram_size, in
>  pc_init1(ram_size, vga_ram_size, boot_device,
>   ds, fd_filename, snapshot,
>   kernel_filename, kernel_cmdline,
> - initrd_filename, 1);
> + initrd_filename, 1, cpu_model);
>  }
>
>  static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
> @@ -962,7 +969,7 @@ static void pc_init_isa(int ram_size, in
>  pc_init1(ram_size, vga_ram_size, boot_device,
>   ds, fd_filename, snapshot,
>   kernel_filename, kernel_cmdline,
> - initrd_filename, 0);
> + initrd_filename, 0, cpu_model);
>  }
>
>  QEMUMachine pc_machine = {
> Index: target-i386/cpu.h
> ===
> RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
> retrieving revision 1.48
> diff -u -p -r1.48 cpu.h
> --- target-i386/cpu.h   23 Sep 2007 15:28:04 -  1.48
> +++ target-i386/cpu.h   24 Sep 2007 16:53:30 -
> @@ -274,23 +274,56 @@
>  #define CPUID_CMOV (1 << 15)
>  #define CPUID_PAT  (1 << 16)
>  #define CPUID_PSE36   (1 << 17)
> +#define CPUID_PN   (1 << 18)
>  #define CPUID_CLFLUSH (1 << 19)
> -/* ... */
> +#define CPUID_DTS (1 << 21)
> +#define CPUID_ACPI (1 << 22)
>  #define CPUID_MMX  (1 << 23)
>  #define CPUID_FXSR (1 << 24)
>  #define CPUID_SSE  (1 << 25)
>  #define CPUID_SSE2 (1 << 26)
> +#define CPUID_SS (1 << 27)
> +#define CPUID_HT (1 << 28)
> +#define CPUID_TM (1 << 29)
> +#define CPUID_IA64 (1 << 30)
> +#define CPUID_PBE (1 << 31)
>
>  #define CPUID_EXT_SSE3 (1 << 0)
>  #define CPUID_EXT_MONITOR  (1 << 3)
> +#define CPUID_EXT_DSCPL(1 << 4)
> +#define CPUID_EXT_VMX  (1 << 5)
> +#define CPUID_EXT_SMX  (1 << 6)
> +#define CPUID_EXT_EST  (1 << 7)
> +#define CPUID_EXT_TM2  (1 << 8)
> +#define CPUID_EXT_SSSE3(1 << 9)
> +#define CPUID_EXT_CID  (1 << 10)
>  #define CPUID_EXT_CX16 (1 << 13)
> +#define CPUID_EXT_XTPR (1 << 14)
> +#define CPUID_EXT_DCA  (1 << 17)
> +#define CPUID_EXT_POPCNT   (1 << 22)
>
>  #define CPUID_EXT2_SYSCALL (1 << 11)
> +#define CPUID_EXT2_MP  (1 << 19)
>  #define CPUID_EXT2_NX  (1 << 20)
> +#define CPUID_EXT2_MMXEXT  (1 << 22)
>  #define CPUID_EXT2_FFXSR   (1 << 25)
> +#define CPUID_EXT2_PDPE1GB (1 << 2

[Qemu-devel] qemu Makefile.target vl.h hw/ecc.c ecc.h

2007-09-24 Thread Andrzej Zaborowski
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski  07/09/25 01:17:04

Modified files:
.  : Makefile.target vl.h 
Added files:
hw : ecc.c 
Removed files:
.  : ecc.h 

Log message:
Move ECC calculation to a more appropriate place.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.196&r2=1.197
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.267&r2=1.268
http://cvs.savannah.gnu.org/viewcvs/qemu/ecc.h?cvsroot=qemu&r1=1.2&r2=0
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ecc.c?cvsroot=qemu&rev=1.1




[Qemu-devel] Re: [PATCH] vvfat mbr fixes

2007-09-24 Thread Johannes Schindelin
Hi,

On Mon, 24 Sep 2007, Lorenzo Campedelli wrote:

> I think you were referring to the small patch I sent. I actually gave up 
> with it, as I don't see how to make it in a clean way.
> 
> Honestly I found your suggestion to try to have it less special-casing 
> vvfat a bit puzzling... vvfat is the only case in which there's any need 
> to override realpath() behaviour, so I tried to make it as clear as 
> possible.

It makes the code ugly as hell, and it limits (unnecessarily) future 
extensions.

But since you made quite clear that you do not want to change your patch, 
I will stop wasting my time.

Ciao,
Dscho





Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

2007-09-24 Thread Fabrice Bellard
I realize that the other pixel formats are buggy too, so at least your 
patch is consistent with what is already coded !


I guess the problem is in the VGA memory handlers. Otherwise it means 
that there is a (Cirrus)VGA configuration register to change the 
endianness of the frame buffer. In such case, it must be emulated correctly.


Regards,

Fabrice.

Stefan Weil wrote:

Hello,

here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.

Regards
Stefan






Index: hw/vga_template.h
===
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h   11 May 2006 21:54:44 -  1.13
+++ hw/vga_template.h   14 Jun 2007 20:10:25 -
@@ -327,6 +327,16 @@
 palette = s1->last_palette;
 width >>= 3;
 for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+((PIXEL_TYPE *)d)[3] = palette[s[0]];
+((PIXEL_TYPE *)d)[2] = palette[s[1]];
+((PIXEL_TYPE *)d)[1] = palette[s[2]];
+((PIXEL_TYPE *)d)[0] = palette[s[3]];
+((PIXEL_TYPE *)d)[7] = palette[s[4]];
+((PIXEL_TYPE *)d)[6] = palette[s[5]];
+((PIXEL_TYPE *)d)[5] = palette[s[6]];
+((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
 ((PIXEL_TYPE *)d)[0] = palette[s[0]];
 ((PIXEL_TYPE *)d)[1] = palette[s[1]];
 ((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
 ((PIXEL_TYPE *)d)[5] = palette[s[5]];
 ((PIXEL_TYPE *)d)[6] = palette[s[6]];
 ((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
 d += BPP * 8;
 s += 8;
 }







Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

2007-09-24 Thread Fabrice Bellard
The problem must come from somewhere else. VGA (as any other device) 
must not depend on the target CPU endianness (note that the endianness 
tests in the memory handlers are only necessary because the bus API is 
still incomplete).


Regards,

Fabrice.

Stefan Weil wrote:

Hello,

here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.

Regards
Stefan






Index: hw/vga_template.h
===
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h   11 May 2006 21:54:44 -  1.13
+++ hw/vga_template.h   14 Jun 2007 20:10:25 -
@@ -327,6 +327,16 @@
 palette = s1->last_palette;
 width >>= 3;
 for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+((PIXEL_TYPE *)d)[3] = palette[s[0]];
+((PIXEL_TYPE *)d)[2] = palette[s[1]];
+((PIXEL_TYPE *)d)[1] = palette[s[2]];
+((PIXEL_TYPE *)d)[0] = palette[s[3]];
+((PIXEL_TYPE *)d)[7] = palette[s[4]];
+((PIXEL_TYPE *)d)[6] = palette[s[5]];
+((PIXEL_TYPE *)d)[5] = palette[s[6]];
+((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
 ((PIXEL_TYPE *)d)[0] = palette[s[0]];
 ((PIXEL_TYPE *)d)[1] = palette[s[1]];
 ((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
 ((PIXEL_TYPE *)d)[5] = palette[s[5]];
 ((PIXEL_TYPE *)d)[6] = palette[s[6]];
 ((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
 d += BPP * 8;
 s += 8;
 }







Re: [Qemu-devel] qemu elf_ops.h

2007-09-24 Thread Fabrice Bellard
Try to avoid using target_phys_addr_t at this place as I don't want this 
code to be CPU dependent (think of a machine having several different 
CPUs !).


Regards,

Fabrice.

Blue Swirl wrote:

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/09/24 18:41:27

Modified files:
	.  : elf_ops.h 


Log message:
 Fix loading above 4G

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemu&r1=1.8&r2=1.9










Re: [Qemu-devel] qemu monitor.c

2007-09-24 Thread Fabrice Bellard

Hi,

I don't think this is the right fix because the monitor expressions can 
be used for either virtual or physical addresses. I suggest using 64 bit 
integers for every target.


Fabrice.

Blue Swirl wrote:

CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/09/24 18:39:04

Modified files:
	.  : monitor.c 


Log message:
 Fix >4G physical memory dump for Sparc32

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemu&r1=1.81&r2=1.82










Re: [Qemu-devel] [Bug] Timer bugs in hw/m48t59.c?

2007-09-24 Thread J. Mayer
On Mon, 2007-09-24 at 19:24 +0200, Stefan Weil wrote:
> Hello,

Hi,

> the bug mentioned in my previous mail is still open.
> Could someone please add the patch to CVS HEAD
> (or find another solution)?

Seems you're right, this code would lead to crashes. I think there are
other issues to address in the same code because alrm_timer and wd_timer
are always NULL if the RTC model is a m48t08.
Could you please take a look at this updated patch ?

Regards.

> 
> Thank you
> Stefan
> 
> Stefan Weil schrieb:
> > Hi,
> >
> > could SPARC or PPC users please check whether the timer code
> > in hw/m48t59.c is really correct?
> >
> > I expect a crash in qemu_mod_timer after wd_timer = NULL and
> > a call to qemu_mod_timer with this NULL value.
> >
> > The same applies to alrm_timer.
> >
> > I wrote a quick-and-dirty patch, but think that even more
> > old code could be removed.
> >
> > Stefan
> >
[...]

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: hw/m48t59.c
===
RCS file: /sources/qemu/qemu/hw/m48t59.c,v
retrieving revision 1.14
diff -u -d -d -p -r1.14 m48t59.c
--- hw/m48t59.c	17 Sep 2007 08:09:47 -	1.14
+++ hw/m48t59.c	24 Sep 2007 20:24:01 -
@@ -161,10 +161,9 @@ static void set_alarm (m48t59_t *NVRAM, 
 NVRAM->alarm = mktime(tm);
 if (NVRAM->alrm_timer != NULL) {
 qemu_del_timer(NVRAM->alrm_timer);
-	NVRAM->alrm_timer = NULL;
+if (NVRAM->alarm - time(NULL) > 0)
+qemu_mod_timer(NVRAM->alrm_timer, NVRAM->alarm * 1000);
 }
-if (NVRAM->alarm - time(NULL) > 0)
-	qemu_mod_timer(NVRAM->alrm_timer, NVRAM->alarm * 1000);
 }
 
 /* Watchdog management */
@@ -188,15 +187,14 @@ static void set_up_watchdog (m48t59_t *N
 {
 uint64_t interval; /* in 1/16 seconds */
 
+NVRAM->buffer[0x1FF0] &= ~0x80;
 if (NVRAM->wd_timer != NULL) {
 qemu_del_timer(NVRAM->wd_timer);
-	NVRAM->wd_timer = NULL;
-}
-NVRAM->buffer[0x1FF0] &= ~0x80;
-if (value != 0) {
-	interval = (1 << (2 * (value & 0x03))) * ((value >> 2) & 0x1F);
-	qemu_mod_timer(NVRAM->wd_timer, ((uint64_t)time(NULL) * 1000) +
-		   ((interval * 1000) >> 4));
+if (value != 0) {
+interval = (1 << (2 * (value & 0x03))) * ((value >> 2) & 0x1F);
+qemu_mod_timer(NVRAM->wd_timer, ((uint64_t)time(NULL) * 1000) +
+   ((interval * 1000) >> 4));
+}
 }
 }
 


Re: [Qemu-devel] Re: [PATCH] linux-user utimensat() syscall

2007-09-24 Thread Thayne Harbaugh
On Sun, 2007-09-23 at 12:58 -0400, Stuart Anderson wrote:
> On Sun, 23 Sep 2007, Thiemo Seufer wrote:
> 
> > Thayne Harbaugh wrote:
> >> This patch adds the utimensat syscall to linux-user

Oops!

> > Doesn't build:
> >
> > gcc-3.4 -g  -Wl,-T,/home/ths/qemu/qemu-work/ppc.ld   -o qemu-arm main.o 
> > syscall.o mmap.o signal.o path.o osdep.o thunk.o elfload.o linuxload.o 
> > flatload.o nwfpe/fpa11.o nwfpe/fpa11_cpdo.o nwfpe/fpa11_cpdt.o 
> > nwfpe/fpa11_cprt.o nwfpe/fpopcode.o nwfpe/single_cpdo.o nwfpe/double_cpdo.o 
> > nwfpe/extended_cpdo.o arm-semi.o libqemu.a gdbstub.o   -lm -lrt
> > syscall.o: In function `do_syscall':
> > /home/ths/qemu/qemu-work/linux-user/syscall.c:4665: undefined reference to 
> > `copy_from_user_timespec'
> > /home/ths/qemu/qemu-work/linux-user/syscall.c:4665: undefined reference to 
> > `copy_from_user_timespec'
> 
> It's looking for something that is in the EFAULT patch.

Yeah, I guess I had the EFAULT patch applied.  I'll work up a patch for
utimensat() without the EFAULT patch.





[Qemu-devel] qemu cpu-exec.c hw/sun4m.c target-sparc/cpu.h t...

2007-09-24 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/09/24 19:44:09

Modified files:
.  : cpu-exec.c 
hw : sun4m.c 
target-sparc   : cpu.h helper.c op_helper.c translate.c 

Log message:
 CPU boot mode

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.116&r2=1.117
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.49&r2=1.50
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemu&r1=1.49&r2=1.50
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/helper.c?cvsroot=qemu&r1=1.26&r2=1.27
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.38&r2=1.39
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.69&r2=1.70




[Qemu-devel] Re: [PATCH] vvfat mbr fixes

2007-09-24 Thread Lorenzo Campedelli

Johannes Schindelin wrote:

Hi,

On Mon, 24 Sep 2007, Ivan Kalvachev wrote:


2007/9/24, Johannes Schindelin <[EMAIL PROTECTED]>:


On Mon, 24 Sep 2007, Ivan Kalvachev wrote:

I had a discussion with Johannes Schindelin over my patch, that I 
thought is on the maillist, but apparently it wasn't. I'm 
subscribed, so please don't send me mails directly, gmail web 
interface could be quite misleading.


So here is the third revision of my patch. Changes include: using 
more structures instead of fixed byte locations. chs and nt_id. more 
detailed comments, function name shortened and if(lba) moved to ?: 
construct.

Almost all my comments went unheeded.

I believe that I've answered and addressed all your comments.


Ooops.  I think I mixed up your patch with the other patch for vvfat that 
floated around recently.  (Probably because the patch was not inlined...)


FWIW if we're talking about qemu_vvfat_mbr_v3.patch, I have no more 
gripes.


Thanks,
Dscho




I think you were referring to the small patch I sent.
I actually gave up with it, as I don't see how to make
it in a clean way.

Honestly I found your suggestion to try to have it
less special-casing vvfat a bit puzzling...
vvfat is the only case in which there's any need to
override realpath() behaviour, so I tried to make it
as clear as possible.
Why is it better to affect code paths which don't need
any change?

Regards,
Lorenzo





[Qemu-devel] qemu elf_ops.h

2007-09-24 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/09/24 18:41:27

Modified files:
.  : elf_ops.h 

Log message:
 Fix loading above 4G

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemu&r1=1.8&r2=1.9




[Qemu-devel] qemu monitor.c

2007-09-24 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/09/24 18:39:04

Modified files:
.  : monitor.c 

Log message:
 Fix >4G physical memory dump for Sparc32

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemu&r1=1.81&r2=1.82




Re: [Qemu-devel] Updated RFC: linux user problems]]

2007-09-24 Thread Jocelyn Mayer
On Mon, 2007-09-24 at 13:19 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > > > > May someone take a look at my patch and say if it seems reasonable to
> > > > > include this in the repository ?
> > > > 
> > > > Looks reasonable, but introduces new compiler warnings
> > > > (on a ppc32/Linux host):
> > 
> > The reported warnings have been fixed.
> > There are still a lot of warnings related to 32/64 bits invalid casts on
> > 64 bits hosts (see above) which will need to be fixed once.
> > 
> > I also changed some parameters of do_ipc from long to int (instead of
> > target_long), following the do_ipc man page specification, and reported
> > this change in child functions. There may be more to do...
> > 
> > Please comment...
> 
> Fine with me, FWIW.

Great. I may do another pass, to check all helpers against long/int
confusion to avoid using target_ulong when not necessary.
I would appreciate anyone who would test the patch on other platforms
than x86 / PowerPC, as I would like not to break everything...






[Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

2007-09-24 Thread Stefan Weil
Hello,

here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.

Regards
Stefan


Index: hw/vga_template.h
===
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h	11 May 2006 21:54:44 -	1.13
+++ hw/vga_template.h	14 Jun 2007 20:10:25 -
@@ -327,6 +327,16 @@
 palette = s1->last_palette;
 width >>= 3;
 for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+((PIXEL_TYPE *)d)[3] = palette[s[0]];
+((PIXEL_TYPE *)d)[2] = palette[s[1]];
+((PIXEL_TYPE *)d)[1] = palette[s[2]];
+((PIXEL_TYPE *)d)[0] = palette[s[3]];
+((PIXEL_TYPE *)d)[7] = palette[s[4]];
+((PIXEL_TYPE *)d)[6] = palette[s[5]];
+((PIXEL_TYPE *)d)[5] = palette[s[6]];
+((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
 ((PIXEL_TYPE *)d)[0] = palette[s[0]];
 ((PIXEL_TYPE *)d)[1] = palette[s[1]];
 ((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
 ((PIXEL_TYPE *)d)[5] = palette[s[5]];
 ((PIXEL_TYPE *)d)[6] = palette[s[6]];
 ((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
 d += BPP * 8;
 s += 8;
 }



[Qemu-devel] expose host CPU features to guests: Take 3

2007-09-24 Thread Dan Kenigsberg
As with previous "Takes" of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.

Another purpose for "Take 2" is to add the -cpu option to the x86
architecture, similarly to that of other architectures. 
-cpu 486, pentium, pentium2 and pentium3 are supported in addition to
finer-grained features such as -cpu pentium,-mmx . As in Take 1,
-cpu host exposes host features to guest.

This patch exposes the requested CPU also right after RESET command, and
not only in CPUID.

Please let me know if you have more suggestions,

Dan.

===

Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.342
diff -u -p -r1.342 vl.c
--- vl.c17 Sep 2007 21:25:20 -  1.342
+++ vl.c24 Sep 2007 16:53:29 -
@@ -7694,6 +7694,8 @@ int main(int argc, char **argv)
 mips_cpu_list(stdout, &fprintf);
 #elif defined(TARGET_SPARC)
 sparc_cpu_list(stdout, &fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, &fprintf);
 #endif
 exit(0);
 } else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.85
diff -u -p -r1.85 pc.c
--- hw/pc.c 17 Sep 2007 08:09:47 -  1.85
+++ hw/pc.c 24 Sep 2007 16:53:29 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
  DisplayState *ds, const char **fd_filename, int snapshot,
  const char *kernel_filename, const char *kernel_cmdline,
  const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
 {
 char buf[1024];
 int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
 linux_boot = (kernel_filename != NULL);
 
 /* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
 for(i = 0; i < smp_cpus; i++) {
 env = cpu_init();
 if (i != 0)
@@ -948,7 +955,7 @@ static void pc_init_pci(int ram_size, in
 pc_init1(ram_size, vga_ram_size, boot_device,
  ds, fd_filename, snapshot,
  kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
 }
 
 static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -962,7 +969,7 @@ static void pc_init_isa(int ram_size, in
 pc_init1(ram_size, vga_ram_size, boot_device,
  ds, fd_filename, snapshot,
  kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
 }
 
 QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.48
diff -u -p -r1.48 cpu.h
--- target-i386/cpu.h   23 Sep 2007 15:28:04 -  1.48
+++ target-i386/cpu.h   24 Sep 2007 16:53:30 -
@@ -274,23 +274,56 @@
 #define CPUID_CMOV (1 << 15)
 #define CPUID_PAT  (1 << 16)
 #define CPUID_PSE36   (1 << 17)
+#define CPUID_PN   (1 << 18)
 #define CPUID_CLFLUSH (1 << 19)
-/* ... */
+#define CPUID_DTS (1 << 21)
+#define CPUID_ACPI (1 << 22)
 #define CPUID_MMX  (1 << 23)
 #define CPUID_FXSR (1 << 24)
 #define CPUID_SSE  (1 << 25)
 #define CPUID_SSE2 (1 << 26)
+#define CPUID_SS (1 << 27)
+#define CPUID_HT (1 << 28)
+#define CPUID_TM (1 << 29)
+#define CPUID_IA64 (1 << 30)
+#define CPUID_PBE (1 << 31)
 
 #define CPUID_EXT_SSE3 (1 << 0)
 #define CPUID_EXT_MONITOR  (1 << 3)
+#define CPUID_EXT_DSCPL(1 << 4)
+#define CPUID_EXT_VMX  (1 << 5)
+#define CPUID_EXT_SMX  (1 << 6)
+#define CPUID_EXT_EST  (1 << 7)
+#define CPUID_EXT_TM2  (1 << 8)
+#define CPUID_EXT_SSSE3(1 << 9)
+#define CPUID_EXT_CID  (1 << 10)
 #define CPUID_EXT_CX16 (1 << 13)
+#define CPUID_EXT_XTPR (1 << 14)
+#define CPUID_EXT_DCA  (1 << 17)
+#define CPUID_EXT_POPCNT   (1 << 22)
 
 #define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MP  (1 << 19)
 #define CPUID_EXT2_NX  (1 << 20)
+#define CPUID_EXT2_MMXEXT  (1 << 22)
 #define CPUID_EXT2_FFXSR   (1 << 25)
+#define CPUID_EXT2_PDPE1GB (1 << 26)
+#define CPUID_EXT2_RDTSCP  (1 << 27)
 #define CPUID_EXT2_LM  (1 << 29)
+#define CPUID_EXT2_3DNOWEXT (1 << 30)
+#define CPUID_EXT2_3DNOW   (1 << 31)
 
+#define CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
 #define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)

Re: [Qemu-devel] QEMU keyboard issue with Gujin-2.2

2007-09-24 Thread Stefan Weil
Hello,

could you try this file (when Berlios servers are online again):
http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/ps2.c?op=file

I had a similar problem, and the patched version of ps2.c helped...

Stefan

Alexander E. Patrakov schrieb:
> Hello,
>
> if one attempts to use the Gujin bootloader inside qemu (even today's
> snapshot), one gets a message about unknown key being pressed.
>





Re: [Qemu-devel] [Bug] Timer bugs in hw/m48t59.c?

2007-09-24 Thread Stefan Weil
Hello,

the bug mentioned in my previous mail is still open.
Could someone please add the patch to CVS HEAD
(or find another solution)?

Thank you
Stefan

Stefan Weil schrieb:
> Hi,
>
> could SPARC or PPC users please check whether the timer code
> in hw/m48t59.c is really correct?
>
> I expect a crash in qemu_mod_timer after wd_timer = NULL and
> a call to qemu_mod_timer with this NULL value.
>
> The same applies to alrm_timer.
>
> I wrote a quick-and-dirty patch, but think that even more
> old code could be removed.
>
> Stefan
>
>
>
> diff -u -b -B -r1.8 m48t59.c
> --- hw/m48t59.c 14 Jun 2006 12:41:34 - 1.8
> +++ hw/m48t59.c 22 Mar 2007 20:29:15 -
> @@ -155,7 +155,6 @@
> NVRAM->alarm = mktime(tm);
> if (NVRAM->alrm_timer != NULL) {
> qemu_del_timer(NVRAM->alrm_timer);
> - NVRAM->alrm_timer = NULL;
> }
> if (NVRAM->alarm - time(NULL) > 0)
> qemu_mod_timer(NVRAM->alrm_timer, NVRAM->alarm * 1000);
> @@ -184,7 +183,6 @@
>
> if (NVRAM->wd_timer != NULL) {
> qemu_del_timer(NVRAM->wd_timer);
> - NVRAM->wd_timer = NULL;
> }
> NVRAM->buffer[0x1FF0] &= ~0x80;
> if (value != 0) {
>
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>





Re: [Qemu-devel] [PATCH] vvfat mbr fixes

2007-09-24 Thread Ivan Kalvachev
2007/9/24, Johannes Schindelin <[EMAIL PROTECTED]>:
> Hi,
> On Mon, 24 Sep 2007, Ivan Kalvachev wrote:
[...]
> > I believe that I've answered and addressed all your comments.
>
> Ooops.  I think I mixed up your patch with the other patch for vvfat that
> floated around recently.  (Probably because the patch was not inlined...)
>
> FWIW if we're talking about qemu_vvfat_mbr_v3.patch, I have no more
> gripes.


Great. Now if somebody is willing to commit it?




Re: [Qemu-devel] view qemu output/console

2007-09-24 Thread Clemens Kolbitsch
On Monday 24 September 2007 18:11:04 andrzej zaborowski wrote:
> On 24/09/2007, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
> > On Mon, 24 Sep 2007, Clemens Kolbitsch wrote:
> > > when the kernel crashes, it displayes the message, however as it is way
> > > much more information that can be displayed in the qemu window, i only
> > > see the last 20-something lines. as the crash is fatal, no entries are
> > > made to the log-files and i have not succeeded redirecting output to my
> > > console (using the -nographic option) as my linux does not boot
> > > correctly then.
> >
> > If your host is not windows, you can use the "-monitor stdio" option to
> > output monitor information on the console you start QEmu in.
>
> AIUI Clemens wants to redirect the VGA console output, not QEmu
> monitor.

exactly...

> One idea is to dig out my ncurses interface patch (I believe 
> debian has a version that applies to post-9.0 qemu, and if you're on
> debian just use the "-curses" switch), then GNU screen would let you
> log all VGA console output to a file.

ok... i'll give it a try!! thanks :-)

> Another idea is to set a 
> breakpoint at the guest printk() address.

that was my first approach.. however as I don't have the uncompressed linux 
image, i don't know what to connect gdb to :-(

can i simply uncompress the kernel-file??




Re: [Qemu-devel] view qemu output/console

2007-09-24 Thread andrzej zaborowski
On 24/09/2007, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007, Clemens Kolbitsch wrote:
>
> > when the kernel crashes, it displayes the message, however as it is way
> > much more information that can be displayed in the qemu window, i only
> > see the last 20-something lines. as the crash is fatal, no entries are
> > made to the log-files and i have not succeeded redirecting output to my
> > console (using the -nographic option) as my linux does not boot
> > correctly then.
>
> If your host is not windows, you can use the "-monitor stdio" option to
> output monitor information on the console you start QEmu in.

AIUI Clemens wants to redirect the VGA console output, not QEmu
monitor. One idea is to dig out my ncurses interface patch (I believe
debian has a version that applies to post-9.0 qemu, and if you're on
debian just use the "-curses" switch), then GNU screen would let you
log all VGA console output to a file. Another idea is to set a
breakpoint at the guest printk() address.

Regards




Re: [Qemu-devel] Re: qemu 0.9.0 and pxe boot menu

2007-09-24 Thread Andreas Hasenack

Em Sex, 2007-09-21 às 19:40 -0500, Anthony Liguori escreveu:
> Andreas Hasenack wrote:
> > Hi,
> > 
> > does qemu support the PXE boot menu? I have such a server here in my
> > network but qemu keeps loading some default system (the first one?)
> > instead of presenting me with the pxe menu.
> 
> QEMU just uses etherboot.  Are you sure that you are using bridging and 
> connected appropriately?

Yes, because the virtual machine gets an IP from my external network's
dhcp server. Anyway, I tried with a standalone etherboot client and it
didn't work either, so I think it's etherboot's fault.





Re: [Qemu-devel] view qemu output/console

2007-09-24 Thread Johannes Schindelin
Hi,

On Mon, 24 Sep 2007, Clemens Kolbitsch wrote:

> when the kernel crashes, it displayes the message, however as it is way 
> much more information that can be displayed in the qemu window, i only 
> see the last 20-something lines. as the crash is fatal, no entries are 
> made to the log-files and i have not succeeded redirecting output to my 
> console (using the -nographic option) as my linux does not boot 
> correctly then.

If your host is not windows, you can use the "-monitor stdio" option to 
output monitor information on the console you start QEmu in.

Hth,
Dscho





Re: [Qemu-devel] Another MIPS quiet NaN fix

2007-09-24 Thread Daniel Jacobowitz
On Mon, Sep 24, 2007 at 04:05:45PM +0200, Andreas Schwab wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> 
> > Glibc's test-float failed on my qemu testing.  I tracked it down to
> > these routines: if you count the bits carefully, you'll see that
> > 0x7FC0 sets the quiet NaN bit (on most hardware - signalling NaN
> > in the MIPS case); so does a.high >> 41, which copies it from the
> > original NaN.  I think this routine should not force a quiet or
> > signalling NaN, but just preserve the input NaN's signalling-ness.
> 
> You may need to make sure that at least one mantissa bit is set.

I think - but am not quite sure - that this will already be the case
because the NaN will have come from some other NaN representation.
Good point, though - we can easily set the next bit, as long as we
don't fiddle with the signalling bit.

-- 
Daniel Jacobowitz
CodeSourcery




[Qemu-devel] [PATCH] USB Webcam Redirection

2007-09-24 Thread Arnon Gilboa
Attached is an updated patch for supporting isochronous transfers in redirected 
host USB devices. The initial goal was supporting USB 1.1 Webcam. Tested on 
WinXP guest with several Webcams. Works on USB 1.1 Webcams, as well as most USB 
2.0 Webcams (backward compatibility) on low resolutions. Some jitter is visible 
in the video stream, and it will be fixed. 

Notice USE_ASYNCIO, which defines whether to use signal based async io or 
polling for receiving urbs. Currently it is disabled, so polling is used, but 
it does not seem to affect the performance because it uses the non-blocking 
USBDEVFS_REAPURBNDELAY ioctl. In order to use the signal based async io, the 
patch to usb-uhci.c should be applied.

The patch includes parts of previous patches posted in Qemu-devel: 
usb_host_update_interfaces (from qemu-0.9.0-usb-multi-configs.patch), 
usb_linux_update_endp_table (qemu-usb-host-async.patch) as well as some other 
lines of code.

I am currently working on the ehci emulation for fully supporting USB 2.0 
isochronous devices.

Waiting for your comments,
Arnon
diff --git a/qemu-head/usb-linux.c b/qemu/usb-linux.c
index 3a23301..70e2e69 100755
--- a/qemu-head/usb-linux.c
+++ b/qemu/usb-linux.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* We redefine it to avoid version problems */
 struct usb_ctrltransfer {
@@ -48,15 +49,171 @@ static int usb_host_find_device(int *pbus_num, int *paddr,
 const char *devname);
 
 //#define DEBUG
+//#define DEBUG_ISOCH
+//#define USE_ASYNCIO
 
 #define USBDEVFS_PATH "/proc/bus/usb"
 #define PRODUCT_NAME_SZ 32
+#define SIG_ISOCOMPLETE (SIGRTMIN+7)
+#define MAX_ENDPOINTS 16
 
+struct sigaction sigact;
+
+// endpoint association data
+struct endp_data {
+uint8_t type;
+};
+
+// FIXME: move USBPacket to PendingURB
 typedef struct USBHostDevice {
 USBDevice dev;
 int fd;
+USBPacket *packet;
+struct endp_data endp_table[MAX_ENDPOINTS];
+int configuration;
+uint8_t descr[1024];
+int descr_len;
+int urbs_ready;
 } USBHostDevice;
 
+typedef struct PendingURB {
+struct usbdevfs_urb *urb;
+USBHostDevice *dev;
+QEMUBH *bh;
+int status;
+struct PendingURB *next;
+} PendingURB;
+
+PendingURB *pending_urbs = NULL;
+
+int add_pending_urb(struct usbdevfs_urb *urb)
+{
+PendingURB *purb = qemu_mallocz(sizeof(PendingURB));
+if (purb) {
+purb->urb = urb;
+purb->dev = NULL;
+purb->bh = NULL;
+purb->status = 0;
+purb->next = pending_urbs;
+pending_urbs = purb;
+return 1;
+}
+return 0;
+}
+
+int del_pending_urb(struct usbdevfs_urb *urb)
+{
+PendingURB *purb = pending_urbs;
+PendingURB *prev = NULL;
+
+while (purb && purb->urb != urb) {
+prev = purb;
+purb = purb->next;
+}
+
+if (purb && purb->urb == urb) {
+if (prev) {
+prev->next = purb->next;
+} else {
+pending_urbs = purb->next;
+}
+qemu_free(purb);
+return 1;
+}
+return 0;
+}
+
+PendingURB *get_pending_urb(struct usbdevfs_urb *urb)
+{
+PendingURB *purb = pending_urbs;
+
+while (purb && purb->urb != urb) {
+purb = purb->next;
+}
+
+if (purb && purb->urb == urb) {
+return purb;
+}
+return NULL;
+}
+
+static int usb_host_update_interfaces(USBHostDevice *dev, int configuration)
+{
+int dev_descr_len, config_descr_len;
+int interface, nb_interfaces, nb_configurations;
+int ret, i;
+
+if (configuration == 0) // address state - ignore
+return 1;
+
+i = 0;
+dev_descr_len = dev->descr[0];
+if (dev_descr_len > dev->descr_len)
+goto fail;
+nb_configurations = dev->descr[17];
+
+i += dev_descr_len;
+while (i < dev->descr_len) {
+#ifdef DEBUG
+printf("i is %d, descr_len is %d, dl %d, dt %d\n", i, dev->descr_len,
+   dev->descr[i], dev->descr[i+1]);
+#endif
+if (dev->descr[i+1] != USB_DT_CONFIG) {
+i += dev->descr[i];
+continue;
+}
+config_descr_len = dev->descr[i];
+
+if (configuration == dev->descr[i + 5])
+break;
+
+i += config_descr_len;
+}
+
+if (i >= dev->descr_len) {
+printf("usb_host: error - device has no matching configuration\n");
+goto fail;
+}
+nb_interfaces = dev->descr[i + 4];
+
+#ifdef USBDEVFS_DISCONNECT
+/* earlier Linux 2.4 do not support that */
+{
+struct usbdevfs_ioctl ctrl;
+for (interface = 0; interface < nb_interfaces; interface++) {
+ctrl.ioctl_code = USBDEVFS_DISCONNECT;
+ctrl.ifno = interface;
+ret = ioctl(dev->fd, USBDEVFS_IOCTL, &ctrl);
+if (ret < 0 && errno != ENODATA) {
+perror("USBDEVFS_DISCONNECT");
+goto fail;
+}
+}
+}
+#endif
+
+/* XXX: only grab if all interfaces are free */
+for (int

Re: [Qemu-devel] [PATCH] vvfat mbr fixes

2007-09-24 Thread Johannes Schindelin
Hi,

On Mon, 24 Sep 2007, Ivan Kalvachev wrote:

> 2007/9/24, Johannes Schindelin <[EMAIL PROTECTED]>:
>
> > On Mon, 24 Sep 2007, Ivan Kalvachev wrote:
> >
> > > I had a discussion with Johannes Schindelin over my patch, that I 
> > > thought is on the maillist, but apparently it wasn't. I'm 
> > > subscribed, so please don't send me mails directly, gmail web 
> > > interface could be quite misleading.
> > >
> > > So here is the third revision of my patch. Changes include: using 
> > > more structures instead of fixed byte locations. chs and nt_id. more 
> > > detailed comments, function name shortened and if(lba) moved to ?: 
> > > construct.
> >
> > Almost all my comments went unheeded.
> 
> I believe that I've answered and addressed all your comments.

Ooops.  I think I mixed up your patch with the other patch for vvfat that 
floated around recently.  (Probably because the patch was not inlined...)

FWIW if we're talking about qemu_vvfat_mbr_v3.patch, I have no more 
gripes.

Thanks,
Dscho




[Qemu-devel] view qemu output/console

2007-09-24 Thread Clemens Kolbitsch
hi!
i'm having a problem that could have a very easy answer:

my i386 linx system crashes due to a module error and i have to find out where 
it crashes exactly i have the module source code.

when the kernel crashes, it displayes the message, however as it is way much 
more information that can be displayed in the qemu window, i only see the 
last 20-something lines. as the crash is fatal, no entries are made to the 
log-files and i have not succeeded redirecting output to my console (using 
the -nographic option) as my linux does not boot correctly then.

i have also tried attaching a debugger, however i neither have a unzipped 
image of my kernel nor are the breakpoints hit correctly as the crash happens 
inside a module that is loaded on system-startup (i.e. is not part of the 
kernel).

can someone give me a hint on how i am able to read the whole output of 
the "kernel-oops"?

thanks!!




[Qemu-devel] [PATCH] Optimise instructions accessing CP0

2007-09-24 Thread Aurelien Jarno
Hi all,

The patch below optimise instructions accessing CP0 by doing access 
rights check at translation time instead of execution time, as it is
already done for other CPx.

This is done by adding a new bit to hflags. Unfortunately that means
reorganising them because there was no space anymore for a new bit.

Bye,
Aurelien

Index: target-mips/cpu.h
===
RCS file: /sources/qemu/qemu/target-mips/cpu.h,v
retrieving revision 1.44
diff -u -d -p -r1.44 cpu.h
--- target-mips/cpu.h   24 Sep 2007 12:48:00 -  1.44
+++ target-mips/cpu.h   24 Sep 2007 14:02:55 -
@@ -414,24 +414,25 @@ struct CPUMIPSState {
 int user_mode_only; /* user mode only simulation */
 uint32_t hflags;/* CPU State */
 /* TMASK defines different execution modes */
-#define MIPS_HFLAG_TMASK  0x007F
+#define MIPS_HFLAG_TMASK  0x00FF
 #define MIPS_HFLAG_MODE   0x0007 /* execution modes*/
 #define MIPS_HFLAG_UM 0x0001 /* user mode  */
 #define MIPS_HFLAG_DM 0x0002 /* Debug mode */
 #define MIPS_HFLAG_SM 0x0004 /* Supervisor mode*/
 #define MIPS_HFLAG_64 0x0008 /* 64-bit instructions enabled*/
-#define MIPS_HFLAG_FPU0x0010 /* FPU enabled*/
-#define MIPS_HFLAG_F640x0020 /* 64-bit FPU enabled */
-#define MIPS_HFLAG_RE 0x0040 /* Reversed endianness*/
+#define MIPS_HFLAG_CP00x0010 /* CP0 enabled*/
+#define MIPS_HFLAG_FPU0x0020 /* FPU enabled*/
+#define MIPS_HFLAG_F640x0040 /* 64-bit FPU enabled */
+#define MIPS_HFLAG_RE 0x0080 /* Reversed endianness*/
 /* If translation is interrupted between the branch instruction and
  * the delay slot, record what type of branch it is so that we can
  * resume translation properly.  It might be possible to reduce
  * this from three bits to two.  */
-#define MIPS_HFLAG_BMASK  0x0380
-#define MIPS_HFLAG_B  0x0080 /* Unconditional branch   */
-#define MIPS_HFLAG_BC 0x0100 /* Conditional branch */
-#define MIPS_HFLAG_BL 0x0180 /* Likely branch  */
-#define MIPS_HFLAG_BR 0x0200 /* branch to register (can't link TB) */
+#define MIPS_HFLAG_BMASK  0x0700
+#define MIPS_HFLAG_B  0x0100 /* Unconditional branch   */
+#define MIPS_HFLAG_BC 0x0200 /* Conditional branch */
+#define MIPS_HFLAG_BL 0x0300 /* Likely branch  */
+#define MIPS_HFLAG_BR 0x0400 /* branch to register (can't link TB) */
 target_ulong btarget;/* Jump / branch target   */
 int bcond;   /* Branch condition (if needed)   */
 
Index: target-mips/helper.c
===
RCS file: /sources/qemu/qemu/target-mips/helper.c,v
retrieving revision 1.49
diff -u -d -p -r1.49 helper.c
--- target-mips/helper.c24 Sep 2007 12:48:00 -  1.49
+++ target-mips/helper.c24 Sep 2007 14:02:55 -
@@ -371,6 +371,7 @@ void do_interrupt (CPUState *env)
 env->hflags |= MIPS_HFLAG_DM;
 env->hflags |= MIPS_HFLAG_64;
 env->hflags &= ~MIPS_HFLAG_UM;
+env->hflags |= MIPS_HFLAG_CP0;
 /* EJTAG probe trap enable is not implemented... */
 if (!(env->CP0_Status & (1 << CP0St_EXL)))
 env->CP0_Cause &= ~(1 << CP0Ca_BD);
@@ -397,6 +398,7 @@ void do_interrupt (CPUState *env)
 env->CP0_Status |= (1 << CP0St_ERL) | (1 << CP0St_BEV);
 env->hflags |= MIPS_HFLAG_64;
 env->hflags &= ~MIPS_HFLAG_UM;
+env->hflags |= MIPS_HFLAG_CP0;
 if (!(env->CP0_Status & (1 << CP0St_EXL)))
 env->CP0_Cause &= ~(1 << CP0Ca_BD);
 env->PC[env->current_tc] = (int32_t)0xBFC0;
@@ -499,6 +501,7 @@ void do_interrupt (CPUState *env)
 env->CP0_Status |= (1 << CP0St_EXL);
 env->hflags |= MIPS_HFLAG_64;
 env->hflags &= ~MIPS_HFLAG_UM;
+env->hflags |= MIPS_HFLAG_CP0;
 }
 env->hflags &= ~MIPS_HFLAG_BMASK;
 if (env->CP0_Status & (1 << CP0St_BEV)) {
Index: target-mips/op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.72
diff -u -d -p -r1.72 op.c
--- target-mips/op.c24 Sep 2007 12:48:00 -  1.72
+++ target-mips/op.c24 Sep 2007 14:02:56 -
@@ -1852,6 +1852,10 @@ void op_mtc0_status (void)
 !(val & (1 << CP0St_UX)))
 env->hflags &= ~MIPS_HFLAG_64;
 #endif
+if ((val & (1 << CP0St_CU0)) || !(env->hflags & MIPS_HFLAG_UM))
+env->hflags |= MIPS_HFLAG_CP0;
+else
+env->hflags &= ~MIPS_HFLAG_CP0;
 if (val & (1 << CP0St_CU1))
 env->hflags |= MIPS_HFLAG_FPU;
 else
@@ -2316

Re: [Qemu-devel] [PATCH] vvfat mbr fixes

2007-09-24 Thread Ivan Kalvachev
2007/9/24, Johannes Schindelin <[EMAIL PROTECTED]>:
> Hi,
>
> On Mon, 24 Sep 2007, Ivan Kalvachev wrote:
>
> > I had a discussion with Johannes Schindelin over my patch, that I
> > thought is on the maillist, but apparently it wasn't. I'm subscribed, so
> > please don't send me mails directly, gmail web interface could be quite
> > misleading.
> >
> > So here is the third revision of my patch. Changes include: using more
> > structures instead of fixed byte locations. chs and nt_id. more detailed
> > comments, function name shortened and if(lba) moved to ?: construct.
>
> Almost all my comments went unheeded.

I believe that I've answered and addressed all your comments.
If you feel sorry that they haven't been documented on the maillist
you could have forwarded them by yourself, as I do now. I just hope I
haven't missed some.

If you have more questions just ask them.


-- Forwarded message --
From: Ivan Kalvachev <[EMAIL PROTECTED]>
Date: 23.09.2007 03:27
Subject: Re: [Qemu-devel] [PATCH] vvfat mbr fixes
To: Johannes Schindelin <[EMAIL PROTECTED]>


2007/9/23, Johannes Schindelin <[EMAIL PROTECTED]>:
> Hi,
>
> On Sun, 23 Sep 2007, Ivan Kalvachev wrote:
>
> > I've been having problems using vvfat virtual block device. Even linux
> > fdisk was able to find problems with it. The reason turned out to be
> > simple, MBR have bogus parameters.
>
> Thanks for doing this; I did not find any time for that.
>
> Overall, I like what you did, but here are some comments (if you would
> have inlined the patch, I would have commented with references):
I'm happy I didn't inlined it:) And I'm sure gmail would've mangled the patch.
>
> - I like the convert_sector2CHS() function, although I would have named it
>   sector2CHS() for brevity (although the pretty magic -- or unintuitive
>   -- detection if lba is needed would have to be done differently, which
>   I maintain would be better),

Making the name shorter is not problem.
However I don't understand your comment about LBA. How do you want it
done and where.
CHS is not used anywhere else, so MBR is the logical place to handle
it. LBA just means that CHS should be ignored and only
partition_start/length_sectors_long should be used. It shouldn't
affect any part of the other code that works with sectors and
clusters.

> - you write the NT-ID byte-per-byte, whereas I would have used strcpy()
>   for clarity,

NT-ID is not supposed to be string and strcpy() implies null terminated string.
NT-ID could be any random value, I just didn't wanted it that random.
Having it memcpy-ed would make some generic calculation harder (e.g.
hash of the fat:dirname or etc).
Having it as uint32_t would bring endian issues, but I think I'd go with that.

> - I'd have introduced a member nt_id instead of hardcoding an offset into
>   the "ignored" part, and

OK, I'll change the structure to have ntid. How do you like to name
the 4 bytes after the ntid and before the partition table -
ignored2[4] ?

> - fat_type == 12 and lba does not make sense, or does it?

Your point is?
Theoretically it could work even on floppy, as long as the guest OS
ignores the CHS.
I think that the FAT_XX_LBA new id's are done to prevent older version
of DOS from trying to access them using the bogus CHS, and that new
versions that support LBA use only LBA even on normal CHS, as LBA it
is always valid.


-- Forwarded message --
From: Johannes Schindelin <[EMAIL PROTECTED]>
Date: 23.09.2007 04:25
Subject: Re: [Qemu-devel] [PATCH] vvfat mbr fixes
To: Ivan Kalvachev <[EMAIL PROTECTED]>


Hi,

On Sun, 23 Sep 2007, Ivan Kalvachev wrote:

> 2007/9/23, Johannes Schindelin <[EMAIL PROTECTED]>:
> >
> > On Sun, 23 Sep 2007, Ivan Kalvachev wrote:
> >
> > > I've been having problems using vvfat virtual block device. Even
> > > linux fdisk was able to find problems with it. The reason turned out
> > > to be simple, MBR have bogus parameters.
> >
> > Thanks for doing this; I did not find any time for that.
> >
> > Overall, I like what you did, but here are some comments (if you would
> > have inlined the patch, I would have commented with references):
>
> I'm happy I didn't inlined it:) And I'm sure gmail would've mangled the
> patch.

Hehe... and you're right, GMail's webmailer mangles patches badly.

> > - I like the convert_sector2CHS() function, although I would have named it
> >   sector2CHS() for brevity (although the pretty magic -- or
> >   unintuitive -- detection if lba is needed would have to be done
> >   differently, which I maintain would be better),
>
> Making the name shorter is not problem.
> However I don't understand your comment about LBA. How do you want it
> done and where.

Like this:

sector2CHS(BlockDriverState* bs, int spos, int *lba)

returning the CHS value.  I like that better, since what you are really
interested in, when calling sector2CHS, are the CHS, and that should be
the return value.

But I see that you did not make a struct of the CHS, so that seems less

Re: [Qemu-devel] Another MIPS quiet NaN fix

2007-09-24 Thread Andreas Schwab
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> Glibc's test-float failed on my qemu testing.  I tracked it down to
> these routines: if you count the bits carefully, you'll see that
> 0x7FC0 sets the quiet NaN bit (on most hardware - signalling NaN
> in the MIPS case); so does a.high >> 41, which copies it from the
> original NaN.  I think this routine should not force a quiet or
> signalling NaN, but just preserve the input NaN's signalling-ness.

You may need to make sure that at least one mantissa bit is set.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




[Qemu-devel] Re: MIPS FP rounding

2007-09-24 Thread Daniel Jacobowitz
On Thu, Sep 20, 2007 at 06:28:25PM +0100, Thiemo Seufer wrote:
> It fixed an internal testcase, I'll have to check what was going
> on there, probably tomorrow.

I don't suppose you've had a chance to look at this?

-- 
Daniel Jacobowitz
CodeSourcery




[Qemu-devel] Another MIPS quiet NaN fix

2007-09-24 Thread Daniel Jacobowitz
Glibc's test-float failed on my qemu testing.  I tracked it down to
these routines: if you count the bits carefully, you'll see that
0x7FC0 sets the quiet NaN bit (on most hardware - signalling NaN
in the MIPS case); so does a.high >> 41, which copies it from the
original NaN.  I think this routine should not force a quiet or
signalling NaN, but just preserve the input NaN's signalling-ness.

With the patch below, everything passes.  cvt.d.s still produces an
ugly pattern different from the one real hardware produces when
converting a single-precision NaN to double; but now it's a quiet
NaN if the input was a quiet NaN so exp10(NaN) no longer raises
Invalid.

-- 
Daniel Jacobowitz
CodeSourcery

--- fpu/softfloat-specialize.h  (revision 182529)
+++ fpu/softfloat-specialize.h  (local)
@@ -120,9 +120,7 @@ static commonNaNT float32ToCommonNaN( fl
 
 static float32 commonNaNToFloat32( commonNaNT a )
 {
-
-return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
-
+return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( a.high>>41 );
 }
 
 /*
@@ -233,7 +231,7 @@ static float64 commonNaNToFloat64( commo
 
 return
   ( ( (bits64) a.sign )<<63 )
-| LIT64( 0x7FF8 )
+| LIT64( 0x7FF0 )
 | ( a.high>>12 );
 
 }




[Qemu-devel] [PATCH, MIPS R2] Timer start/stop implementation

2007-09-24 Thread Aurelien Jarno
Hi all,

The patch below allows the timer to be stopped using the DC bit in the 
CP0 Cause register. This feature is required for MIPS R2 implementations.

It also removes a few places where the interrupt corresponding to the 
timer is hardcoded, and leaves it hardcoded at only one place 
(initialisation).

Bye,
Aurelien

Index: hw/mips_timer.c
===
RCS file: /sources/qemu/qemu/hw/mips_timer.c,v
retrieving revision 1.7
diff -u -d -p -r1.7 mips_timer.c
--- hw/mips_timer.c 6 Sep 2007 00:18:14 -   1.7
+++ hw/mips_timer.c 24 Sep 2007 13:22:50 -
@@ -17,9 +17,12 @@ uint32_t cpu_mips_get_random (CPUState *
 /* MIPS R4K timer */
 uint32_t cpu_mips_get_count (CPUState *env)
 {
-return env->CP0_Count +
-(uint32_t)muldiv64(qemu_get_clock(vm_clock),
-   100 * 1000 * 1000, ticks_per_sec);
+if (env->CP0_Cause & (1 << CP0Ca_DC))
+return env->CP0_Count;
+else
+return env->CP0_Count +
+(uint32_t)muldiv64(qemu_get_clock(vm_clock),
+   100 * 1000 * 1000, ticks_per_sec);
 }
 
 void cpu_mips_store_count (CPUState *env, uint32_t count)
@@ -63,7 +66,19 @@ void cpu_mips_store_compare (CPUState *e
 cpu_mips_update_count(env, cpu_mips_get_count(env));
 if ((env->CP0_Config0 & (0x7 << CP0C0_AR)) == (1 << CP0C0_AR))
 env->CP0_Cause &= ~(1 << CP0Ca_TI);
-qemu_irq_lower(env->irq[7]);
+qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0In_IPTI) & 0x7]);
+}
+
+void cpu_mips_start_count(CPUState *env)
+{
+cpu_mips_store_count(env, env->CP0_Count);
+}
+
+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);
 }
 
 static void mips_timer_cb (void *opaque)
@@ -76,10 +91,14 @@ static void mips_timer_cb (void *opaque)
 fprintf(logfile, "%s\n", __func__);
 }
 #endif
+
+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))
 env->CP0_Cause |= 1 << CP0Ca_TI;
-qemu_irq_raise(env->irq[7]);
+qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0In_IPTI) & 0x7]);
 }
 
 void cpu_mips_clock_init (CPUState *env)
Index: target-mips/exec.h
===
RCS file: /sources/qemu/qemu/target-mips/exec.h,v
retrieving revision 1.32
diff -u -d -p -r1.32 exec.h
--- target-mips/exec.h  16 Sep 2007 21:08:03 -  1.32
+++ target-mips/exec.h  24 Sep 2007 13:22:50 -
@@ -153,6 +153,8 @@ uint32_t cpu_mips_get_random (CPUState *
 uint32_t cpu_mips_get_count (CPUState *env);
 void cpu_mips_store_count (CPUState *env, uint32_t value);
 void cpu_mips_store_compare (CPUState *env, uint32_t value);
+void cpu_mips_start_count(CPUState *env);
+void cpu_mips_stop_count(CPUState *env);
 void cpu_mips_update_irq (CPUState *env);
 void cpu_mips_clock_init (CPUState *env);
 void cpu_mips_tlb_flush (CPUState *env, int flush_global);
Index: target-mips/op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.72
diff -u -d -p -r1.72 op.c
--- target-mips/op.c24 Sep 2007 12:48:00 -  1.72
+++ target-mips/op.c24 Sep 2007 13:22:51 -
@@ -1882,9 +1882,8 @@ void op_mttc0_status(void)
 
 void op_mtc0_intctl (void)
 {
-/* vectored interrupts not implemented, timer on int 7,
-   no performance counters. */
-env->CP0_IntCtl |= T0 & 0x02e0;
+/* vectored interrupts not implemented, no performance counters. */
+env->CP0_IntCtl = (env->CP0_IntCtl & ~0x02e0) | (T0 & 0x02e0);
 RETURN();
 }
 
@@ -1904,12 +1903,20 @@ void op_mtc0_srsmap (void)
 void op_mtc0_cause (void)
 {
 uint32_t mask = 0x00C00300;
+uint32_t old = env->CP0_Cause;
 
 if (env->insn_flags & ISA_MIPS32R2)
 mask |= 1 << CP0Ca_DC;
 
 env->CP0_Cause = (env->CP0_Cause & ~mask) | (T0 & mask);
 
+if ((old ^ env->CP0_Cause) & (1 << CP0Ca_DC)) {
+if (env->CP0_Cause & (1 << CP0Ca_DC))
+CALL_FROM_TB1(cpu_mips_stop_count, env);
+else
+CALL_FROM_TB1(cpu_mips_start_count, env);  
+}
+
 /* Handle the software interrupt as an hardware one, as they
are very similar */
 if (T0 & CP0Ca_IP_mask) {
Index: target-mips/op_helper.c
===
RCS file: /sources/qemu/qemu/target-mips/op_helper.c,v
retrieving revision 1.59
diff -u -d -p -r1.59 op_helper.c
--- target-mips/op_helper.c 17 Sep 2007 08:09:53 -  1.59
+++ target-mips/op_helper.c 24 Sep 2007 13:22:52 -
@@ -265,6 +265,16 @@ void cpu_mips_store_compare(CPUState *en
 cpu_abort(env, "mtc0 compare\n");
 }
 
+void cpu_mips_s

Re: [Qemu-devel] [PATCH][MIPS] Per-CPU instruction decoding implementation

2007-09-24 Thread Thiemo Seufer
Aurelien Jarno wrote:
> Hi all,
> 
> The patch below implements per-cpu decoding on the MIPS target. The 
> supported instruction set is defined by a set of flags. It assumes that
> MIPS2 instructions are always supported. It also removes the check for 
> CP0C0_AT when setting MIPS_HFLAG_64 as it is now obsolete.

I expanded parts of it to (at least theoretically) cover the whole
ISA space, renamed INSN -> ISA / ASE, since that's what we actually
check for, and fixed a few misassumptions (e.g. Xcontext is MIPS3).


Thiemo




[Qemu-devel] qemu/target-mips cpu.h helper.c mips-defs.h op....

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 12:48:00

Modified files:
target-mips: cpu.h helper.c mips-defs.h op.c translate.c 
 translate_init.c 

Log message:
Per-CPU instruction decoding implementation, by Aurelien Jarno.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.43&r2=1.44
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.48&r2=1.49
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.15&r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.71&r2=1.72
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.100&r2=1.101
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.21&r2=1.22




Re: [Qemu-devel] Updated RFC: linux user problems]]

2007-09-24 Thread Thiemo Seufer
J. Mayer wrote:
[snip]
> > > > May someone take a look at my patch and say if it seems reasonable to
> > > > include this in the repository ?
> > > 
> > > Looks reasonable, but introduces new compiler warnings
> > > (on a ppc32/Linux host):
> 
> The reported warnings have been fixed.
> There are still a lot of warnings related to 32/64 bits invalid casts on
> 64 bits hosts (see above) which will need to be fixed once.
> 
> I also changed some parameters of do_ipc from long to int (instead of
> target_long), following the do_ipc man page specification, and reported
> this change in child functions. There may be more to do...
> 
> Please comment...

Fine with me, FWIW.


Thiemo




Re: [Qemu-devel] qemu cpu-all.h cpu-exec.c exec.c target-i386/cp...

2007-09-24 Thread Alexander Graf
Hi Fabrice,

thank you for commenting on this.

Fabrice Bellard wrote:
> Hi,
>
> The code would be simpler if some intercept tests were done at runtime
> in the corresponding helpers (for crN, drN and MSR registers, I/Os).
> This is especially true when the existing helpers can return an
> exception at runtime. 

So basically you mean it would be simpler if all the intercepts that can
occur in helpers are checked for in helpers? Right now I'm quite glad to
have all intercept information in one file (translate.c) and can see if
there is an intercept happening just by taking a look at the opcode
translation code. I don't know about the program flow simplicity though,
so maybe I could change it back to implement all the intercepts that can
be done in helpers in the helpers.

> Complicating the translator to handle SVM is definitely not the way I
> would have handled it.
>

Complicating in which way? Adding extra flags or adding extra
instructions when svm is used? We have to add instructions in cases
where the opcode is not handled by a helper or the order of checks is
different (e.g. an instruction may only run in cpl 3, but the intercept
always occurs).

> For I/Os for example, there was already the necessary support to do
> runtime tests (see gen_check_io()). Adding one bit to return the
> prefix information is all what it needed. The current code is actually
> slower because new ops were added for each I/O instruction.

This looks good. I will take a look at that one.

Thanks,

Alex





Re: [Qemu-devel] [PATCH] vvfat mbr fixes

2007-09-24 Thread Johannes Schindelin
Hi,

On Mon, 24 Sep 2007, Ivan Kalvachev wrote:

> I had a discussion with Johannes Schindelin over my patch, that I 
> thought is on the maillist, but apparently it wasn't. I'm subscribed, so 
> please don't send me mails directly, gmail web interface could be quite 
> misleading.
> 
> So here is the third revision of my patch. Changes include: using more 
> structures instead of fixed byte locations. chs and nt_id. more detailed 
> comments, function name shortened and if(lba) moved to ?: construct.

Almost all my comments went unheeded.

Oh well,
Dscho





[Qemu-devel] QEMU keyboard issue with Gujin-2.2

2007-09-24 Thread Alexander E. Patrakov

Hello,

if one attempts to use the Gujin bootloader inside qemu (even today's 
snapshot), one gets a message about unknown key being pressed.


The easiest way to reproduce the issue is to download install-2.2.tar.gz 
from http://sourceforge.net/project/showfiles.php?group_id=15465, unpack 
the tarball, and run "qemu -fda boot.144". The bottom of the screen will 
flash with the message about unknown command. This message does not show 
up in Bochs and on real hardware.


I also recompiled Gujin from source (gujin-2.2.tar.gz) and added code to 
print information about each call to the 0x16 BIOS interrupt to the 
parallel port. According to this log, Gujin does the following:


# prints:
Debug active!
sizeof MOUSE: 512, sizeof UI: 384, Initial VESA name check: Video card 
changed, reset VGA parameter.


# Get shift flags
AH=0x02 => result: AL=0x00 (i.e., no shift flags)

# keyb.com keyboard capabilities check
AH=0x92 => AH=0x80 (i.e., enhanced keyboard functions are supported)

# keyb.com keyboard capabilities check
AH=0xa2 => AH=0xa2 (i.e., 122-key keyboard functions are not supported)

# prints:
sizeof struct UTIL_str 640, sizeof struct memalloc_str 408.
max_IDE_found 10, max_freelist 64, max_disk 15, max_partition 64
sizeof struct diskparam_str 256, sizeof struct partition_str 64, sizeof 
struct freelist_str 16, sizeof struct IDE_found_str 8.


Reset all BIOS disks for BIOS to acknowledge changes:returns 0x0, status 
0x0

sizeof struct desc_str: 64, sizeof struct BOOTWAY_str: 16
{FAT12 on disk 0 part 5 with type 0x4!} {strange: PhysicaldriveNb = 0x0 
instead of 0x80}  {FAT12 on disk 2 part 5 with type 0x4!}


# check for enhanced keystroke
AH=0x11 => AH=0x11, AL set to 0 by the setnz instruction (i.e., no key)

# Then the check is repeated many times with the same "no key" result 
(because I press no keys). So far so good.

# .

# Then, for some strange reason, the same call returns that a key is 
pressed:


# check for enhanced keystroke
AH=0x11 => AH=0x43, AL set to 1 by the setnz instruction that 
immediately follows int 0x16 in the Gujin source


# get enhanced keycode
AH=0x10 => AH=0x43, AL=0x00 (here is a problem - I pressed nothing!)

# goes to graphical mode
# prints:
best_max_width: found mode index 3 (maxwidth 640) out of UI.nbmode = 16
[get_refresh_freq: timeout after 4]

# Then it begins to loop the following two calls:

# check for enhanced keystroke
AH=0x11 => AH=0x43, AL set to 1 by the setnz instruction that 
immediately follows int 0x16 in the Gujin source


# get enhanced keycode
AH=0x10 => AH=0x43, AL=0x00 (here is a problem - I pressed nothing!)

I.e., this looks like a "garbage in, garbage out" problem, not a Gujin 
bug - BIOS reports non-existing keypress to Gujin in qemu. Could you 
please fix qemu, or at least tell me how to debug further?


--
Alexander E. Patrakov




Re: [Qemu-devel] [PATCH] vvfat mbr fixes

2007-09-24 Thread Ivan Kalvachev
I had a discussion with Johannes Schindelin over my patch, that I
thought is on the maillist, but apparently it wasn't. I'm subscribed,
so please don't send me mails directly, gmail web interface could be
quite misleading.

So here is the third revision of my patch. Changes include:
using more structures instead of fixed byte locations. chs and nt_id.
more detailed comments, function name shortened and if(lba) moved to
?: construct.


qemu_vvfat_mbr_v3.patch
Description: Binary data


[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:27:49

Modified files:
linux-user : syscall.c 

Log message:
linux-user faccessat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.131&r2=1.132




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:26:51

Modified files:
linux-user : syscall.c 

Log message:
linux-user fchmodat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.130&r2=1.131




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:26:10

Modified files:
linux-user : syscall.c 

Log message:
linux-user readlinkat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.129&r2=1.130




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:25:41

Modified files:
linux-user : syscall.c 

Log message:
linux-user symlinkat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.128&r2=1.129




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:25:06

Modified files:
linux-user : syscall.c 

Log message:
linux-user linkat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.127&r2=1.128




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:24:37

Modified files:
linux-user : syscall.c 

Log message:
linux-user renameat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.126&r2=1.127




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:24:11

Modified files:
linux-user : syscall.c 

Log message:
linux-user unlinkat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.125&r2=1.126




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:23:35

Modified files:
linux-user : syscall.c 

Log message:
linux-user fchownat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.124&r2=1.125




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:23:05

Modified files:
linux-user : syscall.c 

Log message:
linux-user mknodat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.123&r2=1.124




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:22:32

Modified files:
linux-user : syscall.c 

Log message:
linux-user mkdirat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.122&r2=1.123




[Qemu-devel] qemu/linux-user syscall.c

2007-09-24 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/09/24 09:21:55

Modified files:
linux-user : syscall.c 

Log message:
linux-user openat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.121&r2=1.122




[Qemu-devel] Is it easy to support booting off real harddrive?

2007-09-24 Thread naruto canada
hi

Is it easy to support booting off real harddrive?
Thanks