Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c

2006-07-08 Thread Paul Jakma 

On Tue, 4 Jul 2006, Fabrice Bellard wrote:

Note: I commited the pcnet patch as some people might be interested by it. I 
was unable to use it with a Knoppix distribution of 2003 so fixes are needed.


Hmm, define 'unable to use it'? It seems (on very quick testing) to 
work in Solaris.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
My problem lies in reconciling my gross habits with my net income.
-- Errol Flynn

Any man who has $10,000 left when he dies is a failure.
-- Errol Flynn


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction (update)

2006-07-08 Thread R. Armiento 

Hi,

Joachim Henke wrote:

Please use the updated patch attached below.


Great work! The patch fixes the kernel panic for me. Thank you.

However, as you probably know, despite not declaring MONITOR in qemu, 
kqemu sees MONITOR on the host processor and Linux CPU usage will still 
be 100%, even with your updated patch. So even with your patch applied 
one should use the 'idle=halt' kernel parameter when booting Linux with 
-kernel-kqemu on newer processors.


While your patch resolves the problem and is great for my setup, I 
suppose it is problematic. If MONITOR is not declared by qemu then still 
serving mwait 'correctly' is not faithful emulation (right?). To make 
sure this does not break anything else, I would guess that either mwait 
has to be emulated better so that it is ok to let qemu declare MONITOR 
support; OR as a temporary workaround make the patch only serve mwait if 
-kernel-kqemu is enabled and host CPUID supports MONITOR.


The whole thing with CPUID not being trappable seems like a can of worms 
to me, partly breaking hardware abstraction. I am totally ignorant of 
the inner workings of kqemu; but if it was somehow possible to "rewrite" 
CPUID into something trappable and handling it correctly, that would 
give a much more satisfying solution to this problem.


Rickard



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Why do qemumenu.bat show such error mess age?

2006-07-08 Thread Jan Marten Simons 
赵刚 wrote:
> When I had installed qemu(Host OS: win98),I execute qemumenu.bat.
> Unfortunately,qemumenu.bat shows lots of error messages,as follows:
> >Bad command or file name
> >Bad command or file name
> >Invalid directory
> >Syntax error
> >Syntax error
> >Bad command or file name
> >Syntax error
> >QEMU_BIOS_DIR=
> >Bad command or file name
> >=== QEMU Menu ^(v20041121^) ===
> > QEMU Menu (C) 2004 Garth Dahlstrom ([EMAIL PROTECTED]
> )
> > QEMU (C) 2004 Fabrice Bellard
> >
> >QEMU Settings:
> > Memory ^(^MB^) BIOS DIR ^(^)
> > ISO/CD ^(^)
> > Network ^(^)
> >
> >Boot QEMU using image:
> >Bad command or file name
> >Syntax error
> >Bad command or file name
> >Syntax error
> > No image files found^^!^^!
> > (you must [C]reate an image to use QEMU) && echo.
> >
> >Settings/Toggles:
> > ^[C^]reate image file ^[M^]emory ^[I^]SO/CD ^[N^]etwork ^[Q^]uit
> >
> >
> >
> >Starting !QEMU_IMG! ...
> >
> >
> >^[ ^] qemu.exe -L "" -m -hda "!QEMU_IMG!" -enable-audio -localtime
> >Bad command or file name
> >Syntax error
> >Press any key to continue . . .
> Could you explain the reasons about these error messages ?
> Best regards
> mathew

Well, have a look at the .bat-file with a normal editor. It's not like
you'll need to understand rocket science to debug a batch file. I
suspect that this batch file is passing outdated command line options to
qemu, as there were some changes from 0.7.x to 0.8.x (e.g. networking)
with a look at qemu manual you should be able to fix the batch file (I
suppose it's using the old options). After fixing it it would be nice,
to post it to this list and the original author.

Have a nice weekend,
Jan




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] MIPS instruction set configuration

