Re: [Qemu-devel] [PATCH] linux-user EFAULT implementation
On Tue, 10 Jul 2007, Fabrice Bellard wrote: I confirm that I expected g2h() to be completely removed in case the Linux user access API is used. I agree too that it should not be used. I'm testing ARM on x86_64, and used it in a few places to clean up some warnings. The real fix is to change what I was doing to not need this asignment anyway. I will take another look at how to bury this part in the copy* interfaces. Would it be OK to use g2h() inside the implementation of copy* ? Since you agree for the copying interface, I suggest to convert all the code to it. OK, I'll continue in this direction, after taking a fresh look at what I did yesterday. Thanks for the feedback. Stuart Stuart R. Anderson [EMAIL PROTECTED] Solutions Architect http://www.c2.net/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
[Qemu-devel] qemu/target-mips TODO
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 10:25:05 Modified files: target-mips: TODO Log message: Update TODO list. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/TODO?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu block-vmdk.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 10:25:58 Modified files: . : block-vmdk.c Log message: Silence compiler warnings. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemur1=1.11r2=1.12
[Qemu-devel] qemu qemu-doc.texi qemu-tech.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 10:24:28 Modified files: . : qemu-doc.texi qemu-tech.texi Log message: Documentation update for MIPS. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.151r2=1.152 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-tech.texi?cvsroot=qemur1=1.11r2=1.12
[Qemu-devel] qemu/target-ppc cpu.h exec.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 10:36:47 Modified files: target-ppc : cpu.h exec.h Log message: Fix PPCEMB for 32bit hosts. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.48r2=1.49 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemur1=1.21r2=1.22
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/10/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote: The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. Huh. That's odd because hello-dynamic is using the dynamic loader. (That's why there's a hello-dynamic and a hello-static.) It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. Running the program on qemu-sparc reveals another problem, probably because of these definitions in ldso/ldso/sparc/dl-sysdep.h: /* 4096 bytes alignment */ /* ...but 8192 is required for mmap() on sparc64 kernel */ #define PAGE_ALIGN 0xe000 #define ADDR_ALIGN 0x1fff #define OFFS_ALIGN 0x7fffe000 On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped.
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Blue Swirl [EMAIL PROTECTED] wrote: It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. Running the program on qemu-sparc reveals another problem, probably because of these definitions in ldso/ldso/sparc/dl-sysdep.h: /* 4096 bytes alignment */ /* ...but 8192 is required for mmap() on sparc64 kernel */ #define PAGE_ALIGN 0xe000 #define ADDR_ALIGN 0x1fff #define OFFS_ALIGN 0x7fffe000 On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped. I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Christian MICHON [EMAIL PROTECTED] wrote: I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. busybox-1.6.0 does segfault here too. I had to remove taskset as apparently the sched_affinity patch did not fix the linking step. is there a repository of sparc/uclibc patches somewhere ? Blue mentionned he'll have a fix for uclibc ldso. I'll try it using this dev environment as soon as it'll be out. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
I have a remote system that boots fine when I use: qemu -vnc :4 -kernel-kqemu -smp 2 -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 But this is not using kqemu and very slow. When I boot the following, the guest never gets past the init process. According to top, the guest qemu system uses 101% of the hosts cpu amd x2 3800. The guest is ubuntu 7.4 running (postgesql, Apache, and ssh) qemu -vnc :4 -kernel-kqemu -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? Is there a way in the proc file system on the guest to see kqemu if is working? Is there a plan to create a stand alone qemu-monitor that can be attached to a running qemu process? Thank you for your time and a great project, Nicholas A. Schembri State College, PA USA PS. qemu -smp 2 has 90 day's uptime on the production hardware.
[Qemu-devel] Crash: When Host HDD is full
Problem 1: When Host HDD is full, all guests simply crash. Tried with dynamically growing .VMDK hard disk. It shouldn't happen. For example, both VirtualPC and VirtualBox pause all VMs, and gray their displays when something like that happens. Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron. Problem 2: Where is Qemu Bugzilla ? -- -Alexey Eremenko Technologov
[Qemu-devel] Solaris 10 dies during install
Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron. Guest: Solaris 10 (32-bit, 2005 release) aborts install in the middle. This shouldn't happen. It works on VMware. Is there any bugzilla ? -- -Alexey Eremenko Technologov
Re: [Qemu-devel] Solaris 10 dies during install
Alexey Eremenko [EMAIL PROTECTED] wrote: Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron. If you are using Qemu 0.9, not CVS, there are several bugs that have been fixed in the CVS code which fixed Solaris installs in QEMU. Guest: Solaris 10 (32-bit, 2005 release) aborts install in the middle. This shouldn't happen. It works on VMware. Ben
Re: [Qemu-devel] Solaris 10 dies during install
Am 11.07.2007 um 17:23 schrieb Alexey Eremenko: Guest: Solaris 10 (32-bit, 2005 release) aborts install in the middle. Have you checked out the instructions on the OpenSolaris site? And am I correct to assume that you mean Solaris x86? Solaris sparc doesn't install at all on sparc32 for me, it wants sparc64. Andreas
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
virtualBox support page talks about a race condition. Is this a race in the guest kernel or user land? It looks like I boot the kernel just fine. the cpu spikes around init time. - Original Message From: n schembr [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Wednesday, July 11, 2007 11:18:14 AM Subject: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? I have a remote system that boots fine when I use: qemu -vnc :4 -kernel-kqemu -smp 2 -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 But this is not using kqemu and very slow. When I boot the following, the guest never gets past the init process. According to top, the guest qemu system uses 101% of the hosts cpu amd x2 3800. The guest is ubuntu 7.4 running (postgesql, Apache, and ssh) qemu -vnc :4 -kernel-kqemu -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? Is there a way in the proc file system on the guest to see kqemu if is working? Is there a plan to create a stand alone qemu-monitor that can be attached to a running qemu process? Thank you for your time and a great project, Nicholas A. Schembri State College, PA USA PS. qemu -smp 2 has 90 day's uptime on the production hardware.
Re: [Qemu-devel] Solaris 10 dies during install
I'd strongly recommend using Solaris 10mu3 -- I got it to install. I have an image but I'd have to mail it to you on a DVD if you want it... jonathan On 7/11/07, Alexey Eremenko [EMAIL PROTECTED] wrote: Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron. Guest: Solaris 10 (32-bit, 2005 release) aborts install in the middle. This shouldn't happen. It works on VMware. Is there any bugzilla ? -- -Alexey Eremenko Technologov -- -- Jonathan Kalbfeld +1 323 620 6682
[Qemu-devel] qemu/target-sparc op.c translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/07/11 16:43:30 Modified files: target-sparc : op.c translate.c Log message: More alignment checks CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.34r2=1.35 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.64r2=1.65
[Qemu-devel] qemu/hw gt64xxx.c mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 16:44:32 Modified files: hw : gt64xxx.c mips_malta.c Log message: Impement Galilleo ISD register. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.41r2=1.42
Re: [Qemu-devel] Missing system calls retries in case of EINTR
Talking about sigaction(SA_RESTART) vs looping around -EINTR everywhere: On Tuesday 10 July 2007 8:57:34 pm Yigael Fleishman wrote: Rob, Thanks, that should also work. Seems do_sigaction() in linux-user/signal.c has some code which does that (though obviously not for the signal that I'm receiving). Any idea why SA_RESTART calls are not invoked by default to restart syscalls for all signals? Fallout from old 1980's-era Unixes that didn't implement SA_RESTART, basically. Standards like SUSv3 say to humor them, because they paid for the standard... http://www.ussg.iu.edu/hypermail/linux/kernel/0507.1/1065.html --Yigael Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] multicast and the eepro100 driver
Hi Jeff, eepro100.c is my work, so maybe I can help you. First of all: there exists a newer version of eepro100.c which fixes some bugs of the CVS version and largely improves support for big endian hosts and targets. Get it from http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=filerev=0sc=0 I am still working on this new version, because support for big endian hosts is still untested. If you define macro DEBUG_EEPRO100 in eepro100.c, you will get debugging messages which show the frames sent and received. Multicast frames should be received, but I never tested this, so maybe there is a bug, and I know that I did not implement all functions needed for multicast. Look in the code for function nic_receive and try to remove the return statement which aborts the reception of unwanted multicast frames. You will get too many multicast frames - but perhaps that is better than getting none at all :-) Regards Stefan Jeff Hoare schrieb: Hi, I have been using a recent snapshot version of QEMU (5th July, 2007) which has the eepro100 Ethernet driver, in order to set up a couple of routing engines (one each in a separate QEMU VM). While I have basic connectivity between each engine (including telnet between each) it seems that the RIP/OSPF routing updates do not pass between them (I have let to try a TCP based one). These are multicast UDP packets, which seem to be output the FXP0 interface (see tcpdump below) and I can even see them on the TAP0 interface, but they don't appear to be received by the other VM. The two VM are connected using VDE (with different values for HDA macaddresses). Does the emulated Ethernet driver receive multicast udp packets? I assumed that the virtual switch is forwarding the packets since they are received by the TAP0 interface. Anyway any information or light that could be shed would be appreciated. Regards jeff
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 11 July 2007 9:34:17 am Christian MICHON wrote: I just managed a compilation of bash-3.2 using ncurses-5.6 and uClibc-0.9.29 inside a qemu-system-sparc (native compilation, no cross compilation). ldd ./bash points naturally to libdl.so.0, libc.so.0, ld-uClibc.so.0 ./bash Segmentation fault When you get that kind of segmentation fault, see if hello world segfaults too. (In general, when building with a new toolchain, new C library, new kernel, new root filesystem packaging method, or a new system in general, if anything goes wrong back up a few steps and make sure hello world works before trying to debug anything fancier.) I do not have gdb compiled yet... I'll check soon with busybox ash, since I recompiled uClibc with the sched_affinity patch. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] ANN: DetaolB v0.4 is released
On Wednesday 11 July 2007 7:17:28 am Blue Swirl wrote: On 7/10/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 10 July 2007 14:30:38 Blue Swirl wrote: The sparc platform has a problem that if I boot with init as a hello world program everything behaves as expected (there are two in the image for testing purposes, /tools/bin/hello-dynamic and /tools/bin/hello-static). But if you boot with init=/tools/bin/bash it hangs. And so do the busybox shells. I think there is a problem with the dynamic loader, I get a bus error when running the programs on real Sparc. Huh. That's odd because hello-dynamic is using the dynamic loader. (That's why there's a hello-dynamic and a hello-static.) It's entirely possibly that qemu and real sparc hardware are behaving differently, but I'm not seeing this bus error under qemu. (I haven't got real sparc hardware, so I can only debug against qemu...) Right. Debugging the problem I found out that in Qemu, 64-bit loads and stores to unaligned addresses do not trigger any traps as they should. I'll commit a fix soon. The problem is in uClibc ldso, there is this kind of store. I'll leave that to you. I can commit the patches to the uClibc repository if you can get them to me and confirm they work for you. (And get them added to the 0.9.29.1 patch list.) On Sparc32 the correct page alignment is still 4096. Because of these definitions, some code apparently tries to clear a 8k page, but only 4k of memory is mapped. Hmmm... It's possible that hello world is working but nothing larger is just because it uses such small amounts of memory nothing ever crosses a page boundary, or gets aligned properly by accident... I look forward to a fix. It would be nice to add sparc to the actually works list. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] Missing system calls retries in case of EINTR
Rob Thanks for the background info. I wasn't very specific in my last question. Actually I meant to ask why doesn't qemu code set sigaction(SA_RESTART) for _all_ signals when running in system emulation mode (or maybe it does, which means there's even larger problem...) --Yigael On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: Talking about sigaction(SA_RESTART) vs looping around -EINTR everywhere: On Tuesday 10 July 2007 8:57:34 pm Yigael Fleishman wrote: Rob, Thanks, that should also work. Seems do_sigaction() in linux-user/signal.c has some code which does that (though obviously not for the signal that I'm receiving). Any idea why SA_RESTART calls are not invoked by default to restart syscalls for all signals? Fallout from old 1980's-era Unixes that didn't implement SA_RESTART, basically. Standards like SUSv3 say to humor them, because they paid for the standard... http://www.ussg.iu.edu/hypermail/linux/kernel/0507.1/1065.html --Yigael Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] Problem with the -serial option of qemu
The MoonSeeker schrieb: On my ubuntu I have qemu 0.9.0 And on my Gentoo I have 0.8.1. Now I don't know howto install qemu 0.9.0 on my gentoo with GCC4 and a 2.6.20 kernel. If I install GCC3, I have to change my kernel. Any idea to avoid this? And use GCC4 with qemu 9.0.x? Finally, I don't have anything on the port 4000 : You have to select a gcc3-profile without pie or ssp via gcc-config before quilding qemu-softmmu or qemu-user. for kqemu you have to use the same compiler used to compile your kernel. regs, Jan
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
ok, This error is in kqemu. The guest boots with -no-kqemu option. The guest is booting ubuntu 7.04 linux 2.6.20-16-server. Note: the host is running 7.4 and I compiled with ./configure --prefix=/usr/local --cc=gcc-3.4 --host-cc=gcc-3.4 --kernel-path=/usr/src/linux-headers-2.6.20-16-server/ The host has a second guest running ubuntu dapper linux 2.6.15-28-686 qemu -vnc :1 -kernel-kqemu -daemonize -no-reboot -monitor unix:/vservers/qemu/mail1/mail1.sock,server,nowait -boot c -hda /dev/sdc -net nic,vlan=0,macaddr=00:16:3e:00:0f:10 -net tap,vlan=0,ifname=br0-mail1,script=/etc/qemu-ifup-br0 -m 512 I also found that qemu is not exiting after guest is halted with init 0. - Original Message From: n schembr [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Wednesday, July 11, 2007 12:27:16 PM Subject: Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? virtualBox support page talks about a race condition. Is this a race in the guest kernel or user land? It looks like I boot the kernel just fine. the cpu spikes around init time. - Original Message From: n schembr [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Wednesday, July 11, 2007 11:18:14 AM Subject: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? I have a remote system that boots fine when I use: qemu -vnc :4 -kernel-kqemu -smp 2 -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 But this is not using kqemu and very slow. When I boot the following, the guest never gets past the init process. According to top, the guest qemu system uses 101% of the hosts cpu amd x2 3800. The guest is ubuntu 7.4 running (postgesql, Apache, and ssh) qemu -vnc :4 -kernel-kqemu -no-reboot -monitor unix:/vservers/qemu/cms1/cms1.sock,server,nowait -boot c -hda hda1.img -hdb swap.img -net nic,vlan=0,macaddr=00:16:3e:00:0f:00 -net tap,vlan=0,ifname=br0-cms1,script=/etc/qemu-ifup-br0 -m 500 Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? Is there a way in the proc file system on the guest to see kqemu if is working? Is there a plan to create a stand alone qemu-monitor that can be attached to a running qemu process? Thank you for your time and a great project, Nicholas A. Schembri State College, PA USA PS. qemu -smp 2 has 90 day's uptime on the production hardware.
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
Hi, On 11/07/07, n schembr [EMAIL PROTECTED] wrote: ok, This error is in kqemu. The guest boots with -no-kqemu option. The guest is booting ubuntu 7.04 linux 2.6.20-16-server. Note: the host is running 7.4 and I compiled with ./configure --prefix=/usr/local --cc=gcc-3.4 --host-cc=gcc-3.4 --kernel-path=/usr/src/linux-headers-2.6.20-16-server/ The host has a second guest running ubuntu dapper linux 2.6.15-28-686 qemu -vnc :1 -kernel-kqemu -daemonize -no-reboot -monitor unix:/vservers/qemu/mail1/mail1.sock,server,nowait -boot c -hda /dev/sdc -net nic,vlan=0,macaddr=00:16:3e:00:0f:10 -net tap,vlan=0,ifname=br0-mail1,script=/etc/qemu-ifup-br0 -m 512 Just an idea, if your host is SMP too: try booting the guest kernel with notsc param or setting qemu's affinity to a single CPU using taskset. It may help or not :) Cheers, Andrzej
Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch
On 08/07/07, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Sun, Jul 08, 2007 at 06:04:51PM +0100, Ricardo Almeida wrote: On 7/8/07, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Sun, Jul 08, 2007 at 02:21:02PM +0200, Robert Millan wrote: Shouldn't /usr/bin/qemu be an alias for qemu-system-$(ARCH), where $(ARCH) is the native architecture? Defaulting to i386 doesn't make much sense nowadays, specially since x86_64 is gradually obsoleting it. Management tools for QEMU will have come to rely on existing semantics of /usr/bin/qemu being i386. Why?! If they rely on 386 I think they should directly use qemu-system-i386... If they manage in an architecture independent way then use the qemu link... Rely on a binary which doesn't currently exist ? A fresh checkout build of qemu cvs does not produce any qemu-system-i386 binary. So that's not Maybe it's a good idea to make qemu-system-i386 a symlink to qemu or the other way, for now, and after some time do what Ricardo proposed, which is more logical. After all qemu has already broken commandline backwards compatibility many times and probably will do more times. And here's one of my usual strange but fun ideas: make qemu a wrapper that reads a number of first bytes of the harddisk/cdrom/kernel image or whatever media was given, and applies a heuristic to decide what architecture the instructions would be best interpreted as. The file program likely already contains a sample of such heuristic. (A similar idea with reusing file code was for vvfat to detect what OS is on a given partition and fake an MBR respective to the OS). Cheers, Andrzej
[Qemu-devel] qemu/hw sun4u.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/07/11 19:51:37 Modified files: hw : sun4u.c Log message: Sparc64 update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemur1=1.18r2=1.19
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
- Original Message From: andrzej zaborowski [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Wednesday, July 11, 2007 2:38:28 PM Subject: Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? Hi, On 11/07/07, n schembr [EMAIL PROTECTED] wrote: ok, This error is in kqemu. The guest boots with -no-kqemu option. The guest is booting ubuntu 7.04 linux 2.6.20-16-server. Note: the host is running 7.4 and I compiled with ./configure --prefix=/usr/local --cc=gcc-3.4 --host-cc=gcc-3.4 --kernel-path=/usr/src/linux-headers-2.6.20-16-server/ The host has a second guest running ubuntu dapper linux 2.6.15-28-686 qemu -vnc :1 -kernel-kqemu -daemonize -no-reboot -monitor unix:/vservers/qemu/mail1/mail1.sock,server,nowait -boot c -hda /dev/sdc -net nic,vlan=0,macaddr=00:16:3e:00:0f:10 -net tap,vlan=0,ifname=br0-mail1,script=/etc/qemu-ifup-br0 -m 512 Just an idea, if your host is SMP too: try booting the guest kernel with notsc param or setting qemu's affinity to a single CPU using taskset. It may help or not :) Cheers, Andrzej ./taskset -c 1 qemu ...etc worked great. What will notsc do to the guest kernel? You just saved my project, thank you. Nicholas A. Schembri State College PA USA For google qemu race condition kqemu ubuntu 7.4 feisty lockup hang
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
On 11/07/07, n schembr [EMAIL PROTECTED] wrote: ./taskset -c 1 qemu ...etc worked great. What will notsc do to the guest kernel? Ok, then it is the rdtsc issue with kqemu. See http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html for explanation and proposed fix. Cheers, Andrzej
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: When you get that kind of segmentation fault, see if hello world segfaults too. (In general, when building with a new toolchain, new C library, new kernel, new root filesystem packaging method, or a new system in general, if anything goes wrong back up a few steps and make sure hello world works before trying to debug anything fancier.) I was not clear then. I've binutils already compiled versus uClibc for sparc, and it works. Some of those binaries from binutils are bigger than the expected size of final uclibc dynamic busybox. of course, as soon as I got uclibc compiled, hello world comes first to my mind, and it was working. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Detaolb-devel] [Qemu-devel] ANN: DetaolB v0.4 is released
On 7/11/07, Rob Landley [EMAIL PROTECTED] wrote: I look forward to a fix. It would be nice to add sparc to the actually works list. :) that's 2 persons looking forward to it. ;-) today's results: - uclibc ok (minus the segfaults coming from it) - conf from busybox segfaults - bash segfaults - busybox segfaults - gcc does not build without bash (I'll replace with ash tomorrow) - binutils ok - ncurses ok (I need to look at uclibc' conf now) - make ok - bzip2 ok - coreutils ok - findutils ok Blue swirl, please note that the porting of DetaolB to sparc32 will take more time than scheduled, once the segfault issues are covered. I'd like to spend some time testing firmware and cross compilation :) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests?
- Original Message From: andrzej zaborowski [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Wednesday, July 11, 2007 4:19:23 PM Subject: Re: [Qemu-devel] Is there a patch for kqemu 1.3.0pre11 and qemu 0.9 to allow accelerated smp guests? On 11/07/07, n schembr [EMAIL PROTECTED] wrote: ./taskset -c 1 qemu ...etc worked great. What will notsc do to the guest kernel? Ok, then it is the rdtsc issue with kqemu. See http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html for explanation and proposed fix. Cheers, Andrzej It it better to boot the guest with notsc and have processor migration or set qemu to one processor? It seems cleaner to set notsc in grub and let it fly. In my case, I'm booting a real hard drive inside qemu. If the host system's hard drive fails, the reboot will load the host off of the guests hard drive. If I add notsc to grub will it still boot on the real hardware? I'm 11 hours from the host machine. :)
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 21:43:14 Modified files: . : qemu-doc.texi Log message: Spelling fix, spotted by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.152r2=1.153
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 22:45:45 Modified files: hw : gt64xxx.c Log message: Remove superfluous gt64xxx_pci_mapping calls. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemur1=1.17r2=1.18
[Qemu-devel] qemu dyngen.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 22:47:56 Modified files: . : dyngen.c Log message: Reduce variable shadowing, by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.52r2=1.53
[Qemu-devel] qemu block-raw.c dis-asm.h gdbstub.c m68k-dis.c...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 22:48:58 Modified files: . : block-raw.c dis-asm.h gdbstub.c m68k-dis.c hw : i2c.h ide.c pl011.c pl181.c rtl8139.c usb.c linux-user : signal.c target-i386: cpu.h Log message: Spelling fixes, by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/dis-asm.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.59r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-dis.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i2c.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.62r2=1.63 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl011.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl181.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.44r2=1.45
[Qemu-devel] qemu/hw fdc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 22:50:53 Modified files: hw : fdc.c Log message: Spelling fix, by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/fdc.c?cvsroot=qemur1=1.24r2=1.25
[Qemu-devel] qemu console.c qemu-doc.texi vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 23:14:59 Modified files: . : console.c qemu-doc.texi vl.c vl.h Log message: New features for QEMU text console, by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/console.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.153r2=1.154 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.320r2=1.321 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.255r2=1.256
[Qemu-devel] qemu/audio sdlaudio.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 23:23:16 Modified files: audio : sdlaudio.c Log message: Ensure signals are properly masked for new SDL Audio threads, by Andrzej Zaborowski. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/sdlaudio.c?cvsroot=qemur1=1.8r2=1.9
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/11 23:39:46 Modified files: . : configure Log message: Display SDL configuration error, idea by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.146r2=1.147
[Qemu-devel] qemu/target-ppc translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/12 00:18:53 Modified files: target-ppc : translate_init.c Log message: Disable dead code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.18r2=1.19
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/07/12 00:27:16 Modified files: . : configure Log message: Nicer script formatting, by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.147r2=1.148
Re: [Qemu-devel] multicast and the eepro100 driver
Hi Stefan, I experienced the same issue as Jeff, so removing the 'return' statement in nic_receive works for multicast (at least 224.0.0.5) with your latest code. Thanks ! Nicolas. Hi Jeff, eepro100.c is my work, so maybe I can help you. First of all: there exists a newer version of eepro100.c which fixes some bugs of the CVS version and largely improves support for big endian hosts and targets. Get it from http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c? op=filerev=0sc=0 I am still working on this new version, because support for big endian hosts is still untested. If you define macro DEBUG_EEPRO100 in eepro100.c, you will get debugging messages which show the frames sent and received. Multicast frames should be received, but I never tested this, so maybe there is a bug, and I know that I did not implement all functions needed for multicast. Look in the code for function nic_receive and try to remove the return statement which aborts the reception of unwanted multicast frames. You will get too many multicast frames - but perhaps that is better than getting none at all :-) Regards Stefan Jeff Hoare schrieb: Hi, I have been using a recent snapshot version of QEMU (5th July, 2007) which has the eepro100 Ethernet driver, in order to set up a couple of routing engines (one each in a separate QEMU VM). While I have basic connectivity between each engine (including telnet between each) it seems that the RIP/OSPF routing updates do not pass between them (I have let to try a TCP based one). These are multicast UDP packets, which seem to be output the FXP0 interface (see tcpdump below) and I can even see them on the TAP0 interface, but they don't appear to be received by the other VM. The two VM are connected using VDE (with different values for HDA macaddresses). Does the emulated Ethernet driver receive multicast udp packets? I assumed that the virtual switch is forwarding the packets since they are received by the TAP0 interface. Anyway any information or light that could be shed would be appreciated. Regards jeff
