[Qemu-devel] [PATCH] enhance gdbstub to support x86-64
The following patch adds x86-64 support to gdbstub. Please consider for
inclusion.
Index: gdbstub.c
===
--- gdbstub.c (revision 2399)
+++ gdbstub.c (revision 2400)
@@ -175,10 +175,144 @@
return 0;
}
-#if defined(TARGET_I386)
+#if defined(TARGET_X86_64)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
+uint8_t *p = mem_buf;
+int i, fpus;
+
+#define PUTREG(x) do { \
+ target_ulong reg = tswapl(x); \
+ memcpy(p, ®, sizeof reg); \
+ p += sizeof reg; \
+} while (0)
+#define PUTREG32(x) do { \
+ uint32_t reg = tswap32(x); \
+ memcpy(p, ®, sizeof reg); \
+ p += sizeof reg; \
+} while (0)
+#define PUTREGF(x) do { \
+ memcpy(p, &(x), 10);\
+ p += sizeof (x);\
+} while (0)
+
+PUTREG(env->regs[R_EAX]);
+PUTREG(env->regs[R_EBX]);
+PUTREG(env->regs[R_ECX]);
+PUTREG(env->regs[R_EDX]);
+PUTREG(env->regs[R_ESI]);
+PUTREG(env->regs[R_EDI]);
+PUTREG(env->regs[R_EBP]);
+PUTREG(env->regs[R_ESP]);
+PUTREG(env->regs[8]);
+PUTREG(env->regs[9]);
+PUTREG(env->regs[10]);
+PUTREG(env->regs[11]);
+PUTREG(env->regs[12]);
+PUTREG(env->regs[13]);
+PUTREG(env->regs[14]);
+PUTREG(env->regs[15]);
+
+PUTREG(env->eip);
+PUTREG32(env->eflags);
+PUTREG32(env->segs[R_CS].selector);
+PUTREG32(env->segs[R_SS].selector);
+PUTREG32(env->segs[R_DS].selector);
+PUTREG32(env->segs[R_ES].selector);
+PUTREG32(env->segs[R_FS].selector);
+PUTREG32(env->segs[R_GS].selector);
+/* XXX: convert floats */
+for(i = 0; i < 8; i++) {
+PUTREGF(env->fpregs[i]);
+}
+PUTREG32(env->fpuc);
+fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
+PUTREG32(fpus);
+PUTREG32(0); /* XXX: convert tags */
+PUTREG32(0); /* fiseg */
+PUTREG32(0); /* fioff */
+PUTREG32(0); /* foseg */
+PUTREG32(0); /* fooff */
+PUTREG32(0); /* fop */
+
+#undef PUTREG
+#undef PUTREG32
+#undef PUTREGF
+
+return p - mem_buf;
+}
+
+static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf,
int size)
+{
+uint8_t *p = mem_buf;
+uint32_t junk;
+int i, fpus;
+
+#define GETREG(x) do { \
+ target_ulong reg; \
+ memcpy(®, p, sizeof reg); \
+ x = tswapl(reg); \
+ p += sizeof reg; \
+} while (0)
+#define GETREG32(x) do { \
+ uint32_t reg; \
+ memcpy(®, p, sizeof reg); \
+ x = tswap32(reg);\
+ p += sizeof reg; \
+} while (0)
+#define GETREGF(x) do { \
+ memcpy(&(x), p, 10); \
+ p += 10; \
+} while (0)
+
+GETREG(env->regs[R_EAX]);
+GETREG(env->regs[R_EBX]);
+GETREG(env->regs[R_ECX]);
+GETREG(env->regs[R_EDX]);
+GETREG(env->regs[R_ESI]);
+GETREG(env->regs[R_EDI]);
+GETREG(env->regs[R_EBP]);
+GETREG(env->regs[R_ESP]);
+GETREG(env->regs[8]);
+GETREG(env->regs[9]);
+GETREG(env->regs[10]);
+GETREG(env->regs[11]);
+GETREG(env->regs[12]);
+GETREG(env->regs[13]);
+GETREG(env->regs[14]);
+GETREG(env->regs[15]);
+
+GETREG(env->eip);
+GETREG32(env->eflags);
+GETREG32(env->segs[R_CS].selector);
+GETREG32(env->segs[R_SS].selector);
+GETREG32(env->segs[R_DS].selector);
+GETREG32(env->segs[R_ES].selector);
+GETREG32(env->segs[R_FS].selector);
+GETREG32(env->segs[R_GS].selector);
+/* XXX: convert floats */
+for(i = 0; i < 8; i++) {
+GETREGF(env->fpregs[i]);
+}
+GETREG32(env->fpuc);
+GETREG32(fpus); /* XXX: convert fpus */
+GETREG32(junk); /* XXX: convert tags */
+GETREG32(junk); /* fiseg */
+GETREG32(junk); /* fioff */
+GETREG32(junk); /* foseg */
+GETREG32(junk); /* fooff */
+GETREG32(junk); /* fop */
+
+#undef GETREG
+#undef GETREG32
+#undef GETREGF
+}
+
+#elif defined(TARGET_I386)
+
+static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
+{
uint32_t *registers = (uint32_t *)mem_buf;
int i, fpus;
@@ -545,7 +679,8 @@
char buf[4096];
uint8_t mem_buf[2000];
uint32_t *registers;
-uint32_t addr, len;
+target_ulong addr;
+uint32_t len;
#ifdef DEBUG_GDB
printf("command='%s'\n", line_buf);
--
error compiling committee.c: too many arguments to function
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compile errors on Solaris for qemu 0.8.2
I went ahead and made Leo's change and it built. Also, I bit the
bullet and used the blastwave compiler. However, I still get
segfaults trying to run sparc-test on qemu-system-sparc from my
sparc/solaris box. Is this a known issue? Also happens with mips.
On 7/24/06, Blue Swirl <[EMAIL PROTECTED]> wrote:
>I ran into this myself yesterday. I couldn't figure out a definitive
>answer, because I am no expert on the SPARC architecture, but it appears
>that at least on an UltraSparc IIi machine from a few years ago, the
>"sparc V9" instructions are supported. However, the gcc by default
>doesn't define __sparc_v9__ on that architecture. There are some -m
>flags that can be passed to gcc (like multisparc, etc.), but I'm not
>sure for what host machines they are appropriate exactly. Perhaps the
>SPARC experts on the list can comment more, but in the meantime, the
>following simple (but likely incorrect) patch worked fine for me:
Well, at least my gcc defines __sparc_v9__ if cpu is either v9, ultrasparc
or ultrasparc3:
%{mcpu=v9:-D__sparc_v9__} %{mcpu=ultrasparc:-D__sparc_v9__}
%{mcpu=ultrasparc3:-D__sparc_v9__}
This is from /usr/lib/gcc-lib/sparc-linux/3.3.5/specs. What does your
compiler define, as you still can compile the RDTICK instruction in the
#ifdef section? RDTICK is not available on V8 (Sparc32) architecture, only
on V9.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
--
--
Jonathan Kalbfeld
+1 323 620 6682
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [PATCH]some vnc enhancement
Hi Xiaowei, Fabrice had mentioned some interest in refactoring some of the SDL code so that the VC switching was shared between VNC/SDL. Not sure quite what he was thinking so hopefully he'll chime in. The only issue I see in the patch is that you're using the XK_ symbols. I purposefully didn't rely on those since they aren't available on Win32 and the VNC spec is suggests that the actual value of these symbols can vary greatly on different platforms (especially the control keys). Regards, Anthony Liguori Yang, Xiaowei wrote: Qemu 0.8 uses a written-from-scratch VNC implementation, which lacks of some original features. One thing is that it doesn't recognize ctrl+alt+1/2/3 to switch among screens. Another issue is VNC client may reset color depth after connection, so if we don't re-calculate color_table, monitor/console's background is abnormal. I made a patch to add them. Thanks, Xiaowei ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: high CPU load / async IO?
On Tue, 25 Jul 2006 00:51:23 +0200, Sven Köhler wrote: >> IDE only supports one outstanding request, so having a thread that runs >> the synchronous block routines appears reasonable. However, SATA and SCSI >> both support multiple outstanding requests. The extension to the existing >> patch would be simple--increase the number of threads. > > ??? > > Wasn't there another variant using the async-I/O support of the Host OS > and thereby supporting a larger number of outstanding requests? Not that I know of. Do you have a pointer? > The approch that i mentioned above (using the host's async I/O) is what > you mean with using linux-aio, right? It depends on what you mean by the host's async I/O implementation. >> So the current thread-based async dma patch is really just the wrong long >> term solution. A more long term solution is likely in the works. It >> requires quite a bit of code modification though. > > I see. So in other words: > > don't ask for simple async I/O now. The more complex and flexible > sollution will follow soon. Yes, hopefully really soon. Regards, Anthony Liguori > ___ > 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] Re QuickStartGuide on QEMU Wiki
Andrew Malcolmson wrote:
Here is a super short addition you might want to add to the
QuickStartGuide page,
A Wiki is something anybody can add improvements himself ;)
Create an empty 3 GB image file. You will be installing into this:
a)
{{{
qemu-img create mylinux.raw 3G
}}}
b)
Install from a downloaded iso file:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot d -net user -m 256
}}}
c)
Run the installation:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot c -net user -m 256
}}}
Mmh, sorry, but I didn't get the point here. What is the key
difference between the things above and
- your step (a) and QuickStartGuide step 2: creation of
blank disk image:
qemu-img create -f qcow c.img 3G
- your step (b) and QuickStartGuide step 3b: suppose you
have an install iso image, called my_os_install.iso. Then run:
qemu -cdrom my_os_install.iso -hda c.img -m 256 -boot d
already in QuickStartGuide?
Your step (c) is an extension of QuickStartGuide's "qemu
-hda c.img -m 256" which I think can be done by anybody who
understands the basics of QuickStartGuide on his own.
Let us keep the QuickStartGuide simple and easy and don't
explain every possible variant. For this anybody can use
http://fabrice.bellard.free.fr/qemu/qemu-doc.html
Regards
Dirk
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] sparc-softmmu
After openbios-sparc32 is introduced for sparc-softmmu, I can see a Linux penguin but can't see booting texts. This happens because OpenBIOS didn't understand Qemu's nographic flag and therefore the Linux console was not changed to the correct device. Adding 'console=/dev/tty0' to command line helps. The current version of OpenBIOS (SVN revision 71) supports the flag, so the sparc-test scripts work like with Proll. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: FreeBSD qemu 0.8.2 update - please test! (and usb cardreader SET_ADDR_FAILED)
On Mon, Jul 24, 2006 at 12:40:41AM +0200, Juergen Lock wrote: > With the help of Lonnie Mendez (he updated his usb host support patch) > I just put together an experimental qemu port update. For some reason > my usb cardreader didnt want to work today: > uhub1: device problem (SET_ADDR_FAILED), disabling port 1 > (anyone have an idea about this one? this is the first time i tried using > it since I updated this box to 6.1), so the usb host support is untested. > > To test usb best run qemu with -monitor stdio, then do `info usbhost' > when its running and then `usb_add host:' where x.y is the host > device you want to add (`plug into' the guest). also see the port's > pkg-message. some quick test have been done on usb now (cardreader started working again without me doing anything), also Bakul Shah tested usb with a w2k guest. usb is slow tho... (and watch out for the new pkg-message note below.) Also Jung-uk Kim made me aware that FreeBSD has clock_gettime(2) too and provided a patch to enable it. And I noted -kernel-kqemu doesnt seem to be faster than `regular' kqemu anymore (subjectively it once even seemd a little slower!), example startup time of root shell xterm on KANOTIX-2006-Easter-RC4.iso went up from maybe 5 to over 20 seconds, and qemu now takes some 30% cpu here even when the guest is idle. And, I got two qemu hangs (guest suddenly hangs completly, qemu eating 99% cpu) with -kernel-kqemu. So, if anyone has any ideas about this... (can the new timing code slow things down that much?) Oh, host has a single 2.0something GHz athlon cpu and 512 MB ram. new qemu port update below, enjoy, Juergen Removed files: files/patch-malc-17h_aqemu files/patch-sdl.c Index: Makefile === RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.53 diff -u -r1.53 Makefile --- Makefile23 Jul 2006 00:04:01 - 1.53 +++ Makefile23 Jul 2006 15:51:45 - @@ -6,8 +6,7 @@ # PORTNAME= qemu -PORTVERSION= 0.8.1 -PORTREVISION= 2 +PORTVERSION= 0.8.2 CATEGORIES=emulators MASTER_SITES= http://www.qemu.org/:release \ http://people.fruitsalad.org/nox/qemu/:snapshot \ Index: distinfo === RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.31 diff -u -r1.31 distinfo --- distinfo6 May 2006 16:15:41 - 1.31 +++ distinfo23 Jul 2006 15:52:26 - @@ -1,6 +1,6 @@ -MD5 (qemu/qemu-0.8.1.tar.gz) = 67d924324a5ab79d017bd97a1e767285 -SHA256 (qemu/qemu-0.8.1.tar.gz) = a1f83666f5c05eaee9bfc608a3a5034ad95d0fd3c99937bb399bf9235a6aa0c9 -SIZE (qemu/qemu-0.8.1.tar.gz) = 1623264 +MD5 (qemu/qemu-0.8.2.tar.gz) = 5b3a89eb2f256a8a6f3bb07f7b3f1b07 +SHA256 (qemu/qemu-0.8.2.tar.gz) = 2a20d811296c859d678bdd00aa7ca7951a641327234f3af144e822d078f3 +SIZE (qemu/qemu-0.8.2.tar.gz) = 1810909 MD5 (qemu/patch3_cirrus) = ebe7ed9fce804c49e024bc93bfdfc810 SHA256 (qemu/patch3_cirrus) = e862371834b7d895a896fbdb84fd9f70d17b5729a6f6789a48a61504fc941e11 SIZE (qemu/patch3_cirrus) = 8817 Index: pkg-descr === RCS file: /home/ncvs/ports/emulators/qemu/pkg-descr,v retrieving revision 1.3 diff -u -r1.3 pkg-descr --- pkg-descr 19 Jul 2005 06:06:56 - 1.3 +++ pkg-descr 23 Jul 2006 17:46:11 - @@ -12,9 +12,9 @@ cross-debugging. As QEMU requires no host kernel patches to run, it is very safe and easy to use. -(but kqemu is now also supported for the i386 on i386 case) +(but kqemu is now also supported for the i386 on i386 and amd64 case) See also the preconfigured system images on http://oszoo.org/ Many live cd isos also work. -WWW: http://fabrice.bellard.free.fr/qemu/ +WWW: http://qemu.org/ Index: pkg-message === RCS file: /home/ncvs/ports/emulators/qemu/pkg-message,v retrieving revision 1.13 diff -u -r1.13 pkg-message --- pkg-message 23 Jul 2006 00:04:01 - 1.13 +++ pkg-message 25 Jul 2006 17:12:19 - @@ -45,4 +45,9 @@ add path 'ugen*' mode 660 group operator corresponding rc.conf line: devfs_system_ruleset="ugen_ruleset" +- still usb: since the hub is no longer attached to the uchi controller +and the wakeup mechanism, resume interrupt is not implemented yet linux +guests will suspend the bus, i.e. they wont see devices usb_add'ed after +its (linux') uhci module got loaded. workaround: either add devices +before linux loads the module or rmmod and modprobe it afterwards. Index: pkg-plist === RCS file: /home/ncvs/ports/emulators/qemu/pkg-plist,v retrieving revision 1.15 diff -u -r1.15 pkg-plist --- pkg-plist 19 May 2006 08:17:54 - 1.15 +++ pkg-plist 23 Jul 2006 17:41:29 - @@ -13,7 +13,7 @@ %%DATADIR%%/vgabios.bin %%DATADIR%%/vgabios-cirrus
[Qemu-devel] Sparc32/64 linux-test errors
I get this error when running linux-test without any emulation on
Sparc32/64:
linux-test.c:477: itimer
Strace output:
setitimer(ITIMER_REAL, {it_interval={0, 1}, it_value={0, 1}}, NULL)
= 0
getitimer(ITIMER_REAL, {it_interval={0, 10998}, it_value={0, 10998}}) = 0
write(2, "linux-test.c:477: ", 18linux-test.c:477: ) = 18
Shouldn't the test run without errors?
Emulated Sparc32:
linux-test.c:221: No child processes (ret=-1, errno=10)
Strace output:
fork() = 24871
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigreturn(0x40149ff4)= 24871
mprotect(0x22000, 4096, PROT_READ|PROT_EXEC) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x22000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
rt_sigreturn(0x22b80) = -2073968511
waitpid(3, 0xbfffdd7c, 0) = -1 ECHILD (No child processes)
Problem with waitpid?
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: high CPU load / async IO?
>>> IDE only supports one outstanding request, so having a thread that runs >>> the synchronous block routines appears reasonable. However, SATA and SCSI >>> both support multiple outstanding requests. The extension to the existing >>> patch would be simple--increase the number of threads. >> ??? >> >> Wasn't there another variant using the async-I/O support of the Host OS >> and thereby supporting a larger number of outstanding requests? > > Not that I know of. Do you have a pointer? Hmm, perhaps i only heard people talking about it ... But if i find anything, i post the link. >>> So the current thread-based async dma patch is really just the wrong long >>> term solution. A more long term solution is likely in the works. It >>> requires quite a bit of code modification though. >> >> I see. So in other words: >> >> don't ask for simple async I/O now. The more complex and flexible >> sollution will follow soon. > > Yes, hopefully really soon. So i will wait patiently :-) signature.asc Description: OpenPGP digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QuickStartGuide on QEMU Wiki
Fabrice Bellard wrote: Thank you for the advices. I modified the web site: tell me if you see other problems. Just an idea: What's about splitting KQEMU kqemu-xxx.tar.gz into two archives, one for Linux and one for Windows? If Linux is tar.gz and Windows uses .zip, people don't need a third party tool to extract tar.gz under Windows. Regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Tue, Jul 25 2006, Sven Köhler wrote: > >>> So the current thread-based async dma patch is really just the wrong long > >>> term solution. A more long term solution is likely in the works. It > >>> requires quite a bit of code modification though. > >> > >> I see. So in other words: > >> > >> don't ask for simple async I/O now. The more complex and flexible > >> sollution will follow soon. > > > > Yes, hopefully really soon. > > So i will wait patiently :-) Is anyone actively working on this, or is it just speculation? I'd greatly prefer (and might do, if no one is working on it and Fabrice would take it) do a libaio version, since that'll for sure perform the best on Linux. But a posixaio version might be saner, as that should work on other operating systems as well. Fabrice, can you let people know what you would prefer? -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][RFC] configure changes to support cross compiling with mingw32
--enable-mingw32 hasn't ever worked for me. The follow patch is a set
of changes to configure so that --cross-prefix=i586-mingw32-msvc does
the right thing.
It needs some testing. It works for me but I don't know if people have
weird setups where the gcc cross prefix != the sdl cross prefix or
something odd like that.
Regards,
Anthony Liguori
# HG changeset patch
# User Anthony Liguori <[EMAIL PROTECTED]>
# Node ID 157550eed1f5e456a0f43167bd21bc14ad164d51
# Parent bda9c89460daa713765b316ea8ef1bfe7fd79091
A number of fixes to configure while getting cross compiling with mingw32 to
work.
Remove the --enable-mingw option. It hardcoded a cross-compile prefix and a
different prefix is used on the mingw32 tools on some distros. Now:
./configure --cross-prefix=i586-mingw32msvc- ...
will do the Right Thing so --enable-mingw is no longer needed.
Add a check after $cc includes the cross-compile prefix so we can determine
what the target really is (as opposed to using uname).
Remove the check for test -e for /usr/include/byteswap.h to a compile check.
This breaks cross compiling.
Add a check for zlib so that we give a nice error if zlib-devel is missing.
Use ${cross_prefix}sdl-config
When we exit, make sure to remove TMP files.
diff -r bda9c89460da -r 157550eed1f5 configure
--- a/configure Sat Jul 22 22:06:44 2006 +
+++ b/configure Tue Jul 25 15:13:19 2006 -0500
@@ -213,8 +213,6 @@ for opt do
;;
--fmod-inc=*) fmod_inc="$optarg"
;;
- --enable-mingw32) mingw32="yes" ; cross_prefix="i386-mingw32-" ; user="no"
- ;;
--disable-slirp) slirp="no"
;;
--enable-adlib) adlib="yes"
@@ -278,7 +276,6 @@ echo " --install=INSTALLuse spe
echo " --install=INSTALLuse specified install [$install]"
echo " --static enable static build [$static]"
echo " --enable-cocoa enable COCOA (Mac OS X only)"
-echo " --enable-mingw32 enable Win32 cross compilation with mingw32"
echo " --enable-adlib enable Adlib emulation"
echo " --enable-coreaudio enable Coreaudio audio driver"
echo " --enable-alsaenable ALSA audio driver"
@@ -301,6 +298,23 @@ ar="${cross_prefix}${ar}"
ar="${cross_prefix}${ar}"
strip="${cross_prefix}${strip}"
+# we really ought move the whole archecture check down here
+targetos=`$cc -dumpmachine`
+case $targetos in
+*-mingw32msvc)
+ mingw32="yes"
+ oss="no"
+ user="no"
+ linux="no" # hack
+ EXESUF=".exe"
+ if [ "$cpu" = "i386" ] ; then
+ kqemu="yes"
+ fi
+ ;;
+*)
+ ;;
+esac
+
# check that the C compiler works.
cat > $TMPC < $TMPC <
+int main(){(void)zlibVersion(); return 0;}
+EOF
+if $cc -o $TMPE $TMPC -lz 2>/dev/null; then
+zlib="yes"
+else
+zlib="no"
+fi
+
+if test "$zlib" = "no"; then
+echo "ERROR: QEMU requires the zlib library. You may have to install"
+echo "the development package."
+rm -f $TMPO $TMPC $TMPE $TMPS
+exit 1;
+fi
+
##
# SDL probe
@@ -448,15 +472,10 @@ sdl_too_old=no
if test -z "$sdl" ; then
-sdl_config="sdl-config"
+sdl_config="${cross-prefix}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
@@ -489,7 +508,6 @@ fi # static link
fi # sdl compile test
-fi # cross compilation
fi # -z $sdl
# Check if tools are available to build documentation.
@@ -540,7 +558,6 @@ if test "$sdl" != "no" ; then
if test "$sdl" != "no" ; then
echo "SDL static link $sdl_static"
fi
-echo "mingw32 support $mingw32"
echo "Adlib support $adlib"
echo "CoreAudio support $coreaudio"
echo "ALSA support $alsa"
@@ -573,6 +590,13 @@ config_h="config-host.h"
config_h="config-host.h"
#echo "Creating $config_mak and $config_h"
+
+have_header() {
+cat > $TMPC <
+EOF
+$cc -c -o $TMPO $TMPC 2>/dev/null
+}
echo "# Automatically generated by configure - do not modify" > $config_mak
echo "# Configured with: $0 $@" >> $config_mak
@@ -644,7 +668,7 @@ if test "$mingw32" = "yes" ; then
if test "$mingw32" = "yes" ; then
echo "CONFIG_WIN32=yes" >> $config_mak
echo "#define CONFIG_WIN32 1" >> $config_h
-elif test -f "/usr/include/byteswap.h" ; then
+elif have_header "/usr/include/byteswap.h" ; then
echo "#define HAVE_BYTESWAP_H 1" >> $config_h
fi
if test "$darwin" = "yes" ; then
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
Jens Axboe wrote: On Tue, Jul 25 2006, Sven Köhler wrote: So the current thread-based async dma patch is really just the wrong long term solution. A more long term solution is likely in the works. It requires quite a bit of code modification though. I see. So in other words: don't ask for simple async I/O now. The more complex and flexible sollution will follow soon. Yes, hopefully really soon. So i will wait patiently :-) Is anyone actively working on this, or is it just speculation? I'd greatly prefer (and might do, if no one is working on it and Fabrice would take it) do a libaio version, since that'll for sure perform the best on Linux. But a posixaio version might be saner, as that should work on other operating systems as well. Fabrice, can you let people know what you would prefer? I am working on an implementation and the first version will use the posix aio and possibly the Windows ReadFile/WriteFile overlapped I/Os. Anthony Liguori got a pre version of the code, but it is not commitable yet. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