2006-07-08 Thread Thiemo Seufer 
Dirk Behme wrote:
> Thiemo Seufer wrote:
> ...
> >I recommend to go for a sufficiently flexible interface first, and then
> >introduce it gradually in all appropriate places. A macro like:
> >
> >MIPS_OPC(ISA, ASE, CPU)
> >
> >which compares the arguments with the currently selected CPU emulation
> >and throws an RI exception if the feature doesn't exist:
> >
> >...
> >case OPC_LD:
> >MIPS_OPC(MIPS-III, 0, 0);
> > ...
> > break;
> >...
> >
> ...
> >My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted
> >better, that is, they should move in the implementation of the
> >MIPS_OPC macro.
> 
> I really like your proposals of MIPS_OPC() and better
> abstraction of MIPS_USES_*/MIPS_FEATURE_*!
> 
> Do you think you can post a patch which introduces the basic
> parts of this functionality in the short term? Then we can
> use it as a starter for more improvements.

I'm busy this weekend.

[snip]
> >Well, there is no CPU named "R4Kc". What qemu emulates today resembles
> >mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support.
> 
> Yes, I understand this. But two things:
> 
> First, in the current MIPS configuration FPU is enabled for
> "R4Kc". I think we shouldn't disable anything what is there
> at the moment, without giving an alternative for people
> using this (e.g. introducing an additional machine). And
> this only because there is no real world equivalent for this.

I agree we should have a generic "emulate everything" configuration
with MIPS64R2 + FPU + all ASEs + all non-conflicting CPU extensions.

> Second, while I agree that there is no real world equivalent
> for this, I think this is one of the biggest advantages of a
> simulator like qemu: Your are able to configure and test
> machine and feature combinations which will never exist in
> real world really quickly.

Probably, but the generic configuration will cover most of that
already.


Thiemo


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c

2006-07-08 Thread Paul Jakma 

On Sat, 8 Jul 2006, Paul Jakma wrote:

Hmm, define 'unable to use it'? It seems (on very quick testing) to work in 
Solaris.


Spoke too soon, ICMP echos and TCP connects work, but it seems to 
have problems transferring anything substantial.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
This is the LAST time I take travel suggestions from Ray Bradbury!


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

2006-07-08 Thread Jim C. Brown 
For the record, we can use wxWidgets in qemu even though we can not use C++
in qemu (something that I would be strongly against).

http://wxc.sourceforge.net/

Requiring this as a dependency would make it easier to deal with issues such as
C++ ABI compatibility by avoiding the direct use of C++.

There's a QtC that I considered using for a Qt GUI for qemu.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c

2006-07-08 Thread Igor Kovalenko 
On 7/8/06, Paul Jakma <[EMAIL PROTECTED]> wrote:
On Sat, 8 Jul 2006, Paul Jakma wrote:> Hmm, define 'unable to use it'? It seems (on very quick testing) to work in> Solaris.Spoke too soon, ICMP echos and TCP connects work, but it seems tohave problems transferring anything substantial.
Try this patch - transfers should start to work
Index: hw/pcnet.c
===
RCS file: /cvsroot/qemu/qemu/hw/pcnet.c,v
retrieving revision 1.2
diff -u -r1.2 pcnet.c
--- hw/pcnet.c	4 Jul 2006 21:42:10 -	1.2
+++ hw/pcnet.c	8 Jul 2006 14:44:28 -
@@ -57,6 +57,7 @@
 uint64_t timer;
 int xmit_pos, recv_pos;
 uint8_t buffer[4096];
+int tx_busy;
 };
 
 #ifdef __GNUC__
@@ -659,6 +660,8 @@
 s->csr[114] = 0x;
 s->csr[122] = 0x;
 s->csr[124] = 0x;
+
+s->tx_busy = 0;
 }
 
 static void pcnet_update_irq(PCNetState *s)
@@ -1104,7 +1107,9 @@
 s->csr[0] &= ~0x0008;
 return;
 }
-
+
+s->tx_busy = 1;
+
 txagain:
 if (pcnet_tdte_poll(s)) {
 struct pcnet_TMD tmd;
@@ -1167,6 +1172,8 @@
 if (count--)
   goto txagain;
 }
+
+s->tx_busy = 0;
 }
 
 static void pcnet_poll(PCNetState *s)
@@ -1177,7 +1184,13 @@
 
 if (CSR_TDMD(s) || 
 (CSR_TXON(s) && !CSR_DPOLL(s) && pcnet_tdte_poll(s)))
+{
+/* prevent recursion */
+if (s->tx_busy)
+return;
+
 pcnet_transmit(s);
+}
 }
 
 static void pcnet_poll_timer(void *opaque)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

