2 files changed, 117 insertions, 0 deletions
diff --git a/results/classifier/108/other/1648 b/results/classifier/108/other/1648
new file mode 100644
index 000000000..85be85365
--- /dev/null
+++ b/results/classifier/108/other/1648
@@ -0,0 +1,73 @@
+permissions: 0.763
+device: 0.723
+performance: 0.709
+socket: 0.563
+vnc: 0.505
+PID: 0.500
+network: 0.482
+graphic: 0.460
+files: 0.442
+boot: 0.428
+semantic: 0.379
+KVM: 0.352
+debug: 0.301
+other: 0.215
+
+linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash
+Description of problem:
+Corrent Print Result:
+
+sp: cdd3b4e8
+
+SUCCEEDED!
+
+qemu-x86_64 Print Result:
+
+sp: 2804170
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+Segmentation fault
+
+Reason of Bug:
+
+sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*)
+
+For example on x86_64:
+
+reference to "qemu/linux-user/i386/signal.c"
+
+```
+# define TARGET_FPSTATE_FXSAVE_OFFSET 0
+
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    struct target_fpstate fpstate QEMU_ALIGNED(16);
+};
+#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET (                                 \
+    offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET)
+```
+
+offsetof(struct rt_sigframe, fpstate) align of 16
+
+TARGET_FPSTATE_FXSAVE_OFFSET is 0
+
+TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64
+
+so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect!
+
+Fix the bug:
+
+```
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    abi_ulong unused QEMU_ALIGNED(16);
+    struct target_fpstate fpstate;
+};
+```
+
+offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64.
diff --git a/results/classifier/108/other/1648726 b/results/classifier/108/other/1648726
new file mode 100644
index 000000000..70971cee0
--- /dev/null
+++ b/results/classifier/108/other/1648726
@@ -0,0 +1,44 @@
+KVM: 0.893
+permissions: 0.892
+vnc: 0.880
+other: 0.874
+performance: 0.873
+graphic: 0.860
+debug: 0.854
+semantic: 0.845
+device: 0.841
+boot: 0.837
+socket: 0.835
+files: 0.829
+network: 0.817
+PID: 0.775
+
+[usb-host] Passthrough of UAS devices fails with Windows (10) guests
+
+Split off from #1579306 as this is a distinct issue.
+
+Physical USB storage devices that support the UAS protocol do not work correctly when passed through to Windows guests (I've only tested this with Windows 10 x64, build 1607).
+
+Passing through such a device results in the older BOT/MSC protocol being used:
+
+<See attachment win10-uas-fail.png>
+
+Using the same domain configuration with a Linux guest (tested with SystemRescueCD 4.8.0) works correctly:
+
+/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
+    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
+/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
+
+
+In both cases, the VM was launched via libvirt, which generated the following command line:
+
+/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on
+
+
+
+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 all 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". Thank you and sorry for the
+inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+