Re: [Qemu-devel] Large USB patch
[EMAIL PROTECTED] wrote: lo Yes I am absolutly sure we need this changes. The usb protocoll is a very sophisticated work. There is an exactly defined sequence in which packets are send. (I have made some small documentation about this: http://217.20.126.200/tino/usb-order-of-events.pdf http://217.20.126.200/tino/usb-order-of-events.odg) If you do not keep track of this, you will never be able to get most devices running. The qemu-specialcase-1.patch is the result of ignoring these sequence. At the moment I'm not even sure, if we have to implement the states in which a device is in (I mean default state, adress state ... USB Spec. 1.1 chapter 9). Well I'm glad someone took a deeper look at it. I never addressed it as a correct solution to the problem. And indeed with the patch applied the transaction log is clean. 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 I'm in favor of a new api but with only one controller there is almost no point in doing this yet. Sorry I can't agree on that point with you. We will get more controller/devices if we can provide an easy api for implementing them. I would really be interrested to see an EHCI Controller - maybe I will even implement it by myself. Sounds good. Not sure what I was going on about there. It may make more sense to either be able to specify either grabbing all or a few interfaces to proxy to the guest. Also, libusb is ok for a generic handler, but there is no way you'll get someone to jump through all the hoops necessary to get usb working under windows with libusb-win32 or even mac os x. On win32 host you have to manually create an inf file with the PID/VID and then install that for every device you try to use. It's not a good idea to use the filter driver unless the corresponding host driver is unbinded (especially for mass storage). On mac os x you would supposedly creates codeless kernel extensions with the PID/VID to unbind the device. That could be done through scripts, but none exist. On that point you have probably misunderstood me. I dont want to liquidate any native usb-host files. On the contrary, with that patch it is easier to get more such native interfaces running. We could even implement on some platforms more than one interface. I for instance would like it, if I could have libusb and linux native support enabled at the same time so I could make such things like: $ qemu -usb controller=uhci -usb device=libusb:002:003,addto=001:001 -usb device=linux:001:002,addto=001:002 and it should now not be so difficult to implement. Yes, I have misunderstood you. It sounds like a good plan. I'll ready the bsd redirector around the api tomorrow if possible. From some limited testing it fails rather early on a linux guest so it shouldn't be too hard to fix on that. There is quite a bit here and the person that would merge this into CVS is Fabrice Bellard. He would have to review all this before it ever touches CVS. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Alexander Voropay [EMAIL PROTECTED] wrote:
Another issue:
IN:
0xbfc00424: mtc0 zero,$13
0x0001: raise_exception 0x11
The problem is a code *before* this :
==
mfc0v0,C0_SR
and v0,SR_SR# preserve Soft Reset
or v0,SR_BEV # set Boot Exceptions
mtc0v0,C0_SR# 32 bit, kernel mode, bootstrap
mtc0zero,C0_CAUSE # -- TRAP there !!!
==
This code is a cut'n'paste from the See MIPS Run p.338
Unfortunately, this code clears CU0 bits in the CP0(SR).
It makes CP0 unusable for program and causes an exception 11 :
Coprocessor Unusable on the next CP0 access.
The Qemu has a bug there. The See MIPS Run p.51 states:
CU0 - Coprocessor 0 usable; Set 1 to be able to use some nominally
priveleged instructions in the user mode. You don't want to do this.
The CPU control instructions encoded as coprocessor 0 type are
always usable in kernel mode, regardless of the setting of this bit.
Qemu does simply check:
./target-mips/translate.c:1181
===
if (!(ctx-CP0_Status (1 CP0St_CU0))
!(ctx-hflags MIPS_HFLAG_UM)
!(ctx-hflags MIPS_HFLAG_ERL)
!(ctx-hflags MIPS_HFLAG_EXL)) {
if (loglevel CPU_LOG_TB_IN_ASM) {
fprintf(logfile, CP0 is not usable\n);
}
generate_exception_err (ctx, EXCP_CpU, 0);
return;
===
This check is not enought to emulate a Coprocessor Unusable
situation on Reset (when CPU is in the kernel mode).
--
-=AV=-
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Alexander Voropay wrote:
[snip]
Unfortunately, this code clears CU0 bits in the CP0(SR).
It makes CP0 unusable for program and causes an exception 11 :
Coprocessor Unusable on the next CP0 access.
The Qemu has a bug there. The See MIPS Run p.51 states:
CU0 - Coprocessor 0 usable; Set 1 to be able to use some nominally
priveleged instructions in the user mode. You don't want to do this.
The CPU control instructions encoded as coprocessor 0 type are
always usable in kernel mode, regardless of the setting of this bit.
Qemu does simply check:
./target-mips/translate.c:1181
===
if (!(ctx-CP0_Status (1 CP0St_CU0))
!(ctx-hflags MIPS_HFLAG_UM)
!(ctx-hflags MIPS_HFLAG_ERL)
!(ctx-hflags MIPS_HFLAG_EXL)) {
if (loglevel CPU_LOG_TB_IN_ASM) {
fprintf(logfile, CP0 is not usable\n);
}
generate_exception_err (ctx, EXCP_CpU, 0);
return;
===
This check is not enought to emulate a Coprocessor Unusable
situation on Reset (when CPU is in the kernel mode).
A patch which doesn't negate the HFLAGS_UM check fixes this and was
posted here a while ago.
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] New usb tablet and numlock
There's another point here. When switching from the qemu monitor to the virtual machine window, we enter ctrl-alt-1 and it seems these keys are passed too. --- Anthony Liguori [EMAIL PROTECTED] a écrit : This is probably because numlock is not sent to the guest unless you are in grab mode. You can still get into that mode by using ctrl-alt. There's an interesting usability question here. What keys should be passed to the guest? Should alt-tab be passed? Should num-lock/caps-lock be passed? It would be pretty easy to hack up a patch that grabbed the keyboard on mouse in and released it on mouse out in grabless mode. The only question in my mind is would this be acceptable from the users perspective? Regards, Anthony Liguori Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Listen to free Music: http://www.jamendo.com Windows is proprietary, use free ReactOS instead : http://www.reactos.org ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Thiemo Seufer [EMAIL PROTECTED] wrote: The Qemu has a bug there. The See MIPS Run p.51 states: A patch which doesn't negate the HFLAGS_UM check fixes this and was posted here a while ago. Thx, found. http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00148.html Is it possible to push it into the CVS ? -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
[EMAIL PROTECTED] wrote: 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 Looking at that now. 2. I did not test usb-hid and usb-hub There was a usb tablet device added recently. You may want to cvs up to account for that. known problems: 1. under linux the uhci controller reports an error if no usb device is connected The port registers on the uhci controller shows no appropriate response to an HCHALT command that is issued and so the hcd puts the controller into global suspend. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Lonnie Mendez wrote: 2. I did not test usb-hid and usb-hub There was a usb tablet device added recently. You may want to cvs up to account for that. Disregard that. Just saw it ;p ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
On Sat, Apr 08, 2006 at 10:12:07PM +0400, Brad Campbell wrote: Samuel Hunt wrote: It occurs to me that this program would make an excellent basis for a VNC terminal server. [...] If you use the vnc patch you kinda get a large part of this already. Major issue is still mouse synch, but to be honest if you turn of all acceleration in the guest it stays pretty well synced up now as it is. I use it all the time on my server to host a win2k session when I need to access windows only stuff.. Coupled with kqemu it makes for a pretty quick combination. [...] Currently I run gentoo, freebsd-6 and win2k sessions on my server.. they just sit there idle until I connect to them with vnc.. works a treat. (server is debian) Have you tried the vnc patch with current CVS? I'm seeing some issues with -vnc-and-sdl, and with -vnc only, it looks like something is not getting initialized, and I only see the qemu console in the vnc window. It appears the guest is running, but no video is going to VNC. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Lonnie Mendez wrote: known problems: 1. under linux the uhci controller reports an error if no usb device is connected The port registers on the uhci controller shows no appropriate response to an HCHALT command that is issued and so the hcd puts the controller into global suspend. The problem is more likely that the controller is being suspended but there is currently nothing being done to signal it to wake up on appropriate events. If the error/warning message you got was something like controller still running then changing uhci writew to always set UHCI_STS_HCHALTED on writing 0 to bit 0 of cmd register seems to clear the message. That means having the bit set in the frame is a bit redundant and also makes the bit a less accurate indicator of hchalt. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VNC terminal server?
On 4/21/06, Troy Benjegerdes [EMAIL PROTECTED] wrote: Have you tried the vnc patch with current CVS? I'm seeing some issues with -vnc-and-sdl, and with -vnc only, it looks like something is not getting initialized, and I only see the qemu console in the vnc window. It appears the guest is running, but no video is going to VNC. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel I'm using either 13 or my hacked 12 version of the rfb patch with current CVS. I can't tell which at the moment. Both -vnc-and-sdl and -vnc work for me, but I do see some initalization wierdness when using -S. Switching to the monitor and back seems to clear it. I haven't investigated why. WD -- ReactOS is a hub, follow the spokes and you'll immediately find absolutely everything you need to know about Windows. ReactOS is not just software, it's people. kjk_hyperion ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
lo. The attached patch applied on top of your patchset seems to work
as far as signaling resume goes.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-21 11:17:08.0 -0500
@@ -32,6 +32,8 @@
// #define DEBUG
// #define DEBUG_PACKET
+#define UHCI_CMD_FGR (1 4)
+#define UHCI_CMD_EGSM (1 3)
#define UHCI_CMD_GRESET (1 2)
#define UHCI_CMD_HCRESET (1 1)
#define UHCI_CMD_RS (1 0)
@@ -109,7 +111,8 @@
((s-status UHCI_STS_USBERR) (s-intr (1 0))) ||
((s-status UHCI_STS_RD) (s-intr (1 1))) ||
(s-status UHCI_STS_HSERR) ||
-(s-status UHCI_STS_HCPERR)) {
+(s-status UHCI_STS_HCPERR) ||
+((s-status UHCI_STS_RD) (s-intr (1 1 {
level = 1;
} else {
level = 0;
@@ -188,7 +191,7 @@
/* start frame processing */
qemu_mod_timer(s-frame_timer, qemu_get_clock(vm_clock));
s-status = ~UHCI_STS_HCHALTED;
-} else if (!(val UHCI_CMD_RS) !(s-cmd UHCI_CMD_RS)) {
+} else if (!(val UHCI_CMD_RS)) {
s-status |= UHCI_STS_HCHALTED;
}
if (val UHCI_CMD_GRESET) {
@@ -335,6 +338,14 @@
UHCIState *s = hub-opaque;
UHCIPort *port;
int i;
+
+// wakeup the controller if suspended
+if (s-cmd UHCI_CMD_EGSM) {
+s-cmd |= UHCI_CMD_FGR;
+s-status |= UHCI_STS_RD;
+uhci_update_irq(s);
+}
+
if (dev) {
if( portnum = NB_PORTS ) {
#ifdef DEBUG
@@ -575,8 +586,6 @@
if (!(s-cmd UHCI_CMD_RS)) {
qemu_del_timer(s-frame_timer);
-/* set hchalted bit in status - UHCI11D 2.1.2 */
-s-status |= UHCI_STS_HCHALTED;
return;
}
frame_addr = s-fl_base_addr + ((s-frnum 0x3ff) 2);
___
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: Lonnie Mendez wrote: The port registers on the uhci controller shows no appropriate response to an HCHALT command that is issued and so the hcd puts the controller into global suspend. The problem is more likely that the controller is being suspended but there is currently nothing being done to signal it to wake up on appropriate events. If the error/warning message you got was something like controller still running then changing uhci writew to always set UHCI_STS_HCHALTED on writing 0 to bit 0 of cmd register seems to clear the message. That means having the bit set in the frame is a bit redundant and also makes the bit a less accurate indicator of hchalt. Yes this seems to be the case. I will take a look at it. Maybe I can get the signaling correct. I will read the specification, what the correct handling should be. I must tell you: very impressive and fast error detection. I take my hat :) With kind regards Tino H. Seifert ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
[EMAIL PROTECTED] wrote:
you are too fast for me :)
Had to rediff it. Fabrice already put the necessary bits in
uhci_update_irq. Right in front of my eyes too.
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-21 11:17:08.0 -0500
@@ -32,6 +32,8 @@
// #define DEBUG
// #define DEBUG_PACKET
+#define UHCI_CMD_FGR (1 4)
+#define UHCI_CMD_EGSM (1 3)
#define UHCI_CMD_GRESET (1 2)
#define UHCI_CMD_HCRESET (1 1)
#define UHCI_CMD_RS (1 0)
@@ -188,7 +191,7 @@
/* start frame processing */
qemu_mod_timer(s-frame_timer, qemu_get_clock(vm_clock));
s-status = ~UHCI_STS_HCHALTED;
-} else if (!(val UHCI_CMD_RS) !(s-cmd UHCI_CMD_RS)) {
+} else if (!(val UHCI_CMD_RS)) {
s-status |= UHCI_STS_HCHALTED;
}
if (val UHCI_CMD_GRESET) {
@@ -335,6 +338,14 @@
UHCIState *s = hub-opaque;
UHCIPort *port;
int i;
+
+// wakeup the controller if suspended
+if (s-cmd UHCI_CMD_EGSM) {
+s-cmd |= UHCI_CMD_FGR;
+s-status |= UHCI_STS_RD;
+uhci_update_irq(s);
+}
+
if (dev) {
if( portnum = NB_PORTS ) {
#ifdef DEBUG
@@ -575,8 +586,6 @@
if (!(s-cmd UHCI_CMD_RS)) {
qemu_del_timer(s-frame_timer);
-/* set hchalted bit in status - UHCI11D 2.1.2 */
-s-status |= UHCI_STS_HCHALTED;
return;
}
frame_addr = s-fl_base_addr + ((s-frnum 0x3ff) 2);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Lonnie Mendez wrote:
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
This problem is addressed in the attached patch.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-21 12:57:04.0 -0500
@@ -382,8 +392,9 @@
} else {
port = s-ports[portnum];
/* set connect status */
-if (!(port-ctrl UHCI_PORT_CCS)) {
-port-ctrl |= UHCI_PORT_CCS | UHCI_PORT_CSC;
+if (port-ctrl UHCI_PORT_CCS) {
+port-ctrl = ~UHCI_PORT_CCS;
+port-ctrl |= UHCI_PORT_CSC;
}
/* disable port */
if (port-ctrl UHCI_PORT_EN) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add special MIPS multiply instructions
Hi,
while playing with different -march options of MIPS GCC, I
found that GCC generates some special R5400 three register
multiply assembly commands if used with -march=vr5400 (MULS,
MULHI, MACC etc.). These commands use 11 bit extended
opcodes where the lowest 6 bits are the same as for the
standard MULT/MULTU instructions (0x18 0x19). See for
example chapter 17.4 of
www.necelam.com/docs/files/1375_V2.pdf
Unfortunately, because QEMU uses mask 0x3F to extract
opcode, it doesn't detect these special opcodes and instead
executes the (wrong) standard ones. No exception or
warning is given. Calculation is simply wrong and program
misbehaves while working with wrong values.
Patch below adds support for these special MIPS opcodes.
Regards
Dirk
--- ./target-mips/op_helper.c_orig 2006-04-21 19:47:43.0 +0200
+++ ./target-mips/op_helper.c 2006-04-21 20:18:38.0 +0200
@@ -129,6 +129,132 @@ void do_msubu (void)
tmp = ((uint64_t)T0 * (uint64_t)T1);
set_HILO(get_HILO() - tmp);
}
+
+void do_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+}
+
+void do_msachiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_mulhi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_mulhiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_mulshi (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
+
+void do_mulshiu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+}
#endif
#if defined(CONFIG_USER_ONLY)
--- ./target-mips/op.c_orig 2006-04-21 19:47:43.0 +0200
+++ ./target-mips/op.c 2006-04-21 20:06:58.0 +0200
@@ -409,6 +409,146 @@ void op_msubu (void)
set_HILO(get_HILO() - tmp);
RETURN();
}
+
+void op_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+RETURN();
+}
+
+void op_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+RETURN();
+}
+
+void op_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+RETURN();
+}
+
+void op_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+RETURN();
+}
+
+void op_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+RETURN();
+}
+
+void op_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp 32;
+RETURN();
+}
+
+void op_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp 0x;
+RETURN();
+}
+
+void op_msachi
Re: [Qemu-devel] Large USB patch
lo. A few more things to note in the current problems category: -emulated devices don't seem to be interacting: frame 36: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 frame 37: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 frame 38: pid=SETUP addr=0x00 ep=0 len=8 data_out= 80 06 00 01 00 00 40 00 -qemu segfaults after giving invalid string for device removal: usb_add tablet usb_del tablet usb_del 001:001 This only happens with the emulated devices. -performing usb_del on a valid string handle gives error message: (qemu) usb_add host:001:021 (qemu) info usb Controller 001: uhci 001:001 = host:001:021 Summary: 1 USB Controller, 1 USB Devices (qemu) usb_del 001:001 Could not remove USB device '001:001' (qemu) info usb Controller 001: uhci Summary: 1 USB Controller, 0 USB Devices (qemu) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB patch
Another patch. This one does a few things:
-fixes minor output bugs and some various OBO bugs
-adds some improvements to the emulated hub
-sets up the emulated devices to use the generic message handler (they
now work again)
-makes tablet device visible to usb_add
There are of course more bugs I've found. Namely being able to
usb_add any particular string with that string showing up as a new
device even though no valid entry for it exists.
--- a/qemu/hw/usb.c 2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb.c 2006-04-21 15:27:19.0 -0500
@@ -455,6 +455,10 @@
/* we found a guest usb mouse */
tree-dev= usb_mouse_init ();
return add_usb_device (tree);
+} else if (strcmp (tree-name,tablet) == 0) {
+/* we found a guest usb tablet */
+tree-dev = usb_tablet_init ();
+return add_usb_device (tree);
}
return 1;
}
@@ -491,6 +495,7 @@
usb_host_info();
usb_hub_info();
usb_mouse_info();
+usb_tablet_info();
}
void usb_print_childs (USBTree *tree, int layer) {
--- a/qemu/hw/usb.h 2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb.h 2006-04-21 15:27:58.0 -0500
@@ -242,7 +242,9 @@
voidusb_hub_info(void);
/* usb-hid.c */
USBDevice* usb_mouse_init (void);
+USBDevice* usb_tablet_init (void);
voidusb_mouse_info (void);
+voidusb_tablet_info (void);
/* The usb dummy device functions, they exist only to make it easier to
--- a/qemu/hw/usb-hub.c 2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-hub.c 2006-04-21 15:23:05.0 -0500
@@ -165,9 +165,9 @@
0x0a, /* u16 wHubCharacteristics; */
0x00, /* (per-port OC, no power switching) */
0x01, /* u8 bPwrOn2pwrGood; 2ms */
-0x00, /* u8 bHubContrCurrent; 0 mA */
-0x00, /* u8 DeviceRemovable; *** 7 Ports max *** */
-0xff/* u8 PortPwrCtrlMask; *** 7 ports max *** */
+0x00/* u8 bHubContrCurrent; 0 mA */
+
+/* DeviceRemovable and PortPwrCtrlMask patched in later */
};
static int usb_hub_attach (USBDevice *hub, USBDevice *dev, int portnum)
@@ -260,6 +260,12 @@
}
ret = 0;
break;
+case EndpointOutRequest | USB_REQ_CLEAR_FEATURE:
+if (value == 0 index != 0x81) { /* clear ep halt */
+goto fail;
+}
+ret = 0;
+break;
case DeviceOutRequest | USB_REQ_SET_FEATURE:
if (value == USB_DEVICE_REMOTE_WAKEUP) {
dev-remote_wakeup = 1;
@@ -282,6 +288,11 @@
case USB_DT_CONFIG:
memcpy(data, qemu_hub_config_descriptor,
sizeof(qemu_hub_config_descriptor));
+
+/* status change endpoint size based on number
+ * of ports */
+data[22] = (s-nb_ports + 1 + 7) / 8;
+
ret = sizeof(qemu_hub_config_descriptor);
break;
case USB_DT_STRING:
@@ -427,11 +438,29 @@
}
break;
case GetHubDescriptor:
-memcpy(data, qemu_hub_hub_descriptor,
- sizeof(qemu_hub_hub_descriptor));
-data[2] = s-nb_ports;
-ret = sizeof(qemu_hub_hub_descriptor);
-break;
+{
+unsigned int n, limit, var_hub_size = 0;
+memcpy(data, qemu_hub_hub_descriptor,
+ sizeof(qemu_hub_hub_descriptor));
+data[2] = s-nb_ports;
+
+/* fill DeviceRemovable bits */
+limit = ((s-nb_ports + 1 + 7) / 8) + 7;
+for (n = 7; n limit; n++) {
+data[n] = 0x00;
+var_hub_size++;
+}
+
+/* fill PortPwrCtrlMask bits */
+limit = limit + ((s-nb_ports + 7) / 8);
+for (;n limit; n++) {
+data[n] = 0xff;
+var_hub_size++;
+}
+
+ret = sizeof(qemu_hub_hub_descriptor) + var_hub_size;
+break;
+}
default:
fail:
ret = USB_RET_STALL;
@@ -453,8 +482,11 @@
unsigned int status;
int i, n;
n = (s-nb_ports + 1 + 7) / 8;
-if (n len)
+if (len == 1) { /* FreeBSD uhub workaround */
+n = 1;
+} else if (n len) {
return USB_RET_BABBLE;
+}
status = 0;
for(i = 0; i s-nb_ports; i++) {
port = s-ports[i];
@@ -467,7 +499,7 @@
}
ret = n;
} else {
-ret = 0;
+ret = USB_RET_NAK; /* usb_20 11.12.1 */
}
} else {
goto fail;
@@ -541,6 +573,7 @@
return NULL;
dev-opaque=s;
dev-speed= USB_SPEED_FULL;
+dev-handle_msg=usb_generic_handle_msg;
dev-handle_packet=
Re: [Qemu-devel] -kernel-kqemu
Troy Benjegerdes wrote: On Thu, Feb 09, 2006 at 04:01:34PM -0600, Anthony Liguori wrote: Jim C. Brown wrote: -kernel-kqemu virtualizes ring 0 code. So it basically makes qemu do what VMware does. IIRC someone reported a 33% speedup with the new option. That was me. That was a 33% speedup on win2k startup time. kqemu (user only) has a negligible impact on win2k startup time which suggests this is mostly ring 0 code running which would make it a good benchmark for kernel-kqemu performance. This was a terribly unscientific benchmarking so don't read too much into it. Regards, Anthony Liguori My win2k guest (with SP4, but not any updates) seemed to hang on startup with -kernel-kqemu. Are you using -m 256 by any chance? I get this result with around that much ram allocated to the guest. -m 160 (or less) or -m 384 (or more) works perfectly here.. -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] USB Tablet Emulation + VNC patch..
Troy Benjegerdes wrote: On Mon, Apr 10, 2006 at 12:23:05PM +0400, Brad Campbell wrote: Anthony Liguori wrote: I spent some time cleaning this all up. The following integrates Brad's patches and the patch from http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch It adds a new emulated USB device that reports absolute coordinates. It also modifies SDL to operate in grabless mode when an absolute input device is enabled. I think it's pretty close to apply-able. To use, just specify: -usbdevice tablet With Xorg from CVS, the evdev driver segfaults. This is apparently expected behavior. Hopefully it will be fixed soon. It works quite nicely under Win2k. Here is the vnc patch to go on top of that and the latest cvs. This works beautifully so far.. I applied the VNC patch to the latest qemu CVS (which has the usb tablet emulation already). Now, does anyone have instructions on how to get Win2k installed and updated to the latest set of security patches? I can get service pack 4 installed, but running windowsupdate seems to never work right. If I run it up with -win2k-hack then windowsupdate works fine.. Here is what I did though (although variants have worked) Install win2k-sp4 run windowsupdate and ignore the warning about ie6, let it install the updated windows-update component. Reboot, install ie6, reboot, then run windows-update and install all the patches. All of this with win2k-hack enabled or it won't work.. and the updated win2k-hack from Leo so it works with dma.. -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