2006-07-08 Thread Joe Lee 

Jim C. Brown wrote:

For the record, we can use wxWidgets in qemu even though we can not use C++
in qemu (something that I would be strongly against).

http://wxc.sourceforge.net/

Requiring this as a dependency would make it easier to deal with issues such as
C++ ABI compatibility by avoiding the direct use of C++.

There's a QtC that I considered using for a Qt GUI for qemu.

  

How about WX using Python - Is that an option?
-joe


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] add 'monitor' and 'mwait' instruction (update)

2006-07-08 Thread Joachim Henke 

R. Armiento wrote:
However, as you probably know, despite not declaring MONITOR in  
qemu, kqemu sees MONITOR on the host processor and Linux CPU usage  
will still be 100%, even with your updated patch. So even with your  
patch applied one should use the 'idle=halt' kernel parameter when  
booting Linux with -kernel-kqemu on newer processors.


Yes, this is obviously true. To lower the cpu usage, you can  
additionally apply the attached patch, which makes 'mwait' similar to  
'hlt'. This ugly hack seems to be sufficient at least for Linux.


While your patch resolves the problem and is great for my setup, I  
suppose it is problematic. If MONITOR is not declared by qemu then  
still serving mwait 'correctly' is not faithful emulation (right?).  
To make sure this does not break anything else, I would guess that  
either mwait has to be emulated better so that it is ok to let qemu  
declare MONITOR support; OR as a temporary workaround make the  
patch only serve mwait if -kernel-kqemu is enabled and host CPUID  
supports MONITOR.


Yes, the emulation should be done in a cleaner way. But to me it  
seems impossible to do real mwait emulation in user space. Probably  
someone else will come up with a better solution. Anyway, your last  
suggestion looks good.


--
Joachim Henke
http://he-jo.net/

mwait_hlt.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu-0.8.1 compile errors on x86_64 suse linux 10.1

2006-07-08 Thread Doctor Bill 
At first I thought the problem was that I was using gcc-4, so I installed gcc-3.4.6, but I still get the same errors:gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/tmp/qemu-0.8.1/target-i386 -I/tmp/qemu-0.8.1
 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o usb-linux.o /tmp/qemu-0.8.1/usb-linux.cIn file included from /tmp/qemu-0.8.1/usb-linux.c:29:
/usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token/tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_control':
/tmp/qemu-0.8.1/usb-linux.c:91: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltransfer'/tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_data':/tmp/qemu-0.8.1/usb-linux.c:110: error: storage size of 'bt' isn't known
/tmp/qemu-0.8.1/usb-linux.c:121: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktransfer'/tmp/qemu-0.8.1/usb-linux.c:110: warning: unused variable `bt'/tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_device_open':
/tmp/qemu-0.8.1/usb-linux.c:185: error: storage size of 'ctrl' isn't known/tmp/qemu-0.8.1/usb-linux.c:188: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'/tmp/qemu-0.8.1/usb-linux.c:185: warning: unused variable `ctrl'
make[1]: *** [usb-linux.o] Error 1make[1]: Leaving directory `/tmp/x/i386-softmmu'make: *** [all] Error 1[EMAIL PROTECTED]:/tmp/x> makefor d in i386-user arm-user armeb-user sparc-user ppc-user mips-user mipsel-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu mips-softmmu mipsel-softmmu arm-softmmu; do \
make -C $d all || exit 1 ; \    donemake[1]: Entering directory `/tmp/x/i386-user'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/i386-user'make[1]: Entering directory `/tmp/x/arm-user'
make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/arm-user'make[1]: Entering directory `/tmp/x/armeb-user'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/armeb-user'
make[1]: Entering directory `/tmp/x/sparc-user'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/sparc-user'make[1]: Entering directory `/tmp/x/ppc-user'make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/x/ppc-user'make[1]: Entering directory `/tmp/x/mips-user'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/mips-user'make[1]: Entering directory `/tmp/x/mipsel-user'
make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/tmp/x/mipsel-user'make[1]: Entering directory `/tmp/x/i386-softmmu'gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/tmp/qemu-0.8.1/target-i386 -I/tmp/qemu-
0.8.1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o usb-linux.o /tmp/qemu-0.8.1/usb-linux.cIn file included from /tmp/qemu-0.8.1/usb-linux.c:29:
/usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token
/usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token/usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token/tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_control':
/tmp/qemu-0.8.1/usb-linux.c:91: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltransfer'/tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_data':/tmp/qemu-0.8.1/usb-linux.c:110: error: storage size of 'bt' isn't known
/tmp/qemu-0.8.1/usb-linux.c:121: error: invalid application o

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

