Re: [Qemu-devel] ATA timeouts on Solaris/OpenIndiana/Opensolaris
On Wed, Apr 2, 2014 at 11:51 AM, Andreas Färber afaer...@suse.de wrote: Hi, Am 02.04.2014 09:32, schrieb Sai Prajeeth: I am booting an OpenIndiana image on qemu by using the -smp 4 option. I seem to be running into this known bug http://docs.oracle.com/cd/E19253-01/820-5245/ggmsj/index.html Can someone tell me how can i go about doing workaround 2 on qemu?? Here's my script for running OpenIndiana using AHCI (SATA): qemu-system-x86_64 -enable-kvm -smp cores=1,threads=1,sockets=1 -m 2G \ -netdev user -device e1000,macaddr=... \ -device ahci,id=ahci \ -device ide-drive,bus=ahci.0,drive=ahcihd \ -drive file=/.../openindiana-151a.img,format=raw,if=none,id=ahcihd \ Note that live migration doesn't work with AHCI ATM. If you could start qemu with both ata and ahci, add a new lun to the ahci controller, and use beadm to migrate to the achi disk, then disconnect the ata disk/controller and bump the cores back to 4. I think that workaround 1 is not technically correct. however, you'd need a really good understanding of Solaris/opensolaris/OI to force the system to reenumerate the device path from a failsafe boot. But this is not for the faint of heart. If it's a new install (ie, not much customization/data), why not just start a new QEMU instance that uses the ahci controller? Ben Ben
Re: [Qemu-devel] building qemu on Oracle Solaris 11 x64
Solaris can be a bit tricky since it supports 32 and 64-bit applications. Oracle Solaris 11 disabled 32-bit boot but still supports 32-bit applications. Are the rest of the libraries in the generated Makefile 32-bit or 64-bit? On Solaris, it's fairly easy to tell since the 64-bit libraries are /lib/64 (or various links to 64 such as amd64 - 64 or sparcv9 - 64). 2012/1/31 Günther Schmidt gue.schm...@web.de: Hi everyone, I'm trying to build qemu on Oracle Solars 11 x64. I've figure out that I need to set the --disable-guest-agent for ./configure, but there are other errors I do not know how to fix. Setting LD_LIBRARY_PATH to /usr/lib/mps/amd64 helps but at least one error still remains: ld: fatal: file cac.o: wrong ELF class: ELFCLASS64 ld: fatal: file processing errors. No output written to vscclient collect2: ld returned 1 exit status Has anyone here successfully build qemu on Oracle Solaris 11 x64? Günther
[Qemu-devel] arm (omap2430) support in qemu?
I picked up a omap2430 prototype board, and am looking to start working with this. Since this is a foray back into development for me, I'm a little overwhelmed by the amount of information I'm trying to digest in starting this project (and the user forum at qemu-forum.ipi.fi being down is a bit depressing). Basically, I have a uboot image, a kernel and a rootfs that I can work with, though I'm suspecting the fstab may need a little tweaking to support the image. Anyone know if I'm expecting too much of qemu, or has some suggestions on how I can go about setting this up. I plan on documenting this journey since the couple of weeks I've spent researching this hasn't really found a definitive guide into do what I want to do. I can take conversations offline to minimize the noise quotient to the list. Thanks, Ben
Re: [Qemu-devel] Re: qemu without an X?
On Sun, Jan 31, 2010 at 1:56 PM, jonatan perry jonata...@gmail.com wrote: Hi Mulyadi! Regarding my first qeustion: no, I don't want remote access to the machine, I want local access, something like starting a linux os, and launch from shell qemu so he will run a graphic operation system, like windows. I want my emulator to run the virtual machine opcodes natively on my cpu, I don't want to emulate ALL my virtual machine opcode, my goal is to get more faster and stable virtual machine. QEMU doesn't do HW emulation then output to your local graphics device. You have to use some sort of display, whether it be vnc, or X if you're talking about some sort of GUI on the client.
Re: [Qemu-devel] [PATCH 1/3] Check for sdl-config before calling it
On Wed, Jan 27, 2010 at 7:10 AM, Loïc Minier l...@dooz.org wrote: Check whether sdl-config is available before calling it, otherwise ./configure triggers a warning: ./configure: 957: sdl-config: not found If neither the .pc file not sdl-config are present, disable SDL support. Signed-off-by: Loïc Minier l...@dooz.org --- configure | 7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 1f6de41..27ab724 100755 --- a/configure +++ b/configure @@ -997,9 +997,14 @@ fi if $pkgconfig sdl --modversion /dev/null 21; then sdlconfig=$pkgconfig sdl _sdlversion=`$sdlconfig --modversion 2/dev/null | sed 's/[^0-9]//g'` -else +elif which sdl-config /dev/null 21; then sdlconfig='sdl-config' _sdlversion=`$sdlconfig --version | sed 's/[^0-9]//g'` +else + if test $sdl = yes ; then + feature_not_found sdl + fi + sdl=no fi sdl_too_old=no Glad to see someone working on Solaris. Wondering why you're using the which command, when you just created a has function in the other patch segments, and just replaced all the other instances of which.
Re: [Qemu-devel] CVS build error
On Thu, Mar 13, 2008 at 4:47 PM, Paul Brook [EMAIL PROTECTED] wrote: gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) Which part of gcc 4.x is not supported didn't you understand? Paul Apparently, we should make configure fail horribly if gcc4 is found even if disable-gcc-check is enabled.
[Qemu-devel] kqemu subversion
I have been maintaining a subversion repository for kqemu for the last 8-9 months due to the large amount of changes required for the Solaris port of kqemu However, due to some life issues, I'm not sure I have managed to get all the patches for kqemu into the repository. The current trunk for the code I have is at http://svn9.cvsdude.com/kdesolaris/kqemu/trunk/1.0.3pre11 If anyone wants to test it out the code in there, and there's a patch I'm missing, let me know. Thanks, Ben Taylor
Re: [Qemu-devel] [PATCH] bdrv_flush error handling
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functions). All of the
implementations and callers are adjusted too.
While looking at this I was surprised to see this:
static void scsi_write_complete(void * opaque, int ret)
...
if (ret) {
fprintf(stderr, scsi-disc: IO write error\n);
exit(1);
}
Surely that is overkill ?
Yes, any i/o errors I'd expect to be propagated back up to the guest
OS as the most appropriate IDE / SCSI error code.
Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
error (the return value from write) whereas the other block read/write
methods return errno values. This is a mistake, surely ? -1 would be
-EPERM. If any of the callers did anything with these return values
you'd get incorrect error indications.
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, then fine, but please don't
spew log messages to the monitor console, because that'll make it
very hard to interact with reliably from management tools.
Would it make sense to have a log messages screen associated with
the monitor (like Ctrl-Alt-7) to deal with those sorts of things?
Ben
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
Andrew Warkentin [EMAIL PROTECTED] wrote: Sergey Bychkov wrote: - Original Message - From: Ralf Baerwaldt [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 19.02.2008 18:09 Subject: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz and I'm using an AMD Opteron. Is this version the correct one for my system ? If You want qemu for your amd64 linux system, You should compile it yourself or install from Your linux distribution repository. This site (http://fabrice.bellard.free.fr/qemu/download.html) doesn't contain precompiled linux binaries except for i386 platform. However You could execute i386 binaries on amd64 linux platform. :) Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55 Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues). Solaris is moving more towards 64-bit for 64-bit systems. The X11 tree (and other subsystems as well) are getting 64-bit versions of binaries and libraries.
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Warner Losh [EMAIL PROTECTED] wrote: From: Andreas Färber [EMAIL PROTECTED] Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x Date: Tue, 5 Feb 2008 13:58:28 +0100 Am 05.02.2008 um 12:30 schrieb Ian Jackson: I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be better for qemu's default range to be a randomly chosen one. Please don't randomly choose a default subnet; knowing that QEMU uses 10.0.2.x allows to adapt to this. If however QEMU starts randomly assigning addresses we will also get random conflicts. Please stick with a default like the current and simply make it statically configurable. I think that the suggestion is that qemu picks, one time, a new default. This new default would be selected at random, and would be the same on all new versions of qemu. I don't think that the suggestion is to pick a random address every time qemu starts. It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. For the most part, it doesn't make any difference to the host because you don't use the 10.0.2.x address from the host, and only the guest is affected IFF running DHCP. Ben
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Asheesh Laroia [EMAIL PROTECTED] wrote: On Tue, 5 Feb 2008, Ben Taylor wrote: It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). That's right - that's the issue that I faced. I've run into that before too.. I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. I would go one step further: Make the default *always* 10.0.2.x, It is. but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. Eventually the guest gets a local network that won't conflict with the user's network infrastructure. Obviously, if you have a 10.0.x.x, a 172.16.x.x and a 192.168.x.x network, having a configurable guest network is probably loads simpler. Ben
[Qemu-devel] hw/e1000.c patch for Solaris
Solaris has boolean_t defined, so this #ifndef allows hw/e1000.c to compile on Solaris. Ben --- qemu.ORIG/hw/e1000.c2008-02-02 21:20:18.0 -0500 +++ qemu/hw/e1000.c 2008-02-04 10:39:33.097052000 -0500 @@ -28,7 +28,9 @@ #include net.h #define __iomem +#ifndef __sun__ typedef int boolean_t; +#endif #include e1000_hw.h #define DEBUG
Re: [Qemu-devel] Configuring qemu on Solaris
Juergen Keil [EMAIL PROTECTED] wrote:
Andreas Färber [EMAIL PROTECTED] wrote:
The following part of configure is triggered on a fully-updated
Solaris 10 8/07 amd64:
#
# Solaris specific configure tool chain decisions
#
if test $solaris = yes ; then
#
# gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu
correctly
# override the check with --disable-gcc-check
#
if test $solarisrev -eq 10 -a $check_gcc = yes ; then
solgcc=`which $cc`
if test $solgcc = /usr/sfw/bin/gcc ; then
echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu
correctly.
echo please get gcc-3.4.3 or later, from www.blastwave.org
using pkg-get -i gcc3
echo or get the latest patch from SunSolve for gcc
exit 1
fi
fi
Depending on the path of gcc, configure bails out. The text appears to
indicate that the latest patch [...] for gcc, whichever that may be,
fixes some compilation issue.
Since the script does not try to detect the presence of such a patch,
can we remove the exit and keep the text as a warning only?
Or can someone comment on what the corresponding Solaris patch id or
gcc version is in order to make this conditional? The system gcc
version is 3.4.3 here and it appears to compile fine.
IIRC, problem was a code generation issue with the specific version of
gcc 3.4.3 (includes some patches from Sun; /usr/sfw/bin/gcc) that is
included with Solaris 10 x86. qemu would compile just fine (32-bit x86
binary), but would crash at run time.
The problematic version of gcc refused to eliminate the frame pointer
for a function like this:
==
#include setjmp.h
jmp_buf env;
void
func(void)
{
longjmp(env, 1);
}
==
% /usr/sfw/bin/gcc -O2 -fomit-frame-pointer -S xx.c
% cat xx.s
.file xx.c
.text
.p2align 2,,3
.globl func
.type func, @function
func:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
pushl $1
pushl $env
calllongjmp
.size func, .-func
.comm env,40,32
.ident GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
==
I'm not sure if there is actually a patch id that we could check for
in showrev -p output.
But maybe the configure script could look at gcc --version output;
I guess if it finds (csl-sol210-3_4-branch+sol_rpath), configure should
complain.
Current opensolaris comes with gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802),
and this version eliminates the frame pointer in the above sample code,
and is able to compile a working qemu 32-bit x86 binary.
I'll look at writing the code to handle this. I will need someone to
test for me since I'm on S10U4 and Solaris Express B80...
Re: [Qemu-devel] Configuring qemu on Solaris
Andreas Färber [EMAIL PROTECTED] wrote: Hi, The following part of configure is triggered on a fully-updated Solaris 10 8/07 amd64: # # Solaris specific configure tool chain decisions # if test $solaris = yes ; then # # gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu correctly # override the check with --disable-gcc-check # if test $solarisrev -eq 10 -a $check_gcc = yes ; then solgcc=`which $cc` if test $solgcc = /usr/sfw/bin/gcc ; then echo Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu correctly. echo please get gcc-3.4.3 or later, from www.blastwave.org using pkg-get -i gcc3 echo or get the latest patch from SunSolve for gcc exit 1 fi fi Depending on the path of gcc, configure bails out. The text appears to indicate that the latest patch [...] for gcc, whichever that may be, fixes some compilation issue. Early in Solaris 10 (perhaps pre-FCS, I don't recall it's been so long), /usr/sfw/bin/gcc on Solaris would not properly compile QEMU. The problem either was silently fixed (though I doubt that since I can't find any reference to a fix), or something in the QEMU source that was causing the error stopped causing the error. Since the script does not try to detect the presence of such a patch, can we remove the exit and keep the text as a warning only? I'd be ok with that. I'll submit another patch with an updated README for Solaris, since there are multiple issues around the gcc's available for Solaris (sfw, blastwave, sunfreeware) Or can someone comment on what the corresponding Solaris patch id or gcc version is in order to make this conditional? The system gcc version is 3.4.3 here and it appears to compile fine. Let's take out the exit. I would prefer to make Solaris depend on /usr/sfw/bin/gcc since blastwave can only compile 32-bit (and not 64-bit because that wasn't enabled), and sunfreeware can't even compile it (I think it's configured to use Solaris as, and not gas). Ben Andreas
Re: [Qemu-devel] qemu-forum.ipi.fi down?
Pablo Virolainen [EMAIL PROTECTED] wrote: Robert Nestor wrote: It seems qemu-forum.ipi.fi is down. Is there an alternate place one can obtain source snapshots or browse the user forums? It should be back online once again (and it has been almost all the time). The reason you haven't been able to reach it was my mistake. When the server moved, ip-addr wasn't updated to dns. I just edited my /etc/hosts to include line 80.64.9.36 qemu-forum.ipi.fi and forget the issue. dns-record is now updated Looks good from this side of the atlantic. Thank you. Ben
Re: [Qemu-devel] qemu-forum.ipi.fi down?
Robert Nestor [EMAIL PROTECTED] wrote: It seems qemu-forum.ipi.fi is down. Is there an alternate place one can obtain source snapshots or browse the user forums? I mentioned something to Pablo, and he said he could see it from where he was, but he suspected there's some DNS problem that needs resolving. Give it a few days, as it sounded like he was out of town. Ben
Re: [Qemu-devel] i386 debug exception should set BS of DR6 when single-stepping
Vegard Nossum [EMAIL PROTECTED] wrote: Hi, I experience the following problem: Setting the trap flag (TF) of the EFLAGS register correctly calls the debug exception DE. However, the DR6 register does not have the single step (BS) flag set. I remember this getting submitted. which version of Qemu are you running? 0.9.0 or 0.9.0-cvs? This patch fixes things for me, and I think it deserves some more attention given that it had no replies at that time and it's not in the latest release. http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00126.html This patch was added to CVS on June 26, 07 Ben
[Qemu-devel] Patch: Fix Win98SE MyComputer regression
After some testing, I've made a minor fix to the Rev 1.66 patch of hw/ide.c. With this patch, and the current CVS tree, I'm once again able to see the devices after clicking on MyComputer in my Win98SE guest. Ben --- qemu.ORIG/hw/ide.c 2007-11-08 11:38:17.0 -0500 +++ qemu/hw/ide.c 2007-11-16 17:02:22.579592000 -0500 @@ -1353,7 +1353,7 @@ buf[8] = 0x2a; buf[9] = 0x12; -buf[10] = 0x08; +buf[10] = 0x00; buf[11] = 0x00; buf[12] = 0x70;
Re: [Qemu-devel] qemu/winME/98
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is it possible to get networking to work with ME/98 as guest ? No network device shows up in this case as in XP which works fine. Command I use; qemu -hda Win98.img -net nic,model=rtl8139 -net user maybe because you have to download the rtl8139 driver from realtek for Win98. Had to do the same thing for Win98SE. Since there's no networking you can use vvfat or a floppy image to let the win98 instance see the file. Ben
[Qemu-devel] win98se guest regression
I have a couple of win98se guests that I keep around for testing and upgrade tests and the like. The current CVS code has no problem booting these images, but the first time I do anything (like read the cdrom, or change directories in windows explorer), the guest just hangs. This seems like a regression. This happens on both iso images and real cdrom's. I realize that Win98 is a bit old at this point, but it's so lightweight compared to Win2K and WinXP, and it's been a good test for several years. Anyone have an idea or seen this behavior? Thanks, Ben
Re: [Qemu-devel] win98se guest regression
Ben Taylor [EMAIL PROTECTED] wrote: I have a couple of win98se guests that I keep around for testing and upgrade tests and the like. The current CVS code has no problem booting these images, but the first time I do anything (like read the cdrom, or change directories in windows explorer), the guest just hangs. This seems like a regression. This happens on both iso images and real cdrom's. I have tracked down the regression to ide.c V1.66. I have a build from 9/16/07, and replaced V1.64, V1.65 and V1.66 of ide.c only in this build. After building all three versions, the last vesion with ide.c V.166 causes Win98SE when I click on MyComputer to hang, and can only be killed by using the process manager. Previous instances of ide.c compiled, and the explorer brings up all the devices. Filip - you have any ideas on this? Thanks, Ben
[Qemu-devel] error compiling hw/sh7750.c
I'm getting this error compiling hw/sh7750.c I believe the problem comes from the include in hw/sh_intc.h with the macro #define _INTC_ARRAY(a) a, sizeof(a)/sizeof(*a) in line 587 of hw/7750.c, I see sh_intc_register_sources(s-intc, _INTC_ARRAY(vectors_irlm), _INTC_ARRAY(NULL)); So the macro turns the last _INTC_ARRAY(NULL) into NULL, sizeof(NULL)/sizeof(*NULL) Since sizeof(*NULL) doesn't make any sense, the compiler barfs on Solaris 10/x86_64. gcc -Wall -O2 -g -fno-strict-aliasing -m64 -I. -I.. -I/export-1/bent/src/qemu/07/qemu/target-sh4 -I/export-1/bent/src/qemu/07/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/export-1/bent/src/qemu/07/qemu/fpu -I/usr/gnu/include -I/export-1/bent/src/qemu/07/qemu/slirp -m64 -c -o sh7750.o /export-1/bent/src/qemu/07/qemu/hw/sh7750.c /export-1/bent/src/qemu/07/qemu/hw/sh7750.c: In function `error_access': /export-1/bent/src/qemu/07/qemu/hw/sh7750.c:184: warning: unsigned int format, different type arg (arg 5) /export-1/bent/src/qemu/07/qemu/hw/sh7750.c: In function `ignore_access': /export-1/bent/src/qemu/07/qemu/hw/sh7750.c:190: warning: unsigned int format, different type arg (arg 5) /export-1/bent/src/qemu/07/qemu/hw/sh7750.c: In function `sh7750_init': /export-1/bent/src/qemu/07/qemu/hw/sh7750.c:576: error: invalid type argument of `unary *' /export-1/bent/src/qemu/07/qemu/hw/sh7750.c:589: error: invalid type argument of `unary *' gmake[1]: *** [sh7750.o] Error 1 gmake[1]: Leaving directory `/export-1/bent/src/qemu/07/qemu/sh4-softmmu' gmake: *** [subdir-sh4-softmmu] Error 2 In this case, I've replaced _INTC_ARRAY(NULL) with NULL, NULL and it succesfully compiles, but I don't have any sh emulation to do. Ben
[Qemu-devel] Updated Solaris x86_64 patches
Enclosed is an updated set of patches for configure, Makefile and
Makefile.target.
the configure and Makefile.target fixes are for compiling qemu on Solaris x86-64
the Makefile patch is for qemu-img when it compiles it on a system
that does not have gnutls in a standard place.
Questions?
Ben--- qemu.ORIG/Makefile 2007-11-07 14:24:01.0 -0500
+++ qemu/Makefile 2007-11-09 23:32:03.122054000 -0500
@@ -94,7 +94,7 @@
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h d3des.c d3des.h
- $(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $
+ $(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(CONFIG_VNC_TLS_CFLAGS) -c -o $@ $
audio/sdlaudio.o: audio/sdlaudio.c
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
--- qemu.ORIG/Makefile.target 2007-11-08 09:25:01.0 -0500
+++ qemu/Makefile.target 2007-11-09 23:15:12.637363000 -0500
@@ -140,7 +140,11 @@
endif
ifeq ($(ARCH),x86_64)
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ ifeq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAG+=-m64
+ else
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifeq ($(ARCH),ppc)
@@ -555,6 +559,13 @@
endif
endif
+ifeq ($(ARCH),x86_64)
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
+endif
+
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
endif
--- qemu.ORIG/configure 2007-11-08 13:05:36.0 -0500
+++ qemu/configure 2007-11-09 23:14:57.708052000 -0500
@@ -346,6 +346,7 @@
if [ $solaris = yes -a $cpu = x86_64 ] ; then
CFLAGS=${CFLAGS} -m64
OS_CFLAGS=${OS_CFLAGS} -m64
+OS_LDFLAGS=${OS_LDFLAGS} -m64
fi
if [ $solaris = yes -a $cpu = i386 ] ; then
@@ -580,7 +581,7 @@
#undef main /* We don't want SDL to override our main() */
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -599,7 +600,7 @@
sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
sdl_static=yes
fi
fi # static link
Re: [Qemu-devel] Unable to Run Gprof Successfully on QEMU
Atoosaah S [EMAIL PROTECTED] wrote: How do I enable debugging? I checked the configure file and I do not see any options for compiling with debugging, i.e. there is no --enable-debug option. I see that the default parameters section of the configure file sets: gdbstub=yes but other than that i do not see any other reference to debugging. Also, I am working with qemu source code, which I configure, make, make install before every run. then run the binary from the source tree, as it is not stripped. As part of make install, the binaries are stripped. HTH Thank you again. On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote: On Fri, 2007-10-12 at 01:00 -0700, Atoosaah S wrote: I'd appreciate any input on how to run gprof successfully on qemu. I'm new to gprof and am probably missing some steps. I successfully ran gprof on a sorting program available online, then I attempted to run gprof on qemu. Here are the steps I take: I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, my qemu version is 0.8.2. I configure qemu with the options configure --prefix=/install_path --enable-gprof. Then I make and make install. I run qemu successfully using the options /install_path/qemu -hda diskimage.img -m 256 which results in the gmon.out file. My run of qemu involved starting the image (virtual linux OS), running a few simple commands and shutting the image down. Finally, I run gprof /intsall_path/qemu gmon.out result.txt which gives the error: gprof: file 'qemu' has no symbols' Are there any other configuration options required? Should the image be run with differently? You need a qemu executable with debugging symbols. Distributed versions are usually stripped, which means the debug symbols are not present anymore. A way to get the debug symbol is to fetch the source and recompile it... -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] Two small Solaris x86-64 patches
Included are two small patches for configure and Makefile.target to
allow QEMU to configure and build correctly on a Solaris x86-64 platform.
Ben--- qemu.ORIG/configure 2007-09-29 21:58:31.0 -0400
+++ qemu/configure 2007-10-04 12:52:30.776801000 -0400
@@ -575,7 +575,7 @@
#undef main /* We don't want SDL to override our main() */
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-$$-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -594,7 +594,7 @@
sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
sdl_static=yes
fi
fi # static link
--- qemu.ORIG/Makefile.target 2007-09-29 21:58:31.0 -0400
+++ qemu/Makefile.target2007-10-04 12:56:59.655018000 -0400
@@ -129,7 +129,11 @@
endif
ifeq ($(ARCH),x86_64)
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ ifeq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAG+=-m64
+ else
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifeq ($(ARCH),ppc)
@@ -544,6 +548,13 @@
endif
endif
+ifeq ($(ARCH),x86_64)
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
+endif
+
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
endif
Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
J. Mayer [EMAIL PROTECTED] wrote: On Mon, 2007-09-17 at 23:14 +0200, Luca wrote: On 9/17/07, Andreas Färber [EMAIL PROTECTED] wrote: Am 17.09.2007 um 14:18 schrieb Christian MICHON: On 9/17/07, Philip Boulain [EMAIL PROTECTED] wrote: DON'T DO THIS KIND OF COMMIT AGAIN, PLEASE. if we were using git (but you can do it locally anyway), you would not have these conflicts problems... Maybe... but Savannah uses a CVS frontend, as far as I know... Those are excuses. So is a you should have used X argument. It doesn't invalidate the point that the commit was disruptive, and merely acts as bait for the grand old version repository flamewar.* since I mentionned you should have used Git, I'll repeat: this commit was not disruptive to any of the Git users, and will never be. Evolve, or prepare to be assimilated into the Collective... Both the qemu.org and the Savannah project page only mention CVS. If there are better ways to get the code then inform your users how to use that. http://brick.kernel.dk/git/?p=qemu.git;a=summary It's tracking QEMU CVS; you're right that it's not mentioned anywhere on the site (AFAICS). You can also DIY with git-cvsimport; see e.g. http://chneukirchen.org/blog/archive/2006/04/tracking-the-ruby-cvs-with-git.html Another point is CVS is an industry standard. It has many drawbacks but is prooven to do its job as specified in a very reliable way. For now, not such a thing for git, afaik. If it ever become the new industry standard, after having prooven its reliability and long term stability, then you may be able to expect everyone to use it. Did anyone has done a long term comparison of CVS and git running on two copies of the same production repository and have made sure that any extraction at any time of any data (ie, checkout in the present and any date in the past, diffs, ...) of the two gives exactly the same result ? Please show me such studies and I may reconsider my position... If not, you can always use it, closing your eyes and praying for everything to be OK... The wine folks have been using it for a while, (maybe a year?), and they are prolithic committers. I see approximately 20-30 patches a day, monday-friday.
Re: [Qemu-devel] Comment for Solaris fix for the HPTC
Johannes Schindelin [EMAIL PROTECTED] wrote: Hi Ben, On Sat, 15 Sep 2007, Ben Taylor wrote: +#ifdef __sun__ +/* Have to define this for Solaris as ULONG_LONG_MAX is not defined + anywhere. ULONG_MAX is correct only on _LP64 systems */ +#define ULONG_LONG_MAX 18446744073709551615UL +#endif + These constants are always defined, right? So why not #ifndef ULONG_LONG_MAX? I fear I may not have explained this well. On the Solaris systems I have access to, I find no system include file that defines ULONG_LONG_MAX. There are defines for ULONG_MAX which is equivilent to the value that ULONG_LONG_MAX is, but only when the system is being compiled on an _LP64 (ie x86_64) system. When the system is 32-bit, ULONG_MAX defaults to a typical max value for a 32-bit unsigned int. That help? Ben
[Qemu-devel] Solaris x86_64 configure patch
By default, uname -i returns i86pc on i386 or x86_64 system. This patch makes
it possible to for Solaris systems to get the right hardware type.
--- qemu.ORIG/configure 2007-08-24 21:37:51.0 -0400
+++ qemu/configure 2007-09-15 08:53:34.288345000 -0400
@@ -155,6 +155,12 @@
install=ginstall
needs_libsunmath=no
solarisrev=`uname -r | cut -f2 -d.`
+# have to select again, because `uname -m` returns i86pc
+# even on an x86_64 box.
+solariscpu=`isainfo -k`
+if test ${solariscpu} = amd64 ; then
+cpu=x86_64
+fi
if [ $cpu = i386 -o $cpu = x86_64 ] ; then
if test $solarisrev -le 9 ; then
if test -f /opt/SUNWspro/prod/lib/libsunmath.so.1; then
[Qemu-devel] configure white space cleanup
just cleaning up some annoying at the end of some lines --- qemu/configure.ORIG 2007-09-15 08:58:23.283818000 -0400 +++ qemu/configure 2007-09-15 08:58:34.878425000 -0400 @@ -409,7 +409,7 @@ oss=no fi -# Check for gcc4, error if pre-gcc4 +# Check for gcc4, error if pre-gcc4 if test $check_gcc = yes ; then cat $TMPC EOF #if __GNUC__ 4 @@ -450,7 +450,7 @@ # # gcc for solaris 10/fcs in /usr/sfw/bin doesn't compile qemu correctly # override the check with --disable-gcc-check - # + # if test $solarisrev -eq 10 -a $check_gcc = yes ; then solgcc=`which $cc` if test $solgcc = /usr/sfw/bin/gcc ; then @@ -481,7 +481,7 @@ fi exit 1 fi -fi +fi if test -z $target_list ; then
Re: [Qemu-devel] Solaris x86_64 configure patch
Corrected version of the patch.
--- qemu.ORIG/configure 2007-08-24 21:37:51.0 -0400
+++ qemu/configure 2007-09-15 09:07:47.928893000 -0400
@@ -155,6 +155,12 @@
install=ginstall
needs_libsunmath=no
solarisrev=`uname -r | cut -f2 -d.`
+# have to select again, because `uname -m` returns i86pc
+# even on an x86_64 box.
+solariscpu=`isainfo -k`
+if test ${solariscpu} = amd64 ; then
+cpu=x86_64
+fi
if [ $cpu = i386 -o $cpu = x86_64 ] ; then
if test $solarisrev -le 9 ; then
if test -f /opt/SUNWspro/prod/lib/libsunmath.so.1; then
@@ -333,6 +339,16 @@
;;
esac
+if [ $solaris = yes -a $cpu = x86_64 ] ; then
+CFLAGS=${CFLAGS} -m64
+OS_CFLAGS=${OS_CFLAGS} -m64
+fi
+
+if [ $solaris = yes -a $cpu = i386 ] ; then
+CFLAGS=${CFLAGS} -m32
+OS_CFLAGS=${OS_CFLAGS} -m32
+fi
+
if test x$show_help = xyes ; then
cat EOF
[Qemu-devel] Comment for Solaris fix for the HPTC
Compiling the latest CVS code, I found that a function in vl.c uses a define called ULONG_LONG_MAX. The value is defined in solaris's sys/types.h, but only on _LP64 builds, so 32-bit builds won't pickup if I redefine it as ULONG_MAX. I'm looking for comments on this patch. --- qemu.ORIG/vl.h 2007-08-26 13:46:00.0 -0400 +++ qemu/vl.h 2007-09-15 17:59:24.179299000 -0400 @@ -49,6 +49,12 @@ #define ENOMEDIUM ENODEV #endif +#ifdef __sun__ +/* Have to define this for Solaris as ULONG_LONG_MAX is not defined + anywhere. ULONG_MAX is correct only on _LP64 systems */ +#define ULONG_LONG_MAX 18446744073709551615UL +#endif + #ifdef _WIN32 #include windows.h #define fsync _commit
Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Jorge Lucángeli Obes [EMAIL PROTECTED] wrote: I've been giving some thought to Anthony's idea: http://kvm.qumranet.com/kvmwiki/Specs/StoringCommandLineInImage However, maybe I'm just too much on vacations, but I don't seem to come up with a nice way of doing this. Everything keeps coming back to creating a new 'container' image format and then implementing block layer functions that only add the number of sectors occupied by the command-line to the read and write calls made by QEMU, and then just relay those calls to the image-specific functions. That doesn't sound very efficient. No, and it fundamentally breaks using a real disk with QEMU. The '#!' trick works nice with scripts, but I don't see it playing very well with images. ¿Comments? ¿Pointers? Personally, I'm not sure why we wouldn't just write out the command line data to a file tied to the primary image file, with some kind of time stamp to correlate the data from the command line and the last updated time of the primary image file. It's intuitive, and doesn't require a bucket of programming to make work. The down side is if qemu crashes, the time stamp between the parameter file and the image file may indicate the potential for difference, but this can just be a notice (just as snapshots used to do with the image files in 0.7.x) The only hard part here is when a real physical disk is used with QEMU since it's harder to make sure the name is valid. Thoughts? Ben
Re: [Qemu-devel] Solaris 10 dies during install
Alexey Eremenko [EMAIL PROTECTED] wrote: Some news about Solaris on Qemu: My Solaris is v2005, x86-64 + x86 on the same DVD. I installed the x86-64 version. Ugh. don't bother with that version. Download S10 U3 (11/06) or S10 U4 (07/07) [if it's been released yet] Host: Fedora 7, 64-bit, Qemu CVS 2007-07-12, Intel Xeon. Now the situation is better, Solaris dies after the install, not during the install. Screenshot of problem: (link will expire soon) http://www.yousendit.com/download/OGhkMFhqQzdYSHcwTVE9PQ odd message. Again, I think you are better served by running a version of Solaris that isn't stone age (at this point). So I did: 1. upgraded Qemu from 0.9 to CVS. I didn't: 1. Solaris U3 (I wanted the original Solaris to run, but I may try this version as well) 2. The instructions at opensolaris website cannot be used with Solaris 10 2005 release. They are specific to GRUB. This ver of Solaris uses some other bootloader. Which one? The bootloader for Solaris 10 you are running is called device configuration assistant. Please try a more current version with grub. Ben
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
[Qemu-devel] Patches
There are two patches included in the mail
1) qemu-sdl-error.diff - patch to capture output from the sdl compile test, and
output it if there
is an error at reporting time (and delete the file when finished)
2) qemu-sdl-whitespace.diff - patch to fix the indentation for the sdl-config
section
Ben--- qemu/configure 2007-06-23 12:03:35.0 -0400
+++ ../062707/qemu/configure 2007-06-28 17:55:52.348903000 -0400
@@ -553,7 +553,7 @@
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /dev/null ; then
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -562,6 +562,9 @@
sdl=yes
fi
fi
+if [ -s /tmp/qemu-sdl-config.log ]; then
+ check_sdl_log=yes
+fi
# static link with sdl ?
if test $sdl = yes ; then
@@ -688,6 +691,11 @@
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
fi
+if test $check_sdl_log = yes; then
+ echo The error log from compiling the libSDL test is:
+ cat /tmp/qemu-sdl-config.log
+fi
+/usr/bin/rm -f /tmp/qemu-sdl-config.log
#if test $sdl_static = no; then
# echo WARNING: cannot compile statically with SDL - qemu-fast won't have a graphical output
#fi
--- configure.ORIG 2007-06-29 22:59:52.754312000 -0400
+++ configure 2007-06-29 23:11:11.638889000 -0400
@@ -537,60 +537,60 @@
if test -z $sdl ; then
-sdl_config=sdl-config
-sdl=no
-sdl_static=no
-
-if test $mingw32 = yes -a ! -z $cross_prefix ; then
-# win32 cross compilation case
-sdl_config=i386-mingw32msvc-sdl-config
-sdl=yes
-else
-# normal SDL probe
+sdl_config=sdl-config
+sdl=no
+sdl_static=no
+
+if test $mingw32 = yes -a ! -z $cross_prefix ; then
+# win32 cross compilation case
+sdl_config=i386-mingw32msvc-sdl-config
+sdl=yes
+else
+# normal SDL probe
cat $TMPC EOF
#include SDL.h
#undef main /* We don't want SDL to override our main() */
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
-_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
-if test $_sdlversion -lt 121 ; then
-sdl_too_old=yes
-else
- if test $cocoa = no ; then
- sdl=yes
- fi
-fi
-if [ -s /tmp/qemu-sdl-config.log ]; then
- check_sdl_log=yes
-fi
-
-# static link with sdl ?
-if test $sdl = yes ; then
-aa=no
-`$sdl_config --static-libs 2/dev/null | grep \\\-laa /dev/null` aa=yes
-sdl_static_libs=`$sdl_config --static-libs 2/dev/null`
-if [ $aa = yes ] ; then
- sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
-fi
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
+_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
+if test $_sdlversion -lt 121 ; then
+sdl_too_old=yes
+else
+if test $cocoa = no ; then
+sdl=yes
+fi
+fi
+if [ -s /tmp/qemu-sdl-config.log ]; then
+check_sdl_log=yes
+fi
+
+# static link with sdl ?
+if test $sdl = yes ; then
+aa=no
+`$sdl_config --static-libs 2/dev/null | grep \\\-laa /dev/null` aa=yes
+sdl_static_libs=`$sdl_config --static-libs 2/dev/null`
+if [ $aa = yes ] ; then
+sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
+fi
+
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+sdl_static=yes
+fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
- sdl_static=yes
-fi
+fi # static link
-fi # static link
+fi # sdl compile test
-fi # sdl compile test
-
-fi # cross compilation
+fi # cross compilation
else
- # Make sure to disable cocoa if sdl was set
- if test $sdl = yes ; then
- cocoa=no
- coreaudio=no
- fi
+# Make sure to disable cocoa if sdl was set
+if test $sdl = yes ; then
+cocoa=no
+coreaudio=no
+fi
fi # -z $sdl
##
[Qemu-devel] logging the sdl test error
This is short configure patch which saves the output of the libsdl test comile
output
for a file which can be reviewed after configure runs. This allows for easier
debugging
of why the libSDL test failed.
Ben--- qemu/configure.ORIG 2007-06-14 13:58:26.144281000 -0400
+++ qemu/configure 2007-06-14 14:07:40.975474000 -0400
@@ -547,7 +547,7 @@
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /dev/null ; then
+if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /tmp/qemu-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -572,6 +572,8 @@
fi # static link
+else
+ check_sdl_log=yes
fi # sdl compile test
fi # cross compilation
@@ -682,6 +684,9 @@
if test $sdl_too_old = yes; then
echo - Your SDL version is too old - please upgrade to have SDL support
fi
+if test $check_sdl_log = yes; then
+ echo The error log from compiling the libSDL test is in /tmp/qemu-sdl-config.log
+fi
#if test $sdl_static = no; then
# echo WARNING: cannot compile statically with SDL - qemu-fast won't have a graphical output
#fi
Re: [Qemu-devel] Regression bug
Blue Swirl [EMAIL PROTECTED] 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. Works for me, too. Ben
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=qemur1=1.96r2=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] Regression bug
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
[Qemu-devel] support 64-bit compile on Solaris 10/X86
This set of patches allows 64-bit Solaris 10/11 X86 to compile qemu in a 64bit
environment. It requires a 64-bit libsdl, but has been tested with all the
tests
(sparc, arm, mips, mipsel, linux-i386, and DamnSmallLinux)
Ben
--- qemu.ORIG/Makefile.target 2007-05-16 07:59:39.0 -0400
+++ qemu/Makefile.target 2007-05-18 10:21:33.498971000 -0400
@@ -120,7 +120,10 @@
endif
ifeq ($(ARCH),x86_64)
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ BASE_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifeq ($(ARCH),ppc)
@@ -518,6 +521,13 @@
endif
endif
+ifeq ($(ARCH),x86_64)
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
+endif
+
ifdef CONFIG_WIN32
SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole
endif
--- qemu.ORIG/configure 2007-05-13 14:02:43.0 -0400
+++ qemu/configure 2007-05-18 10:29:17.151695000 -0400
@@ -141,6 +141,12 @@
install=ginstall
needs_libsunmath=no
solarisrev=`uname -r | cut -f2 -d.`
+# have to select again, because `uname -m` returns i86pc
+# even on an x86_64 box.
+solariscpu=`isainfo -k`
+if test ${solariscpu} = amd64 ; then
+cpu=x86_64
+fi
if [ $cpu = i386 -o $cpu = x86_64 ] ; then
if test $solarisrev -le 9 ; then
if test -f /opt/SUNWspro/prod/lib/libsunmath.so.1; then
@@ -317,6 +323,11 @@
;;
esac
+if [ $solaris = yes -a $cpu = x86_64 ] ; then
+CFLAGS=${CFLAGS} -m64
+OS_CFLAGS=${OS_CFLAGS} -m64
+fi
+
if test x$show_help = xyes ; then
cat EOF
@@ -547,7 +558,7 @@
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /dev/null ; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC `$sdl_config --libs 2 /dev/null` 2 /dev/null ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test $_sdlversion -lt 121 ; then
sdl_too_old=yes
@@ -566,7 +577,7 @@
sdl_static_libs=$sdl_static_libs `aalib-config --static-libs`
fi
-if $cc -o $TMPE `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
+if $cc -o $TMPE ${OS_CFLAGS} `$sdl_config --cflags 2 /dev/null` $TMPC $sdl_static_libs 2 /dev/null; then
sdl_static=yes
fi
[Qemu-devel] Patch: support OSS on solaris
I've recrafted my patch for supporting OpenSound System on Solaris by checking for it automatically, instead of providing an option. Also added a status flag on whether OSS is enabled or not. Ben--- qemu.ORIG/configure 2007-05-09 10:06:06.0 -0400 +++ qemu/configure 2007-05-12 13:30:31.292001000 -0400 @@ -157,6 +157,9 @@ kqemu=yes fi fi +if test -f /usr/include/sys/soundcard.h ; then +oss=yes +fi ;; *) oss=yes @@ -667,6 +670,7 @@ fmod_support= fi echo FMOD support $fmod $fmod_support +echo OSS support $oss if test -n $sparc_cpu; then echo Target Sparc Arch $sparc_cpu fi
Re: [Qemu-devel] [PATCH] configure
Jeff Chua [EMAIL PROTECTED] wrote: For those who does minimal install. In this case, texi2html would not be available on the system. I've seen quite a few systems without texi2html. Again, the patch is not a MUST, but it's nice not to see unnecessary warning. I suppose you could do a -n `texi2html -verbose 21 | head -1 |grep 'This is texi2html'` which would be more representative if you have texi2html or not. Ben
Re: [Qemu-devel] [PATCH] fix exception precision for cmpxchg8b
a patch like this was posted about 6 weeks ago. the only difference I can see between this and the previous patch is the location of the inserted function. take a look at http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00123.html for hints. This patch fixed the Solaris/express install in a qemu guest. Ben Nickolai Zeldovich [EMAIL PROTECTED] wrote: In qemu-0.9.0, an exception in cmpxchg8b (e.g. page fault due to a missing TLB entry) causes the wrong eip value to be pushed onto the exception stack -- it seems to be the eip of the last exception or the start of the translation block, whichever happened last. This makes it impossible to resume execution after such an exception. The simple patch below fixes it, by explicitly saving the current eip before invoking the cmpxchg8b helper; the same approach appears to be taken in many other instructions before generating code that could raise an exception. Apologies for the non-tab-clean patch, but it's simple enough to apply by hand. I can't quite understand what's generating the equivalent piece of code (to save pc_start into eip) for the cmpxchgl instruction (defined right above cmpxchg8b in translate.c). I'd be thankful if someone could explain to me where it's getting saved. Nickolai. --- qemu-0.9.0/target-i386/translate.c2007-02-05 15:01:54.0 -0800 +++ /home/nickolai/build/qemu-0.9.0/target-i386/translate.c 2007-04-24 19:33:47.0 -0700 @@ -3800,6 +3800,7 @@ if (s-cc_op != CC_OP_DYNAMIC) gen_op_set_cc_op(s-cc_op); gen_lea_modrm(s, modrm, reg_addr, offset_addr); +gen_jmp_im(pc_start - s-cs_base); gen_op_cmpxchg8b(); s-cc_op = CC_OP_EFLAGS; break;
Re: [Qemu-devel] qemu-img qcow and raw format
Francois Visconte [EMAIL PROTECTED] wrote: Hello, I'm currently developing an OS deployment tool similar to G4U (ghost for unix). This is a very basic tool - boot an initrd - configure network - ssh deployment-server cat image.dd /dev/sda - reboot I'm using qemu to test my initrd and deployment tool and i would like replace my raw image format with qcow images (size/compression and crypto) - ssh deployment-server cat image.qcow | qemu-img - -O raw /dev/sda The problem is qemu-img can't read from stdin, so i tried : - mkfifo deploy-in.fifo - qemu-img convert deploy-in.fifo -O raw /dev/sda - ssh deployment-server cat image.qcow deploy-in.fifo qemu-img: Could not open 'deploy-in.fifo' I have not looked at the code in qemu-img (and the associated routines). It appears that qemu-img is probably looking for a file handle and not a named pipe. Either that, or you need to shove the ssh command in the background before the qemu-img command so qemu-img has a chance to start processing the data. It's not clear whether or not qemu-img is seeing an empty file because there's no data on the pipe, or it can't read from the pipe. Ben
[Qemu-devel] PATCH: qemu sparc host cleanup
This patch is a consolodation of patches and ideas from BlueSwirl, Martin
Bochnig and myself.
The patch is comprized of three parts:
1) to more accurately set the compile flags on sparc hosts, with an eye
for sparc_v8plus and sparc_v8plusa, as well as sparc_v9, and leaving
the option for non-ultrasparc hosts to compile qemu. Use of the
ARCH_CFLAGS/ARCH_LDFLAGS at the top level guarantees that
specific host information is dissemnated throughout the build environment
If no default target is selected, sparc_v8plus is used for 32-bit, and sparc_v9
is used for 64-bit (sparc64)
2) cleanup of the Makefile.target for Sparc 32/64 and Linux/Solaris hosts,
reducing redundnancy of configuration parameters
3) enable sparc_v8plus and sparc_v8plusa to use the rtdc. Prior to this
patch, sparc_v8plus and sparc_v8plusa targets were not able to use
the rtdc, and this makes the guests correctly pull the host clock.
This patch supercedes a previous patch I posted for Makefile.target cleanup.
Comments?
Bendiff -ruN qemu.ORIG/Makefile qemu/Makefile
--- qemu.ORIG/Makefile 2007-04-05 16:46:02.0 -0400
+++ qemu/Makefile 2007-04-10 12:14:14.18050 -0400
@@ -8,10 +8,9 @@
BASE_CFLAGS=
BASE_LDFLAGS=
-BASE_CFLAGS += $(OS_CFLAGS)
-ifeq ($(ARCH),sparc)
-BASE_CFLAGS += -mcpu=ultrasparc
-endif
+BASE_CFLAGS += $(OS_CFLAGS) $(ARCH_CFLAGS)
+BASE_LDFLAGS += $(OS_LDFLAGS) $(ARCH_LDFLAGS)
+
CPPFLAGS += -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
LIBS=
TOOLS=qemu-img$(EXESUF)
diff -ruN qemu.ORIG/Makefile.target qemu/Makefile.target
--- qemu.ORIG/Makefile.target 2007-04-07 14:14:41.0 -0400
+++ qemu/Makefile.target 2007-04-10 12:32:13.579045000 -0400
@@ -132,25 +132,28 @@
endif
ifeq ($(ARCH),sparc)
-ifeq ($(CONFIG_SOLARIS),yes)
-BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3
-BASE_LDFLAGS+=-m32
-OP_CFLAGS+=-fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0
-else
-BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
-BASE_LDFLAGS+=-m32
-OP_CFLAGS+=-fno-delayed-branch -ffixed-i0
-HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat
-# -static is used to avoid g1/g3 usage by the dynamic linker
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static
-endif
+ BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3
+ BASE_LDFLAGS+=-m32
+ OP_CFLAGS+=-fno-delayed-branch -ffixed-i0
+ ifeq ($(CONFIG_SOLARIS),yes)
+OP_CFLAGS+=-fno-omit-frame-pointer
+ else
+BASE_CFLAGS+=-ffixed-g1 -ffixed-g6
+HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat
+# -static is used to avoid g1/g3 usage by the dynamic linker
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static
+ endif
endif
ifeq ($(ARCH),sparc64)
-BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
-BASE_LDFLAGS+=-m64
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
-OP_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -fno-delayed-branch -ffixed-i0
+ BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
+ DEFINES+=-D__sparc_v9__
+ BASE_LDFLAGS+=-m64
+ OP_CFLAGS+=-mcpu=ultrasparc -m64 -fno-delayed-branch -ffixed-i0
+ ifneq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+OP_CFLAGS+=-ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
+ endif
endif
ifeq ($(ARCH),alpha)
@@ -202,8 +205,10 @@
BASE_LDFLAGS+=-Wl,-segaddr,__STD_PROG_ZONE,0x1000 -image_base 0x0e00
endif
-BASE_CFLAGS+=$(OS_CFLAGS)
-OP_CFLAGS+=$(OS_CFLAGS)
+BASE_CFLAGS+=$(OS_CFLAGS) $(ARCH_CFLAGS)
+BASE_LDFLAGS+=$(OS_LDFLAGS) $(ARCH_LDFLAGS)
+OP_CFLAGS+=$(OS_CFLAGS) $(ARCH_CFLAGS)
+OP_LDFLAGS+=$(OS_LDFLAGS) $(ARCH_LDFLAGS)
#
@@ -499,8 +504,10 @@
endif
ifeq ($(ARCH),sparc64)
-VL_LDFLAGS+=-m64
-VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifdef CONFIG_WIN32
diff -ruN qemu.ORIG/configure qemu/configure
--- qemu.ORIG/configure 2007-04-05 16:46:02.0 -0400
+++ qemu/configure 2007-04-10 12:15:48.200123000 -0400
@@ -56,7 +56,7 @@
s390)
cpu=s390
;;
- sparc|sun4[muv])
+ sparc|sun4[cdmuv])
cpu=sparc
;;
sparc64)
@@ -266,6 +266,18 @@
;;
--enable-uname-release=*) uname_release=$optarg
;;
+ --sparc_cpu=*)
+ sparc_cpu=$optarg
+ case $sparc_cpu in
+v7|v8) SP_CFLAGS=-m32 -mcpu=${sparc_cpu} -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m32
+ target_cpu=sparc; cpu=sparc ;;
+v8plus|v8plusa) SP_CFLAGS=-m32 -mcpu=ultrasparc -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m32
+ target_cpu=sparc; cpu=sparc ;;
+v9)SP_CFLAGS=-m64 -mcpu=ultrasparc -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m64
+ target_cpu=sparc64; cpu=sparc64 ;;
+*) echo undefined SPARC architecture. Exiting;exit 1;;
+ esac
+ ;;
esac
done
@@ -279,6 +291,29 @@
CFLAGS=$CFLAGS -Wall -O2 -g
[Qemu-devel] Updated PATCH: qemu sparc host cleanup
An Update to the previous patch. Some of the variables and
defines in Makefile.target were not removed as part of the
new sparc host configuration.
Ben
Ben Taylor [EMAIL PROTECTED] wrote:
This patch is a consolodation of patches and ideas from BlueSwirl, Martin
Bochnig and myself.
The patch is comprized of three parts:
1) to more accurately set the compile flags on sparc hosts, with an eye
for sparc_v8plus and sparc_v8plusa, as well as sparc_v9, and leaving
the option for non-ultrasparc hosts to compile qemu. Use of the
ARCH_CFLAGS/ARCH_LDFLAGS at the top level guarantees that
specific host information is dissemnated throughout the build environment
If no default target is selected, sparc_v8plus is used for 32-bit, and
sparc_v9
is used for 64-bit (sparc64)
2) cleanup of the Makefile.target for Sparc 32/64 and Linux/Solaris hosts,
reducing redundnancy of configuration parameters
3) enable sparc_v8plus and sparc_v8plusa to use the rtdc. Prior to this
patch, sparc_v8plus and sparc_v8plusa targets were not able to use
the rtdc, and this makes the guests correctly pull the host clock.
This patch supercedes a previous patch I posted for Makefile.target cleanup.
Comments?
Ben
diff -ruN qemu.ORIG/Makefile qemu/Makefile
--- qemu.ORIG/Makefile 2007-04-05 16:46:02.0 -0400
+++ qemu/Makefile 2007-04-10 12:14:14.18050 -0400
@@ -8,10 +8,9 @@
BASE_CFLAGS=
BASE_LDFLAGS=
-BASE_CFLAGS += $(OS_CFLAGS)
-ifeq ($(ARCH),sparc)
-BASE_CFLAGS += -mcpu=ultrasparc
-endif
+BASE_CFLAGS += $(OS_CFLAGS) $(ARCH_CFLAGS)
+BASE_LDFLAGS += $(OS_LDFLAGS) $(ARCH_LDFLAGS)
+
CPPFLAGS += -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
LIBS=
TOOLS=qemu-img$(EXESUF)
diff -ruN qemu.ORIG/Makefile.target qemu/Makefile.target
--- qemu.ORIG/Makefile.target 2007-04-07 14:14:41.0 -0400
+++ qemu/Makefile.target 2007-04-10 14:36:20.810045000 -0400
@@ -132,25 +132,25 @@
endif
ifeq ($(ARCH),sparc)
-ifeq ($(CONFIG_SOLARIS),yes)
-BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3
-BASE_LDFLAGS+=-m32
-OP_CFLAGS+=-fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0
-else
-BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6
-BASE_LDFLAGS+=-m32
-OP_CFLAGS+=-fno-delayed-branch -ffixed-i0
-HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat
-# -static is used to avoid g1/g3 usage by the dynamic linker
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static
-endif
+ BASE_CFLAGS+=-ffixed-g2 -ffixed-g3
+ OP_CFLAGS+=-fno-delayed-branch -ffixed-i0
+ ifeq ($(CONFIG_SOLARIS),yes)
+OP_CFLAGS+=-fno-omit-frame-pointer
+ else
+BASE_CFLAGS+=-ffixed-g1 -ffixed-g6
+HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat
+# -static is used to avoid g1/g3 usage by the dynamic linker
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static
+ endif
endif
ifeq ($(ARCH),sparc64)
-BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
-BASE_LDFLAGS+=-m64
-BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
-OP_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -fno-delayed-branch -ffixed-i0
+ BASE_CFLAGS+=-ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
+ OP_CFLAGS+=-mcpu=ultrasparc -m64 -fno-delayed-branch -ffixed-i0
+ ifneq ($(CONFIG_SOLARIS),yes)
+BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+OP_CFLAGS+=-ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7
+ endif
endif
ifeq ($(ARCH),alpha)
@@ -202,8 +202,10 @@
BASE_LDFLAGS+=-Wl,-segaddr,__STD_PROG_ZONE,0x1000 -image_base 0x0e00
endif
-BASE_CFLAGS+=$(OS_CFLAGS)
-OP_CFLAGS+=$(OS_CFLAGS)
+BASE_CFLAGS+=$(OS_CFLAGS) $(ARCH_CFLAGS)
+BASE_LDFLAGS+=$(OS_LDFLAGS) $(ARCH_LDFLAGS)
+OP_CFLAGS+=$(OS_CFLAGS) $(ARCH_CFLAGS)
+OP_LDFLAGS+=$(OS_LDFLAGS) $(ARCH_LDFLAGS)
#
@@ -499,8 +501,10 @@
endif
ifeq ($(ARCH),sparc64)
-VL_LDFLAGS+=-m64
-VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld
+ VL_LDFLAGS+=-m64
+ ifneq ($(CONFIG_SOLARIS),yes)
+VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
+ endif
endif
ifdef CONFIG_WIN32
diff -ruN qemu.ORIG/configure qemu/configure
--- qemu.ORIG/configure 2007-04-05 16:46:02.0 -0400
+++ qemu/configure 2007-04-10 12:15:48.200123000 -0400
@@ -56,7 +56,7 @@
s390)
cpu=s390
;;
- sparc|sun4[muv])
+ sparc|sun4[cdmuv])
cpu=sparc
;;
sparc64)
@@ -266,6 +266,18 @@
;;
--enable-uname-release=*) uname_release=$optarg
;;
+ --sparc_cpu=*)
+ sparc_cpu=$optarg
+ case $sparc_cpu in
+v7|v8) SP_CFLAGS=-m32 -mcpu=${sparc_cpu} -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m32
+ target_cpu=sparc; cpu=sparc ;;
+v8plus|v8plusa) SP_CFLAGS=-m32 -mcpu=ultrasparc -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m32
+ target_cpu=sparc; cpu=sparc ;;
+v9)SP_CFLAGS=-m64 -mcpu=ultrasparc -D__sparc_${sparc_cpu}__; SP_LDFLAGS=-m64
+ target_cpu=sparc64; cpu=sparc64 ;;
+*) echo undefined SPARC architecture
[Qemu-devel] Patch: fix helper.c with isinf on Solaris 9/Sparc
This fixes a linker error for target-i386/helper.c on Solaris 9/Sparc,
as Solaris 9/Sparc does not include the isinf function or macro.
Due to the use of libsunmath on Solaris 9/X86, this feature is
not needed.
Ben
--- qemu.ORIG/target-i386/helper.c 2007-04-03 12:38:34.0 -0400
+++ qemu/target-i386/helper.c 2007-04-05 16:57:31.311064000 -0400
@@ -21,6 +21,11 @@
//#define DEBUG_PCALL
+#if defined(__sparc__) (HOST_SOLARIS 10)
+#include ieeefp.h
+#define isinf(x) (fpclass(x) == FP_NINF || fpclass(x) == FP_PINF)
+#endif
+
#if 0
#define raise_exception_err(a, b)\
do {\
Re: [Qemu-devel] SDL audio and AIO hogging each other's signals
andrzej zaborowski [EMAIL PROTECTED] wrote: Hi, with QEMU_AUDIO_DRV set to sdl and booting from CD-ROM with AIO on a Linux host and with SDL 1.2.11, qemu locks up in sigwait() (the main thread) and SDL_SemWait() (the audio thread) as soon as music is playing and CD-ROM is being read at the same time. It appears that audio/sdlaudio.c:sdl_callback is called by SDL when it shouldn't be called, and block-raw.c is trying to flush the AIO operations, so it would seem that the SIGUSR2 which is intended to wake up the sigwait is instead captured by SDL and SDL tries to be smart and calls sdl_callback. sdl_callback has a sanity check but this check is *after* SDL_SemWait() so it is not triggered. The strange thing is that using a different signal (tried SIGUSR1 and SIGPOLL) for AIO doesn't help. Does SDL catch all signals? I could be totally wrong because I don't know SDLAudio at all. Any ideas about the exact reason why this is happening and how to fix it? On Solaris 10/11 x86, I was seeing a bunch of semphore errors emitted from SDL when using SDL audio. I'll track this down and report back. Ben
[Qemu-devel] PATCH: Solaris kqemu.c
This patch further isolates the functions needed for kqemu.c by Solaris. The original include has the unintended side effect of screwing up the mips targets on Solaris 9/x86 because there are some defines that get included via sys/modctl.h that change how the CPU structure in the mips-target/cpu.h file is processed. (Bascially, the PC variable name gets changed to 14, which completely botches the compile). Kudos to Juergen Keil for another smart fix. qemu-kqemu.c-diff Description: Binary data
Re: [Qemu-devel] [patch] More PCI ethernet emulations
Stefan Weil [EMAIL PROTECTED] wrote: Hi, File eepro100.tar.bz2 (added to this mail) contains everything needed to add 3 new PCI network device (all similar to EEPRO100): eepro100.patch: Makefile.target: added two binaries needed for EEPRO100 split entries for PCI network devices (1 line / entry, better merging with CVS) vl.h: added prototypes for EEPRO100 hw/pci.c: added new PCI network models: i82551, i82557b, i82559er hw/eepro100.c: EEPRO100 PCI network emulation hw/eeprom93xx.c, hw/eeprom93xx.h: EEPROM emulation, needed for EEPRO100 (and others) I just finished running these tests using a PC host running Debian GNU Linux: * compilation for all QEMU target architectures: ok * cross compilation (Windows) for all QEMU target architectures: ok * functional test: ok The last test was started like this: i386-softmmu/qemu -L pc-bios --net nic,model=i82559er --net tap /dev/hda --snapshot Networking was tested using ping and ssh connection from emulated system to host. I did not apply your patch, because I cannot test it (it needs a system with different endianess). Your feedback is welcome I have a question. in eepro100_write2, I see a word (16-bits) being passed in, but only the low part of the word gets written to the eeprom. Since it's a word write, shouldn't it be writing both bytes to the eeprom? Ben
Re: [Qemu-devel] QEMU + -std-vga + XFree86
Anthony Liguori [EMAIL PROTECTED] wrote: Kyle Hubert wrote: Hi, I'm working with QEMU on an XFree86 machine. I was desirous of having 1600x1200 working in the virtual machine, so I looked at using the -std-vga option with the vesa X driver. You probably have to increase your hsync and vrefresh ranges. yeah, except for the 640x480 reports not enough memory Regards, Anthony Liguori While initializing X, I get the following: (II) VESA(0): Primary V_BIOS segment is: 0xc000 (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 0.0 (II) VESA(0): VESA VBE Total Mem: 0 kB (II) VESA(0): VESA VBE OEM: ^A The log continues on to say: (II) VESA(0): Total Memory: 0 64KB banks (0kB) (II) VESA(0): Generic Monitor: Using hsync range of 28.00-51.00 kHz (II) VESA(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz (II) VESA(0): Not using mode 1600x1200 (no mode of this name) (II) VESA(0): Not using mode 1280x1024 (no mode of this name) (II) VESA(0): Not using mode 1024x768 (no mode of this name) (II) VESA(0): Not using mode 800x600 (no mode of this name) (II) VESA(0): Not using built-in mode 640x480 (insufficient memory given virtual size) I'm not positive this is my problem, but it looks like it isn't reporting the vram size correctly, does this sound correct? Thanks for the time. -Kyle
Re: [Qemu-devel] please review this scsi patch
Avi Kivity [EMAIL PROTECTED] wrote: Wang Cheng Yeh wrote: thanks If you include a description of what the patch does and why it is necessary, it will probably be reviewed a lot quicker. He's posted this one before, and the patch fixes such blatent programming errors like an XOR case option using | instead of ^ and a 32-bit write split into 4 byte writes, and passing the third byte twice. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: arm, mips and sparc targets on Host Solaris/sparc
This patch is to fix (correctly) running mips, sparc and arm targets on a Solaris/Sparc host. This patch reverts the patch posted February 2nd, 2007, (found at http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg8.html for reference). Juergen Keil found that config.h was not included in target-arm/exec.h and config.h was included *after* dyngen-exec.h in target-sparc/exec.h. By config.h not being included before dyngen-exec.h, the code in dyngen-exec.h assumed a linux-sparc host and used different register allocations which were incompatible with Solaris/Sparc. I can boot the sparc-test and mips-tests now. The arm-test is not functional due a Solaris library bug, and we are working on a fix. Bendiff -ruN qemu-ORIG/target-arm/exec.h qemu/target-arm/exec.h --- qemu-ORIG/target-arm/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-arm/exec.h 2007-03-19 09:19:44.33096 -0400 @@ -17,19 +17,13 @@ * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include config.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUARMState *env; -uint32_t T0; -uint32_t T1; -uint32_t T2; -#else register struct CPUARMState *env asm(AREG0); register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); register uint32_t T2 asm(AREG3); -#endif /* TODO: Put these in FP regs on targets that have such things. */ /* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */ diff -ruN qemu-ORIG/target-mips/exec.h qemu/target-mips/exec.h --- qemu-ORIG/target-mips/exec.h 2007-02-28 17:37:42.0 -0500 +++ qemu/target-mips/exec.h 2007-03-19 09:20:30.439432000 -0400 @@ -7,11 +7,7 @@ #include mips-defs.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUMIPSState *env; -#else register struct CPUMIPSState *env asm(AREG0); -#endif #if defined (USE_64BITS_REGS) typedef int64_t host_int_t; @@ -21,11 +17,6 @@ typedef uint32_t host_uint_t; #endif -#if defined(__sparc__) -host_uint_t T0; -host_uint_t T1; -host_uint_t T2; -#else #if TARGET_LONG_BITS HOST_LONG_BITS #define T0 (env-t0) #define T1 (env-t1) @@ -35,7 +26,6 @@ register host_uint_t T1 asm(AREG2); register host_uint_t T2 asm(AREG3); #endif -#endif #if defined (USE_HOST_FLOAT_REGS) #error implement me. diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h 2007-03-19 09:22:48.76391 -0400 @@ -3,11 +3,7 @@ #include dyngen-exec.h #include config.h -#if defined(__sparc__) -struct CPUSPARCState *env; -#else register struct CPUSPARCState *env asm(AREG0); -#endif #ifdef TARGET_SPARC64 #define T0 (env-t0) @@ -15,13 +11,8 @@ #define T2 (env-t2) #define REGWPTR env-regwptr #else -#if defined(__sparc__) -register uint32_t T0 asm(AREG3); -register uint32_t T1 asm(AREG2); -#else register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); -#endif #undef REG_REGWPTR // Broken #ifdef REG_REGWPTR @@ -33,11 +24,7 @@ #define reg_REGWPTR #ifdef AREG4 -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG4); -#endif #define reg_T2 #else #define T2 (env-t2) @@ -45,14 +32,10 @@ #else #define REGWPTR env-regwptr -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG3); #endif #define reg_T2 #endif -#endif #define FT0 (env-ft0) #define FT1 (env-ft1) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: arm, mips and sparc targets on Host Solaris/sparc
Thiemo Seufer [EMAIL PROTECTED] wrote: Ben Taylor wrote: This patch is to fix (correctly) running mips, sparc and arm targets on a Solaris/Sparc host. This patch reverts the patch posted February 2nd, 2007, (found at http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg8.html for reference). Juergen Keil found that config.h was not included in target-arm/exec.h and config.h was included *after* dyngen-exec.h in target-sparc/exec.h. [snip] diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h2007-03-19 09:22:48.76391 -0400 @@ -3,11 +3,7 @@ #include dyngen-exec.h #include config.h You missed a bit... sigh Thanks for the catch. Here's the updated patch Bendiff -ruN qemu-ORIG/target-arm/exec.h qemu/target-arm/exec.h --- qemu-ORIG/target-arm/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-arm/exec.h 2007-03-19 09:19:44.33096 -0400 @@ -17,19 +17,13 @@ * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include config.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUARMState *env; -uint32_t T0; -uint32_t T1; -uint32_t T2; -#else register struct CPUARMState *env asm(AREG0); register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); register uint32_t T2 asm(AREG3); -#endif /* TODO: Put these in FP regs on targets that have such things. */ /* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */ diff -ruN qemu-ORIG/target-mips/exec.h qemu/target-mips/exec.h --- qemu-ORIG/target-mips/exec.h 2007-02-28 17:37:42.0 -0500 +++ qemu/target-mips/exec.h 2007-03-19 09:20:30.439432000 -0400 @@ -7,11 +7,7 @@ #include mips-defs.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUMIPSState *env; -#else register struct CPUMIPSState *env asm(AREG0); -#endif #if defined (USE_64BITS_REGS) typedef int64_t host_int_t; @@ -21,11 +17,6 @@ typedef uint32_t host_uint_t; #endif -#if defined(__sparc__) -host_uint_t T0; -host_uint_t T1; -host_uint_t T2; -#else #if TARGET_LONG_BITS HOST_LONG_BITS #define T0 (env-t0) #define T1 (env-t1) @@ -35,7 +26,6 @@ register host_uint_t T1 asm(AREG2); register host_uint_t T2 asm(AREG3); #endif -#endif #if defined (USE_HOST_FLOAT_REGS) #error implement me. diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h 2007-03-19 09:57:13.694272000 -0400 @@ -1,13 +1,9 @@ #ifndef EXEC_SPARC_H #define EXEC_SPARC_H 1 -#include dyngen-exec.h #include config.h +#include dyngen-exec.h -#if defined(__sparc__) -struct CPUSPARCState *env; -#else register struct CPUSPARCState *env asm(AREG0); -#endif #ifdef TARGET_SPARC64 #define T0 (env-t0) @@ -15,13 +11,8 @@ #define T2 (env-t2) #define REGWPTR env-regwptr #else -#if defined(__sparc__) -register uint32_t T0 asm(AREG3); -register uint32_t T1 asm(AREG2); -#else register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); -#endif #undef REG_REGWPTR // Broken #ifdef REG_REGWPTR @@ -33,11 +24,7 @@ #define reg_REGWPTR #ifdef AREG4 -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG4); -#endif #define reg_T2 #else #define T2 (env-t2) @@ -45,14 +32,10 @@ #else #define REGWPTR env-regwptr -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG3); #endif #define reg_T2 #endif -#endif #define FT0 (env-ft0) #define FT1 (env-ft1) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH Makefile.target cleanup
This patch cleans up Makefile target for sparc32 and sparc64 Solaris and non-Solaris targets share a large amount of the definitions, so I split out the common parts and isolate just the Solaris/non-Solaris portions and added readability. Also fixed the x86_64 targets for Solaris to not use the loader for linux, and fixed up Sparc64 and ia64 to use $(ARCH) instead of a hard-coded definition for the library. Bendiff -ruN qemu-ORIG/Makefile.target qemu/Makefile.target --- qemu-ORIG/Makefile.target 2007-03-18 19:23:31.0 -0400 +++ qemu/Makefile.target 2007-03-19 09:44:49.714657000 -0400 @@ -109,7 +109,11 @@ endif ifeq ($(ARCH),x86_64) -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + ifeq ($(CONFIG_SOLARIS),yes) +BASE_LDFLAGS+=-m64 + else +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif endif ifeq ($(ARCH),ppc) @@ -124,25 +128,28 @@ endif ifeq ($(ARCH),sparc) -ifeq ($(CONFIG_SOLARIS),yes) -BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 -BASE_LDFLAGS+=-m32 -OP_CFLAGS+=-fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0 -else -BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 -BASE_LDFLAGS+=-m32 -OP_CFLAGS+=-fno-delayed-branch -ffixed-i0 -HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat -# -static is used to avoid g1/g3 usage by the dynamic linker -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static -endif + BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 + BASE_LDFLAGS+=-m32 + OP_CFLAGS+=-fno-delayed-branch -ffixed-i0 + ifeq ($(CONFIG_SOLARIS),yes) +OP_CFLAGS+=-fno-omit-frame-pointer + else +BASE_CFLAGS+=-ffixed-g1 -ffixed-g6 +HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat +# -static is used to avoid g1/g3 usage by the dynamic linker +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static + endif endif ifeq ($(ARCH),sparc64) -BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -BASE_LDFLAGS+=-m64 -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -OP_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -fno-delayed-branch -ffixed-i0 + BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 + DEFINES+=-D__sparc_v9__ + BASE_LDFLAGS+=-m64 + OP_CFLAGS+=-mcpu=ultrasparc -m64 -fno-delayed-branch -ffixed-i0 + ifneq ($(CONFIG_SOLARIS),yes) +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld +OP_CFLAGS+=-ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 + endif endif ifeq ($(ARCH),alpha) @@ -457,14 +464,24 @@ endif ifeq ($(ARCH),ia64) -VL_LDFLAGS+=-Wl,-G0 -Wl,-T,$(SRC_PATH)/ia64.ld + VL_LDFLAGS+=-Wl,-G0 -Wl,-T,$(SRC_PATH)/$(ARCH).ld endif ifeq ($(ARCH),sparc64) -VL_LDFLAGS+=-m64 -VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld + VL_LDFLAGS+=-m64 + ifneq ($(CONFIG_SOLARIS),yes) +VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif endif +ifeq ($(ARCH),x86_64) + VL_LDFLAGS+=-m64 + ifneq ($(CONFIG_SOLARIS),yes) +VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif +endif + + ifdef CONFIG_WIN32 SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole endif ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: arm guest on Solaris/Sparc host
This patch was suggested by Juergen Keil. It prevents a crash by qemu when running the arm-test on Solaris/Sparc. Removing the previous arm patch for sparc uncovered a use of global registers o0-05 which hadn't been defined previously. Ben--- qemu-ORIG/cpu-exec.c 2007-03-16 19:58:11.0 -0400 +++ qemu/cpu-exec.c 2007-03-19 15:14:21.930962000 -0400 @@ -648,6 +648,7 @@ : /* no outputs */ : r (gen_func) : i0, i1, i2, i3, i4, i5, + o0, o1, o2, o3, o4, o5, l0, l1, l2, l3, l4, l5, l6, l7); #elif defined(__arm__) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Makefile Makefile.target configure
Thiemo Seufer [EMAIL PROTECTED] wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/03/17 15:00:38 Modified files: . : Makefile Makefile.target configure Log message: Better way to select -lrt, by Andrzei Zaborowski. Unfortunately, this introduced a regression in Solaris. Solaris needs -lrt. This was fixed a couple of weeks back, but this patch was posted back in november and wasn't regressed on the current code. I can post a patch, but we just need the solaris check taken out of the configure script for AIO_LIBS Thanks, Ben CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.113r2=1.114 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.147r2=1.148 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.129r2=1.130 ___ 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
Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible
J M Cerqueira Esteves [EMAIL PROTECTED] wrote: herbie hancock wrote: Hello, i had also a reproducible disk crash: info of the last good image, size is about 3,5GB I never experienced such a bad problem with qemu before, maybe it is a problem with qcow2 format ? After the problems with qcow2 images which I reported here a few weeks ago, I've only been using qcow images (under QEMU 0.9.0), without such surprises. So it seems qemu has some bug related to qcow2 images, maybe manifesting itself only after they get larger than 4GB... I suspect I saw problems with qcow2 images as well. I was able to suspend a Solaris Nevada B58 install and use savevm about 30% into the install and restart it later. As the image completd, the file system went all to hell with corruption that was impossible to fix. At the time, I attributed it to the Solaris install (thinking it might have something to do with the cmpxchg8b bug that was later fixed), but I suspect with the multiple reports I've seen, I'm now thinking I saw the same thing. I'm testing conversion of a qcow image to a qcow2 image. We'll see how that goes Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu
This patch fixes crashes when testing with arm-test-0.2.tar.gz and mips-test-0.2.tar.gz. Without the patch, both arm-test and mips-test segfault when trying to boot. The original patch was authored by Martin Bochnig. --- qemu/cpu-exec.c.ORIG 2007-03-13 09:46:51.940624000 -0400 +++ qemu/cpu-exec.c 2007-03-13 09:33:34.130534000 -0400 @@ -738,7 +744,10 @@ #else gen_func(); #endif +/* sparc hosts don't seem to like this method very much */ +#if !(defined(__sparc__) !defined(TARGET_I386) !defined(TARGET_X86_64) !defined(TARGET_PPC)) env-current_tb = NULL; +#endif /* reset soft MMU for next block (it can currently only be set by a memory fault) */ #if defined(TARGET_I386) !defined(CONFIG_SOFTMMU) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: allow Sparc hosts to run arm/mips/sparc-softmmu
Paul Brook [EMAIL PROTECTED] wrote: On Tuesday 13 March 2007 14:01, Ben Taylor wrote: This patch fixes crashes when testing with arm-test-0.2.tar.gz and mips-test-0.2.tar.gz. Without the patch, both arm-test and mips-test segfault when trying to boot. I don't believe this is correct. You're going to have to come up with a fairly convincing argument to get a patch like this accepted. don't seem to like this very much is not a useful comment. Yeah, so the comment is not very useful. I copied it from the author. I'll see if he can actually explain why this patch is important. However, it's very wax-on, wax-off kind of thing. Without the patch, arm-test and mips-test crash. With the patch, I can run both tests. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: hw/rtl8139.c for Sparc (BigEndian) Hosts
This patch is to fix a big-endian problem in the RTL-8139 driver. The additional
debugging is mine, and the actual code fixes are by Garrison (Igor Kovalenko -
[EMAIL PROTECTED]). Code has been tested on 32-bit Solaris x86 and 32-bit
Solaris Sparc hosts, with and without debugging.
There were two problems.
1) the setup of the MAC address was not big-endian friendly
2) due to some feature of le32_to_cpu, the pointer to the buffer
for the packet was off in never-never land. Just setting the
val in rtl8139_TxAddr_write was enough to fix the problem,
and networking both in and out are working properly on a sparc host.
Ben--- qemu/hw/rtl8139.c.ORIG 2007-03-12 17:41:46.739541000 -0400
+++ qemu/hw/rtl8139.c 2007-03-12 17:55:14.749309000 -0400
@@ -73,7 +73,9 @@
( ( input ) ( size - 1 ) )
#if defined (DEBUG_RTL8139)
-# define DEBUG_PRINT(x) do { printf x ; } while (0)
+#include stdarg.h
+# define DEBUG_PRINT_VA(fmt, ...) do { printf ( rtl8139.c:%d:%s: fmt, __LINE__, __FUNCTION__, ## __VA_ARGS__ ); } while (0)
+# define DEBUG_PRINT(x) do { DEBUG_PRINT_VA x ; } while (0)
#else
# define DEBUG_PRINT(x)
#endif
@@ -637,8 +639,13 @@
int prom9346_get_wire(RTL8139State *s)
{
EEprom9346 *eeprom = s-eeprom;
-if (!eeprom-eecs)
+DEBUG_PRINT((eeprom-eecs = 0x%08x, eeprom-eedo = 0x%08x\n, eeprom-eecs, eeprom-eedo));
+if (!eeprom-eecs) {
+DEBUG_PRINT((eeprom-eedo = 0, returning 0\n));
return 0;
+}
+
+DEBUG_PRINT((return eeprom-eedo = 0x%08x\n, eeprom-eedo));
return eeprom-eedo;
}
@@ -778,6 +785,7 @@
/* non-wrapping path or overwrapping enabled */
cpu_physical_memory_write( s-RxBuf + s-RxBufAddr, buf, size );
+DEBUG_PRINT(( RTL8139: called cpu_physical_memory_write\n ));
s-RxBufAddr += size;
}
@@ -797,6 +805,7 @@
RTL8139State *s = opaque;
int avail;
+DEBUG_PRINT((s-clock_enabled = 0x%04x\n, s-clock_enabled ));
/* Recieve (drop) packets if card is disabled. */
if (!s-clock_enabled)
return 1;
@@ -1162,6 +1171,7 @@
static void rtl8139_receive(void *opaque, const uint8_t *buf, int size)
{
+DEBUG_PRINT((entering rtl8139_receive\n));
rtl8139_do_receive(opaque, buf, size, 1);
}
@@ -1192,7 +1202,9 @@
s-eeprom.contents[1] = 0x10ec;
s-eeprom.contents[2] = 0x8139;
#endif
-memcpy(s-eeprom.contents[7], s-macaddr, 6);
+s-eeprom.contents[7] = s-macaddr[0] | s-macaddr[1] 8;
+s-eeprom.contents[8] = s-macaddr[2] | s-macaddr[3] 8;
+s-eeprom.contents[9] = s-macaddr[4] | s-macaddr[5] 8;
/* mark all status registers as owned by host */
for (i = 0; i 4; ++i)
@@ -1756,6 +1768,7 @@
}
else
{
+DEBUG_PRINT((RTL8139: +++ qemu_send_packet(s-vc, buf, size)\n));
qemu_send_packet(s-vc, buf, size);
}
}
@@ -1786,10 +1799,20 @@
cpu_physical_memory_read(s-TxAddr[descriptor], txbuffer, txsize);
+DEBUG_PRINT((RTL8139: +++ finished calling cpu_physical_memory_read, txbuffer = 0x%08x\n, txbuffer ));
+#if DEBUG_RTL8139
+int bx;
+for(bx=0;bxtxsize;bx+=8) {
+DEBUG_PRINT((txbuffer[%d]: 0x%2x 0x%2x 0x%2x 0x%2x 0x%2x 0x%2x 0x%2x 0x%2x\n,
+bx,txbuffer[bx],txbuffer[bx+1],txbuffer[bx+2],txbuffer[bx+3],txbuffer[bx+4],txbuffer[bx+5],txbuffer[bx+6],txbuffer[bx+7]));
+}
+#endif
+
/* Mark descriptor as transferred */
s-TxStatus[descriptor] |= TxHostOwns;
s-TxStatus[descriptor] |= TxStatOK;
-
+DEBUG_PRINT((RTL8139: +++ calling rtl8139_transfer_frame(s, txbuffer = 0x%08x, txsize = 0x%04x, 0)\n,
+txbuffer, txsize));
rtl8139_transfer_frame(s, txbuffer, txsize, 0);
DEBUG_PRINT((RTL8139: +++ transmitted %d bytes from descriptor %d\n, txsize, descriptor));
@@ -2455,14 +2478,15 @@
{
DEBUG_PRINT((RTL8139: TxAddr write offset=0x%x val=0x%08x\n, txAddrOffset, val));
-s-TxAddr[txAddrOffset/4] = le32_to_cpu(val);
+s-TxAddr[txAddrOffset/4] = val;
+DEBUG_PRINT((RTL8139: s-TxAddr[%d] = 0x%08x\n, txAddrOffset/4, val));
}
static uint32_t rtl8139_TxAddr_read(RTL8139State *s, uint32_t txAddrOffset)
{
uint32_t ret = cpu_to_le32(s-TxAddr[txAddrOffset/4]);
-DEBUG_PRINT((RTL8139: TxAddr read offset=0x%x val=0x%08x\n, txAddrOffset, ret));
+DEBUG_PRINT((RTL8139: TxAddr read offset=0x%x val=0x%08x\n, txAddrOffset/4, ret));
return ret;
}
@@ -2608,36 +2632,46 @@
switch (addr)
{
case MAC0 ... MAC0+5:
+DEBUG_PRINT((RTL8139: s-phys[%d] set 0x%x\n, addr - MAC0, val));
s-phys[addr - MAC0] = val;
break;
case MAC0+6 ... MAC0+7:
/* reserved */
break;
case MAR0 ... MAR0+7:
+DEBUG_PRINT((RTL8139: s-mult[%d] set 0x%x\n, addr - MAR0, val));
s-mult[addr - MAR0] = val;
break;
case ChipCmd:
+DEBUG_PRINT((RTL8139: ChipCmd write set 0x%x\n, val));
[Qemu-devel] Updated PATCH: hw/rtl8139.c for Sparc (BigEndian) Hosts
Apologies to the list. I forgot to separate out the patches in a more appropriate manner. Patch 1: qemu-rtl8139-bigend.diff This fixes the big-endian problem with the hw/rtl8139.c on a Sparc host. Patch 2: qemu-rtl8139-impv-debug.difff This is an improved macro for debugging. This patch layers on the first patch. The above two patches were coded by Igor Kovalenko ([EMAIL PROTECTED]) Patch 3: qemu-rtl8139-extra-debug.diff This just adds a lot of debugging that was used to isolate the problem with the big-endian problem, and layers on the first two patches. Ben qemu-rtl8139-bigend.diff Description: Binary data qemu-rtl8139-extra-debug.diff Description: Binary data qemu-rtl8139-impr-debug.diff Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Patch: trunc undefined in Solaris 9/Sparc
This fix was suggested by Juergen Kiel, and appears to work on my
Solaris 9/Sparc V490.
--- fpu/softfloat-native.c.ORIG 2007-03-07 07:30:28.662257000 -0500
+++ fpu/softfloat-native.c 2007-03-07 07:30:44.595051000 -0500
@@ -221,6 +221,12 @@
/*
| Software IEC/IEEE double-precision operations.
**/
+#if ( defined(__sun__) ( HOST_SOLARIS 10 ))
+double trunc(double x)
+{
+return x 0 ? -floor(-x) : floor(x);
+}
+#endif
float64 float64_trunc_to_int( float64 a STATUS_PARAM )
{
return trunc(a);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] (no subject)
jeremy fenelon [EMAIL PROTECTED] wrote: Hey guys thanks for a great product. I don't know if its been documented already but I was able to install windows xp on qemu with a HP Laptop Restore disk. Lucky. I think the last time I tried that, it didn't work because of the way that HP locked the restore media to the BIOS identifier. Always wanted to be able to have the Bochs bios have an idenfier setting I coudl pass in so I could do something like that. I did need my key from the bottom. I hope this meets the EULA . Can't tell you if it meets the EULA. I picked up a key when a company trashed a laptop that still had the key on the bottom. My laptop did die last year and I have been wondering what I could do with that extra copy. Will Qemu boot a .iso file like ubuntu? Yes, it's a whole lot easrier than shuffling CD's and DVD's about. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Access to qemu-monitor on Solaris/Sparc host
Was doing some testing on a sparc host, and found an interesting situation. Code is 0.9.0-CVS, and I start qemu on my Ultra 60 (guest is windows 98se). When I hit ctrl-alt-2, I don't get the monitor. I've added some debugging to sdl.c, to try and figure out what is going on. Hitting ctrl-alt-2, I see the following kbd_put_keyboard events kbd_put_keycode(29) # ctrl kbd_put_keycode(56) # alt kbd_put_keycode(3) # 2 kbd_put_keycode(131)# 2 | 0x80 The following key combinations get me interesting places (Unfortunately my debugging didn't generate any specifics for these key combinations yet) ctrl-alt-F1goes to serial0 console ctrl-alt-F2goes to parallel console ctrl-alt-AGAIN goes back to the graphical screen from serial0 or parallel0 (Again is at the top of the second column of keys on the left side of a sun keyboard) However, if I run the client in a VNC session, I have no problem getting to the qemu monitor/console. Thoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
Hi Malc, malc [EMAIL PROTECTED] wrote: On Sun, 25 Feb 2007, Ben Taylor wrote: As I seem to have hit a wall with the ES1370 driver in qemu not working on Solaris, I have modified configure to allow Solaris to use OpenSoundSystems audio. Is there any interest in having a default audio setting for SDL so that you won't have to always put QEMU_SDL_AUDIO=oss before you start qemu? I don't quite get what does not work OSS or ES1370? Using a precompiled version of qemu from opensolaris.org, that binary didn't work with a Solaris Nevada guest with OSS audio running on a Solaris Nevada host running native audio. I think its a problem with the precompiled version of qemu I was using. After I got the OSS version runnning on a different system with OSS, I went back and recompiled the CVS code (enabling the debugging) and the audio worked (though the debugging makes the timing of the sound choppy). Once recompiled without debugging, it worked just fine. I apologize for the false alarm. An aside. To the best of my knowledge OSS on Solaris, Net/OpenBSD (FreeBSDs OSS is fine though) is not your usual OSS but some reduced version which among other things only allows one open per device (meaning that to do both DAC/ADC one has to use single file descriptor) I have no idea. I know it worked, but wouldn't know how to test for that case you are talking about. From where i stand SDL as the default is a bad idea. Solaris without OSS audio doesn't have any other options. There is no ALSA, and AFAIK, there isn't an fmod either. However, I still think it is probably a good idea to have the QEMU_SDL_AUDIO device default to the audio subsystem that is defined (or defaulted to). Thoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
malc [EMAIL PROTECTED] wrote: On Mon, 26 Feb 2007, Ben Taylor wrote: [..snip..] From where i stand SDL as the default is a bad idea. Solaris without OSS audio doesn't have any other options. There is no ALSA, and AFAIK, there isn't an fmod either. However, I still think it is probably a good idea to have the QEMU_SDL_AUDIO device default to the audio subsystem that is defined (or defaulted to). Thoughts? I'm somewhat lost, there's no QEMU_SDL_AUDIO, furthermore there's no way to tell SDL what subsystem to use other than setting the environment variable. Sorry. I had a brain fart. I meant QEMU_AUDIO_DRV. And after looking at the code, it appears to be smart enough to pick the right audio subsystem. I just remember having to fiddle with QEMU_AUDIO_DRV when I was trying to figure out a previous problem with audio occurred (like 18 months ago) And to reiterate the point: NetBSD, OpenBSD and Solaris do not have full fledged OSS, they provide a wrapper that implements some basic functionality. The native thing for them is SUN audio[1] (more or less). And there's no QEMU driver for that. Options for those system include: OSS wrapper provided with the system, 4Front drivers and SDL (if it can use /dev/audio at all). Well, it appears to use SDL in that case where there is no OSS. Only 4Front's solution will allow DAC/ADC because it is basically full blown OSS implementation. Unless, ofcourse, native `/dev/audio' QEMU driver is written. [1] http://docs.sun.com/app/docs/doc/816-0222/6m6nmlssf?q=audioa=view Thanks for the clarification. Guess I'll just go ahead an use the OSS stuff. Regards, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Patch: allow Solaris to use OSS (OpenSound)
As I seem to have hit a wall with the ES1370 driver in qemu not working on Solaris, I have modified configure to allow Solaris to use OpenSoundSystems audio. Is there any interest in having a default audio setting for SDL so that you won't have to always put QEMU_SDL_AUDIO=oss before you start qemu? Ben diff -ruN qemu-ORIG/configure qemu/configure --- qemu-ORIG/configure 2007-02-15 17:58:18.0 -0500 +++ qemu/configure 2007-02-25 20:26:11.270139000 -0500 @@ -221,6 +221,8 @@ ;; --fmod-inc=*) fmod_inc=$optarg ;; + --enable-oss) oss=yes + ;; --enable-mingw32) mingw32=yes ; cross_prefix=i386-mingw32- ; linux_user=no ;; --disable-slirp) slirp=no @@ -289,6 +291,7 @@ echo --enable-coreaudio enable Coreaudio audio driver echo --enable-alsaenable ALSA audio driver echo --enable-fmodenable FMOD audio driver +echo --enable-oss enable OSS audio driver echo --enabled-dsound enable DirectSound audio driver echo --enable-system enable all system emulation targets echo --disable-system disable all system emulation targets @@ -619,6 +622,16 @@ fmod_support= fi echo FMOD support $fmod $fmod_support +if test $oss = yes; then +if test $solaris = yes ! test -f /usr/include/sys/soundcard.h ; then +echo +echo Error: /usr/include/sys/soundcard.h not found +echo Error: You must install OSS to use the oss module +echo +exit 1 +fi +fi +echo OSS support $oss echo kqemu support $kqemu echo Documentation $build_docs [ ! -z $uname_release ] \ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get 1280x1024 display from guest running Xorg?
Robin Atwood [EMAIL PROTECTED] wrote: This has been driving me mad! I have just installed Solaris 10 under Qemu and specified the Xorg server to be used. I created xorg.conf with xorgconfig and X started fine at 1024x768 using the Cirrus driver. When I edited xorg.conf to specify a 1280x1024 display, the Xorg.0.log file showed no mode. You may have to define HorizSync and VertRefresh in the xorg.conf file. I have a nexenta alpha 6 with updates that just comes up in 1280x800 by setting the HorizSync value in the xorg.conf. Now, I have both Win XP and Plan 9 running at 1280x1024, so I booted up XP and poked around the Display/Settings dialog and determined XP was running the display at 1280x1024 at 43Hz interlaced and 16 bit colour. So you also need to define DefaultDepth in the xorg.conf file. So, using the handy http://xtiming.sourceforge.net site, I generated a mode line like XP's and added it to the xorg.conf file. X refused the interlaced mode so I tried an uninterlaced one at 43Hz. That kind of worked but only rendered half the screen! Everything else I tried got rejected as bad mode... Since the virtual monitor doesn't specify EDID, it is unlikely to be able to handle resolutions over the basic ones. I know that a while ago (maybe 18 months) I was able to get something like 1156x864 out of the adapter with early versions of Solaris express. . So does someone have a magic modeline or xorg.conf to get Xorg going in a guest at high-res? There's another guy on the Linux-under-Qemu forum with the same problem hosting Ubuntu. I am using qemu 0.9, FWIW. Probably a combination of HorizSync/VertRefresh in the monitor section, DefaultDepth in the Screen section, and a mode line, you might get what you want. HTH, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get 1280x1024 display from guest running Xorg?
Robin Atwood [EMAIL PROTECTED] wrote: On Wednesday 21 Feb 2007, Julian Seward wrote: (replying off list) So you have Solaris 10 (x86 ?) running on qemu-0.9 ? Is it stable? Does it work? I have it running on vmware-5.5.3 but would prefer to move to running it on qemu if possible; however I've had mixed results with qemu in the past and don't want to spend loads of time on failed attempts to get it to work. Hence the question. It was a great battle to install but now it is stable. Do the following things: 1. install from the DVD image 2. Use the text console install 3. At the end of the install, backup the image file *before* the first reboot This is a good recommendation for any install. I know I must have 4-5 copies of my working Win98SE and WinXPHome images. 4. If during the first boot of the image, you get a segfault, restore and try again until you get to a prompt. Ignore any service failures. (the filesystem seems prone corruption at the first boot.) How much memory are you giving the virtual machine. Solaris 10 really needs 384MB and more like 512 for S10U3 to run reasonably. 5. If you have problems caused by damaged files, re-install choosing the Update option: this will restore the damaged files. That really sounds like a problem with the checksum of the DVD iso or a bad DVD burn. I must have burned 4-5 copies of S10U3 this weekend and finally got a DVD-RW to work with no errors after writing it on one machine, pulling the DVD writer and putting on the machine to install. After that, I was able to boot reliably into X. However, the filesystem seems very fragile if not shut down cleanly, so take regular backups! That's very odd. Solaris's UFS is a very stable file system. I'll give it a whirl and see how it goes. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Expanding the size of the vram for GDM5446?
I was wondering about the possibility of expanding the amount of vram for the Cirrus Logic GDM5446 emulation. 8MB of ram would give the ability to do 1600x1200 24 bit color. I know, this would probably completely break windows and other drivers, but am wondeirng if the Cirrus Xorg driver could deal with the extra memory, or could be easily modified to accept it. Thoughts? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: updated solaris tap patch
This patch against current CVS is an update of the previously posted Solaris
TAP patch. This small change fixes a large performance problem with
inbound packets (scp, ftp). The author found that some packets were
concatenated, which was the reason for the poor performance. This patch
fixes the handling of inbound packets and the performance problem.
Using the tap to the localhost, downloaded several 50MB files
(1.6MB/sec-4.0MB/sec)
and using the bridge, downloaded a 60MB file from an external host and
got 649 KB/sec.
Thanks again to Sittichai Palingsong for the quick fix.
diff -ruN qemu-ORIG/vl.c qemu/vl.c
--- qemu-ORIG/vl.c 2007-02-10 16:50:42.0 -0500
+++ qemu/vl.c 2007-02-12 14:25:35.211509000 -0500
@@ -55,6 +55,21 @@
#include malloc.h
#include linux/rtc.h
#include linux/ppdev.h
+#else
+#include sys/stat.h
+#include sys/ethernet.h
+#include sys/sockio.h
+#include arpa/inet.h
+#include netinet/arp.h
+#include netinet/in.h
+#include netinet/in_systm.h
+#include netinet/ip.h
+#include netinet/ip_icmp.h // must come after ip.h
+#include netinet/udp.h
+#include netinet/tcp.h
+#include net/if.h
+#include syslog.h
+#include stropts.h
#endif
#endif
#endif
@@ -3199,7 +3214,15 @@
uint8_t buf[4096];
int size;
+#ifdef __sun__
+struct strbuf sbuf;
+int f = 0;
+sbuf.maxlen = sizeof(buf);
+sbuf.buf = buf;
+size = getmsg(s-fd, NULL, sbuf, f) =0 ? sbuf.len : -1;
+#else
size = read(s-fd, buf, sizeof(buf));
+#endif
if (size 0) {
qemu_send_packet(s-vc, buf, size);
}
@@ -3242,10 +3265,135 @@
return fd;
}
#elif defined(__sun__)
+#define TUNNEWPPA (('T'16) | 0x0001)
+/*
+ * Allocate TAP device, returns opened fd.
+ * Stores dev name in the first arg(must be large enough).
+ */
+int tap_alloc(char *dev)
+{
+int tap_fd, if_fd, ppa = -1;
+static int ip_fd = 0;
+char *ptr;
+
+static int arp_fd = 0;
+int ip_muxid, arp_muxid;
+struct strioctl strioc_if, strioc_ppa;
+int link_type = I_PLINK;;
+struct lifreq ifr;
+char actual_name[32] = ;
+
+memset(ifr, 0x0, sizeof(ifr));
+
+if( *dev ){
+ ptr = dev;
+ while( *ptr !isdigit((int)*ptr) ) ptr++;
+ ppa = atoi(ptr);
+}
+
+/* Check if IP device was opened */
+if( ip_fd )
+ close(ip_fd);
+
+if( (ip_fd = open(/dev/udp, O_RDWR, 0)) 0){
+ syslog(LOG_ERR, Can't open /dev/ip (actually /dev/udp));
+ return -1;
+}
+
+if( (tap_fd = open(/dev/tap, O_RDWR, 0)) 0){
+ syslog(LOG_ERR, Can't open /dev/tap);
+ return -1;
+}
+
+/* Assign a new PPA and get its unit number. */
+strioc_ppa.ic_cmd = TUNNEWPPA;
+strioc_ppa.ic_timout = 0;
+strioc_ppa.ic_len = sizeof(ppa);
+strioc_ppa.ic_dp = (char *)ppa;
+if ((ppa = ioctl (tap_fd, I_STR, strioc_ppa)) 0)
+ syslog (LOG_ERR, Can't assign new interface);
+
+if( (if_fd = open(/dev/tap, O_RDWR, 0)) 0){
+ syslog(LOG_ERR, Can't open /dev/tap (2));
+ return -1;
+}
+if(ioctl(if_fd, I_PUSH, ip) 0){
+ syslog(LOG_ERR, Can't push IP module);
+ return -1;
+}
+
+if (ioctl(if_fd, SIOCGLIFFLAGS, ifr) 0)
+ syslog(LOG_ERR, Can't get flags\n);
+
+snprintf (actual_name, 32, tap%d, ppa);
+strncpy (ifr.lifr_name, actual_name, sizeof (ifr.lifr_name));
+
+ifr.lifr_ppa = ppa;
+/* Assign ppa according to the unit number returned by tun device */
+
+if (ioctl (if_fd, SIOCSLIFNAME, ifr) 0)
+syslog (LOG_ERR, Can't set PPA %d, ppa);
+if (ioctl(if_fd, SIOCGLIFFLAGS, ifr) 0)
+syslog (LOG_ERR, Can't get flags\n);
+/* Push arp module to if_fd */
+if (ioctl (if_fd, I_PUSH, arp) 0)
+syslog (LOG_ERR, Can't push ARP module (2));
+
+/* Push arp module to ip_fd */
+if (ioctl (ip_fd, I_POP, NULL) 0)
+syslog (LOG_ERR, I_POP failed\n);
+if (ioctl (ip_fd, I_PUSH, arp) 0)
+syslog (LOG_ERR, Can't push ARP module (3)\n);
+/* Open arp_fd */
+if ((arp_fd = open (/dev/tap, O_RDWR, 0)) 0)
+ syslog (LOG_ERR, Can't open %s\n, /dev/tap);
+
+/* Set ifname to arp */
+strioc_if.ic_cmd = SIOCSLIFNAME;
+strioc_if.ic_timout = 0;
+strioc_if.ic_len = sizeof(ifr);
+strioc_if.ic_dp = (char *)ifr;
+if (ioctl(arp_fd, I_STR, strioc_if) 0){
+syslog (LOG_ERR, Can't set ifname to arp\n);
+}
+
+if((ip_muxid = ioctl(ip_fd, I_LINK, if_fd)) 0){
+ syslog(LOG_ERR, Can't link TAP device to IP);
+ return -1;
+}
+
+if ((arp_muxid = ioctl (ip_fd, link_type, arp_fd)) 0)
+syslog (LOG_ERR, Can't link TAP device to ARP);
+
+close (if_fd);
+
+memset(ifr, 0x0, sizeof(ifr));
+strncpy (ifr.lifr_name, actual_name, sizeof (ifr.lifr_name));
+ifr.lifr_ip_muxid = ip_muxid;
+ifr.lifr_arp_muxid = arp_muxid;
+
+if (ioctl (ip_fd, SIOCSLIFMUXID, ifr) 0)
+{
+ ioctl (ip_fd, I_PUNLINK , arp_muxid);
+ ioctl (ip_fd, I_PUNLINK, ip_muxid);
+ syslog
Re: [Qemu-devel] Can I run FC4 inside Qemu on Sparc?
Neo Jia [EMAIL PROTECTED] wrote: hi, I am wondering if I can do this - running FC4 inside Qemu on Sparc. From opensolaris website, it seems that qemu 0.8.2 can be built but not sure if it can work correctly. http://www.opensolaris.org/os/project/qemu/ The current 0.9.0 CVS code plus the tap patch includes most of the patches in the opensolaris 0.8.2 port on the website. There are only a few minor patches which have not made it to CVS, and the current CVS code should build with no problems. If you're going to build it, you definitely want to get gcc3, and libsdl from blastwave.org, just to make it simpler. I know that my test systems when we did the original sparc work were Damn Small Linux, Win98SE and Solaris 10, so I'd be pretty comfortable saying it should run. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
Kevin F. Quinn [EMAIL PROTECTED] wrote: On Fri, 9 Feb 2007 22:48:51 + Paul Brook [EMAIL PROTECTED] wrote: I've very little sympathy (read: none) for people who accidentally break things by running them as root. On a related note, I've been running qemu(-system 0.8.2) as root recently as a hopefully temporary measure so that it can setup the network interfaces. Recent linux kernels require CAP_NET_ADMIN for the tun network configuration that qemu does (specifically the TUNSETIFF ioctl), and the only way to get the capability is to start the process as root. Other capabilities could be dropped; as indeed could CAP_NET_ADMIN once the network configuration is done, but that means modifications to qemu itself to release the capabilities, and would still leave qemu as a suid-root binary, which it would be nicer to avoid. Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. I just dealt with that. I got a patch for tap for Solaris and I have a setuid script that creates the tap and uses the /etc/qemu-ifup script to configure the interface, then calls a script with the file descriptor of the tap interface to a script which then invokes qemu with the right parameteres. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] qemu-gui status report
got patches? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Solaris kqemu patch
This patch allows for the opensolaris kqemu module to be activated under
a Solaris Express (11) host running qemu.
The solaris kqemu module is located at:
http://www.opensolaris.org/os/project/qemu/downloads/kqemu-osol-1.3.0pre9-v0.2.tar.gz
diff -ruN qemu-base/configure qemu/configure
--- qemu-base/configure 2007-01-05 16:25:54.0 -0500
+++ qemu/configure 2007-01-12 12:14:34.352357000 -0500
@@ -151,6 +151,11 @@
make=gmake
install=ginstall
solarisrev=`uname -r | cut -f2 -d.`
+if [ $cpu = i386 -o $cpu = x86_64 ] ; then
+if test $solarisrev -gt 10 ; then
+kqemu=yes
+fi
+fi
fi
# find source path
diff -ruN qemu-base/kqemu.c qemu/kqemu.c
--- qemu-base/kqemu.c 2006-10-02 13:58:33.0 -0400
+++ qemu/kqemu.c 2007-01-12 12:08:02.935409000 -0500
@@ -26,6 +26,9 @@
#include sys/mman.h
#include sys/ioctl.h
#endif
+#ifdef HOST_SOLARIS
+#include sys/modctl.h
+#endif
#include stdlib.h
#include stdio.h
#include stdarg.h
diff -ruN qemu-base/osdep.c qemu/osdep.c
--- qemu-base/osdep.c 2006-08-17 12:19:07.0 -0400
+++ qemu/osdep.c 2007-01-12 12:16:19.137607000 -0500
@@ -27,6 +27,10 @@
#include string.h
#include errno.h
#include unistd.h
+#ifdef HOST_SOLARIS
+#include sys/types.h
+#include sys/statvfs.h
+#endif
#include cpu.h
#if defined(USE_KQEMU)
@@ -86,13 +90,22 @@
const char *tmpdir;
char phys_ram_file[1024];
void *ptr;
+#ifdef HOST_SOLARIS
+struct statvfs stfs;
+#else
struct statfs stfs;
+#endif
if (phys_ram_fd 0) {
tmpdir = getenv(QEMU_TMPDIR);
if (!tmpdir)
+#ifdef HOST_SOLARIS
+tmpdir = /tmp;
+if (statvfs(tmpdir, stfs) == 0) {
+#else
tmpdir = /dev/shm;
if (statfs(tmpdir, stfs) == 0) {
+#endif
int64_t free_space;
int ram_mb;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] monitor help menu paging?
Anyone think that the monitor help screen ought to implement some kind of paging (think more) or something? I did a help, and half of the help is off the screen before I can figure out what I'm looking for (and apparently what I'm looking for is already scrolled off). THoughts? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] patch for block-raw.c for Solaris
This is a patch to make block-raw.c compile correctly on Solaris. I successfully created a raw image file after the patch was applied. Ben diff -ruN qemu-122806/block-raw.c qemu/block-raw.c --- qemu-122806/block-raw.c 2006-12-22 09:19:53.0 -0500 +++ qemu/block-raw.c 2006-12-28 15:46:31.282932000 -0500 @@ -44,6 +44,8 @@ #endif #ifdef __sun__ +#define _POSIX_PTHREAD_SEMANTICS 1 +#include signal.h #include sys/dkio.h #endif #ifdef __linux__ diff -ruN qemu-122806/vl.h qemu/vl.h --- qemu-122806/vl.h 2006-12-24 12:12:43.0 -0500 +++ qemu/vl.h 2006-12-28 15:49:43.181801000 -0500 @@ -45,6 +45,10 @@ #define O_BINARY 0 #endif +#ifdef __sun__ +#define ENOMEDIUM 4097 +#endif + #ifdef _WIN32 #include windows.h #define fsync _commit ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu block-raw.c block.c block_int.h qemu-doc.t...
Fabrice, Quick question about this patch (August 19, 2006) The ENOMEDIUM variable is dummy'd up for Windows in vl.h. I found that Solaris doesn't have an ENOMEDIUM variable, and I've been able to get block.c to compile correctly by adding this to vl.h. Before I go submitting anything, I just wanted to understand if I was heading in the right direction. thanks, Ben Fabrice Bellard [EMAIL PROTECTED] wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Fabrice Bellard bellard 06/08/19 11:45:59 Modified files: . : block-raw.c block.c block_int.h qemu-doc.texi vl.h Log message: better support of host drives CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.103r2=1.104 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.142r2=1.143 ___ 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
Re: [Qemu-devel] patch for supporting SMB on Solaris host
Lennert Buytenhek [EMAIL PROTECTED] wrote: On Fri, Dec 22, 2006 at 08:40:27PM -0500, Ben Taylor wrote: -snprintf(smb_cmdline, sizeof(smb_cmdline), /usr/sbin/smbd -s %s, - smb_conf); +snprintf(smb_cmdline, sizeof(smb_cmdline), % -s %s, + SMBD_BINARY, smb_conf); Doesn't look right to me? (s/%/%s/) Good catch. otherwise, the patch is better? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] patch for supporting SMB on Solaris host
Seeing as there is some working going on in the Solaris QEMU port again, here's a real short patch to support Samba working on a Solaris Host. --- qemu-ORIG/vl.c 2006-12-22 12:29:05.0 -0500 +++ qemu/vl.c 2006-12-22 14:22:17.338815000 -0500 @@ -3069,8 +3069,13 @@ fclose(f); atexit(smb_exit); +#ifdef __sun__ +snprintf(smb_cmdline, sizeof(smb_cmdline), /bin/env LC_ALL=C /usr/sfw/sbin/smbd -s %s, + smb_conf); +#else snprintf(smb_cmdline, sizeof(smb_cmdline), /usr/sbin/smbd -s %s, smb_conf); +#endif slirp_add_exec(0, smb_cmdline, 4, 139); } ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for supporting SMB on Solaris host
Paul Brook [EMAIL PROTECTED] wrote: On Friday 22 December 2006 21:29, Paul Brook wrote: On Friday 22 December 2006 20:07, Ben Taylor wrote: Seeing as there is some working going on in the Solaris QEMU port again, here's a real short patch to support Samba working on a Solaris Host. +#ifdef __sun__ +snprintf(smb_cmdline, sizeof(smb_cmdline), /bin/env LC_ALL=C /usr/sfw/sbin/smbd -s %s, + smb_conf); +#else Why does this have anything to do with solaris? Sorry, I was unclear. The /usr/swf bif is obviously a Solaris hack, and I think this is a bad way of implementing this. Well, I suppose I can write a configure hack to replace to definte the smbd binary, which will take about 30 seconds, hoping you'll find that more digestable. I don't see why the /bin/env LC_ALL bits have anything to do with Solaris. Let me inject a little humor. I'm american and speak only one language. The guy who did the patch is in germany and did it for a reason, though he never explained to me. In meantime, I will resubmit the patch without the /bin/env LC_ALL bits, hopefully to your liking and if it breaks on Solaris for some other reason, I'll be able to argue with you why it needs to be there. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for supporting SMB on Solaris host
Paul Brook [EMAIL PROTECTED] wrote: On Friday 22 December 2006 21:29, Paul Brook wrote: On Friday 22 December 2006 20:07, Ben Taylor wrote: Seeing as there is some working going on in the Solaris QEMU port again, here's a real short patch to support Samba working on a Solaris Host. +#ifdef __sun__ +snprintf(smb_cmdline, sizeof(smb_cmdline), /bin/env LC_ALL=C /usr/sfw/sbin/smbd -s %s, + smb_conf); +#else Why does this have anything to do with solaris? Sorry, I was unclear. The /usr/swf bif is obviously a Solaris hack, and I think this is a bad way of implementing this. I don't see why the /bin/env LC_ALL bits have anything to do with Solaris. Hopefully, you find this patch to be more reasonable. Bendiff -ruN qemu-ORIG/configure qemu-smb/configure --- qemu-ORIG/configure 2006-12-18 22:31:34.0 -0500 +++ qemu-smb/configure 2006-12-22 19:15:05.710251000 -0500 @@ -30,6 +30,7 @@ install=install strip=strip cpu=`uname -m` +smbd=/usr/sbin/smbd target_list= case $cpu in i386|i486|i586|i686|i86pc|BePC) @@ -150,6 +151,7 @@ make=gmake install=ginstall solarisrev=`uname -r | cut -f2 -d.` +smbd=/usr/sfw/sbin/smbd fi # find source path @@ -579,6 +581,7 @@ echo Documentation $build_docs [ ! -z $uname_release ] \ echo uname -r $uname_release +echo smbd $smbd if test $sdl_too_old = yes; then echo - Your SDL version is too old - please upgrade to have SDL support @@ -613,6 +616,7 @@ echo CFLAGS=$CFLAGS $config_mak echo LDFLAGS=$LDFLAGS $config_mak echo EXESUF=$EXESUF $config_mak +echo #define SMBD_BINARY \$smbd\ $config_h if test $cpu = i386 ; then echo ARCH=i386 $config_mak echo #define HOST_I386 1 $config_h diff -ruN qemu-ORIG/vl.c qemu-smb/vl.c --- qemu-ORIG/vl.c 2006-12-22 12:29:05.0 -0500 +++ qemu-smb/vl.c 2006-12-22 19:11:08.010585000 -0500 @@ -3069,8 +3069,8 @@ fclose(f); atexit(smb_exit); -snprintf(smb_cmdline, sizeof(smb_cmdline), /usr/sbin/smbd -s %s, - smb_conf); +snprintf(smb_cmdline, sizeof(smb_cmdline), % -s %s, + SMBD_BINARY, smb_conf); slirp_add_exec(0, smb_cmdline, 4, 139); } ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] patch for supporting SMB on Solaris host
Paul Brook [EMAIL PROTECTED] wrote: On Friday 22 December 2006 21:29, Paul Brook wrote: On Friday 22 December 2006 20:07, Ben Taylor wrote: Seeing as there is some working going on in the Solaris QEMU port again, here's a real short patch to support Samba working on a Solaris Host. +#ifdef __sun__ +snprintf(smb_cmdline, sizeof(smb_cmdline), /bin/env LC_ALL=C /usr/sfw/sbin/smbd -s %s, + smb_conf); +#else Why does this have anything to do with solaris? Sorry, I was unclear. The /usr/swf bif is obviously a Solaris hack, and I think this is a bad way of implementing this. I don't see why the /bin/env LC_ALL bits have anything to do with Solaris. Hopefully, you find this patch to be more reasonable. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] configure flag for compilation question..
Ishwar Rattan [EMAIL PROTECTED] wrote: Trying to compile qemu on amd64 based Solaris. I do not have write permission to /usr/local subtree ./configure --libdir=other-path --prefix=not-ustlocal is fine but make always generates binaries that want to find /usr/local/lib/libSDL-1.2.so.0 etc. (checked with ldd). What is the way out for this sticky point? Manually add -L/usr/local/lib -R/usr/local/lib to the Makefile for the link phase so it will correctly add those paths to the library lookup. If I had a code base to look at this instance, I could tell you where. You could also add those flags to Makefile.target in the SOLARIS specific areas, which would probably make more sense. As Martin indicated, setting LD_LIBRARY_PATH may get you a running binary, but LD_LIBRARY_PATH is the wrong answer for Solaris. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] configure flag for compilation question..
Ishwar Rattan [EMAIL PROTECTED] wrote: Trying to compile qemu on amd64 based Solaris. I do not have write permission to /usr/local subtree ./configure --libdir=other-path --prefix=not-ustlocal is fine but make always generates binaries that want to find /usr/local/lib/libSDL-1.2.so.0 etc. (checked with ldd). What is the way out for this sticky point? Manually add -L/usr/local/lib -R/usr/local/lib to the Makefile for the link phase so it will correctly add those paths to the library lookup. If I had a code base to look at this instance, I could tell you where. You could also add those flags to Makefile.target in the SOLARIS specific areas, which would probably make more sense. As Martin indicated, setting LD_LIBRARY_PATH may get you a running binary, but LD_LIBRARY_PATH is the wrong answer for Solaris. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] configure flag for compilation question..
Martin Bochnig [EMAIL PROTECTED] wrote: Ben Taylor wrote: As Martin indicated, setting LD_LIBRARY_PATH may get you a running binary, but LD_LIBRARY_PATH is the wrong answer for Solaris. My answer had been a bit longer: Read ld.so.1(1) i.e. # man ld.so.1 Then: *One* option is to set $LD_LIBRARY_PATH (or potentially $LD_LIBRARY_PATH_64 [not required]). I'm not saying it doesn't work. But properly compiled programs for Solaris include the run time paths to the libraries so an LD_LIBRARY_PATH environment variable is not required. LD_LIBRARY_PATH is interesting to test out new versions of support libraries without actually having to recompile, so it has it's uses. but too often, folks use LD_LIBRARY_PATH as a panacea on Solaris to fix poorly compiled programs. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] configure flag for compilation question..
Martin Bochnig [EMAIL PROTECTED] wrote: Ben Taylor wrote: Ishwar Rattan [EMAIL PROTECTED] wrote: Trying to compile qemu on amd64 based Solaris. I do not have write permission to /usr/local subtree ./configure --libdir=other-path --prefix=not-ustlocal is fine but make always generates binaries that want to find /usr/local/lib/libSDL-1.2.so.0 etc. (checked with ldd). What is the way out for this sticky point? Manually add -L/usr/local/lib -R/usr/local/lib Rather -L/his/home/sdl_amd64/lib -R/his/home/sdl_amd64/lib Yeah, that. brain fart when I was typing that. Because I doubt, an amd64 version of libSDL is currently present in /usr/local/lib/amd64 (and he doesn't have w access). Right. I knew what I meant, I just didn't type it right. This method is btw not really new to me, see my posting from a few hours ago: http://www.opensolaris.org/jive/thread.jspa?threadID=15448tstart=0 to the Makefile for the link phase so it will correctly add those paths to the library lookup. If I had a code base to look at this instance, I could tell you where. You could also add those flags to Makefile.target in the SOLARIS specific areas, which would probably make more sense. As Martin indicated, setting LD_LIBRARY_PATH may get you a running binary, but LD_LIBRARY_PATH is the wrong answer for Solaris. Ben LD_LIBRARY_PATH is the wrong answer for Solaris ??? --- Weak statement. LD_LIBRARY_PATH is the wrong answer for Solaris. It's great for trying to fix problems like this when the app won't run with a particular set of libraries, or you're testing with new libraries and you don't want to recompile (I've done this before). Too many people use it as a panacea for poorly compiled/configured Open source software. In this case, he might just set the LD_LIBRARY_PATH and never recompile it, even though it won't work if it uses the default LIB path. It has its [dis]advantages. Namely that the paths to a library are _not_ hardwired. But then that requires a dependency on knowing where your libraries are, and could possibly create an imcombaility by overriding a library path for some other application that is also leaning on LD_LIBRARY_PATH. Obviously you can get around this by encapsulating each application requiring LD_LIBRARY_PATH, thereby negating the need for a user or system wide LD_LIBRARY_PATH variable. That's the exactly reason, why I did recommend it in this very scenario. In this case, I can agree for the purposes of a test. But it also indicates that some work is required for the Solaris port if other library paths need to be linked in during the compliation/link phase. And I would do it again for Ishwar's current needs. Works for me. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] configure flag for compilation question..
Ishwar Rattan [EMAIL PROTECTED] wrote: On Fri, 13 Oct 2006, Martin Bochnig wrote: Ishwar Rattan wrote: Where is the problem 64bit versus 32bit ? (32 bit version of libSDL-1.2.so.0 found while amd64 64bit version needed?) (should go under /usr/local/lib/amd64/libSDL-1.2.so.0) Well, the problem is I do not root privileges so can't place libSL in /usr/local/lib or /usr/local/lib/amd64. I would like to keep it in $HOME/lib and want qemu to see the lib archive. I will try LD_LIBRARY_PATH option. It should work. the main thing is to not to agressive with LD_LIBRARY_PATH in this case. Since it sounds like it already may be linking against /usr/local/lib where the current libSDL is, you should just be able to add the new lib dir to the LD_LIBRARY_PATH env variable, and then run ldd on qemu to make sure it's finding the right libraries. When you have the right LD_LIBRARY_PATH, then it should be working for you. Is to possible to have a staticly linked version of libSDL in the qemu binaries? There is an option for statically linked libSDL in the qemu binaries, and I tried to make sure I kept that intact for solaris in the configure script. Try it and see what happens. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Blue Swirl [EMAIL PROTECTED] wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. This s reminds me of Java. Except that Java VM is not suitable target for all classes of programming languages, like C. I wondered if you could use the host's native java as an extension inside the qemu host to improve java runtime performance in the qemu guest. But that sounds way to convoluted to work. :-) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
Alessandro Corradi [EMAIL PROTECTED] wrote: Hi all, This is my question: If I run qemu for i386 without kqemu it uses soft-mmu, so it operates as another architetture as ppc or mips right? So... are the performace of qemu the same if I use i386 or mips or something change deeply? Example: if I run the same program on i386 emulation without kqemu or on mips are the performance circa the same? Would you expect qemu to perform the same on an AMD 4600X2 as a 400 Mhz MIPS? It's probably all relative to the speed of the cpu, host OS, compiler optimizations and trans cpu data transforms, as to how well the emulated system performs. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Soft float for Sparc32/64 (update)
Blue Swirl [EMAIL PROTECTED] wrote: Last time I missed a lot of the functions, this version should be complete. I see no difference in operation with or without the patch. Comments? Other than it didn't apply against the current CVS? Was there a requirement for a previous patch you posted which hasn't been applied to CVS? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: floppy controller missing in acpi tables
Paul Jakma [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Ben Taylor wrote: (ITU), such as the DiskUpdate on tools.de/solaris/itu/DU.zip which has a modifed RTL8029 driver that works with Qemu on SolarisX86. Obviosly, if you boot a Solaris 10/x86 install with -B acpi-user-options=0x0, you will not see the floppy. (I see that a patch is in the works for OpenSolaris, so eventually this will be fixed for good on Solaris). Excellent, thanks Ben and Juergen. FWIW, the RTL8139 NIC in current Qemu /ought/ to work with the 'rtls' driver included with Solaris. I havn't managed to test this yet as Qemu CVS /seems/ still to have timeout issues with Solaris NV 39 (booting from the install CD at least). You have to turn off atapi-cd-dma-enabled at the initial solaris grub boot prompt like: hit e on the primary solaris install add ,-B atapi-cd-dma-enabled=0 to the line then hit b to boot. That should get you a working install. Also, there was an AMD PCNet patch for Qemu (by Anthony Curtis). Which (possibly) Xen are using, but it is not included with Qemu. Solaris has a driver for this, based on the newer 'GLDv2' NIC driver framework. I tried quickly (ie i spent 5 minutes on it) porting Anthony's patch to the updated VLAN-client framework in Qemu, it gets recognised by the Solaris miniroot, but I must have missed something / made a mistake as Qemu crashes. Just use the ITU from Juergen. I've installed solaris express b39 and used the ni driver from the ITU and ti works like a champ. (Juergen modified Murayama's ni (ne2000) driver to work correctly with qemu). Ben regards, -- Paul Jakma[EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Power is poison. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: RE : Re: [Qemu-devel] Windows Vista
Christian MICHON [EMAIL PROTECTED] wrote: no the error message from vista is explicit: no acpi, no boot. On 6/9/06, Sylvain Petreolle [EMAIL PROTECTED] wrote: --- Nigel J. Terry [EMAIL PROTECTED] a écrit : Yes you do need ACPI to get the .iso to boot. I tried it and it failed. You also need 512M of ram and the ability to accept that your PC will BSOD often :-) I'll stick with FC5 Nigel You could try -no-acpi switch perhaps. ReactOS has problems with the ACPI features too. Does the ACPI patch that was posted a couple of weeks ago for Solaris/X86 support help at all? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Typo in get_reloc_expr (dyngen.c)
Fabrice or Paul: Can we get this added? This patch has been posted to the list 4 or 5 times in various incarnations in the last year or soj. I posted a long message with the logs from the compile on why the current code is wrong, and why this patch fixes it. The basic problem is that code uses a sizeof construct, instead of the size of the string. What happens is all the labels end up being truncated, and the op.c won't compile on sparc. see analysis of this problem in http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00494.html Ben Stuart Brady [EMAIL PROTECTED] wrote: Hi, There's a small bug in get_reloc_expr in dyngen.c. It should only affect SPARC hosts, but it can't be causing any real problems, or someone would have noticed it by now. I'm trying to port QEMU to PA-RISC[0], and needed this code, so it did actually affect me. I've attached the (one-line) patch. -- Stuart Brady [0] http://homepage.ntlworld.com/wholehog/stuart/qemu/guest.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] getting the 5446 in 1152x864 mode
Julian Seward [EMAIL PROTECTED] wrote: Using the latest cvs sources on x86 SuSE 10.0 host, Win2K guest, the 1152x864 mode offered to me by Windows doesn't work. Instead I just get moved to 640x480, it looks like. The modes on either side of it - 1024x768 and 1280x1024 work fine. Is 1152x864 supported by the driver? I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver so there must be something else that's causing you problems. I think I've gotten win98se to do it as well. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] work needed to get solaris to boot under qemu-system-sparc
Paul Brook [EMAIL PROTECTED] wrote: On Thursday 25 May 2006 14:16, Ben Taylor wrote: The question came up a little while back about getting Solaris (Sparc) to boot in qemu under qemu-system-sparc. I did a little work yesterday to find out that the boot process in hw/sun4m.c is really kind of hard wired for a linux boot. If there is no kernel or initrd, it drops right through. In reality, if those variables aren't set, and the boot device is cdrom, shouldn't there be some code to load the boot block in slice 3 of the cd/dvd? At worst case, it seems that we could probably extract the boot block and force qemu to load that with the hope of getting a solaris/sparc on qemu started, since slice 1 of the cd/dvd is the kernel and root directory structure. Slice 0 is the install media. Ideas? I'm neck deep in the pool and have no idea where to start. Real sun SPARC systems use an OpenFirmware (aka OpenBoot) based system. Right. http://www.openbios.org/ indicates there is a qemu/sparc port in progress. well, interestingly enough, trying to boot a Solaris 10U1 sparc cd with qemu-system-sparc (32-bit) comes up and says this hw is not supported. So the boot block appears to be getting read. I tried configuring with --target-list=sparc64-softmmu, but got an error when I tried to run it, saying: /tmp/qemu5/share/qemu/proll-sparc64.elf: No such file or directory qemu: could not load prom '/tmp/qemu5/share/qemu/proll-sparc64.bin' attempting to copy the proll.elf to proll-sparc64.elf ended up in a core dump with this message to start: fatal: Trap 0x0010 while trap level is MAXTL, Error state I wouldn't have thought that the proll would have needed to be 64-bit. is this just a feature of the sparc64 code not getting too much exercise? I'll try somore more tests with earlier versions of Solaris and the sparc32 module. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu-0.8.1 and Belneix-0.4.3?
Ishwar Rattan [EMAIL PROTECTED] wrote: Any one has had success with this combination? Haven't tried it yet. Also, anyone running any x86 version of Solaris under qemu? I would like a copy of the disk-image if possible. Depending on the version of Solaris x86 you want to run, the best way to get Solaris running is to apply the acpi patch that was posted to the list (and run the iasl against it to create the hex file) and grab a dvd image (or burn the dvd if short of the 2.5G that the dvd images requires) and install Solaris. Hints for installing Solaris under qemu: 1) At a minimum, you will need at least a 4-5GB qemu image file to load all of Solaris on. Even the developer subset is probably around 3GB. a bare minimum install is a 3-400MB, but is barely usable unless you like a bare system with no X. 2) solaris 8/9/10 FCS - at least 256 MB of memory, 384 is better. solaris 10 U1 or better, or Solaris Express (11) really needs 384 at a bare minimum or 512 to do the graphical install. I prefer the text install, just to keep the overhead down. You can configure the xorg driver to do 1152x864 (IIRC) at the maximum resolution. Default should be around 1024x768. You can also do this very easily post reboot if you've done a text install. (Though build 38 or 39 of Solaris Express does a really job of picking the right resolution for displaying) 3) If loading S10U1 or Solaris express (11), you'll need to edit the initial grub boot menu, and add ,atapi-cd-dma-enabled=0 after the -B install something or other I can't remember right now While I haven't installed 8, 9 or 10FCS recently, you may or may not have to go into the DCS (Device configuration setup), and modify the parameter acpi-user-options=0x2. This will be F4 at the boot device selection menu. I haven't tested this these older releases with the acpi patch, so you might not have to do this. 4) Download the DU Install Time Update (ITU) floppy from tools.de/solaris/itu. There is one for Solaris 9/10, and one for Solaris Express (Nevada). This driver disk has a modified version of Murayama's ni driver (ne2000) that works with qemu. For Solaris 9 and 10/FCS, you will hit F4 in the DCS menu to install the ITU. For Solaris Express and Solaris 10 U1 or later, you will have to do it once the machine is booted (IIRC, select #5). The ACPI patch is important here because Sun's grub boot code doesn't correctly enumerate an ISA floppy. The ACPI patch allows Solaris to recognize the floppy, and therefore you can do an Install time update. HTH, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] objective benchmark?
Kazu [EMAIL PROTECTED] wrote: Tuesday, May 16, 2006 3:55 PM Christian MICHON wrote: how can we do the same if the host is winXP ? Today, on linux guests, 2.4.x kernel boot faster than 2.6.x kernel inside qemu (unless using clock=pit on 2.6.x). 2 days ago, when I tried to setup Solaris x86 10 guest inside winXP host, I gave up since the timing engine inside the guest seems slow. I would really like to know how to solve this on XP hosts. RTC is not used on Win host. SpeedStep/PowerNow! is disabled by changing miminal power management to other items at Control Panel-Power Option-Power Management Setting. I don't think it is necessary to set it if your PC is ACPI. Set it if the clock of win2k guest is faster than the real time while IE is running. It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I don't know why Solaris x86 10 doesn't work. add ,atapi-cd-dma-enabled=0 to the boot line when installing. The QEMU IDE controller doesn't implement DMA (or dma correctly). If you don't give a Solaris VM enough memory, the installer (java) will coredump, and it appears that it's running out of memory. Once you've got Solaris 10 X86 installed, you'll need to get the Disk Update from http://tools.de/solaris/itu/DU.zip. Normally you could do an Install Time Update to add this driver disk, but Qemu doesn't implement a floppy in ACPI (I'm testing patches now to see if that fixes the problem), and some folks are working on OpenSolaris to fix the enumeration of the floppy on the emulated ISA bus (or when -no-acpi is called). So the trick to getting the NIC driver into Solaris 10x86 is to call QEMU with the DU.img as hdd. Then once Solaris is booted, you do the following: mount -F pcfs /dev/dsk/c1d1p0:c /mnt cd /mnt/DU/210/i86pc/Product cp ni.Z /var/tmp uncompress ni.Z cpio -idvm ni pkgadd -d . CSWni At this point, it's probably easier just to do a sys-unconfig so that Solaris 10/x86 with redo it's networking for DHCP. (tun/tap support is not in qemu for Solaris yet) HTH, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: PATCH: Solaris/Sparc patch against yesterdays' BGR CVS update
Ben Pfaff [EMAIL PROTECTED] wrote: Ben Taylor [EMAIL PROTECTED] writes: Enclosed is the latest version of the qemu solaris/sparc patch, applied against yesterday's CVS (post BGR update). I'm happy to say that this patch makes qemu compile and work on Solaris quite nicely for me. I did have to invoke configure with --extra-ldflags=-lsocket (and fix configure to put $LDFLAGS in the libSDL probing commands). Odd. It may have something to do with your localized copy of libSDL. The one from blastwave doesn't require -lsocket. I've been using a version of these patches for a year, and never ran into that problem. I also had to override the configure script's desire to use /usr/ucb/install instead of GNU install. The configure script wants to use ginstall, assuming you've got it in your path. I did not use install because there are several variations of install on Solaris, and configure is coded to make sure you don't use them. It recommends /usr/ucb/install if you don't have GNU install (or it can't find it because it's looking for ginstall). I'll have to check the logic to make sure The former won't let me install without being root, because it wants to install everything as a staff account; the latter will. That's a localized configuration requirement you have, and that configure should probably not try to take into account. Thanks for making this work! You're welcome. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
