[Qemu-devel] [mips-linux-user] patch for pipe() result handling
pipe(2) on MIPS does some funny, non-standard stuff with it's return
data. This patch implments this unusual handling. Without this patch,
bash closes it's own stdin by mistake and therefore exits immediately
after presenting the prompt.
The LTP test results for the pipe() tests are improved with this patch
as well.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-05-29 22:42:04.0 -0400
+++ qemu/linux-user/syscall.c 2007-05-29 22:47:00.0 -0400
@@ -2916,8 +2916,13 @@
int host_pipe[2];
ret = get_errno(pipe(host_pipe));
if (!is_error(ret)) {
+#if defined(TARGET_MIPS)
+ ((CPUMIPSState*)cpu_env)->gpr[3] = host_pipe[1];
+ ret = host_pipe[0];
+#else
tput32(arg1, host_pipe[0]);
tput32(arg1 + 4, host_pipe[1]);
+#endif
}
}
break;
[Qemu-devel] [PATCH] message queue IPC structures
This is a refresh (vs 05/28 cvs) of a patch sent several weeks ago. This
patch implements the structure handling for the structures used by the
Message queue IPC interfaces msgctl(), msgrcv() and msgsnd().
This was tested using LTP on an ARM target.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-03-23 09:06:14.0 -0400
+++ qemu/linux-user/syscall.c 2007-03-23 09:06:16.0 -0400
@@ -1322,6 +1322,117 @@
return ret;
}
+struct target_msqid_ds
+{
+ struct target_ipc_perm msg_perm;
+ target_ulong msg_stime;
+ target_ulong __unused1;
+ target_ulong msg_rtime;
+ target_ulong __unused2;
+ target_ulong msg_ctime;
+ target_ulong __unused3;
+ target_ulong __msg_cbytes;
+ target_ulong msg_qnum;
+ target_ulong msg_qbytes;
+ target_ulong msg_lspid;
+ target_ulong msg_lrpid;
+ target_ulong __unused4;
+ target_ulong __unused5;
+};
+
+static inline void target_to_host_msqid_ds(struct msqid_ds *host_md,
+ target_ulong target_addr)
+{
+struct target_msqid_ds *target_md;
+
+lock_user_struct(target_md, target_addr, 1);
+target_to_host_ipc_perm(&(host_md->msg_perm),target_addr);
+host_md->msg_stime = tswapl(target_md->msg_stime);
+host_md->msg_rtime = tswapl(target_md->msg_rtime);
+host_md->msg_ctime = tswapl(target_md->msg_ctime);
+host_md->__msg_cbytes = tswapl(target_md->__msg_cbytes);
+host_md->msg_qnum = tswapl(target_md->msg_qnum);
+host_md->msg_qbytes = tswapl(target_md->msg_qbytes);
+host_md->msg_lspid = tswapl(target_md->msg_lspid);
+host_md->msg_lrpid = tswapl(target_md->msg_lrpid);
+unlock_user_struct(target_md, target_addr, 0);
+}
+
+static inline void host_to_target_msqid_ds(target_ulong target_addr,
+ struct msqid_ds *host_md)
+{
+struct target_msqid_ds *target_md;
+
+lock_user_struct(target_md, target_addr, 0);
+host_to_target_ipc_perm(target_addr,&(host_md->msg_perm));
+target_md->msg_stime = tswapl(host_md->msg_stime);
+target_md->msg_rtime = tswapl(host_md->msg_rtime);
+target_md->msg_ctime = tswapl(host_md->msg_ctime);
+target_md->__msg_cbytes = tswapl(host_md->__msg_cbytes);
+target_md->msg_qnum = tswapl(host_md->msg_qnum);
+target_md->msg_qbytes = tswapl(host_md->msg_qbytes);
+target_md->msg_lspid = tswapl(host_md->msg_lspid);
+target_md->msg_lrpid = tswapl(host_md->msg_lrpid);
+unlock_user_struct(target_md, target_addr, 1);
+}
+
+static inline long do_msgctl(long first, long second, long ptr)
+{
+struct msqid_ds dsarg;
+int cmd = second&0xff;
+long ret = 0;
+switch( cmd ) {
+case IPC_STAT:
+case IPC_SET:
+target_to_host_msqid_ds(&dsarg,ptr);
+ret = get_errno(msgctl(first, cmd, &dsarg));
+host_to_target_msqid_ds(ptr,&dsarg);
+default:
+ret = get_errno(msgctl(first, cmd, &dsarg));
+}
+return ret;
+}
+
+struct target_msgbuf {
+ target_ulong mtype;
+ char mtext[1];
+};
+
+static inline long do_msgsnd(long msqid, long msgp, long msgsz, long msgflg)
+{
+struct target_msgbuf *target_mb;
+struct msgbuf *host_mb;
+long ret = 0;
+
+lock_user_struct(target_mb,msgp,0);
+host_mb = malloc(msgsz+sizeof(long));
+host_mb->mtype = tswapl(target_mb->mtype);
+memcpy(host_mb->mtext,target_mb->mtext,msgsz);
+ret = get_errno(msgsnd(msqid, host_mb, msgsz, msgflg));
+free(host_mb);
+unlock_user_struct(target_mb, msgp, 0);
+
+return ret;
+}
+
+static inline long do_msgrcv(long msqid, long msgp, long msgsz, long msgtype, long msgflg)
+{
+struct target_msgbuf *target_mb;
+struct msgbuf *host_mb;
+long ret = 0;
+
+lock_user_struct(target_mb,msgp,0);
+host_mb = malloc(msgsz+sizeof(long));
+ret = get_errno(msgrcv(msqid, host_mb, msgsz, 1, msgflg));
+if( ret > 0 )
+ memcpy(target_mb->mtext,host_mb->mtext,ret);
+target_mb->mtype = tswapl(host_mb->mtype);
+free(host_mb);
+unlock_user_struct(target_mb, msgp, 0);
+
+return ret;
+}
+
/* ??? This only works with linear mappings. */
static long do_ipc(long call, long first, long second, long third,
long ptr, long fifth)
@@ -1358,27 +1469,27 @@
break;
case IPCOP_msgsnd:
- ret = get_errno(msgsnd(first, (struct msgbuf *) ptr, second, third));
+ ret = do_msgsnd(first, ptr, second, third);
break;
case IPCOP_msgctl:
- ret = get_errno(msgctl(first, second, (struct msqid_ds *) ptr));
+ ret = do_msgctl(first, second, ptr);
break;
case IPCOP_msgrcv:
- {
- struct ipc_kludge
-
[Qemu-devel] [PATCH] linux-user semaphore structure mapping
This is a refresh (vs 5/28 cvs) of a patch sent several weeks ago. This
patch implments the structure handling for the semaphore IPC related
structures used by semctl().
This was tested using LTP on an ARM target.
Were there any objections to this patch?
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: qemu/linux-user/i386/syscall.h
===
--- qemu.orig/linux-user/i386/syscall.h 2007-03-23 09:05:19.0 -0400
+++ qemu/linux-user/i386/syscall.h 2007-03-23 09:05:32.0 -0400
@@ -142,80 +142,4 @@
struct target_vm86plus_info_struct vm86plus;
};
-/* ipcs */
-
-#define TARGET_SEMOP 1
-#define TARGET_SEMGET 2
-#define TARGET_SEMCTL 3
-#define TARGET_MSGSND 11
-#define TARGET_MSGRCV 12
-#define TARGET_MSGGET 13
-#define TARGET_MSGCTL 14
-#define TARGET_SHMAT 21
-#define TARGET_SHMDT 22
-#define TARGET_SHMGET 23
-#define TARGET_SHMCTL 24
-
-struct target_msgbuf {
- int mtype;
- char mtext[1];
-};
-
-struct target_ipc_kludge {
- unsigned int msgp; /* Really (struct msgbuf *) */
- int msgtyp;
-};
-
-struct target_ipc_perm {
- int key;
- unsigned short uid;
- unsigned short gid;
- unsigned short cuid;
- unsigned short cgid;
- unsigned short mode;
- unsigned short seq;
-};
-
-struct target_msqid_ds {
- struct target_ipc_perm msg_perm;
- unsigned int msg_first; /* really struct target_msg* */
- unsigned int msg_last; /* really struct target_msg* */
- unsigned int msg_stime; /* really target_time_t */
- unsigned int msg_rtime; /* really target_time_t */
- unsigned int msg_ctime; /* really target_time_t */
- unsigned int wwait; /* really struct wait_queue* */
- unsigned int rwait; /* really struct wait_queue* */
- unsigned short msg_cbytes;
- unsigned short msg_qnum;
- unsigned short msg_qbytes;
- unsigned short msg_lspid;
- unsigned short msg_lrpid;
-};
-
-struct target_shmid_ds {
- struct target_ipc_perm shm_perm;
- int shm_segsz;
- unsigned int shm_atime; /* really target_time_t */
- unsigned int shm_dtime; /* really target_time_t */
- unsigned int shm_ctime; /* really target_time_t */
- unsigned short shm_cpid;
- unsigned short shm_lpid;
- short shm_nattch;
- unsigned short shm_npages;
- unsigned long *shm_pages;
- void *attaches; /* really struct shm_desc * */
-};
-
-#define TARGET_IPC_RMID 0
-#define TARGET_IPC_SET 1
-#define TARGET_IPC_STAT 2
-
-union target_semun {
-int val;
-unsigned int buf; /* really struct semid_ds * */
-unsigned int array; /* really unsigned short * */
-unsigned int __buf; /* really struct seminfo * */
-unsigned int __pad; /* really void* */
-};
-
#define UNAME_MACHINE "i686"
Index: qemu/linux-user/ppc/syscall.h
===
--- qemu.orig/linux-user/ppc/syscall.h 2007-03-23 09:05:19.0 -0400
+++ qemu/linux-user/ppc/syscall.h 2007-03-23 09:05:32.0 -0400
@@ -51,80 +51,4 @@
* flags masks
*/
-/* ipcs */
-
-#define TARGET_SEMOP 1
-#define TARGET_SEMGET 2
-#define TARGET_SEMCTL 3
-#define TARGET_MSGSND 11
-#define TARGET_MSGRCV 12
-#define TARGET_MSGGET 13
-#define TARGET_MSGCTL 14
-#define TARGET_SHMAT 21
-#define TARGET_SHMDT 22
-#define TARGET_SHMGET 23
-#define TARGET_SHMCTL 24
-
-struct target_msgbuf {
- int mtype;
- char mtext[1];
-};
-
-struct target_ipc_kludge {
- unsigned int msgp; /* Really (struct msgbuf *) */
- int msgtyp;
-};
-
-struct target_ipc_perm {
- int key;
- unsigned short uid;
- unsigned short gid;
- unsigned short cuid;
- unsigned short cgid;
- unsigned short mode;
- unsigned short seq;
-};
-
-struct target_msqid_ds {
- struct target_ipc_perm msg_perm;
- unsigned int msg_first; /* really struct target_msg* */
- unsigned int msg_last; /* really struct target_msg* */
- unsigned int msg_stime; /* really target_time_t */
- unsigned int msg_rtime; /* really target_time_t */
- unsigned int msg_ctime; /* really target_time_t */
- unsigned int wwait; /* really struct wait_queue* */
- unsigned int rwait; /* really struct wait_queue* */
- unsigned short msg_cbytes;
- unsigned short msg_qnum;
- unsigned short msg_qbytes;
- unsigned short msg_lspid;
- unsigned short msg_lrpid;
-};
-
-struct target_shmid_ds {
- struct target_ipc_perm shm_perm;
- int shm_segsz;
- unsigned int shm_atime; /* really target_time_t */
- unsigned int shm_dtime; /* really target_time_t */
- unsigned int shm_ctime; /* really target_time_t */
- unsigned short shm_cpid;
- unsigned short shm_lpid;
- short
[Qemu-devel] [mips-linux-user] patch for struct stat mapping
The code that maps struct stat is wrong for MIPS. It uses the wrong sized calls (16 vs 32) for swapping some of the structure members. A patch to fix this is attached. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149Index: qemu/linux-user/syscall.c === --- qemu.orig/linux-user/syscall.c 2007-05-29 22:17:15.0 -0400 +++ qemu/linux-user/syscall.c 2007-05-29 22:18:16.0 -0400 @@ -3698,7 +3698,11 @@ lock_user_struct(target_st, arg2, 0); if( ret=page_check_range(target_st,sizeof(*target_st),PAGE_WRITE) ) return -ret; +#if defined(TARGET_MIPS) +target_st->st_dev = tswapl(st.st_dev); +#else target_st->st_dev = tswap16(st.st_dev); +#endif target_st->st_ino = tswapl(st.st_ino); #if defined(TARGET_PPC) || defined(TARGET_MIPS) target_st->st_mode = tswapl(st.st_mode); /* XXX: check this */ @@ -3709,8 +3713,14 @@ target_st->st_uid = tswap16(st.st_uid); target_st->st_gid = tswap16(st.st_gid); #endif +#if defined(TARGET_MIPS) + /* If this is the same on PPC, then just merge w/ the above ifdef */ +target_st->st_nlink = tswapl(st.st_nlink); +target_st->st_rdev = tswapl(st.st_rdev); +#else target_st->st_nlink = tswap16(st.st_nlink); target_st->st_rdev = tswap16(st.st_rdev); +#endif target_st->st_size = tswapl(st.st_size); target_st->st_blksize = tswapl(st.st_blksize); target_st->st_blocks = tswapl(st.st_blocks);
[Qemu-devel] Re: New QEMU 0.9.0 packages available for Solaris 10/SPARC (May 22 CVS) and Solaris 10/x86_64 (May 24 CVS) & RTEMS yummy goodness
Jonathan Kalbfeld wrote: This includes mtools. And for your RTEMS needs, there is a Solaris/SPARC toolchain available on the same website, for generating RTEMS code for other architectures. http://www.thoughtwave.net/downloads.html What version of RTEMS are these for? Could you please update http://www.rtems.org/wiki/index.php/RTEMS_Prebuilt_Tools with your information? Thanks. --joel Thanks, Jonathan P.S., Completely off topic, I downloaded Joost and installed it on my PC. I have been watching Stella from Comedy Central and it is hilarious. -- -- Jonathan Kalbfeld +1 323 620 6682 ___ rtems-users mailing list [EMAIL PROTECTED] http://rtems.rtems.org/mailman/listinfo/rtems-users
Re: [Qemu-devel] Regression bug
On Tue, May 29, 2007 at 10:33:37PM +0300, Blue Swirl wrote: > On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >On Tue, May 29, 2007 at 09:44:39PM +0300, Blue Swirl wrote: > >> Hi, > >> > >> I found a bug in the subpage checking code. Could you try if the > >> attached patch fixes the problem? > > > >thats a negative. the exact same behavior as before. > > Thanks. > > The bug was actually that on PC, the very last addresses are mapped, > and the current code failed when the start_addr + size wrapped back to > 0. That didn't happen on amd64, where I first tried to reproduce the > bug. > > The attached patch fixes the problem for me, I'll commit it if there > are no objections. this patch works. thanks. :) Julia Longtin <[EMAIL PROTECTED]>
[Qemu-devel] New QEMU 0.9.0 packages available for Solaris 10/SPARC (May 22 CVS) and Solaris 10/x86_64 (May 24 CVS) & RTEMS yummy goodness
This includes mtools. And for your RTEMS needs, there is a Solaris/SPARC toolchain available on the same website, for generating RTEMS code for other architectures. http://www.thoughtwave.net/downloads.html Thanks, Jonathan P.S., Completely off topic, I downloaded Joost and installed it on my PC. I have been watching Stella from Comedy Central and it is hilarious. -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] Regression bug
On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, May 29, 2007 at 09:44:39PM +0300, Blue Swirl wrote:
> Hi,
>
> I found a bug in the subpage checking code. Could you try if the
> attached patch fixes the problem?
thats a negative. the exact same behavior as before.
Thanks.
The bug was actually that on PC, the very last addresses are mapped,
and the current code failed when the start_addr + size wrapped back to
0. That didn't happen on amd64, where I first tried to reproduce the
bug.
The attached patch fixes the problem for me, I'll commit it if there
are no objections.
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-05-29 19:31:15.0 +
+++ qemu/exec.c 2007-05-29 19:31:24.0 +
@@ -1922,7 +1922,7 @@
need_subpage = 1; \
} \
\
-if (end_addr - addr > TARGET_PAGE_SIZE) \
+if ((start_addr + orig_size) - addr >= TARGET_PAGE_SIZE)\
end_addr2 = TARGET_PAGE_SIZE - 1; \
else { \
end_addr2 = (start_addr + orig_size - 1) & ~TARGET_PAGE_MASK; \
@@ -1944,9 +1944,9 @@
unsigned long orig_size = size;
void *subpage;
-end_addr = start_addr + (target_phys_addr_t)size;
size = (size + TARGET_PAGE_SIZE - 1) & TARGET_PAGE_MASK;
-for(addr = start_addr; addr < end_addr; addr += TARGET_PAGE_SIZE) {
+end_addr = start_addr + (target_phys_addr_t)size;
+for(addr = start_addr; addr != end_addr; addr += TARGET_PAGE_SIZE) {
p = phys_page_find(addr >> TARGET_PAGE_BITS);
if (p && p->phys_offset != IO_MEM_UNASSIGNED) {
unsigned long orig_memory = p->phys_offset;
Re: [Qemu-devel] Regression bug
On Tue, May 29, 2007 at 09:44:39PM +0300, Blue Swirl wrote: > Hi, > > I found a bug in the subpage checking code. Could you try if the > attached patch fixes the problem? thats a negative. the exact same behavior as before. qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0 EAX= EBX= ECX= EDX=0600 ESI= EDI= EBP= ESP= EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = CS =f000 SS = DS = FS = GS = LDT= 8000 TR = 8000 GDT= IDT= CR0=6010 CR2= CR3= CR4= CCS= CCD= CCO=EFLAGS FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= ./start.sh: line 4: 14065 Aborted qemu -hda ide0.img ouch. Julia Longtin <[EMAIL PROTECTED]>
[Qemu-devel] qemu/target-mips cpu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/29 18:55:34 Modified files: target-mips: cpu.h Log message: Fix usermode check, thanks Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.37&r2=1.38
Re: [Qemu-devel] Regression bug
Hi,
I found a bug in the subpage checking code. Could you try if the
attached patch fixes the problem?
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-05-29 18:39:35.0 +
+++ qemu/exec.c 2007-05-29 18:39:54.0 +
@@ -1922,7 +1922,7 @@
need_subpage = 1; \
} \
\
-if (end_addr - addr > TARGET_PAGE_SIZE) \
+if (end_addr - addr >= TARGET_PAGE_SIZE)\
end_addr2 = TARGET_PAGE_SIZE - 1; \
else { \
end_addr2 = (start_addr + orig_size - 1) & ~TARGET_PAGE_MASK; \
Re: [Qemu-devel] Regression bug
On 5/29/07, Ben Taylor <[EMAIL PROTECTED]> wrote: Looks like the patch from http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.96&r2=1.97 needs to be reverted and reworked before being recommitted. Thank you for the reports. I still can't reproduce the bug, but it seems that on PC, the area between 0xa and 0x10 is registered multiple times and this could confuse the subpage code. Adding printf to cpu_register_physical memory reveals: cpu_register_physical_memory: start_addr 000a size 1000 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 1000 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 1000 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 1000 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 1000 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 2 phys_offset 70 cpu_register_physical_memory: start_addr 000a size 2 phys_offset a The subpage part in cpu_register_physical_memory could be disabled just for i386. A better fix would be to fix the PC/VGA/PIIX memory registrations and also make the subpage code handle this case.
[Qemu-devel] qemu/target-mips cpu.h fop_template.c op.c tran...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/29 16:52:57 Modified files: target-mips: cpu.h fop_template.c op.c translate.c Log message: Don't check the FPU state for each FPU instruction, use hflags to handle this per-tb. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.36&r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/fop_template.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.64&r2=1.65 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.89&r2=1.90
[Qemu-devel] qemu cpu-exec.c target-m68k/cpu.h target-m68k/h...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/05/29 14:57:59 Modified files: . : cpu-exec.c target-m68k: cpu.h helper.c op.c qregs.def translate.c Log message: ColdFire EMAC support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.105&r2=1.106 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/cpu.h?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/helper.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/qregs.def?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemu&r1=1.12&r2=1.13
Re: [Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Hi, On Tue, 29 May 2007, Clemens Kolbitsch wrote: > Johannes Schindelin wrote: > > Hi, > > > > On Tue, 29 May 2007, Clemens Kolbitsch wrote: > > > > > > > Clemens Kolbitsch wrote: > > > > > > > > > > my virtual device inside qemu (a pci device) is listening for > > > > socket-(tcp)-connections. > > > > > > > > however, accept() always fails (code works fine if not executed inside > > > > the qemu-process)... now i'm wondering if qemu interferes somehow... > > > > > > > > is that possible? > > > > > > > > frustrated *gg* > > > > > > > > > > > ok i found an answer to it. > > > > > > obviously, qemu has to handle interrupt-signals (e.g. from its > > > client-os). this interrupts accepting connections. > > > > > > very bad for me, but at least a logical reason :-/ > > > > > > > I guess that you use the Slirp device. This device is masqueraded to the > > outside, so unless you use something different, like VLAN or TAP, you can > > only make it work using a tunnel. > > > > > no... i think you misunderstand... > > I'm trying to accept a socket inside the qemu-emulation-process. not inside > the simulated operating system. Ah, sorry. I cannot think of anything which could trigger that, except what you suggested (interrupts are in the way), or maybe timing problems. Sorry, Dscho
Re: [Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Johannes Schindelin wrote: Hi, On Tue, 29 May 2007, Clemens Kolbitsch wrote: Clemens Kolbitsch wrote: my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg* ok i found an answer to it. obviously, qemu has to handle interrupt-signals (e.g. from its client-os). this interrupts accepting connections. very bad for me, but at least a logical reason :-/ I guess that you use the Slirp device. This device is masqueraded to the outside, so unless you use something different, like VLAN or TAP, you can only make it work using a tunnel. no... i think you misunderstand... I'm trying to accept a socket inside the qemu-emulation-process. not inside the simulated operating system.
Re: [Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Hi, On Tue, 29 May 2007, Clemens Kolbitsch wrote: > Clemens Kolbitsch wrote: > > > my virtual device inside qemu (a pci device) is listening for > > socket-(tcp)-connections. > > > > however, accept() always fails (code works fine if not executed inside > > the qemu-process)... now i'm wondering if qemu interferes somehow... > > > > is that possible? > > > > frustrated *gg* > > > ok i found an answer to it. > > obviously, qemu has to handle interrupt-signals (e.g. from its > client-os). this interrupts accepting connections. > > very bad for me, but at least a logical reason :-/ I guess that you use the Slirp device. This device is masqueraded to the outside, so unless you use something different, like VLAN or TAP, you can only make it work using a tunnel. Hth, Dscho
[Qemu-devel] Re: Accepting socket connections in qemu (not the client... the emulator)
Clemens Kolbitsch wrote: hi! my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg* ok i found an answer to it. obviously, qemu has to handle interrupt-signals (e.g. from its client-os). this interrupts accepting connections. very bad for me, but at least a logical reason :-/
Re: [Qemu-devel] Regression bug
Hi Julia, [EMAIL PROTECTED] wrote: > On Tue, May 29, 2007 at 01:10:02AM -0400, Ben Taylor wrote: > > > > I've been keeping up with CVS patches for qemu about once a week. I just > > updated > > tonight after the big round of patches that have been commited and am > > seeing a > > consistent failure with my existing ubuntu-7.04 32-bit guest on Solaris > > 10/x86 32-bit > > host. The last time I tested the CVS code would have been 5/21/07, so > > something > > recently changed has broken the i386-softmmu > > > > qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0 > > > > Anyone seen this? > > > > Ben > > > Ben: > > i've been monitoring this, and reporting on irc since the bug was comitted. > i've tracked it down to somewhere between CVS version 2007-05-26 15:00 and > 2007-05-26 17:40. > as in, 15:00 works, 17:40 dosent, and if i try to check out the version > between.. it fails to compile. Great spot. I reverted the patch to exec.c from 05/26/07 at 17:36 and QEMU again booted my ubuntu 7.04 image. Looks like the patch from http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.96&r2=1.97 needs to be reverted and reworked before being recommitted. > I'm quite new here, so i didn't feel like yelling "the sky is falling" on a > mailing list. What you did was perfect. Thanks. > > hope this helps, > > Julia Longtin <[EMAIL PROTECTED]> Regards, Ben
[Qemu-devel] Accepting socket connections in qemu (not the client... the emulator)
hi! my virtual device inside qemu (a pci device) is listening for socket-(tcp)-connections. however, accept() always fails (code works fine if not executed inside the qemu-process)... now i'm wondering if qemu interferes somehow... is that possible? frustrated *gg*
Re: [Qemu-devel] Regression bug
On Tue, May 29, 2007 at 01:10:02AM -0400, Ben Taylor wrote: > > I've been keeping up with CVS patches for qemu about once a week. I just > updated > tonight after the big round of patches that have been commited and am seeing a > consistent failure with my existing ubuntu-7.04 32-bit guest on Solaris > 10/x86 32-bit > host. The last time I tested the CVS code would have been 5/21/07, so > something > recently changed has broken the i386-softmmu > > qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0 > > EAX= EBX= ECX= EDX=0600 > ESI= EDI= EBP= ESP= > EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES = > CS =f000 > SS = > DS = > FS = > GS = > LDT= 8000 > TR = 8000 > GDT= > IDT= > CR0=6010 CR2= CR3= CR4= > CCS= CCD= CCO=EFLAGS > FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 > FPR0= FPR1= > FPR2= FPR3= > FPR4= FPR5= > FPR6= FPR7= > XMM00= XMM01= > XMM02= XMM03= > XMM04= XMM05= > XMM06= XMM07= > > Anyone seen this? > > Ben > Ben: i've been monitoring this, and reporting on irc since the bug was comitted. i've tracked it down to somewhere between CVS version 2007-05-26 15:00 and 2007-05-26 17:40. as in, 15:00 works, 17:40 dosent, and if i try to check out the version between.. it fails to compile. I'm quite new here, so i didn't feel like yelling "the sky is falling" on a mailing list. hope this helps, Julia Longtin <[EMAIL PROTECTED]>
Re: [Qemu-devel] Regression bug
Hi, I do reproduce that trying to boot a kubuntu i386 on an i368. Now we have to bisect... Xavier. I've been keeping up with CVS patches for qemu about once a week. I just updated tonight after the big round of patches that have been commited and am seeing a consistent failure with my existing ubuntu-7.04 32-bit guest on Solaris 10/x86 32-bit host. The last time I tested the CVS code would have been 5/21/07, so something recently changed has broken the i386-softmmu qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0 EAX= EBX= ECX= EDX=0600 ESI= EDI= EBP= ESP= EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = CS =f000 SS = DS = FS = GS = LDT= 8000 TR = 8000 GDT= IDT= CR0=6010 CR2= CR3= CR4= CCS= CCD= CCO=EFLAGS FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Anyone seen this? Ben -- Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: [EMAIL PROTECTED]
[Qemu-devel] Adding multiple files to qemu Makefile ... a pain
hi! sorry that I'm posting for such a dumb thing, but I'm going crazy Up until now, I had a single file added to the qemu/hw folder. after adding VL_OBJS += myfile.o everything compiled without problems. but now my project grew too large and i wanted to split everything into multiple header- and source-files (all inside qemu/hw). Now, I've been sitting here for hours trying to get everything working, without success (obviously, otherwise I wouldn't be asking ;-) ) What adoptions do I have to make to Makefile(.target) to add new header&source files (best would be if I could add a seperate folder inside qemu/hw/) thanks and sorry for such a basic-gcc/makefile question :-( greets!!