2006-07-08 Thread Jim C. Brown 
On Sat, Jul 08, 2006 at 11:02:31AM -0400, Joe Lee wrote:
> Jim C. Brown wrote:
> >For the record, we can use wxWidgets in qemu even though we can not use C++
> >in qemu (something that I would be strongly against).
> >
> >http://wxc.sourceforge.net/
> >
> >Requiring this as a dependency would make it easier to deal with issues 
> >such as
> >C++ ABI compatibility by avoiding the direct use of C++.
> >
> >There's a QtC that I considered using for a Qt GUI for qemu.
> >
> >  
> How about WX using Python - Is that an option?
> -joe
> 

Good question. I'm not aware of a way to call Python code from inside of C.
I suppose if we could compile it into a shared library of some sort, that would
do the trick. (I'm assuming the Python lib would compile into something that
was callable externally using the C ABI, not the C++ ABI. If it's the latter
then using Python would still be a bad idea.)

I'm of the opinion that it would just be easier to use wxc directly instead of
trying to use a Python binding in a C project, though.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-0.8.1 compile errors on x86_64 suse linux 10.1

2006-07-08 Thread Jim C. Brown 
The issue is with your linux kernel headers.

On Sat, Jul 08, 2006 at 11:07:57AM -0400, Doctor Bill wrote:
> At first I thought the problem was that I was using gcc-4, so I installed
> gcc-3.4.6, but I still get the same errors:
> 
> gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I..
> -I/tmp/qemu-0.8.1/target-i386
> -I/tmp/qemu-0.8.1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o
> usb-linux.o/tmp/qemu-
> 0.8.1/usb-linux.c
> In file included from /tmp/qemu-0.8.1/usb-linux.c:29:
> /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token
> /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
> /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_control':
> /tmp/qemu-0.8.1/usb-linux.c:91: error: invalid application of `sizeof' to
> incomplete type `usbdevfs_ctrltransfer'
> /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_handle_data':
> /tmp/qemu-0.8.1/usb-linux.c:110: error: storage size of 'bt' isn't known
> /tmp/qemu-0.8.1/usb-linux.c:121: error: invalid application of `sizeof' to
> incomplete type `usbdevfs_bulktransfer'
> /tmp/qemu-0.8.1/usb-linux.c:110: warning: unused variable `bt'
> /tmp/qemu-0.8.1/usb-linux.c: In function `usb_host_device_open':
> /tmp/qemu-0.8.1/usb-linux.c:185: error: storage size of 'ctrl' isn't known
> /tmp/qemu-0.8.1/usb-linux.c:188: error: invalid application of `sizeof' to
> incomplete type `usbdevfs_ioctl'
> /tmp/qemu-0.8.1/usb-linux.c:185: warning: unused variable `ctrl'
> make[1]: *** [usb-linux.o] Error 1
> make[1]: Leaving directory `/tmp/x/i386-softmmu'
> make: *** [all] Error 1
> [EMAIL PROTECTED]:/tmp/x> make
> for d in i386-user arm-user armeb-user sparc-user ppc-user mips-user
> mipsel-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu
> mips-softmmu mipsel-softmmu arm-softmmu; do \
> make -C $d all || exit 1 ; \
>done
> make[1]: Entering directory `/tmp/x/i386-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/i386-user'
> make[1]: Entering directory `/tmp/x/arm-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/arm-user'
> make[1]: Entering directory `/tmp/x/armeb-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/armeb-user'
> make[1]: Entering directory `/tmp/x/sparc-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/sparc-user'
> make[1]: Entering directory `/tmp/x/ppc-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/ppc-user'
> make[1]: Entering directory `/tmp/x/mips-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/mips-user'
> make[1]: Entering directory `/tmp/x/mipsel-user'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/tmp/x/mipsel-user'
> make[1]: Entering directory `/tmp/x/i386-softmmu'
> gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I..
> -I/tmp/qemu-0.8.1/target-i386
> -I/tmp/qemu-0.8.1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -I/tmp/qemu-0.8.1/fpu -DHAS_AUDIO -I/tmp/qemu-0.8.1/slirp -c -o
> usb-linux.o/tmp/qemu-
> 0.8.1/usb-linux.c
> In file included from /tmp/qemu-0.8.1/usb-linux.c:29:
> /usr/include/linux/usbdevice_fs.h:49: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:49: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:56: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:56: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:66: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:66: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:100: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:100: error: syntax error before '*' token
> /usr/include/linux/usbdevice_fs.h:109: error: syntax error before '}' token
> /usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user'
> declared void
> /usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
> /tmp/qemu-0.8.1/usb-linux.c: In funct

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

