Re: [Qemu-devel] Patch: generate a DBF when a GPF could not be delivered on x86
Bernhard Kauer wrote: Qemu does not generate a double fault (DBF) on x86, if a general protection fault could not be delivered. Instead it hangs in a loop. The patch fix this bug by checking whether we are already in a GPF exception. If you're at it, maybe add triple fault handling (ie exception if DBF handler) -- it should reset CPU. rgds -- Sebastian Kaliszewski
Re: [Qemu-devel] Patch: generate a DBF when a GPF could not be delivered on x86
On Wed, Mar 28, 2007 at 10:13:49AM +0200, Sebastian Kaliszewski wrote: Bernhard Kauer wrote: Qemu does not generate a double fault (DBF) on x86, if a general protection fault could not be delivered. Instead it hangs in a loop. The patch fix this bug by checking whether we are already in a GPF exception. If you're at it, maybe add triple fault handling (ie exception if DBF handler) -- it should reset CPU. There are many things missing in the x86 exception handling. For example the case PF - PF is also not handled. Bernhard Kauer
Re: [Qemu-devel] [PATCH] Increase max -kernel size
On Wednesday 28 March 2007 03:21, Daniel Jacobowitz wrote: On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote: Right, a piggyback-style loader would likely fail in that case. Which is exactly the interesting case for x86_64. So, since Paul's verified that grub and lilo just put them far apart, maybe bumping up the size is the right thing to do. Or always putting the initrd at the top of emulated RAM. I'd prefer the latter, so that both big and small machines work. Linux still (just about) boots on 8Mb machines. Paul
Re: [Qemu-devel] virtual machine halting and loosing connections
On 3/27/07, Kyle Hubert [EMAIL PROTECTED] wrote: Also, I have noticed that when using the ondemand governor for the host OS (AMD PowerNow) that QEMU doesn't register for some reason. My host CPU stays running at 1GHz, when it is capable of 2.6GHz. I can run anything on the host OS, and I see the cpu freq jump up, so it works on the host OS. I believe this may have something to do with kqemu's acceleration. I have seen the same behavior with cpufreq, but I run the 'conservative' governor on my AMD. Haven't decided if it's a bug or a feature yet. ;0) -- 22:38 @WaxDragon false ^ true 22:39 false :( 22:39 false dont you think you can XOR me and get away with it! I always return!
[Qemu-devel] [PATCH] qemu/target-ppc/cpu.h: fix recent changes break Solaris 8 builds
Hi, Recent changes to qemu/target-ppc/cpu.h have broken Solaris 8 builds. Specifically, the insertion of a stdint.h insertion, which is not part of the Solaris C development library. [SNIP] make[1]: Entering directory `/var/home/shaddy/src/qemu/qemu/ppc-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/var/home/shaddy/src/qemu/qemu/target-ppc -I/var/home/shaddy/src/qemu/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/var/home/shaddy/src/qemu/qemu/fpu -DHAS_AUDIO -I/var/home/shaddy/src/qemu/qemu/slirp -mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 -c -o vl.o /var/home/shaddy/src/qemu/qemu/vl.c In file included from /var/home/shaddy/src/qemu/qemu/vl.h:85, from /var/home/shaddy/src/qemu/qemu/vl.c:24: /var/home/shaddy/src/qemu/qemu/target-ppc/cpu.h:24:20: stdint.h: No such file or directory /var/home/shaddy/src/qemu/qemu/vl.c: In function `init_timer_alarm': /var/home/shaddy/src/qemu/qemu/vl.c:1116: warning: label `use_itimer' defined but not used /var/home/shaddy/src/qemu/qemu/vl.c: In function `parse_host_port': /var/home/shaddy/src/qemu/qemu/vl.c:3078: warning: subscript has type `char' /var/home/shaddy/src/qemu/qemu/vl.c: In function `net_slirp_smb': /var/home/shaddy/src/qemu/qemu/vl.c:3322: warning: int format, pid_t arg (arg 4) /var/home/shaddy/src/qemu/qemu/vl.c: At top level: /var/home/shaddy/src/qemu/qemu/vl.c:1030: warning: 'start_rtc_timer' defined but not used make[1]: *** [vl.o] Error 1 make[1]: Leaving directory `/var/home/shaddy/src/qemu/qemu/ppc-softmmu' make: *** [subdir-ppc-softmmu] Error 2 [/SNIP] Simple solution is to replace inclusion, unconditionally, with inttypes.h. This is consistent with the rest of the code-base. Patch inline'ed below. HTH, Shaddy Index: target-ppc/cpu.h === RCS file: /sources/qemu/qemu/target-ppc/cpu.h,v retrieving revision 1.31 diff -u -r1.31 cpu.h --- target-ppc/cpu.h23 Mar 2007 09:45:27 - 1.31 +++ target-ppc/cpu.h28 Mar 2007 16:30:12 - @@ -21,7 +21,7 @@ #define __CPU_PPC_H__ #include config.h -#include stdint.h +#include inttypes.h #if defined(TARGET_PPC64) || (HOST_LONG_BITS = 64) /* When using 64 bits temporary registers,
[Qemu-devel] SPARC Solaris 8: i386 guest - frequent hangs (cross-post)
Hi, This is a cross-post from http://qemu-forum.ipi.fi/viewtopic.php?p=10639#10639. Continuing on from http://qemu-forum.ipi.fi/viewtopic.php?p=10487#10487, I am being continually frustrated in bringing up my Debian i386 installation on my external USB drive. I have tried both the 0.8.2 version from the opensolaris.org project, my build of 0.9.0 and my build of latest CVS (as at this email) plus my earlier emailed patch. I am now running them with this command line (the no networking bit is to try to simplify the setup, and avoid the hangs... doesn't work though): *Code:* qemu -m 128 -hda /dev/rdsk/c3t0d0s0 -net none -nographic Basically, at random points, qemu hangs completely. The confirmation of this is, also at random points, I'm sending a ctrl-a h to output the command help onto the console. *Code:* C-a hprint this help C-a xexit emulator C-a ssave disk data back to file (if -snapshot) C-a bsend break (magic sysrq) C-a ttoggle console timestamps C-a cswitch between console and monitor C-a C-a send C-a When the hang occurs, I get no response from inputting this key sequence. In fact, there is obviously never a *read* call being made, because after I manually kill the process from another terminal session, the buffered inputs are being unbuffered to the shell prompt. The most interesting hang I had was, after booting single user, and then issuing a shutdown -h now, the hang occurred after the Linux kernel outputting: *Code:* Power down. I checked the message log, and there are no apparent USB IO errors. By the way, this is all aside from the seemingly much reported general slowness of the virtual machine. It's not nice, but I don't mind it if the VM is at least stable. As it stands now, I can't risk using it, as fsck has to sort out the mess after every hang. Any help on the matter (like how I can diagnose the problem) will be greatly appreciated. TIA, Shaddy
Re: [Qemu-devel] virtual machine halting and loosing connections
On 3/28/07, WaxDragon [EMAIL PROTECTED] wrote: On 3/27/07, Kyle Hubert [EMAIL PROTECTED] wrote: Also, I have noticed that when using the ondemand governor for the host OS (AMD PowerNow) that QEMU doesn't register for some reason. My host CPU stays running at 1GHz, when it is capable of 2.6GHz. I can run anything on the host OS, and I see the cpu freq jump up, so it works on the host OS. I believe this may have something to do with kqemu's acceleration. I have seen the same behavior with cpufreq, but I run the 'conservative' governor on my AMD. Haven't decided if it's a bug or a feature yet. ;0) I was running ondemand, and I came to the conclusion it's a bug. If you see this paper: http://linux.inet.hr/ols2006_the_ondemand_governor.html You'll see that the ondemand governor policy is based on the idle/busy statistics from scheduler ticks. I believe that kqemu runs off of ioctl's from /dev/kqemu, and perhaps the system call doesn't accurately change this? How do the processes run in kqemu? Is it a kernel thread? Section 7.3 in that PDF talks of real time threads affecting the ondemand scheduler. NOTE: conservative is a fork of ondemand, so it applies here. I'll try running without kqemu, and see if I still have the problem. -Kyle
Re: [Qemu-devel] virtual machine halting and loosing connections
On 3/27/07, andrzej zaborowski [EMAIL PROTECTED] wrote: On 28/03/07, Kyle Hubert [EMAIL PROTECTED] wrote: I've been looking online, but I can't say that I have found the answer to this yet. When using QEMU, I've noticed that if I switch away to a different virtual desktop on the host OS's WM, then QEMU stops what it is doing. It's really clear when it's in the middle of a boot, but it always occurs. This causes havoc since I'm using qemu as an ssh client and the server I'm connecting to drops me for inactivity. This doesn't matter if I use keepalive or not. Just confirming that I'm seeing the same thing, and it's not a recent problem because I remember it happening in 0.7.2 and earlier. Just to let you and the list know, I downgraded to a 32bit kernel and it seems to have sorted itself out. Are you running on x86_64? -Kyle
Re: [Qemu-devel] virtual machine halting and loosing connections
On Tuesday 27 March 2007 08:53:42 pm Rick Vernam wrote: On Tuesday 27 March 2007 06:34:04 pm Kyle Hubert wrote: I've been looking online, but I can't say that I have found the answer to this yet. When using QEMU, I've noticed that if I switch away to a different virtual desktop on the host OS's WM, then QEMU stops what it is doing. It's really clear when it's in the middle of a boot, but it always occurs. This causes havoc since I'm using qemu as an ssh client and the server I'm connecting to drops me for inactivity. This doesn't matter if I use keepalive or not. I can say that I do not get this behavior. Host OS is linux, no-frills Xorg, KDE. I start up one of my VMs and switch to different desktop...a minute or so later I'm able to ssh to that VM - after starting it, I never even visited the desktop it's on. fwiw, I run 64-bit (host) kernel. all guest stuff is 32 bit.
Re: [Qemu-devel] virtual machine halting and loosing connections
On 3/28/07, Rick Vernam [EMAIL PROTECTED] wrote: On Tuesday 27 March 2007 08:53:42 pm Rick Vernam wrote: On Tuesday 27 March 2007 06:34:04 pm Kyle Hubert wrote: I've been looking online, but I can't say that I have found the answer to this yet. When using QEMU, I've noticed that if I switch away to a different virtual desktop on the host OS's WM, then QEMU stops what it is doing. It's really clear when it's in the middle of a boot, but it always occurs. This causes havoc since I'm using qemu as an ssh client and the server I'm connecting to drops me for inactivity. This doesn't matter if I use keepalive or not. I can say that I do not get this behavior. Host OS is linux, no-frills Xorg, KDE. I start up one of my VMs and switch to different desktop...a minute or so later I'm able to ssh to that VM - after starting it, I never even visited the desktop it's on. fwiw, I run 64-bit (host) kernel. all guest stuff is 32 bit. Thanks, I should specify that I am now running the same configuration, and I no longer have dropouts. Under 64bit(host) and 64bit(guest), I had the hanging. I don't understand why, since it had happened during boot, runtime, or shutdown. -Kyle
Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
On Saturday 24 March 2007 8:32 am, Sunil Amitkumar Janki wrote: Anyhow, I expect 32-bit hardware to gradually die because of wear and tear in the next few years and the replacement will be 64-bit hardware so the problem will solve itself that way. Specifically, in 2008 32-bit x86 hardware both drops below 50% of the installed base and stops being a commercial viable option for new sales in the desktop or laptop space. (Eric Raymond and I did research about this, and made a table and everything. :) http://www.catb.org/~esr/writings/world-domination/world-domination-201.html#id248066 Rob -- Vista: Windows Millenium Second Edition
[Qemu-devel] qemu/target-ppc cpu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/03/28 20:43:46 Modified files: target-ppc : cpu.h Log message: Solaris host compilation fix by Shaddy Baddah. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.31r2=1.32
Re: [Qemu-devel] [patch] More PCI ethernet emulations
Good question. I stumbled about this, too, when I looked at the code how I could apply your patch. Some months had past since I wrote it :-) The code writes to a serial EEPROM, so the 16 bits are sent using only a clock and a single data bit. The EEPROM emulation then takes the single bits and puts them together. The function gets a byte which contains clock, data and two other significant bits, and 4 bits which are always 0. When called with a word, only one byte is needed. Maybe it is the wrong one - if you work with different endianess. I'l have a look at the other problems next weekend. Stefan Ben Taylor wrote: I have a question. in eepro100_write2, I see a word (16-bits) being passed in, but only the low part of the word gets written to the eeprom. Since it's a word write, shouldn't it be writing both bytes to the eeprom? Ben
Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
Axel Zeuner wrote:
Hi Anthony,
On Monday 26 March 2007 01:44, you wrote:
Axel Zeuner wrote:
On Saturday 24 March 2007 21:15, Anthony Liguori wrote:
The tricky thing I still can't figure out is how to get ASM_SOFTMMU
working. The problem is GLUE(st, SUFFIX) function. First GCC cannot
deal with the register pressure. The problem I can't seem to fix though
is that GCC sticks %1 in %esi because we're only using an r
constraint, not a q constraint. This results in the generation of
%sib which is an invalid register. However, refactoring the code to not
require a q constraint doesn't seem to help either.
Hi Anthony,
could you please try the attached patch for softmmu_header.h? Allows
compiling with gcc4 and ASM_SOFTMMU.
That did the trick. Could you explain what your changes did?
QEMU/i386 has only 3 three available registers if TARGET_I386 is selected
because ebx,ebp,esi,edi are used by the environment and T0, T1, T3( AKA A0).
This makes inline assembly really ugly. The called external C functions in
ASM_SOFTMMU are REGPARM(1,2), i.e. require their first arguments in eax, edx.
Based on some feedback from Paul Brook, I wrote another patch that just
disables the use of register variables for GCC4. I think this is a
considerably less hackish way to go about this.
The generated code won't be as nice of course but at least it works.
The patch applies against your cvtasm patches.
Regards,
Anthony Liguori
In the two ld functions three registers (eax, edx, ecx) are required and
destroyed because an external C function may be called. We relax the register
pressure a little bit by forcing the return value (res) into eax , because
the return value is returned in a destroyed register. Furthermore the called
C function returns its value in eax anyway (call %7).
The st functions are a little more tricky: we need three registers and the
assembly code requires a reload of %0 (ptr) after the check if the external
function must be called. In the external function the three remaining
registers are destroyed. After the call a need also to reload of %1 (v) into
register is needed, i.e. we need more registers. Register saving on the stack
does not work, because there exist already 2 m constraints: if the code is
compiled with -fomit-frame-pointers these are expressed as offsets relative
to %esp, i.e X(%esp) and would become invalid after pushes onto the stack.
One solution was to force all inputs to the asm block onto the stack, thats
what the replacement of the r constraints into m constraints do: they
force a memory reference. Because i386 can not do direct memory memory moves
one has to reload m(v) into ecx again, otherwise the generated assembler
code is invalid.
It must be mentioned, that the generated code is a little bit slower than the
original one.
Kind Regards
Axel
Regards,
Anthony Liguori
Kind regards
Axel
diff -r d19a5903d749 softmmu_header.h
--- a/softmmu_header.h Tue Mar 27 13:23:10 2007 -0500
+++ b/softmmu_header.h Tue Mar 27 13:23:21 2007 -0500
@@ -240,9 +240,13 @@ static inline void glue(glue(st, SUFFIX)
2:\n
:
: r (ptr),
+#ifdef USE_REGISTER_VARIABLES
/* NOTE: 'q' would be needed as constraint, but we could not use it
with T1 ! */
r (v),
+#else
+ q (v),
+#endif
i ((CPU_TLB_SIZE - 1) CPU_TLB_ENTRY_BITS),
i (TARGET_PAGE_BITS - CPU_TLB_ENTRY_BITS),
i (TARGET_PAGE_MASK | (DATA_SIZE - 1)),
diff -r d19a5903d749 target-i386/cpu.h
--- a/target-i386/cpu.h Tue Mar 27 13:23:10 2007 -0500
+++ b/target-i386/cpu.h Tue Mar 27 13:23:21 2007 -0500
@@ -26,6 +26,10 @@
#define TARGET_LONG_BITS 64
#else
#define TARGET_LONG_BITS 32
+#endif
+
+#if TARGET_LONG_BITS = HOST_LONG_BITS __GNUC__ 4
+#define USE_REGISTER_VARIABLES
#endif
/* target supports implicit self modifying code */
@@ -424,7 +428,7 @@ typedef union {
#endif
typedef struct CPUX86State {
-#if TARGET_LONG_BITS HOST_LONG_BITS
+#ifndef USE_REGISTER_VARIABLES
/* temporaries if we cannot store them in host registers */
target_ulong t0, t1, t2;
#endif
diff -r d19a5903d749 target-i386/exec.h
--- a/target-i386/exec.h Tue Mar 27 13:23:10 2007 -0500
+++ b/target-i386/exec.h Tue Mar 27 13:23:21 2007 -0500
@@ -27,12 +27,16 @@
#define TARGET_LONG_BITS 32
#endif
+#if TARGET_LONG_BITS = HOST_LONG_BITS __GNUC__ 4
+#define USE_REGISTER_VARIABLES
+#endif
+
#include cpu-defs.h
/* at least 4 register variables are defined */
register struct CPUX86State *env asm(AREG0);
-#if TARGET_LONG_BITS HOST_LONG_BITS
+#ifndef USE_REGISTER_VARIABLES
/* no registers can be used */
#define T0 (env-t0)
@@ -88,7 +92,7 @@ register target_ulong EDI asm(AREG11);
#define reg_EDI
#endif
-#endif /* ! (TARGET_LONG_BITS HOST_LONG_BITS) */
+#endif /* ! USE_REGISTER_VARIABLES */
#define A0 T2
[Qemu-devel] QEMU only support USB endpoint 02(output) and 81(input)?
Hi guys, I found that some USB disks do not work in QEMU. I collected seven types of USB disks, and tested them in QEMU. Four of them can work properly, but other three do not work. I compared their information in /proc/bus/usb/devices, and found that the four good disks all use endpoint 02 as output endpoint, and use endpoint 81 as input endpoint, while other three are not. So, is QEMU only support USB endpoint 02(output) and 81(input)? I put the USB information of the seven disks below. The first four disks can work with QEMU, and the last three disks do not work with QEMU. USB disks work with QEMU: === Baitangping: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Chuan: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk S: SerialNumber=200506211217 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Meng: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk S: SerialNumber=200510172115 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Kingston: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=6533 Rev= 1.00 S: Manufacturer=Kingston S: Product=DataTraveler 2.0 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=64ms USB disks do not work with QEMU CNDATA: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0ed1 ProdID=6680 Rev= 1.00 S: Manufacturer=Generic S: Product=Mass Storage Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 50mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms TH: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0204 ProdID=6025 Rev= 1.00 S: Manufacturer=USB0612 S: Product=Flash Disk S: SerialNumber=335657409262 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Intel: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0204 ProdID=6025 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Thanks Xiaoyang
[Qemu-devel] QEMU only support USB endpoint 02(output) and 81(input)?
Hi guys, I found that some USB disks do not work in QEMU. I collected seven types of USB disks, and tested them in QEMU. Four of them can work properly, but other three do not work. I compared their information in /proc/bus/usb/devices, and found that the four good disks all use endpoint 02 as output endpoint, and use endpoint 81 as input endpoint, while other three are not. So, is QEMU only support USB endpoint 02(output) and 81(input)? I put the USB information of the seven disks below. The first four disks can work with QEMU, and the last three disks do not work with QEMU. USB disks work with QEMU: === Baitangping: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Chuan: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk S: SerialNumber=200506211217 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Meng: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1043 ProdID=8006 Rev= 1.00 S: Manufacturer=Generic S: Product=Flash Disk S: SerialNumber=200510172115 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Kingston: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=6533 Rev= 1.00 S: Manufacturer=Kingston S: Product=DataTraveler 2.0 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=64ms USB disks do not work with QEMU CNDATA: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0ed1 ProdID=6680 Rev= 1.00 S: Manufacturer=Generic S: Product=Mass Storage Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 50mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms TH: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0204 ProdID=6025 Rev= 1.00 S: Manufacturer=USB0612 S: Product=Flash Disk S: SerialNumber=335657409262 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Intel: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0204 ProdID=6025 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Thanks Xiaoyang
Re: [Qemu-devel] QEMU only support USB endpoint 02(output) and 81(input)?
Hi, On 3/29/2007 11:49 AM, Yu, Xiaoyang wrote: I found that some USB disks do not work in QEMU. I don't quite understand. In which way? As I understand it, QEMU just uses the I/O layer provided by the host operating system. In my experience, if there has been any USB problem, it is either with the USB device and its interaction with the kernel drivers. Regards, Shaddy
Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
Hi Anthony, On Thursday 29 March 2007 04:07, you wrote: Axel Zeuner wrote: Hi Anthony, On Monday 26 March 2007 01:44, you wrote: Axel Zeuner wrote: On Saturday 24 March 2007 21:15, Anthony Liguori wrote: The tricky thing I still can't figure out is how to get ASM_SOFTMMU working. The problem is GLUE(st, SUFFIX) function. First GCC cannot deal with the register pressure. The problem I can't seem to fix though is that GCC sticks %1 in %esi because we're only using an r constraint, not a q constraint. This results in the generation of %sib which is an invalid register. However, refactoring the code to not require a q constraint doesn't seem to help either. Hi Anthony, could you please try the attached patch for softmmu_header.h? Allows compiling with gcc4 and ASM_SOFTMMU. That did the trick. Could you explain what your changes did? QEMU/i386 has only 3 three available registers if TARGET_I386 is selected because ebx,ebp,esi,edi are used by the environment and T0, T1, T3( AKA A0). This makes inline assembly really ugly. The called external C functions in ASM_SOFTMMU are REGPARM(1,2), i.e. require their first arguments in eax, edx. Based on some feedback from Paul Brook, I wrote another patch that just disables the use of register variables for GCC4. I think this is a considerably less hackish way to go about this. The generated code won't be as nice of course but at least it works. The patch applies against your cvtasm patches. Looks good to me, sorry I had no time yet to test your patch. Did you check the performance impact of your changes? Perhaps it is possible to use register variables in dependence of the register count of the host processor. Kind Regards Axel
RE: [Qemu-devel] QEMU only support USB endpoint 02(output)and 81(input)?
I used QEMU 0.9.0 to do the testing. All the seven USB disks can work properly in host OS (Linux 2.6), so the USB devices and its interaction with the kernel drivers should be okay. So the problem must be in QEMU USB code. Thanks Xiaoyang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shaddy Baddah Sent: 2007年3月29日 12:18 To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] QEMU only support USB endpoint 02(output)and 81(input)? Hi, On 3/29/2007 11:49 AM, Yu, Xiaoyang wrote: I found that some USB disks do not work in QEMU. I don't quite understand. In which way? As I understand it, QEMU just uses the I/O layer provided by the host operating system. In my experience, if there has been any USB problem, it is either with the USB device and its interaction with the kernel drivers. Regards, Shaddy
