Re: [Qemu-devel] We need more reviewers/maintainers!!
Is there a core group/committee that handles all fixes, code, and what not? On 3/12/12, Alexander Graf ag...@suse.de wrote: Am 13.03.2012 um 02:01 schrieb Andreas Färber afaer...@suse.de: Am 13.03.2012 01:16, schrieb Anthony Liguori: On 03/12/2012 06:32 PM, Andreas Färber wrote: Take Blue's recent target-ppc fix 9d4df9c02866f39d3eef105033091f367cc7c29e for example: After applying patches on day one of FOSDEM he posted a -Werror fix, it got confirmed by me and Alex but wasn't applied until a week later, because apparently no other committer dared to apply Blue's patch despite SoB and acks and people reporting the issue... Not happy. No doubt Alex is to blame for not catching that issue in his ppc queue, but asking Alex as submaintainer to submit a PULL for a single patch posted by Blue as committer seems overly complicated to me! ;) I think this is a good demonstration of what the problem is. Unclear responsibility. Agreed. Solution is documentation of expected workflows. I'm pretty sure that Blue thought that Alex would handle the patch. I'm pretty sure that Alex thought Blue would handle the patch. Alex actually asked Blue to. However from what I understand, Blue is not working on QEMU full-time, like me previously. I assume he handled the patch once he read and came around to it. It's just that no one else with commit powers reacted to the situation. The way I see it no one owns code in QEMU. Some people feel responsible for (or comfortable reviewing changes to) parts of QEMU, and the project scales by distributing review, testing and queuing to more such shoulders. However where a (sub)maintainer is unresponsive - and *there* I differentiate between build breakages, runtime issues and feature additions - we can't wait forever and need to adapt processes. Fixing the build within a reasonable time is one requirement, moving forward with target-mips at all is another example. It's not really that we have too few maintainers, it's that not all maintainers maintain at all times - for valid work or personal reasons - and we don't seem to have a well-working escalation mechanism beyond ping^n to handle that. Let's take a real world example from Linux here. 3.3-rc5 had a pretty nasty compile bug that made the build break on any 32 bit target when autofs was activated. I posted the bug plus a small bugfix upstream. What happened? Linus went ahead and fixed the thing properly so rc6 could go out quickly. I guess that's what Andreas is trying to say here. Making sure new stuff works, fixing uncritical bugs etc is well within a maintainer's responsibility. Keeping all the code together is where it boils down to the next, the global level, the comitters. That doesn't mean that any of this is exclusive, but it means that whoever works on the global scale of the project - and that's what commit rights mean - is oblidged to care about the wellbeing of the whole project as a whole. You can't just pick a few subsystems and say I maintain QEMU but I don't care if SH4 breaks. That'd be hypocritical :). The same way I can't say This is a patch in PPC code but because this is a particular implementation I don't care about I'll ignore it. Unfortunately - mainly for historical and political reasons - that subsytem thinking happens a lot in QEMU land these days. And I'm not sure how to change that. Few people actually care about all aspects of QEMU at the same time. Alex
Re: [Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging
On Mon, Jul 18, 2011 at 2:22 PM, Juergen Lock n...@jelal.kn-bremen.dewrote: Hi! I'm the FreeBSD qemu port maintainer and don't have a sparc64 box myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using i386-softmmu What's the difference- an honest question- between this and a normal qemu boot? and we found two things: 1. The hang people have been reporting seems to be caused by this tb: IN: 0x000e7a31: in $0xb3,%al 0x000e7a33: test %al,%al 0x000e7a35: jne0xe7a31 i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 to become zero. This port is #defined in hw/apm.c as: qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 but the definition seems to be used nowhere in that source file. Anyone have an idea why this port is never zero on sparc64 hosts but seems to be on others? (endian issue? uninitialized variable?) Have you asked Whitehorn what it my be? 2. Booting the same guest with -no-acpi gets further, bios and bootloader messages are printed until it hangs again, this time while handling a guest irq 8 which seems to be rtc. Is there a way of disabling the clock? If not, then would it be useful to set the emulated cpu speed? Maybe this is useful to some... :) Actually, it's quite useful to me. Thanx, Juergen Thanks here the same.
Re: [Qemu-devel] SPARC64 support on FreeBSD, has it improved as of yet?
On Fri, Jul 1, 2011 at 4:21 PM, Blue Swirl blauwir...@gmail.com wrote: On Fri, Jul 1, 2011 at 7:03 PM, Super Bisquit superbisq...@gmail.com wrote: On Wed, Jun 29, 2011 at 9:46 PM, Super Bisquit superbisq...@gmail.com wrote: On Wed, Jun 29, 2011 at 1:10 AM, Bob Breuer breu...@mc.net wrote: Super Bisquit wrote: ... It builds, doesn't run. More like it runs and hangs. $ qemu-system-sparc -cpu LEON3 -hda test.img -cdrom Downloads/debian-6.0.2.1-sparc-businesscard.iso -m 256 -boot d That command line won't work. OpenBIOS doesn't support LEON, and the last version of Debian for sparc32 was 4.0. Try instead: qemu-system-sparc -cdrom debian-40r9-sparc-netinst.iso -boot d You can get a cd image from http://cdimage.debian.org/cdimage/archive/4.0_r9/sparc/iso-cd/ but the installer may not be able to load packages from the internet because the packages have been moved to archive.debian.org. Bob No response either from sparc32 or powerpc. I386 also didn't work. What gdb commands should be ran on the core and what qemu monitor commands should I run? Here. When someone else on the list has FreeBSD installed to a SPARC64/UltraSPARC device and has installed qemu to it, then it will be easy to see what I am referring to constantly. More Sparc (or BSD) hackers are very much welcome. Is there a way of verbose logging qemu while it runs? Maybe comparing the FreeBSD output to the OpenBSD output will help. Also, I can send you a list of the installed binaries, libraries, scripts, and config files. Qemu on qemu has worked for me. This means that anyone with a machine that has the CPU and memory to support a sparc64 guest could install FreeBSD as a virtual sparc64 client/vm.
Re: [Qemu-devel] SPARC64 support on FreeBSD, has it improved as of yet?
On Wed, Jun 29, 2011 at 9:46 PM, Super Bisquit superbisq...@gmail.comwrote: On Wed, Jun 29, 2011 at 1:10 AM, Bob Breuer breu...@mc.net wrote: Super Bisquit wrote: ... It builds, doesn't run. More like it runs and hangs. $ qemu-system-sparc -cpu LEON3 -hda test.img -cdrom Downloads/debian-6.0.2.1-sparc-businesscard.iso -m 256 -boot d That command line won't work. OpenBIOS doesn't support LEON, and the last version of Debian for sparc32 was 4.0. Try instead: qemu-system-sparc -cdrom debian-40r9-sparc-netinst.iso -boot d You can get a cd image from http://cdimage.debian.org/cdimage/archive/4.0_r9/sparc/iso-cd/ but the installer may not be able to load packages from the internet because the packages have been moved to archive.debian.org. Bob No response either from sparc32 or powerpc. I386 also didn't work. What gdb commands should be ran on the core and what qemu monitor commands should I run? Here. When someone else on the list has FreeBSD installed to a SPARC64/UltraSPARC device and has installed qemu to it, then it will be easy to see what I am referring to constantly.
Re: [Qemu-devel] SPARC64 support on FreeBSD, has it improved as of yet?
On Wed, Jun 29, 2011 at 1:10 AM, Bob Breuer breu...@mc.net wrote: Super Bisquit wrote: ... It builds, doesn't run. More like it runs and hangs. $ qemu-system-sparc -cpu LEON3 -hda test.img -cdrom Downloads/debian-6.0.2.1-sparc-businesscard.iso -m 256 -boot d That command line won't work. OpenBIOS doesn't support LEON, and the last version of Debian for sparc32 was 4.0. Try instead: qemu-system-sparc -cdrom debian-40r9-sparc-netinst.iso -boot d You can get a cd image from http://cdimage.debian.org/cdimage/archive/4.0_r9/sparc/iso-cd/ but the installer may not be able to load packages from the internet because the packages have been moved to archive.debian.org. Bob No response either from sparc32 or powerpc. I386 also didn't work. What gdb commands should be ran on the core and what qemu monitor commands should I run?
Re: [Qemu-devel] SPARC64 support on FreeBSD, has it improved as of yet?
On Sun, Jun 26, 2011 at 1:58 PM, Blue Swirl blauwir...@gmail.com wrote: On Fri, Jun 24, 2011 at 3:52 AM, Super Bisquit superbisq...@gmail.com wrote: The last time I asked, Blue Swirl was somewhat working on the port. Has anything been improved since? I'm somewhat working on OpenBSD host support, not FreeBSD, but there shouldn't be great differences. What's the status on FreeBSD, does QEMU build and run? http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02277.html Our last conversation on the subject. It builds, doesn't run. More like it runs and hangs. The core is ~428M in size. $ qemu-system-sparc -cpu LEON3 -hda test.img -cdrom Downloads/debian-6.0.2.1-sparc-businesscard.iso -m 256 -boot d qemu: fatal: Trap 0x02 while interrupts disabled, Error state pc: npc: 0004 General Registers: %g0-7: Current Register Window: %o0-7: %l0-7: %i0-7: Floating Point Registers: %f00: 0.00 0.00 0.00 0.00 %f04: 0.00 0.00 0.00 0.00 %f08: 0.00 0.00 0.00 0.00 %f12: 0.00 0.00 0.00 0.00 %f16: 0.00 0.00 0.00 0.00 %f20: 0.00 0.00 0.00 0.00 %f24: 0.00 0.00 0.00 0.00 %f28: 0.00 0.00 0.00 0.00 psr: f3c0 (icc: SPE: SP-) wim: 0001 fsr: 0008 y: Abort trap (core dumped) $ gdb qemu-system-sparc qemu-system-sparc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc64-marcel-freebsd...(no debugging symbols found)... warning: core file may not match specified executable file. Core was generated by `qemu-system-sparc'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /usr/local/lib/libcurl.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcurl.so.6 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/local/lib/libgnutls.so.40...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnutls.so.40 Reading symbols from /lib/libpcap.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libpcap.so.7 Reading symbols from /usr/local/lib/libSDL-1.2.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSDL-1.2.so.11 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libssl.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /usr/local/lib/libgcrypt.so.17...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.17 Reading symbols from /usr/local/lib/libgpg-error.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /usr/local/lib/libintl.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libggi.so.2...done. Loaded symbols for /usr/local/lib/libggi.so.2 Reading symbols from /usr/local/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libgii.so.1...done. Loaded symbols for /usr/local/lib/libgii.so.1 Reading symbols from
[Qemu-devel] SPARC64 support on FreeBSD, has it improved as of yet?
The last time I asked, Blue Swirl was somewhat working on the port. Has anything been improved since? Thanks
Re: [Qemu-devel] [PATCH] sparc64: fix wrpstate and wrtl on delay slot
Just curious, is this for host or guest? On Sat, Apr 30, 2011 at 3:32 PM, Igor Kovalenko igor.v.kovale...@gmail.comwrote: On Sat, Apr 30, 2011 at 7:42 PM, Blue Swirl blauwir...@gmail.com wrote: Use TCG local to work around TCG register flush due to a branch. Thanks to Artyom Tarasenko, Igor Kovalenko and Aurelien Jarno. Signed-off-by: Blue Swirl blauwir...@gmail.com --- I analyzed the call tree in target-sparc/translate.c for brcond* usage. In the following lines, first level function uses brcond* directly, second level calls the first level etc. I want to be able to do exhaustive searches as well :) Have you used recently posted gcc save-temps method? -- Kind regards, Igor V. Kovalenko
Re: [Qemu-devel] Question on qemu build environment.
qemu-system-sparc -monitor stdio -vnc :0 With any system emulation, it is the same: high cpu use, no graphical output, segmentation fault. On 4/26/11, Super Bisquit superbisq...@gmail.com wrote: Those are the current settings. I can run ./configure or vi the file to add the sparc cpu value. I've installed extra sdl bindings/parts.addons from ports. I've enabled gnutls and pcap. Bsd user doesn't work currently for sparc64. I had sent the files earlier. These contain patches from nox (Juergen Lock) made a patch which helped the port to build. I've added WITH_DEBUG=yes to the /etc/make.conf. Something tells me now that it may be out of context. Probably should be a cflag. On Tue, Apr 26, 2011 at 2:11 PM, Blue Swirl blauwir...@gmail.com wrote: On Tue, Apr 26, 2011 at 4:23 PM, Super Bisquit superbisq...@gmail.com wrote: I have noticed that qemu does not fully function on FreeBSD sparc64. Besides n...@freebsd.org and myself, has anyone tried building and running qemu under FreeBSD sparc64? I think you are the first to report. On OpenBSD/Sparc64 I could run qemu-system-sparc with the test image and get a command prompt (it seems to be broken now), but i386 emulator (or Sparc64 TCG target) has problems with unaligned accesses.
[Qemu-devel] Question on qemu build environment.
I have noticed that qemu does not fully function on FreeBSD sparc64. Besides n...@freebsd.org and myself, has anyone tried building and running qemu under FreeBSD sparc64?
Re: [Qemu-devel] Question on qemu build environment.
Those are the current settings. I can run ./configure or vi the file to add the sparc cpu value. I've installed extra sdl bindings/parts.addons from ports. I've enabled gnutls and pcap. Bsd user doesn't work currently for sparc64. I had sent the files earlier. These contain patches from nox (Juergen Lock) made a patch which helped the port to build. I've added WITH_DEBUG=yes to the /etc/make.conf. Something tells me now that it may be out of context. Probably should be a cflag. On Tue, Apr 26, 2011 at 2:11 PM, Blue Swirl blauwir...@gmail.com wrote: On Tue, Apr 26, 2011 at 4:23 PM, Super Bisquit superbisq...@gmail.com wrote: I have noticed that qemu does not fully function on FreeBSD sparc64. Besides n...@freebsd.org and myself, has anyone tried building and running qemu under FreeBSD sparc64? I think you are the first to report. On OpenBSD/Sparc64 I could run qemu-system-sparc with the test image and get a command prompt (it seems to be broken now), but i386 emulator (or Sparc64 TCG target) has problems with unaligned accesses. Makefile Description: Binary data
