diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/none/1613 | 67 | ||||
| -rw-r--r-- | results/classifier/118/none/1613817 | 147 |
2 files changed, 214 insertions, 0 deletions
diff --git a/results/classifier/118/none/1613 b/results/classifier/118/none/1613 new file mode 100644 index 00000000..8cc7ce0a --- /dev/null +++ b/results/classifier/118/none/1613 @@ -0,0 +1,67 @@ +files: 0.558 +graphic: 0.531 +device: 0.492 +performance: 0.468 +socket: 0.377 +architecture: 0.342 +network: 0.328 +ppc: 0.313 +arm: 0.302 +PID: 0.286 +vnc: 0.275 +kernel: 0.275 +hypervisor: 0.274 +peripherals: 0.267 +VMM: 0.261 +permissions: 0.239 +TCG: 0.227 +mistranslation: 0.225 +semantic: 0.224 +x86: 0.222 +risc-v: 0.217 +user-level: 0.210 +boot: 0.203 +debug: 0.169 +register: 0.168 +assembly: 0.136 +i386: 0.118 +KVM: 0.116 +virtual: 0.098 + +Enhanced SuperSpeed Isochronous Endpoints with high-bandwidth pipes not working (Webcams and Microphones) +Description of problem: +I have encountered an issue with QEMU when forwarding HD webcams and microphones in SuperSpeed mode. + +When passing the USB webcam "Logitech BRIO Ultra HD Webcam" to the guest using USB HighSpeed mode, all pixel formats and video modes work as expected. However, when using SuperSpeed mode, only the MJPEG format operates at low resolutions. I have attached a [USB_Webcam_Testing_Truth_Table.pdf](/uploads/309d493989da1164198af0b315012fb1/USB_Webcam_Testing_Truth_Table.pdf) that displays the functioning modes. + +This issue arises with both qemu-xhci and nec-usb-xhci xHCI implementations, as well as with usb-host and usb-redir. + +Upon tracing and comparing the USB packets from the host and guest systems, I discovered an issue with the isochronous endpoint configurations supporting "high bandwidth" pipes (e.g., SS Companion Descriptor with bMaxBurst > 0). I created three pcap files to illustrate the problem: +1. [host-libusb.pcapng](/uploads/18a66948dc6dc10ff68b7f55d70fa209/host-libusb.pcapng) +2. [qemu-guest.pcapng](/uploads/b616507f2f7c1c042a9d085dc3af579f/qemu-guest.pcapng) +3. [host-native.pcapng](/uploads/279aa7f264a75a77203fa7bf6c5afc83/host-native.pcapng) + +To generate each capture, I executed the following command: +```console +timeout --preserve-status 3s ffplay -f v4l2 -i "/dev/video0" -input_format mjpeg -framerate 30 -video_size 1920x1060 +``` + +The "SET INTERFACE" packet reveals that the USB video driver selects bAlternateSetting=7, which has the following parameters: +``` +wMaxPacketSize: 1024 +bMaxBurst: 2 +bmAttributes: 0x01 + .... ..01 = Mult: 1 +``` +According to Section 4.14.2.1.3 of the xHCI specification, the size of an isoch transfer should be `Packet Size * (Max Burst Size + 1) * (Mult + 1) = 6144`. + +However, the host-libusb.pcapng capture shows that each transfer is only 1024 bytes in size. + +For higher bitrate formats, it is observed that the system generates erroneous transfers in which the data offset in the isodescriptor exceeds the packet size. + +Currently, I am unsure of the cause of this issue. If you need any additional information, logs, or specific USB packet captures, I would be more than happy to provide them. + +Thanks +Additional information: +[lsusb-cam-SuperSpeed.txt](/uploads/712ac9e67d0b53ce46573bee3df883d0/lsusb-cam-SuperSpeed.txt) +[lsusb-cam-HighSpeed.txt](/uploads/70f855e471714fb1b48a7ed7912c0be4/lsusb-cam-HighSpeed.txt) diff --git a/results/classifier/118/none/1613817 b/results/classifier/118/none/1613817 new file mode 100644 index 00000000..66ddebfd --- /dev/null +++ b/results/classifier/118/none/1613817 @@ -0,0 +1,147 @@ +peripherals: 0.723 +mistranslation: 0.697 +user-level: 0.658 +permissions: 0.657 +hypervisor: 0.652 +ppc: 0.623 +TCG: 0.623 +KVM: 0.623 +graphic: 0.617 +vnc: 0.599 +risc-v: 0.594 +debug: 0.594 +performance: 0.592 +VMM: 0.588 +register: 0.587 +files: 0.585 +x86: 0.573 +architecture: 0.570 +virtual: 0.563 +device: 0.558 +semantic: 0.550 +boot: 0.543 +assembly: 0.543 +network: 0.536 +socket: 0.523 +arm: 0.522 +PID: 0.512 +i386: 0.509 +kernel: 0.497 + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +# qemu-system-x86_64 --version +QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008 Fabrice Bellard + +Running it like this: + +qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio -append "panic=1" + +(i.e. no KVM, no unusual options) + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +Still happens with qemu 5.1.92 + +I imagine the fix should be inserted here: + +static inline void helper_ret_protected(CPUX86State *env, int shift, + int is_iret, int addend, + uintptr_t retaddr) +{ + uint32_t new_cs, new_eflags, new_ss; + uint32_t new_es, new_ds, new_fs, new_gs; + uint32_t e1, e2, ss_e1, ss_e2; + int cpl, dpl, rpl, eflags_mask, iopl; + target_ulong ssp, sp, new_eip, new_esp, sp_mask; + +#ifdef TARGET_X86_64 + if (shift == 2) { + sp_mask = -1; + } else +#endif + { + sp_mask = get_sp_mask(env->segs[R_SS].flags); + } + sp = env->regs[R_ESP]; + ssp = env->segs[R_SS].base; + new_eflags = 0; /* avoid warning */ +#ifdef TARGET_X86_64 + if (shift == 2) { + POPQ_RA(sp, new_eip, retaddr); +if (new_eip is not canonical) raise_exception_err_ra(); <==== HERE + POPQ_RA(sp, new_cs, retaddr); + new_cs &= 0xffff; + if (is_iret) { + POPQ_RA(sp, new_eflags, retaddr); + } + } else +#endif + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/125 + + |