2006-07-08 Thread Kevin F. Quinn 
On Sat, 8 Jul 2006 11:13:52 -0400
"Jim C. Brown" <[EMAIL PROTECTED]> wrote:

> Good question. I'm not aware of a way to call Python code from inside
> of C. 

See http://docs.python.org/ext/ext.html

However doing this just means yet another language dependency.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] add 'monitor' and 'mwait' instruction (update)

2006-07-08 Thread R. Armiento 

Hi,

Again, thank you for helping out with updated patches, it is much 
appreciated.


Joachim Henke wrote:

R. Armiento wrote:

So even with your patch applied one should use the 'idle=halt'
kernel parameter when booting Linux with -kernel-kqemu on newer
processors. [...]

To lower the cpu usage, you can additionally apply the attached
patch, which makes 'mwait' similar to 'hlt'. This ugly hack seems to
be sufficient at least for Linux.


Is this hack really 'safe'? I don't claim to know much about modern x86 
instructions, but some googling tells me that mwait is supposed to wake 
on a monitored memory write (but is allowed to wake up earlier, hence it 
is acceptable but CPU consuming to emulate it with a nop). Couldn't 
there be situations where someone depends on mwait waking up without 
there being an event that wakes hlt? Or are we sure qemu's hlt will 
happen to wake up anyway?


Yes, the emulation should be done in a cleaner way. But to me it seems 
impossible to do real mwait emulation in user space. 


Again, excuse my lack of knowledge of the internals of qemu and kqemu. 
If 'hlt' can be emulated to give CPU time back to the host OS until an 
interrupt occurs in the guest; then it is not obvious why mwait couldn't 
be simulated in a similar way, only with the addition that qemu also 
restarts guest CPU execution should there be writes in monitored memory. 
While I have no idea of how much work it would be, it would much 
surprise me if this is truly un-doable, at least for non-kqemu emulation.


Rickard



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c

2006-07-08 Thread Paul Jakma 

On Sat, 8 Jul 2006, Igor Kovalenko wrote:


Try this patch - transfers should start to work


Hmm, no obvious improvement I'm afraid.

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
I CAN'T SEE DEAD PEOPLE
I CAN'T SEE DEAD PEOPLE
I CAN'T SEE DEAD PEOPLE
I CAN'T SEE DEAD PEOPLE

Bart Simpson on chalkboard in episode BABF05


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI

2006-07-08 Thread Oliver Gerlich 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim C. Brown schrieb:
> For the record, we can use wxWidgets in qemu even though we can not use C++
> in qemu (something that I would be strongly against).
> 
> http://wxc.sourceforge.net/
> 
> Requiring this as a dependency would make it easier to deal with issues such 
> as
> C++ ABI compatibility by avoiding the direct use of C++.
> 
> There's a QtC that I considered using for a Qt GUI for qemu.
> 

Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.

Generally it might be quite difficult to find a GUI toolkit with C
bindings (besides GTK), as most toolkits seem to be targeted at an
object-oriented language, and many go into the direction of script
languages and "rapid application development".
So I think we should either just use GTK, or make Qemu ready for
integration of C++ GUI code (and use one of the common GUI toolkits), or
add an interface for external GUIs (and run the GUI as an external
process, written in Python or Perl or the like).

Regards,
Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEsCLoTFOM6DcNJ6cRAp4dAJwPa7JW7JJzBkg3GnsP+XskTVtAPwCgzpr1
W9RuT6XdO66GtD8evBXfDKc=
=inA8
-END PGP SIGNATURE-


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] balloon driver

