[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 14:35:23 Modified files: . : configure Log message: check if specified compiler exists CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.92tr2=1.93r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Hi, Could you make a small patch containing just the bug fixes of the state machine ? Concerning your API changes, I am relunctant to include them now, but my mind can evolve. An API change that I would consider as very useful could be to be able to make asynchronous USB I/Os to avoid blocking QEMU while doing host USB I/Os. Regards, Fabrice. [EMAIL PROTECTED] wrote: Hello everybody, I have extended the USB support for Qemu. The patch is included and compiles just fine against todays cvs repository. As explained below, this patch touches 15 different files, which makes it not so easy to keep it applying on that very fast developing project. Thats why I would ask you to test it quickly and apply it to cvs as soon as possible. With this patch applied I could detect a USB Epson Scanner and a USB Epson Printer from Windows 98 + XP and I could even print pages with the printer (see known problems below). reasons for this patch: I was looking for a way to address my USB printer with windows while working on linux. As I started the work I had to recognize that my printer was not even detected under qemu. So I started to work on it. changes I made: First I eliminated all potential error sources, which could be avoided. One of these sources where the 1. usb-hub - which I transfered to an extra file usb-hub.c, then I added the usb-libusb.c devices directly to the UHCI controller this introduced the changes of 2) 2. I enhanced the usb add device potentialities so that you should be able to add a device to the UHCI controller. This device can be a usb hub or a usb device. Behind this device you can add another hub or device ... (remember this feature is now theoretically possible but not tested yet), this let to a new usb syntax: #$ qemu -usb controller=uhci,busnum=001 device=host:2:3,addto=001:001 (the short form is: #$ qemu -usb controller=uhci -usb device=host:2:3) so you can build up a complete usb tree. 3. I changed the usb_generic_handle_packet() function and implemented a state machine, which is able to handle the usb packets correct. 4. I changed the linux standard usb-host library to libusb. I personally will always prefer a portable solution if possible. 5. I changed large parts of usb-libusb.c. Some changes were made because I found the source very awkward, some others because I fixed errors and some because I changed the general usb api (see item 2). 6. I tried to join as many usb functions as possible to the usb related files. So that hopefully nobody has to change 15 files again. 7. I made minor changes to usb-uhci - mainly I applied the new api and changed the handling of special messages like usb_reset or usb_attach 8. I made the necessary changes to usb-hid.c and usb-hub.c 9. I wrote a lot of source comments this patch breaks some things: Sorry guys but I could not fix all of it, so I need your help, I didn't want to destroy anybodys work, but the new api makes it necessary to change some files: 1. usb-linux.c and usb-bsd.c will not work without adoption of the new api 2. I did not test usb-hid and usb-hub known problems: 1. under linux the uhci controller reports an error if no usb device is connected 2. the printer and the scanner are recognized under Windows 98/XP and Linux, but the scanner goes into STALL state as soon as a packet in usb_write_bulk() or usb_read_bulk() 3. the libusb usb_host_reset() function does not work as expected and I don't know why (i have commented out this part of the source) 4. the printer stops printing on large images and is then in a state, where it will not resume his work (probably a timing issue) With kind regards, Tino H. Seifert ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips op.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 15:18:58 Modified files: target-mips: op.c Log message: Fix overflow conditions for MIPS add / subtract (Stefan Weil) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/op.c.diff?tr1=1.5tr2=1.6r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 15:21:24 Modified files: target-mips: translate.c Log message: MIPS CP0 not usable in kernel mode (Stefan Weil) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/translate.c.diff?tr1=1.11tr2=1.12r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips op.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 15:23:48 Modified files: target-mips: op.c Log message: MIPS single stepping fix (Dirk Behme) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/op.c.diff?tr1=1.6tr2=1.7r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Hello Fabrice, I can understand, that you are not so happy with such an huge patch. But sorry it can't be done with just patching the state machine. The main problem is, that the cvs source needs the usbhub. But this hub is not operational at its current state. So in fact whenever we try to find a usb problem, we have to look in at least 4 completly different USB components (uhci controller, usb state machine, usb hub, usb device). It is a great help to reduce these components by one. Now if you go so far, you have to touch all these 15 files and then it makes no sence not to implement a better, and more flexible api. I have done this work and I was successful, as in the last days we (Lonnie Mendez and I) have found a lot of bugs. Some bugs were surely introduced by the new api, but we have also fixed bugs which were simply not detected earlier because the USB system was never bevor working so good. Today I have even detected why my usb scanner was not recognised. I will add the patch later on. So for the foregoing reasons, I will clearly reject to produce a patch which will only cover the state machine. I have worked very hard on that patch and some times you have to take what you get :) But as I said before I can understand, that it is a problem to add such a huge patch. So I want to submit the following offer: I and maybe also Lonnie Mendez (hey Lonnie this is a request for some more of your wonderful help :) ) will test the patch one week longer and get it a little more stable. On saturday I will make another comprehensive patch and you will please add it to cvs. Is that an offer? Thanks for your time and your work so far, Tino H. Seifert PS: Your feature request is noted and I will look into it after we have successfully dealt with the issues above. At the moment I'm not sure if it is possible at all. Fabrice Bellard wrote: Hi, Could you make a small patch containing just the bug fixes of the state machine ? Concerning your API changes, I am relunctant to include them now, but my mind can evolve. An API change that I would consider as very useful could be to be able to make asynchronous USB I/Os to avoid blocking QEMU while doing host USB I/Os. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target vl.c vl.h loader.c elf_ops.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 17:12:42 Modified files: . : Makefile.target vl.c vl.h Added files: . : loader.c elf_ops.h Log message: generic ELF loader CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/loader.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/elf_ops.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.97tr2=1.98r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.171tr2=1.172r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.109tr2=1.110r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw sun4m.c sun4u.c magic-load.c elf_ops.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 17:14:05 Modified files: hw : sun4m.c sun4u.c Removed files: hw : magic-load.c elf_ops.h Log message: use generic ELF loader CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4m.c.diff?tr1=1.14tr2=1.15r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4u.c.diff?tr1=1.6tr2=1.7r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu exec.c cpu-all.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 17:14:48 Modified files: . : exec.c cpu-all.h Log message: added cpu_physical_memory_write_rom() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.78tr2=1.79r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/cpu-all.h.diff?tr1=1.52tr2=1.53r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile configure
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/04/23 17:57:59 Modified files: . : Makefile configure Log message: Autodetect tools neccessary for building documentation. Make distclean remove generated documentation files. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.96tr2=1.97r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.93tr2=1.94r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-ppc op_helper.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 18:17:56 Modified files: target-ppc : op_helper.c Log message: removed unnecessary header CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-ppc/op_helper.c.diff?tr1=1.16tr2=1.17r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips op_helper.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 18:18:10 Modified files: target-mips: op_helper.c Log message: removed unnecessary header CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-mips/op_helper.c.diff?tr1=1.10tr2=1.11r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [usb][patch] anomaly with windows guests queuing an extra TD
Can you try this simpler patch ?
Index: usb.c
===
RCS file: /sources/qemu/qemu/hw/usb.c,v
retrieving revision 1.4
diff -u -w -r1.4 usb.c
--- usb.c 11 Mar 2006 20:37:58 - 1.4
+++ usb.c 23 Apr 2006 18:37:22 -
@@ -91,8 +91,8 @@
case 0:
switch(s-setup_state) {
case SETUP_STATE_ACK:
-s-setup_state = SETUP_STATE_IDLE;
if (!(s-setup_buf[0] USB_DIR_IN)) {
+s-setup_state = SETUP_STATE_IDLE;
ret = s-handle_control(s,
(s-setup_buf[0] 8) |
s-setup_buf[1], (s-setup_buf[3]
8) | s-setup_buf[2],@@ -102,7 +102,7 @@
if (ret 0)
ret = 0;
} else {
-goto fail;
+/* return 0 byte */
}
break;
case SETUP_STATE_DATA:
@@ -136,11 +136,11 @@
case 0:
switch(s-setup_state) {
case SETUP_STATE_ACK:
-s-setup_state = SETUP_STATE_IDLE;
if (s-setup_buf[0] USB_DIR_IN) {
+s-setup_state = SETUP_STATE_IDLE;
/* transfer OK */
} else {
-goto fail;
+/* ignore additionnal output */
}
break;
case SETUP_STATE_DATA:
Fabrice.
Lonnie Mendez wrote:
Hello list. I've noticed something odd going on with Windows guests in
that they will queue up and extra IN TD on a setup packet having a 32
byte data stage. So far I've seen this happen twice. Here is one
occurance:
frame 41: pid=SETUP addr=0x02 ep=0 len=8
data_out= 80 06 00 02 00 00 ff 00
ret=32
frame 42: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 09 02 20 00 01 01 00 c0
frame 43: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 01 09 04 00 00 02 00 00
frame 44: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 00 00 07 05 81 03 08 00
frame 45: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 0a 07 05 02 03 08 00 0a
frame 46: pid=IN addr=0x02 ep=0 len=8
ret=-3
A test case device that allows anyone to see the bug in action is
linked here:
http://gnome.dnsalias.net/patches/qemu-x10dev-bugged.diff (usb_add mysdev)
Here is a kind of workaround for this linked below. In the
setup_state SETUP_STATE_ACK if the packet has direction IN then it will
change setup state back to SETUP_STATE_ACK to wait for the further
queued OUT TD (ACK) and then return an appropriate value to the uhci
emulation so that it can handle the condition. At present it marks the
TD inactive and invalidates the frame. Setting an error condition
results in transfer failure and letting the frame continue without frame
invalidation results in the TD being queued several more times until the
hcd gives up and sends the OUT TD.
http://gnome.dnsalias.net/patches/qemu-usbquirk-wildtd.patch
___
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] new MIPS instructions
Thiemo Seufer wrote: Fabrice Bellard wrote: I suggest adding a parameter to cpu_mips_init() telling the exact CPU model which is emulated. Optionnal features (such as the FPU) could be specified with an additionnal parameter. Probably with an additional switch emulate everything we know about, which would be especially useful for usermode emulation where CPU specifics don't matter that much. Good points, but I don't know which is the best way to go ;) I think there are pros for both ways: Pro emulate everything we know about or one MIPS fits all: Compile your program with a -march option you want, load the binary (or now the ELF as well ;) ) into QEMU and (if QEMU has support for the selected architecture) it will run. Without the user to select any special configuration on the command line (or tweaking inside QEMUs source code). It will run correctly without the user even to think about any special QEMU configuration. This was what I assumed before investigating why my code with a special -march option didn't work. Pro additional parameter: FPU is a good example for this. If the processor I want to emulate has no FPU I would assume if my code uses (accidently?) FPU instructions I get exception/error/warning from QEMU. It confused me that QEMU (wrongly) executes my program with unsupported instructions (architecture) without any warning. one MIPS fits all is a user friendly and QEMU easy to use option, while additional parameter is the option for emulation accuracy. I'm not an ELF expert: Does ELF contain information about architecture compiled for? If yes, we can combine both ways above? Load ELF file, read architecture from it and let QEMU autoselect correct architecture features (or give error if not supported). Then we have emulation accuracy but don't need additional options. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu gdbstub.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 18:42:15 Modified files: . : gdbstub.c Log message: SIGINT generation (Jason Wessel) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/gdbstub.c.diff?tr1=1.34tr2=1.35r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] new MIPS instructions
On Sunday 23 April 2006 19:41, Dirk Behme wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: I suggest adding a parameter to cpu_mips_init() telling the exact CPU model which is emulated. Optionnal features (such as the FPU) could be specified with an additionnal parameter. Probably with an additional switch emulate everything we know about, which would be especially useful for usermode emulation where CPU specifics don't matter that much. Good points, but I don't know which is the best way to go ;) I think there are pros for both ways: The way the Arm emulation handles this is to have a set of features that are checked by the emulation code. Or at least that's the idea, current CVS doesn't actually enforce most of these. CPU selection is done by CPU model. This selects which features are available, and cpu specific info (Device IDs, etc). If neccy for usermode emulation you can invent a fictional CPU that contains the superset of all features. I think ppc does something similar. Ideally there would be a common mechanism, but that doesn't exist. The important thing is to make the emulation conditional, even if the initial implementation just uses compile time constants. Once the conditionals are there it's relatively easy to wire them up to whatever cpu selection mechanisms qemu invents. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEUM converting VMware image to run on XEN/VPS?
Hi All, I am new to the list. I understand it may be possible for QEUM to take a VMware image and convert the VMware file format so that it can run on a XEN/VPS (domu). I would appreciate if anyone can confirm this for me. Also, any further comments/suggestions to the above would be helpful! Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/slirp misc.c slirp.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/04/23 19:41:17 Modified files: slirp : misc.c slirp.c Log message: Fix slirp redirection on systems without a useful host IP address. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/misc.c.diff?tr1=1.5tr2=1.6r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/slirp.c.diff?tr1=1.10tr2=1.11r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Unified device model
I think that a device model with support for devices in shared libraries combined with dynamic definition of the simulated HW would be great to be able to support a large number of HW variants in QEmu. I have developed several full system simulators for large embedded systems, and we have always ended up with a systems with a very small component runtime combined with a script based description of the system to simulate. All parts of the system except the component loading and instantiation was implemented as dynamically loaded components. I have worked on implementations that use a pure C based component model as well as systems that supports both C and C++ bindings for interface implementation. I have not been able to find any information about the proposed Bochs component model. Stanislav: where can I find any information about the Bochs plugin architecture that you talk about?Among the open source component frameworks i guess that XPCOM used in the Mozilla products is one of the most interesting. It currently support C++, Python and Java bindings but it can easily support C as well. /EinarI strongly support the idea of being able to use shared objects to be able to have a more dynamic device model; I can work on moving some ofthe drivers over to whatever new model that you figure out.It'd be nice too to have a dynamic board definition. For instance,being able to describe in a configuration file a board with some odd configuration (eg. 10 serial port, no IDE controller) withoutrecompiling would be helpful. I'm not sure what kind of file format'sappropriate.The number of supported devices on QEMU is going to explode... Having a good scalable architecture is going to be very useful.- Alex ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-sparc op.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 21:33:48 Modified files: target-sparc : op.c Log message: sparc condition code computation fix (Even Rouault) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-sparc/op.c.diff?tr1=1.18tr2=1.19r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 cpu.h exec.h helper2.c op.c tr...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 21:54:01 Modified files: target-i386: cpu.h exec.h helper2.c op.c translate.c Log message: SSE3 support (Joachim Henke) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/cpu.h.diff?tr1=1.35tr2=1.36r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/exec.h.diff?tr1=1.27tr2=1.28r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/helper2.c.diff?tr1=1.39tr2=1.40r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/op.c.diff?tr1=1.42tr2=1.43r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-i386/translate.c.diff?tr1=1.54tr2=1.55r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Hello, Lonnie Mendez wrote: That works but not in the literal means of the attached device actually functioning (see below). Here is something interesting: (qemu) usb_add mouse Controller 001: uhci 001:001 = mouse Summary: 1 USB Controller, 1 USB Devices (qemu) usb_add tablet,addto 001:001:001 (qemu) info usb Controller 001: uhci 001:001 = mouse 001:001:001 = tablet Summary: 1 USB Controller, 2 USB Devices (qemu) I have changed that, the usb_dummy_ funtions did return 0, but must return -1 The device attached on the hub doesn't seem to be receiving transactions (like before with the emulated devices): frame 1227: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 uhci readw port=0x0002 val=0x0001 uhci writew port=0x0002 val=0x0001 uhci readw port=0x0006 val=0x04cc frame 1228: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 frame 1229: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 uhci readw port=0x0002 val=0x0002 uhci writew port=0x0002 val=0x0002 There are some problems with the port status request traffic from the hub as well: frame 1174: pid=SETUP addr=0x03 ep=0 len=8 data_out= 23 03 04 00 01 00 00 00 error usb_generic_handle_packet: unknown USB-Token - 258 ret=0 Yes this is clear, the usbhub does not work at all. If I find the time I will look at it, this week. The interface is also giving incorrect errors at certain times: (qemu) usb_add usbhub usb_add: extraneous characters at the end of line (qemu) Yes I also noticed this. It's very strange. If you add the same line again, it will work in most cases. I don't know why it happens. It is a bug which is located in monitor.c. Attached is a patch to get the linux redirector working with the changes. It has a few other modifications as well but nothing radical. The default redirector for linux host was changed to the linux redirector as well (just a heads up). I'm still using the libusb redirector for testing here but it's good to restore the linux redirector as default on linux host. Thanks works very well. I have found today an error in the state machine and fixed it. You will find the fix in the patch: http://217.20.126.200/tino/usb-2006-04-23.patch which includes all of our patches until today. With kind regards, Tino H. Seifert ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 21:57:03 Modified files: . : qemu-doc.texi Log message: warning fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.84tr2=1.85r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 22:21:30 Modified files: hw : ide.c Log message: -win2k-hack performance+DMA support (Leonardo E. Reiter) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ide.c.diff?tr1=1.40tr2=1.41r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] new MIPS instructions
Dirk Behme wrote: [snip] Pro additional parameter: FPU is a good example for this. If the processor I want to emulate has no FPU I would assume if my code uses (accidently?) FPU instructions I get exception/error/warning from QEMU. It confused me that QEMU (wrongly) executes my program with unsupported instructions (architecture) without any warning. In the long term we want both, I think, but ATM enhancing the emulation capabilities has clearly priority for me. We should probably go for a two-way approach: a per-ISA switch for the userland emulation, and a per (generic-ish) CPU switch for system emulation. I'm not an ELF expert: Does ELF contain information about architecture compiled for? If yes, we can combine both ways above? Load ELF file, read architecture from it and let QEMU autoselect correct architecture features (or give error if not supported). Then we have emulation accuracy but don't need additional options. Binutils adds usually header flags for the ISA, but it doesn't have to, and the original ELF ABI mandates even the flags should be zero. It doesn't cover FPU, and MIPS16 as only ASE AFAIR. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/fpu softfloat-native.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/04/23 22:59:41 Modified files: fpu: softfloat-native.c Log message: 64 bit fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/fpu/softfloat-native.c.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEUM converting VMware image to run on XEN/VPS?
On Sun, Apr 23, 2006 at 03:08:04PM -0400, Joe Lee wrote: Hi All, I am new to the list. I understand it may be possible for QEUM to take a VMware image and convert the VMware file format so that it can run on a XEN/VPS (domu). I would appreciate if anyone can confirm this for me. Also, any further comments/suggestions to the above would be helpful! Yes, it can be done. Just tell qemu-img to convert it from VMware format to raw format. See the man page for more info. Joe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEUM converting VMware image to run on XEN/VPS?
Thanks Jim, that's great to hear! Jim C. Brown wrote: On Sun, Apr 23, 2006 at 03:08:04PM -0400, Joe Lee wrote: Hi All, I am new to the list. I understand it may be possible for QEUM to take a VMware image and convert the VMware file format so that it can run on a XEN/VPS (domu). I would appreciate if anyone can confirm this for me. Also, any further comments/suggestions to the above would be helpful! Yes, it can be done. Just tell qemu-img to convert it from VMware format to raw format. See the man page for more info. Joe ___ 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
