[Qemu-devel] Login a guest use commandline
when I run the command in bash: "sudo qemu -hda testaa.img -boot c -localtime -serial stdio -pidfile pidfile1.txt && sleep 300 && root && 123456 && ifconfig" root is the guest's user, 123456 is password, Why can't I login in the guest and run the ifconfig? and run "sudo qemu -hda testaa.img -boot c -localtime -serial stdio -pidfile pidfile1.txt && root && 123456 && ifconfig" is same Is the command like "ssh"? Thank you! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] ACPI support
To support the ACPI event, qemu should at least have General-Purpose Event (GPE) register and SCI interrupt (see ACPI 2.0 spec, ch 5.6). It may not be as simple as calculating checksum and updating acpi.S, so I guess you have to use real hardware currently. If there are more and more usage models for ACPI in qemu, I guess people will consider adding ACPI support in qemu :) Best Regards Yu Ke Intel, Open Source Technology Center From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shahar Livne Sent: 2005年11月9日 15:41 To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] ACPI support Thanks! Actually, I don't need the whole ACPI mechanism working. On the real target, I want to use the power button to initiate a reboot. Such a thing can be done with something like: cat /proc/acpi/event | grep specific_event > /dev/null && reboot In the qemu, I never get to load the relevant kernel modules (like button.ko), since the ACPI is disabled due to the mentioned checksum failure. If it is only some small adaptation of the mentioned patch with checksum calculation for RSDT and updating acpi.S than I would gladly do it (do you have any hints?). Otherwise - I just give up on this now, and use the real hardware. Cheers, Shahar Livne LivneX - Open Source Development and Services http://livnex.com On 11/8/05, Yu, Ke <[EMAIL PROTECTED]> wrote: This is an interesting topic, however, not an easy task :) The patch is for APIC support, and only contains one ACPI MADT entry, which is far from full ACPI support. So you may like to call it an APIC patch rather than ACPI patch. If you want to test power management of embedded system with qemu, IMHO, there will be a lot of work to do: * Implement ACPI hardware in QEMU, which includes - General ACPI hardware in chipset - Specific ACPI hardware in every device * Add ACPI table in BIOS. Best Regards Yu Ke Intel Opensource Technology Center From: qemu-devel-bounces+ke.yu= [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shahar Livne Sent: 2005年11月9日 1:40 To: qemu-devel@nongnu.org Subject: [Qemu-devel] ACPI support Hi there, I use qemu for development of embedded systems. Lately I had a need to check ACPI related kernel module, but I have seen that there isn't any support in the version 0.7.1 that I use. I have checked also 0.7.2 and found no support. A patch that I have found on www.h7.dion.ne.jp/~qemu-win/ for x86_64 by F.Navara seemed like close enough. I have applied it (after adaptation, since it didn't go smooth for 0.7.1 or 0.7.2). The system booted, but running dmesg | grep ACPI inside the embedded system on the qemu gave: ACPI: RSDP (v000 QEMU ) @ 0x000e ACPI: Invalid RSDT checksum ACPI: Subsystem revision 20050211 ACPI: Interpreter disabled. I use the i386 emulation, and the kernel running inside is 2.6.11 Has someone any experience with ACPI in qemu? Thanks, Shahar Livne LivneX - Open Source Development and Services http://livnex.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Shane: good news
Hello, Quit o ng f cations - visi harmaExp hop verpayi or your Meddi t our P ress S C V P V X A I I r A a m A A o L n b L G z I a i I R a U x e S A c M n 99,95 69,95 85,45 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Login a guest use commandline
zheng sw wrote: when I run the command in bash: "sudo qemu -hda testaa.img -boot c -localtime -serial stdio -pidfile pidfile1.txt && sleep 300 && root && 123456 && ifconfig" root is the guest's user, 123456 is password, Why can't I login in the guest and run the ifconfig? and run you intend to queue commands to be executed within the qemu guest? && is not suitable for "entering commands", it is a sh/bash control operator (which executes whatever comes after && if the previous command returned true, read "man bash" to learn more about this) furthermore, what you intent to do seems to rely on a linux guest kernel where kernel console (and login shell like agetty) is redirected to ttyS0, so make sure your guests kernel configuration and /etc/inittab are set up properly. but even if you "correctly" pipe commands to your linux guest, i doubt you get the results you want - agetty clears any stdinput before the password prompt etc, so you'd need an "interactive" script to parse stdin and generate stdout (from remote controls script view), for example "expect", see "man expect" and if you expect to interact on the serial console after your "startup commands", you would be lost with classical piping anyway. perhaps screen helps you there? see "man screen" if what you showed in your example is really what you want to to, how about a simple script within the guest executed in the end of the startup process, which shows you the current ifconfig? (see your guests /etc/rc* scripts for that) running sshd in the guest and queing commans via ssh is of course the most stable (and not-qemu-specific) solution, but required correctly set-up networking between guest and qemu. sincerly, martin koniczek ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Qemu 7.2 build: missing libutil.h
When I try to build Qemu 7.2 on OpenBSD 3.7, the file libutil.h is reported as not found. The file is not in /usr/include or /usr/local/include. Libutil.h also is not found in the qemu 7.2 source. Is libutil.h a linux file or part of Qemu 7.2? Thanks, Dave Feustel -- Tired of having to defend against Malware? You know: trojans, viruses, SPYWARE, ADWARE, KEYLOGGERS, rootkits, worms and popups. Then Switch to OpenBSD with a KDE desktop!!! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: timing problems
Hi! I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on an SLES9 (ppc) host. The target clock runs faster(? I've got positive offsets running ntpdate ?) than the host clock. I've tried severel kernel parameters (eg. clock=pit or clock=pmtmr) without any success. The timing problems seem to be not only a problem with Windows XP as guest os. Best regards christoph -- Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: timing problems
>From what I know, you'll just have to put up with it for now. Also, I believe that ntpdate showing positive offsets means that the clock is running slower. Run the date command before the ntpdate one to check what the guest clock is at before the NTP update. On 11/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi! > > I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on > an SLES9 (ppc) host. The target clock runs faster(? I've got positive > offsets running ntpdate ?) than the host clock. I've tried severel kernel > parameters (eg. clock=pit or clock=pmtmr) without any success. > > The timing problems seem to be not only a problem with Windows XP as guest > os. > > Best regards > > christoph > > -- > Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, > DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
Hi!
It turned out that newer gcc produces very interesting code
for op_goto_tbX and possibly other functions used by dyngen;
in that it adds 'rep' prefix to return instruction.
I have the following code in i386-softmmu/op.o:
84c0 :
84c0: 8b 05 00 00 00 00 mov0(%rip),%eax# 84c6
84c6: ff e0 jmpq *%eax
84c8: f3 c3 repz retq
84ca: 66 data16
84cb: 66 data16
84cc: 90 nop
84cd: 66 data16
84ce: 66 data16
84cf: 90 nop
Quite obviously stripping the 'retq' in dyngen won't always
work because 'rep' prefix could interfere with appended code.
I found that trying to run qemu under valgrind, see bug page
http://bugs.kde.org/show_bug.cgi?id=115869 for details.
For example, at the very beginning of qemu booting the pc
the following code is generated:
## ...
## 0x000fe07d: je 0xfe092
##
0x016f75ec: cmpb $0x0,0x2c(%rbp)
0x016f75f0: jne0x16f75f7
0x016f75f2: jmpq 0x16f760f
###the return from call
0x016f75f7: mov-13631729(%rip),%eax# 0x9f750c
0x016f75fd: jmpq *%eax
0x016f75ff: repz mov $0xe07f,%eax
0x016f7605: mov%eax,0x20(%rbp)
0x016f7608: lea-13631814(%rip),%ebx# 0x9f74c8
0x016f760e: retq
###the not zero branch
0x016f760f: mov-13631749(%rip),%eax# 0x9f7510
0x016f7615: jmpq *%eax
0x016f7617: repz mov $0xe092,%eax
0x016f761d: mov%eax,0x20(%rbp)
0x016f7620: lea-13631837(%rip),%ebx# 0x9f74c9
0x016f7626: retq
Notice the 'repz mov' sequence, which seems to be undocumented
instruction. It seems to work somehow but chokes valgrind decoder.
The following patch (against current CVS) fixes this problem,
please apply:
Index: dyngen.c
===
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -r1.40 dyngen.c
--- dyngen.c27 Apr 2005 19:55:58 - 1.40
+++ dyngen.c9 Nov 2005 19:12:38 -
@@ -1387,6 +1387,12 @@
error("empty code for %s", name);
if (p_end[-1] == 0xc3) {
len--;
+/* This can be 'rep ; ret' optimized return sequence,
+ * need to check further and strip the 'rep' prefix
+ */
+if (len != 0 && p_end[-2] == 0xf3) {
+len--;
+}
} else {
error("ret or jmp expected at the end of %s", name);
}
--
Kind regards,
Igor V. Kovalenko
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
> Notice the 'repz mov' sequence, which seems to be undocumented
> instruction. It seems to work somehow but chokes valgrind decoder.
> The following patch (against current CVS) fixes this problem,
This patch is incorrect.
It could match any number of other instructions that happen to end in 0xf3. eg
0: c7 45 00 00 00 00 f3movl $0xf300,0x0(%ebp)
7: c3 ret
IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs. Try
tuning for a different CPU.
Paul
> Index: dyngen.c
> ===
> RCS file: /cvsroot/qemu/qemu/dyngen.c,v
> retrieving revision 1.40
> diff -u -r1.40 dyngen.c
> --- dyngen.c27 Apr 2005 19:55:58 - 1.40
> +++ dyngen.c9 Nov 2005 19:12:38 -
> @@ -1387,6 +1387,12 @@
> error("empty code for %s", name);
> if (p_end[-1] == 0xc3) {
> len--;
> +/* This can be 'rep ; ret' optimized return sequence,
> + * need to check further and strip the 'rep' prefix
> + */
> +if (len != 0 && p_end[-2] == 0xf3) {
> +len--;
> +}
> } else {
> error("ret or jmp expected at the end of %s", name);
> }
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
Paul Brook wrote:
Notice the 'repz mov' sequence, which seems to be undocumented
instruction. It seems to work somehow but chokes valgrind decoder.
The following patch (against current CVS) fixes this problem,
This patch is incorrect.
It could match any number of other instructions that happen to end in 0xf3. eg
0: c7 45 00 00 00 00 f3movl $0xf300,0x0(%ebp)
7: c3 ret
IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs. Try
tuning for a different CPU.
Paul
Index: dyngen.c
===
RCS file: /cvsroot/qemu/qemu/dyngen.c,v
retrieving revision 1.40
diff -u -r1.40 dyngen.c
--- dyngen.c27 Apr 2005 19:55:58 - 1.40
+++ dyngen.c9 Nov 2005 19:12:38 -
@@ -1387,6 +1387,12 @@
error("empty code for %s", name);
if (p_end[-1] == 0xc3) {
len--;
+/* This can be 'rep ; ret' optimized return sequence,
+ * need to check further and strip the 'rep' prefix
+ */
+if (len != 0 && p_end[-2] == 0xf3) {
+len--;
+}
} else {
error("ret or jmp expected at the end of %s", name);
}
OK I missed that...
Then a discussion about gcc-4 turns into something much more interesting :)
--
Kind regards,
Igor V. Kovalenko
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu and software suspend
Hi. Has somebody tried to hibernate Linux while qemu is running? Here is my experience: 1. I was running qemu 0.7.2 fullscreen (under X with SDL), on Linux 2.6.14 host, with Win95 quest. All was fine, together with kqemu. 2. I changed to a virtual console and initiated hibernate (software suspend2 2.2-rc9). Everything latest stuff :) 3. That's when weird things started. The kernel throwed a "BUG", with the usual instruction and stack dump. The offending process was kswapd0. 4. But it successfully hibernated anyway. This was my first kernel complaint at hibernating ever. 5. After resuming the machine later, it seemed to work fine. I switched to qemu, but it was almost dead. Actually, qemu was fine, but the guest OS was almost dead. I could move application windows a bit, click on things to select them, but all this stopped after a while (seconds) and it didn't respond again. But qemu was going along. I could toggle fullscreen and it was taking 100% CPU (which is correct here). The management console worked fine. 6. On the host side, I noticed kswapd0 (kernel swap thread) was killed, but the OS still swapped fine. 7. I couldn't wake win95 so I had to quit qemu. My questions: 1. May there be a problem with the kqemu module? Does it have proper suspend/resume routines? Or it doesn't need them (it is not a device driver)? 2. Can the problem also be inside Win95? What happens in qemu when the time in the host system suddenly changes? Mine skipped 20 hours. Does the time in the quest continue without skips, thus the guest has different time than the host? Before win95 completelly stopped responding, it showed the old time from before the suspending on the taskbar. Or does qemu synchronise the time to the host? But I doubt that, mine was drifting behind even without suspending, the machine is quite slow. I'd like to ask if suspending with qemu is officially declared "A bad thing to do", or it should work, but I have something wrong with my system. I run latest Slackware 10.2 on a Pentium MMX. Peter ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu and software suspend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ace schrieb: > Hi. > > Has somebody tried to hibernate Linux while qemu is running? > Here is my experience: > 1. I was running qemu 0.7.2 fullscreen (under X with SDL), > on Linux 2.6.14 host, with Win95 quest. All was fine, > together with kqemu. > 2. I changed to a virtual console and initiated hibernate > (software suspend2 2.2-rc9). Everything latest stuff :) > 3. That's when weird things started. The kernel throwed > a "BUG", with the usual instruction and stack dump. The > offending process was kswapd0. > 4. But it successfully hibernated anyway. This was my first > kernel complaint at hibernating ever. > 5. After resuming the machine later, it seemed to work fine. > I switched to qemu, but it was almost dead. Actually, qemu > was fine, but the guest OS was almost dead. I could move > application windows a bit, click on things to select them, > but all this stopped after a while (seconds) and it didn't > respond again. But qemu was going along. I could toggle > fullscreen and it was taking 100% CPU (which is correct > here). The management console worked fine. > 6. On the host side, I noticed kswapd0 (kernel swap thread) > was killed, but the OS still swapped fine. > 7. I couldn't wake win95 so I had to quit qemu. > > My questions: > 1. May there be a problem with the kqemu module? Does > it have proper suspend/resume routines? Or it doesn't need > them (it is not a device driver)? Have you already tried to hibernate without haveing kqemu loaded? That could narrow down the problem. > 2. Can the problem also be inside Win95? What happens > in qemu when the time in the host system suddenly changes? > Mine skipped 20 hours. Does the time in the quest continue > without skips, thus the guest has different time than the > host? Before win95 completelly stopped responding, it showed > the old time from before the suspending on the taskbar. > Or does qemu synchronise the time to the host? But I doubt > that, mine was drifting behind even without suspending, the > machine is quite slow. I notice that when I stop emulation (while eg. Win2k is running in qemu) and resume qemu some hours later, the guest clock has paused and is then wrong by some hours. You could try that as well with Win95 and see what happens (you can stop emulation by executing "stop" in the qemu monitor, and resume operation by running "c" in the monitor). > > I'd like to ask if suspending with qemu is officially > declared "A bad thing to do", or it should work, but I have > something wrong with my system. I run latest Slackware 10.2 > on a Pentium MMX. There's been a posting on that topic some weeks ago, with a link to http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html#suspend You could try hibernating with that patch applied. Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDcljyTFOM6DcNJ6cRApZWAJ9fjUC0v/NBRzT7n1Znk2zOayan/wCfRVrh PYHxM7Hz/jkejQ3T4val2zE= =tpza -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] GTK GUI for QEmu
Howdy, I started working last week on a GTK GUI for QEmu. I've made enough progress that I wanted to share the results with everyone and collect feedback--especially any feedback regarding what should be added/changed for inclusion in Fabrice's tree. Here's a rough overview of the features: o XShmImage based display widget--initial performance tests indicate it has identical overhead to the SDL GUI. o GUI-based pause/save/restore/eject o Screenshot (supporting all formats of GdkPixbuf--png, jpg, bmp, etc.) o Video Capture (based on ffmpeg--currently uses mpeg1) o Fullscreen mode with autohiding toolbar (thanks to libview--http://view.sf.net) o Software scaling (so there's no black bars in full screen mode like with SDL) o XEmbed support (a pygtk based POC tabbed GUI is available at http://qemu.codemonkey.ws/qemu-tabbed.py) You can grab a tarball at: http://qemu.codemonkey.ws/tarballs/qemu-gtk-20051109.tar.gz Or you can clone my hg tree with: hg clone http://qemu.codemonkey.ws/hg/gtk A couple screenshots are available at: http://qemu.codemonkey.ws/screenshots/ Any feedback is greatly appreciated. A bunch of stuff is not there yet (there's barely any accelerator support so you can't get to the monitor yet) and I haven't tested on non true color X servers so your results may vary. Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Login a guest use commandline
On Wed, 9 Nov 2005, Martin Koniczek wrote: and if you expect to interact on the serial console after your "startup commands", you would be lost with classical piping anyway. perhaps screen helps you there? see "man screen" expect is the tool in such situations as well.. an expect script can at any time drop into interactive mode. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Changing cdroms while qemu is running
I have read all the qemu documentation that I have, but I still don't understand how to change the cdrom being read by qemu (running in graphics mode). I need to be able to do this to install a multi-cd version of Linux (Scientific Linux - has 4 cdroms). Can someone post the method for doing this? Thanks, Dave Feustel -- Tired of having to defend against Malware? You know: trojans, viruses, SPYWARE, ADWARE, KEYLOGGERS, rootkits, worms and popups. Then Switch to OpenBSD with a KDE desktop!!! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CANCEL Changing cdroms while qemu is running
Cancel this. I read the documentation again and figured it out. -- Tired of having to defend against Malware? You know: trojans, viruses, SPYWARE, ADWARE, KEYLOGGERS, rootkits, worms and popups. Then Switch to OpenBSD with a KDE desktop!!! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Changing cdroms while qemu is running
Actually, I think you missed one doc. http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-b566901cb0207e8c085232c84e354cf97684ddc4 On Wed, Nov 09, 2005 at 06:39:39PM -0500, Dave Feustel wrote: > I have read all the qemu documentation that I have, but I still don't > understand how to change the cdrom being read by qemu (running > in graphics mode). I need to be able to do this to install a multi-cd > version of Linux (Scientific Linux - has 4 cdroms). Can someone post > the method for doing this? > > Thanks, > Dave Feustel > -- > Tired of having to defend against Malware? > You know: trojans, viruses, SPYWARE, ADWARE, > KEYLOGGERS, rootkits, worms and popups. > Then Switch to OpenBSD with a KDE desktop!!! > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Changing cdroms while qemu is running
On Wednesday 09 November 2005 19:18, Jim C. Brown wrote: > Actually, I think you missed one doc. > > http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuestions#head-b566901cb0207e8c085232c84e354cf97684ddc4 Jim, This is outstanding! Thanks!!! Dave Feustel -- Tired of having to defend against Malware? You know: trojans, viruses, SPYWARE, ADWARE, KEYLOGGERS, rootkits, worms and popups. Then Switch to OpenBSD with a KDE desktop!!! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Compile error on Mac OS X 10.3.9 (Panther) - CoreAudio
I'm trying to compile QEMU on Mac OS X 10.3.9, and I'm getting the following error message: gcc -Wall -O2 -g -fno-strict-aliasing -D__powerpc__ -I. -I/Users/stealthdave/Source/qemu/qemu/target-i386 -I/Users/stealthdave/Source/qemu/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/Users/stealthdave/Source/qemu/qemu/fpu -DHAS_AUDIO -I/Users/stealthdave/Source/qemu/qemu/slirp -c -o coreaudio.o /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c: In function `coreaudio_init_out': /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c:378: error: `freq' undeclared (first use in this function) /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c:378: error: (Each undeclared identifier is reported only once /Users/stealthdave/Source/qemu/qemu/audio/coreaudio.c:378: error: for each function it appears in.) make[1]: *** [coreaudio.o] Error 1 make: *** [all] Error 1 I'm running configure with "./configure --prefix=/sw --enable-cocoa", which also enables coreaudio by default with no way to switch it off (that I could find). After an Google search, I found a Core Audio SDK from Apple, but that didn't seem to help any. Any suggestions on what might be wrong? Is this possibly a bug? - Dave ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
The use of gcc to generate the back end in QEMU's early days was a
clever way to get the project up and running quickly. But surely
now it would be better to transition to a handwritten backend, so
as to be independent future changes in gcc, and generally more robust?
J
On Wednesday 09 November 2005 19:51, Igor Kovalenko wrote:
> Paul Brook wrote:
> >> Notice the 'repz mov' sequence, which seems to be undocumented
> >> instruction. It seems to work somehow but chokes valgrind decoder.
> >> The following patch (against current CVS) fixes this problem,
> >
> > This patch is incorrect.
> >
> > It could match any number of other instructions that happen to end in
> > 0xf3. eg
> >
> >0: c7 45 00 00 00 00 f3movl $0xf300,0x0(%ebp)
> >7: c3 ret
> >
> > IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs.
> > Try tuning for a different CPU.
> >
> > Paul
> >
> >> Index: dyngen.c
> >> ===
> >> RCS file: /cvsroot/qemu/qemu/dyngen.c,v
> >> retrieving revision 1.40
> >> diff -u -r1.40 dyngen.c
> >> --- dyngen.c27 Apr 2005 19:55:58 - 1.40
> >> +++ dyngen.c9 Nov 2005 19:12:38 -
> >> @@ -1387,6 +1387,12 @@
> >> error("empty code for %s", name);
> >> if (p_end[-1] == 0xc3) {
> >> len--;
> >> +/* This can be 'rep ; ret' optimized return sequence,
> >> + * need to check further and strip the 'rep' prefix
> >> + */
> >> +if (len != 0 && p_end[-2] == 0xf3) {
> >> +len--;
> >> +}
> >> } else {
> >> error("ret or jmp expected at the end of %s", name);
> >> }
>
> OK I missed that...
> Then a discussion about gcc-4 turns into something much more interesting :)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
> > The use of gcc to generate the back end in QEMU's early days was a > clever way to get the project up and running quickly. But surely > now it would be better to transition to a handwritten backend, so It should be trivial to take the _currently_ generated GCC code for all the architectures QEMU is commonly built on, and just distribute that code with the QEMU source. Then it would be independent of future changes to GCC. I understand a handwritten backend is already being written. But until a proper one is done, wouldn't that serve as a useful stopgap? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
On Thu, Nov 10, 2005 at 01:33:55AM +, Julian Seward wrote:
>
> The use of gcc to generate the back end in QEMU's early days was a
> clever way to get the project up and running quickly. But surely
> now it would be better to transition to a handwritten backend, so
> as to be independent future changes in gcc, and generally more robust?
>
> J
>
Yes, Paul Brook is working on it.
> On Wednesday 09 November 2005 19:51, Igor Kovalenko wrote:
> > Paul Brook wrote:
> > >> Notice the 'repz mov' sequence, which seems to be undocumented
> > >> instruction. It seems to work somehow but chokes valgrind decoder.
> > >> The following patch (against current CVS) fixes this problem,
> > >
> > > This patch is incorrect.
> > >
> > > It could match any number of other instructions that happen to end in
> > > 0xf3. eg
> > >
> > >0: c7 45 00 00 00 00 f3movl $0xf300,0x0(%ebp)
> > >7: c3 ret
> > >
> > > IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs.
> > > Try tuning for a different CPU.
> > >
> > > Paul
> > >
> > >> Index: dyngen.c
> > >> ===
> > >> RCS file: /cvsroot/qemu/qemu/dyngen.c,v
> > >> retrieving revision 1.40
> > >> diff -u -r1.40 dyngen.c
> > >> --- dyngen.c27 Apr 2005 19:55:58 - 1.40
> > >> +++ dyngen.c9 Nov 2005 19:12:38 -
> > >> @@ -1387,6 +1387,12 @@
> > >> error("empty code for %s", name);
> > >> if (p_end[-1] == 0xc3) {
> > >> len--;
> > >> +/* This can be 'rep ; ret' optimized return sequence,
> > >> + * need to check further and strip the 'rep' prefix
> > >> + */
> > >> +if (len != 0 && p_end[-2] == 0xf3) {
> > >> +len--;
> > >> +}
> > >> } else {
> > >> error("ret or jmp expected at the end of %s", name);
> > >> }
> >
> > OK I missed that...
> > Then a discussion about gcc-4 turns into something much more interesting :)
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMWare player
John R. Hogerhuis said: > I understood. I just don't believe it; I didn't get the impression Stefano was saying that he had actually tried it. AFAIK, VMware Player writes changes to the hard disk image. I was able to successfully take my qemu installation of Windows XP, convert it with qemu-img to a vmdk file, and then boot it up in VMWare player (and yes, I own the full version of VMWare as well on another machine, so I'm not worried about the legality if there are any concerns). I was also able to create a vmdk image from scratch using qemu-img and install OpenBSD in it. As I've only owned the full version for about two weeks, I haven't researched what VMWare tools adds to the picture, but I know resolution hasn't been a problem with VMWare Player, at least on the XP image. Performance does seem a bit better than qemu, but I done anything to quantify this. I'm running on the latest version of Ubuntu. John ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMWare player
On 11/9/05, John Wells <[EMAIL PROTECTED]> wrote: > I was able to successfully take my qemu installation of Windows XP, > convert it with qemu-img to a vmdk file, and then boot it up in VMWare > player (and yes, I own the full version of VMWare as well on another > machine, so I'm not worried about the legality if there are any concerns). VMware Workstation 5.5 Beta also carries the VMware Player, yes even before the Player became official. ;) -- Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)
On Thu, Nov 10, 2005 at 01:44:04AM +, Jamie Lokier wrote: > > > > The use of gcc to generate the back end in QEMU's early days was a > > clever way to get the project up and running quickly. But surely > > now it would be better to transition to a handwritten backend, so > > It should be trivial to take the _currently_ generated GCC code for > all the architectures QEMU is commonly built on, and just distribute > that code with the QEMU source. > You mean convert the code with gcc 3 into asm, and then distribute that? I'm no expert, but I would imagine such a solution would be quite brittle. That's assuming one can make gcc 3 assembly code work with gcc 4 (5?) code to form a single object file. > Then it would be independent of future changes to GCC. Well, someone would still need to maintain all those assembly files. Or else keep an old copy of gcc 3 around to regenerate them whenever needed. > > I understand a handwritten backend is already being written. But > until a proper one is done, wouldn't that serve as a useful stopgap? > I believe the current version works - but it doesn't implement every possible op yet. For now, it relies on dyngen to produce the missing ops (until they are replaced with the hand coded version). > -- Jamie > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMWare player
Regarding performances of vmware player vs kqemu/qemu (I'm not being critical about the figures here, just stating what I measured)... using a slax-live cdrom, I managed to compile linux-2.6.14 in less than 3 minutes, when it takes more than 6 minutes with kqemu/qemu-0.7.2, and around 20 minutes without kqemu. The test was made using vmdk image format. But vmware player setup file is over 25Mb compressed, when kqemu/qemu is less than 2Mb uncompressed :) Christian On 11/10/05, John Wells wrote: > Performance does seem a bit better than qemu, but I done anything to > quantify this. I'm running on the latest version of Ubuntu. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Changing cdroms while qemu is running
Dave Feustel wrote: > I have read all the qemu documentation that I have, but I still don't > understand how to change the cdrom being read by qemu (running > in graphics mode). I need to be able to do this to install a multi-cd > version of Linux (Scientific Linux - has 4 cdroms). Can someone post > the method for doing this? I did a small patch to deal with this situation. But I didn't take the time to make something smart. Furthermore it only works for Linux hosts. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