2006-07-08 Thread Eric L 

On 7/5/06, Paul Brook <[EMAIL PROTECTED]> wrote:

On Wednesday 05 July 2006 03:58, Eric L wrote:
> I've been playing around with QEMU the past few days and have been
> quite impressed.  One thing I wondered about: it seems that most of
> the other virtualization schemes have some sort of balloon driver to
> reclaim unused (cached) guest memory.  (VMWare, Xen and I think user
> mode linux has something too).  It seems like a pretty good idea to
> me, but from my searching, it would appear that QEMU does not have
> anything similar.  Is this correct?  If so, is there a reason why?

Partly because qemu is just a normal user application. It can be swapped out
by the host OS just like any other process. Adding a few Gb of extra swap and
letting the host OS figure it out should get you 90% of the benefit.

Paul



It seems the point of the balloon driver is to avoid forcing the host
to swap.  For example, suppose I start a new guest OS.  I check the
memory usage on the host and everything looks pretty good, maybe 30MB
used.  Then suppose I run a recursive grep command in a Linux source
tree on the guest.  The host memory usage will climb to the maximum
allotted memory as the guest OS fills its page cache with pages of
kernel source.  Now, I go back to the host and decide I want to run
something a little memory intensive.  The host has to swap and
dutifully copies those pages of kernel source to swap.  Much better
would be if I could just chuck those pages and give them back to the
host, no swapping at all.

Even if the guest has to swap, the reasoning is that the guest is in a
much better position to figure out what to swap than if the host were
forced to.

It is a rather crude approach and I'm not sure how much practical
benefit there is, but I'll probably go ahead and code it up (at least
for a Linux host) if only for myself as it looks pretty simple.
(Linux 2.6.16 added the ability to punch holes in tmpfs files so all
the hard work should be done).  I just wondered if there was anything
I was missing or if anyone had considered it before.


- E


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] balloon driver

2006-07-08 Thread Mark Williamson 
> It seems the point of the balloon driver is to avoid forcing the host
> to swap.  For example, suppose I start a new guest OS.  I check the
> memory usage on the host and everything looks pretty good, maybe 30MB
> used.  Then suppose I run a recursive grep command in a Linux source
> tree on the guest.  The host memory usage will climb to the maximum
> allotted memory as the guest OS fills its page cache with pages of
> kernel source.  Now, I go back to the host and decide I want to run
> something a little memory intensive.  The host has to swap and
> dutifully copies those pages of kernel source to swap.  Much better
> would be if I could just chuck those pages and give them back to the
> host, no swapping at all.
>
> Even if the guest has to swap, the reasoning is that the guest is in a
> much better position to figure out what to swap than if the host were
> forced to.

Worse, the guest might decide to swap out a page that's already swapped in by 
the host, forcing it to be read in again only to be immediately written out 
to disk by the guest :-(

> It is a rather crude approach and I'm not sure how much practical
> benefit there is, but I'll probably go ahead and code it up (at least
> for a Linux host) if only for myself as it looks pretty simple.
> (Linux 2.6.16 added the ability to punch holes in tmpfs files so all
> the hard work should be done).  I just wondered if there was anything
> I was missing or if anyone had considered it before.

Xen has a balloon driver - you might like to take a look at that for starters, 
and maybe borrow some code from it!  There's been occasional talk to the 
effect that a number of projects might as well share functionality like 
ballooning since a number of systems require it.

Cheers,
Mark

>
> - E
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] balloon driver

2006-07-08 Thread Jamie Lokier 
Mark Williamson wrote:
> > Even if the guest has to swap, the reasoning is that the guest is in a
> > much better position to figure out what to swap than if the host were
> > forced to.
> 
> Worse, the guest might decide to swap out a page that's already
> swapped in by the host, forcing it to be read in again only to be
> immediately written out to disk by the guest :-(

...unless the guest's disk I/O is with simulated DMA or recognisable
block-copy instruction sequences, and doesn't look at the data.  In
that case the emulator can, in principle, keep track of where pages
are copied around without being examined, and avoid actually swapping
them in.

Probably not worth the complexity.

-- Jamie


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel