diff options
Diffstat (limited to 'results/classifier/118/mistranslation-risc-v')
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1095531 | 215 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1331 | 61 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1397 | 61 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1449 | 65 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1483070 | 224 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1879175 | 210 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/1923693 | 84 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/2203 | 61 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/53 | 61 | ||||
| -rw-r--r-- | results/classifier/118/mistranslation-risc-v/773 | 87 |
10 files changed, 1129 insertions, 0 deletions
diff --git a/results/classifier/118/mistranslation-risc-v/1095531 b/results/classifier/118/mistranslation-risc-v/1095531 new file mode 100644 index 00000000..07e875bb --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1095531 @@ -0,0 +1,215 @@ +risc-v: 0.850 +mistranslation: 0.833 +user-level: 0.830 +permissions: 0.723 +TCG: 0.719 +hypervisor: 0.692 +ppc: 0.689 +peripherals: 0.687 +VMM: 0.685 +semantic: 0.674 +graphic: 0.655 +debug: 0.645 +x86: 0.642 +device: 0.639 +performance: 0.638 +architecture: 0.630 +assembly: 0.607 +register: 0.592 +arm: 0.587 +KVM: 0.579 +PID: 0.556 +vnc: 0.552 +files: 0.542 +boot: 0.518 +socket: 0.508 +virtual: 0.499 +kernel: 0.443 +i386: 0.432 +network: 0.409 +-------------------- +x86: 0.992 +assembly: 0.963 +debug: 0.947 +files: 0.085 +TCG: 0.062 +register: 0.042 +kernel: 0.033 +ppc: 0.021 +i386: 0.016 +virtual: 0.012 +PID: 0.008 +semantic: 0.006 +VMM: 0.006 +architecture: 0.005 +device: 0.004 +hypervisor: 0.003 +performance: 0.003 +KVM: 0.003 +boot: 0.002 +user-level: 0.002 +mistranslation: 0.002 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +socket: 0.001 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +arm: 0.000 + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. + +-------------- +IN: +0x0000000040804aa8: st %i0, [ %fp + 0x44 ] + +OP: + ---- 0x40804aa8 + ld_i64 tmp1,regwptr,$0xb0 + mov_i64 tmp0,tmp1 + movi_i64 tmp2,$0x44 + add_i64 tmp0,tmp0,tmp2 + ld_i64 tmp2,regwptr,$0x80 + ext32u_i64 tmp0,tmp0 + qemu_st32 tmp2,tmp0,$0x0 + +OUT: [size=345] +0x6032d7f0: mov 0x40(%r14),%rbp +0x6032d7f4: mov 0xb0(%rbp),%rbx +0x6032d7fb: add $0x44,%rbx +0x6032d7ff: mov 0x80(%rbp),%rbp +0x6032d806: mov %ebx,%ebx <- bug +0x6032d808: mov %ebp,%edi +0x6032d80a: bswap %edi +0x6032d80c: mov %edi,(%rbx) + +-------------- +IN: +0x0000000040804aec: add %l7, %o7, %l7 +0x0000000040804af0: ld [ %l7 ], %g2 + +OP: + ---- 0x40804aec + ld_i64 tmp1,regwptr,$0x78 + ld_i64 tmp2,regwptr,$0x38 + add_i64 tmp0,tmp1,tmp2 + st_i64 tmp0,regwptr,$0x78 + + ---- 0x40804af0 + ld_i64 tmp1,regwptr,$0x78 + mov_i64 tmp0,tmp1 + ext32u_i64 tmp0,tmp0 + qemu_ld32u g2,tmp0,$0x0 + +OUT: [size=395] +0x6032da80: mov 0x40(%r14),%rbp +0x6032da84: mov 0x78(%rbp),%rbx +0x6032da88: mov 0x38(%rbp),%r12 +0x6032da8c: add %r12,%rbx +0x6032da8f: mov %rbx,0x78(%rbp) +0x6032da93: mov 0x78(%rbp),%rbx +0x6032da97: mov %ebx,%ebx <- bug +0x6032da99: mov (%rbx),%ebx + +In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. + +I forgot to add, this is on the latest master branch as of this post. I am doing a static compile with debug enabled. My test is doing a chroot of a sparc system built from debootstrap. + +Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +I no longer have a setup to test this so I can only say to close it. + +On Jul 11, 2017 4:15 PM, "Thomas Huth" <email address hidden> wrote: + +> Can you still reproduce this problem wit the latest release of QEMU +> (currently version 2.9.0), or could we close this bug nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1095531 +> +> Title: +> sparc32plus (and others?) has x86 code generation errors on 64bit +> hosts +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> On 64bit hosts, the load and store functions compile improperly. The +> issue is the call to gen_address_mask() under the ld and st functions +> in target-sparc/translate.c. Below are some snips from the log file. +> Doing a gdb debug, this results in constant access violation errors +> which I do not see when debugging qemu in powerpc mode. +> +> -------------- +> IN: +> 0x0000000040804aa8: st %i0, [ %fp + 0x44 ] +> +> OP: +> ---- 0x40804aa8 +> ld_i64 tmp1,regwptr,$0xb0 +> mov_i64 tmp0,tmp1 +> movi_i64 tmp2,$0x44 +> add_i64 tmp0,tmp0,tmp2 +> ld_i64 tmp2,regwptr,$0x80 +> ext32u_i64 tmp0,tmp0 +> qemu_st32 tmp2,tmp0,$0x0 +> +> OUT: [size=345] +> 0x6032d7f0: mov 0x40(%r14),%rbp +> 0x6032d7f4: mov 0xb0(%rbp),%rbx +> 0x6032d7fb: add $0x44,%rbx +> 0x6032d7ff: mov 0x80(%rbp),%rbp +> 0x6032d806: mov %ebx,%ebx <- bug +> 0x6032d808: mov %ebp,%edi +> 0x6032d80a: bswap %edi +> 0x6032d80c: mov %edi,(%rbx) +> +> -------------- +> IN: +> 0x0000000040804aec: add %l7, %o7, %l7 +> 0x0000000040804af0: ld [ %l7 ], %g2 +> +> OP: +> ---- 0x40804aec +> ld_i64 tmp1,regwptr,$0x78 +> ld_i64 tmp2,regwptr,$0x38 +> add_i64 tmp0,tmp1,tmp2 +> st_i64 tmp0,regwptr,$0x78 +> +> ---- 0x40804af0 +> ld_i64 tmp1,regwptr,$0x78 +> mov_i64 tmp0,tmp1 +> ext32u_i64 tmp0,tmp0 +> qemu_ld32u g2,tmp0,$0x0 +> +> OUT: [size=395] +> 0x6032da80: mov 0x40(%r14),%rbp +> 0x6032da84: mov 0x78(%rbp),%rbx +> 0x6032da88: mov 0x38(%rbp),%r12 +> 0x6032da8c: add %r12,%rbx +> 0x6032da8f: mov %rbx,0x78(%rbp) +> 0x6032da93: mov 0x78(%rbp),%rbx +> 0x6032da97: mov %ebx,%ebx <- bug +> 0x6032da99: mov (%rbx),%ebx +> +> In 64bit mode, doing a 32bit operation will result in the top 32bit's +> being zero'd. I attempted to simply disable the call to +> gen_address_mask() but that did not fix the issue and actually caused +> the sparc32plus I was testing to become unusable. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions +> + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/mistranslation-risc-v/1331 b/results/classifier/118/mistranslation-risc-v/1331 new file mode 100644 index 00000000..4d1706c6 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1331 @@ -0,0 +1,61 @@ +risc-v: 0.994 +mistranslation: 0.881 +virtual: 0.711 +device: 0.636 +graphic: 0.575 +vnc: 0.447 +semantic: 0.352 +performance: 0.299 +network: 0.259 +hypervisor: 0.206 +register: 0.200 +arm: 0.190 +peripherals: 0.167 +user-level: 0.152 +ppc: 0.133 +VMM: 0.127 +boot: 0.116 +files: 0.112 +debug: 0.106 +architecture: 0.086 +assembly: 0.084 +socket: 0.063 +TCG: 0.039 +i386: 0.039 +kernel: 0.038 +PID: 0.034 +permissions: 0.031 +x86: 0.023 +KVM: 0.017 +-------------------- +risc-v: 0.990 +debug: 0.971 +network: 0.597 +virtual: 0.302 +user-level: 0.222 +device: 0.050 +files: 0.035 +x86: 0.030 +assembly: 0.018 +hypervisor: 0.011 +i386: 0.010 +semantic: 0.010 +PID: 0.005 +performance: 0.005 +boot: 0.005 +peripherals: 0.005 +kernel: 0.004 +ppc: 0.004 +VMM: 0.003 +graphic: 0.003 +arm: 0.003 +socket: 0.002 +vnc: 0.002 +KVM: 0.002 +register: 0.001 +TCG: 0.001 +mistranslation: 0.001 +permissions: 0.001 +architecture: 0.001 + +risc-v sstatus bug diff --git a/results/classifier/118/mistranslation-risc-v/1397 b/results/classifier/118/mistranslation-risc-v/1397 new file mode 100644 index 00000000..34ea248c --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1397 @@ -0,0 +1,61 @@ +mistranslation: 0.942 +risc-v: 0.923 +performance: 0.705 +device: 0.663 +network: 0.537 +architecture: 0.435 +graphic: 0.387 +semantic: 0.381 +files: 0.337 +peripherals: 0.328 +arm: 0.317 +hypervisor: 0.316 +kernel: 0.304 +i386: 0.301 +x86: 0.276 +assembly: 0.271 +socket: 0.252 +virtual: 0.228 +VMM: 0.226 +KVM: 0.212 +TCG: 0.204 +PID: 0.180 +register: 0.145 +debug: 0.143 +permissions: 0.138 +boot: 0.134 +vnc: 0.133 +ppc: 0.131 +user-level: 0.099 +-------------------- +debug: 0.989 +risc-v: 0.901 +assembly: 0.429 +hypervisor: 0.138 +user-level: 0.134 +virtual: 0.101 +performance: 0.048 +network: 0.035 +files: 0.024 +semantic: 0.018 +x86: 0.009 +device: 0.008 +kernel: 0.005 +register: 0.004 +i386: 0.003 +graphic: 0.003 +boot: 0.003 +TCG: 0.003 +mistranslation: 0.003 +PID: 0.003 +architecture: 0.002 +VMM: 0.002 +peripherals: 0.002 +ppc: 0.002 +arm: 0.001 +permissions: 0.001 +KVM: 0.001 +socket: 0.001 +vnc: 0.000 + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/118/mistranslation-risc-v/1449 b/results/classifier/118/mistranslation-risc-v/1449 new file mode 100644 index 00000000..359eb91e --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1449 @@ -0,0 +1,65 @@ +mistranslation: 0.941 +risc-v: 0.870 +device: 0.715 +graphic: 0.491 +socket: 0.454 +arm: 0.434 +network: 0.426 +files: 0.373 +semantic: 0.348 +boot: 0.310 +kernel: 0.298 +vnc: 0.290 +x86: 0.269 +i386: 0.259 +ppc: 0.226 +VMM: 0.223 +debug: 0.173 +PID: 0.165 +virtual: 0.153 +performance: 0.150 +architecture: 0.142 +assembly: 0.125 +TCG: 0.117 +hypervisor: 0.098 +KVM: 0.094 +register: 0.092 +user-level: 0.084 +peripherals: 0.057 +permissions: 0.042 +-------------------- +risc-v: 0.926 +debug: 0.465 +files: 0.250 +semantic: 0.068 +register: 0.065 +virtual: 0.046 +hypervisor: 0.039 +architecture: 0.028 +TCG: 0.026 +assembly: 0.026 +kernel: 0.025 +performance: 0.020 +user-level: 0.017 +device: 0.010 +peripherals: 0.005 +PID: 0.003 +boot: 0.002 +network: 0.002 +mistranslation: 0.001 +socket: 0.001 +graphic: 0.001 +permissions: 0.001 +VMM: 0.001 +vnc: 0.001 +arm: 0.000 +KVM: 0.000 +i386: 0.000 +x86: 0.000 +ppc: 0.000 + +RISCV: wrong check for vector extension ELEN value. +Description of problem: +When checking if the vector extension ELEN value is in the range [8, 64], the lower bound check uses the `vlen` field instead of the `elen` one: https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c#L885. +Additional information: +This is basically just a typo I found while reading the code, I do not have a real case scenario which resulted in this check to fail. diff --git a/results/classifier/118/mistranslation-risc-v/1483070 b/results/classifier/118/mistranslation-risc-v/1483070 new file mode 100644 index 00000000..0fe19da3 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1483070 @@ -0,0 +1,224 @@ +mistranslation: 0.909 +register: 0.899 +user-level: 0.895 +permissions: 0.884 +risc-v: 0.870 +assembly: 0.865 +TCG: 0.862 +arm: 0.861 +performance: 0.849 +VMM: 0.838 +hypervisor: 0.836 +vnc: 0.829 +peripherals: 0.827 +graphic: 0.820 +PID: 0.819 +kernel: 0.807 +debug: 0.801 +device: 0.782 +KVM: 0.781 +semantic: 0.761 +files: 0.760 +virtual: 0.748 +boot: 0.745 +ppc: 0.724 +architecture: 0.720 +x86: 0.607 +network: 0.592 +socket: 0.569 +i386: 0.449 +-------------------- +virtual: 0.968 +TCG: 0.926 +performance: 0.919 +register: 0.889 +hypervisor: 0.888 +KVM: 0.854 +debug: 0.643 +risc-v: 0.625 +device: 0.272 +PID: 0.265 +boot: 0.246 +kernel: 0.214 +socket: 0.194 +vnc: 0.106 +semantic: 0.095 +files: 0.082 +VMM: 0.062 +x86: 0.040 +architecture: 0.032 +permissions: 0.026 +assembly: 0.013 +user-level: 0.011 +peripherals: 0.010 +network: 0.009 +i386: 0.006 +graphic: 0.004 +ppc: 0.003 +mistranslation: 0.002 +arm: 0.001 + +VIRTIO Sequential Write IOPS limits not working + +Root Problem: +IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. + +To confirm: +IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. + +Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. + +For Linux: +The issue is also apparent, tested on Ubuntu 14.04 + +On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 and 4) using multiple machines but all are 64bit intel. + +Even though the latest VIRTIO guest drivers fix the problem, the guest drivers shouldn't be able to ignore the limits the host puts in place or am I missing something?? + +On Mon, Aug 10, 2015 at 12:15:25AM -0000, James Watson wrote: +> IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. +> +> To confirm: +> IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +> VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. +> +> Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +> virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +> virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. +> +> For Linux: +> The issue is also apparent, tested on Ubuntu 14.04 +> +> On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 +> (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 +> and 4) using multiple machines but all are 64bit intel. +> +> Even though the latest VIRTIO guest drivers fix the problem, the guest +> drivers shouldn't be able to ignore the limits the host puts in place or +> am I missing something?? + +This is probably due to I/O request merging: + +Your benchmark application may generate 32 x 4KB write requests, but +they are merged by the virtio-blk device into just 1 x 128KB write +request. + +The merging can happen inside the guest, depending on your benchmark +application and the guest kernel's I/O stack. It also happens in QEMU's +virtio-blk emulation. + +The most recent versions of QEMU merge both read and write requests. +Older versions only merged write requests. + +It would be more intuitive for request merging to happen after QEMU I/O +throttling checks. Currently QEMU's I/O queue plug/unplug isn't +advanced enough to do the request merging, so it's done earlier in the +virtio-blk emulation code. + +I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have more +thoughts on this. + + + +Am 10.08.2015 um 11:59 schrieb Stefan Hajnoczi <email address hidden>: + +> On Mon, Aug 10, 2015 at 12:15:25AM -0000, James Watson wrote: +>> IOPS limit does not work for VIRTIO devices if the disk workload is a sequential write. +>> +>> To confirm: +>> IDE disk devices - the IOPS limit works fine. Disk transfer speed limit works fine. +>> VIRTIO disk devices - the IOPS limit works fine for random IO (write/read) and sequential read, but not for sequential write. Disk transfer speed limits work fine. +>> +>> Tested on Windows 7,10 and 2k12 (Fedora drivers used and here is the twist): +>> virtio-win-0.1.96 (stable) or older won't limit write IO if workload is sequential. +>> virtio-win-0.1.105 (latest) or newer will limit but I have had two test machines crash when under high workload using IOPS limit. +>> +>> For Linux: +>> The issue is also apparent, tested on Ubuntu 14.04 +>> +>> On the hypervisor (using KVM) machine I have tried with Qemu 2.1.2 +>> (3.16.0-4-amd64 - Debian 8) and Qemu 2.3.0 (3.19.8-1-pve - Proxmox 3.4 +>> and 4) using multiple machines but all are 64bit intel. +>> +>> Even though the latest VIRTIO guest drivers fix the problem, the guest +>> drivers shouldn't be able to ignore the limits the host puts in place or +>> am I missing something?? +> +> This is probably due to I/O request merging: +> +> Your benchmark application may generate 32 x 4KB write requests, but +> they are merged by the virtio-blk device into just 1 x 128KB write +> request. +> +> The merging can happen inside the guest, depending on your benchmark +> application and the guest kernel's I/O stack. It also happens in QEMU's +> virtio-blk emulation. +> +> The most recent versions of QEMU merge both read and write requests. +> Older versions only merged write requests. +> +> It would be more intuitive for request merging to happen after QEMU I/O +> throttling checks. Currently QEMU's I/O queue plug/unplug isn't +> advanced enough to do the request merging, so it's done earlier in the +> virtio-blk emulation code. +> +> I've CCed Kevin Wolf, Alberto Garcia, and Peter Lieven who may have more +> thoughts on this. + +I wouldn't consider this behavior bad. Instead of virtio-blk merging the request +the guest could have issued big IOPS right from the beginning. If you are +concerned that big I/O is harming your storage, you can define a maximum +iops_size for throttling or limit the maximum bandwidth. + +Peter + + + + +On Fri 14 Aug 2015 01:34:50 AM CEST, Peter Lieven <email address hidden> wrote: + +>>> IOPS limit does not work for VIRTIO devices if the disk workload is +>>> a sequential write. + +>> This is probably due to I/O request merging: +>> +>> Your benchmark application may generate 32 x 4KB write requests, but +>> they are merged by the virtio-blk device into just 1 x 128KB write +>> request. +>> +>> The merging can happen inside the guest, depending on your benchmark +>> application and the guest kernel's I/O stack. It also happens in +>> QEMU's virtio-blk emulation. +>> +>> The most recent versions of QEMU merge both read and write requests. +>> Older versions only merged write requests. +>> +>> It would be more intuitive for request merging to happen after QEMU +>> I/O throttling checks. Currently QEMU's I/O queue plug/unplug isn't +>> advanced enough to do the request merging, so it's done earlier in +>> the virtio-blk emulation code. + +Alternatively we could keep the original number of requests and pass it +to throttle_account(), but I'm not sure if it's a good idea. + +> I wouldn't consider this behavior bad. Instead of virtio-blk merging +> the request the guest could have issued big IOPS right from the +> beginning. If you are concerned that big I/O is harming your storage, +> you can define a maximum iops_size for throttling or limit the maximum +> bandwidth. + +That's right. The way throttling.iops-size works is that I/O requests +larger than this are accounted as if they were split into smaller +operations. So, if iops-size is 32KB, a 128KB request will be counted as +4 for the purpose of limiting the number of IOPS. + +Berto + + +Has this issue ever been fixed? If not, is there still interest in fixing it? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/mistranslation-risc-v/1879175 b/results/classifier/118/mistranslation-risc-v/1879175 new file mode 100644 index 00000000..9273f2a7 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1879175 @@ -0,0 +1,210 @@ +mistranslation: 0.926 +user-level: 0.887 +risc-v: 0.874 +KVM: 0.873 +peripherals: 0.844 +graphic: 0.841 +hypervisor: 0.839 +register: 0.828 +TCG: 0.818 +ppc: 0.808 +vnc: 0.803 +performance: 0.788 +virtual: 0.788 +debug: 0.773 +device: 0.770 +assembly: 0.761 +semantic: 0.756 +architecture: 0.741 +permissions: 0.738 +x86: 0.724 +socket: 0.724 +VMM: 0.724 +arm: 0.722 +PID: 0.704 +boot: 0.704 +kernel: 0.687 +network: 0.676 +files: 0.578 +i386: 0.559 +-------------------- +x86: 0.964 +user-level: 0.875 +virtual: 0.764 +debug: 0.674 +hypervisor: 0.074 +TCG: 0.067 +register: 0.058 +files: 0.043 +device: 0.031 +assembly: 0.023 +PID: 0.017 +kernel: 0.017 +performance: 0.011 +ppc: 0.011 +i386: 0.009 +network: 0.007 +semantic: 0.005 +peripherals: 0.004 +graphic: 0.004 +socket: 0.004 +architecture: 0.004 +boot: 0.002 +VMM: 0.002 +arm: 0.002 +risc-v: 0.002 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +GVTd not working (black screen) after upgrade to qemu-5.0.0 + +Hi QEMU team, + + +=== Problem Summary === + +I have recently upgraded from QEMU-3.1.0 to to QEMU-5.0.0 on Debian Unstable. Unfortunately GVTd (legacy passthrough of the integrated intel gpu) stopped working correctly. The guest can still see and loads the driver for the GPU, but the screen stays black. + +The following is the version used: + +$ /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 (Debian 1:5.0-5) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + + + +=== Investigation/Triage done so far === + +Running QEMU with trace flags enabled shows the following behavior change for the same VM (left: 3.1.0, right: 5.0.0): + +vfio_realize (0000:00:02.0) group 1 vfio_realize (0000:00:02.0) group 1 +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f2bb1e00000] +vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f5d1d400000] | vfio_listener_region_add_ram region_add [ram] 0xc0000 - 0xdffff [0x7f2d7c800000] +vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f5d1d620000] | vfio_listener_region_add_ram region_add [ram] 0xe0000 - 0xfffff [0x7f2d84220000] +vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f5b41f00000] | vfio_listener_region_add_ram region_add [ram] 0x100000 - 0xbfffffff [0x7f2bb1f00000] +vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff vfio_listener_region_add_skip SKIPPING region_add 0xfec00000 - 0xfec00fff +vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff vfio_listener_region_add_skip SKIPPING region_add 0xfee00000 - 0xfeefffff +vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f5d1d600000] | vfio_listener_region_add_ram region_add [ram] 0xfffc0000 - 0xffffffff [0x7f2d84200000] +vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f5c01e00000] | vfio_listener_region_add_ram region_add [ram] 0x100000000 - 0x201ffffff [0x7f2c71e00000] +vfio_mdev (0000:00:02.0) is_mdev 0 vfio_mdev (0000:00:02.0) is_mdev 0 +vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 vfio_get_device Device 0000:00:02.0 flags: 3, regions: 12, irqs: 5 +vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s vfio_region_setup Device 0000:00:02.0, region 0 "0000:00:02.0 BAR 0", flags: 0x7, offset: 0x0, s +vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 vfio_region_setup Device 0000:00:02.0, region 1 "0000:00:02.0 BAR 1", flags: 0x0, offset: 0x1000 +vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 vfio_region_setup Device 0000:00:02.0, region 2 "0000:00:02.0 BAR 2", flags: 0x7, offset: 0x2000 +vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 vfio_region_setup Device 0000:00:02.0, region 3 "0000:00:02.0 BAR 3", flags: 0x0, offset: 0x3000 +vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 vfio_region_setup Device 0000:00:02.0, region 4 "0000:00:02.0 BAR 4", flags: 0x3, offset: 0x4000 +vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 vfio_region_setup Device 0000:00:02.0, region 5 "0000:00:02.0 BAR 5", flags: 0x0, offset: 0x5000 +vfio_populate_device_config Device 0000:00:02.0 config: vfio_populate_device_config Device 0000:00:02.0 config: + 0x1000, offset: 0x70000000000, flags: 0x3 0x1000, offset: 0x70000000000, flags: 0x3 +vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] vfio_region_mmap Region 0000:00:02.0 BAR 0 mmaps[0] [0x0 - 0xffffff] +vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] vfio_region_mmap Region 0000:00:02.0 BAR 2 mmaps[0] [0x0 - 0xfffffff] +vfio_check_pm_reset 0000:00:02.0 Supports PM reset vfio_check_pm_reset 0000:00:02.0 Supports PM reset +vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac vfio_msi_setup 0000:00:02.0 PCI MSI CAP @0xac +vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap vfio_check_pcie_flr 0000:00:02.0 Supports FLR via PCIe cap +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 9, 80008086/18 < +vfio_get_dev_region 0000:00:02.0 index 10, 80008086/28 < +vfio_get_dev_region 0000:00:02.0 index 11, 80008086/38 < +vfio_listener_region_del region_del 0x0 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0x9ffff [0x7f5b41e00000] < +vfio_listener_region_add_skip SKIPPING region_add 0xa0000 - 0xbffff < +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < +vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled vfio_intx_enable_kvm (0000:00:02.0) KVM INTx accel enabled +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) + 0x100, offset: 0x70000000000, flags: 0x3 0x100, offset: 0x70000000000, flags: 0x3 +vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument vfio_populate_device_get_irq_info_failure VFIO_DEVICE_GET_IRQ_INFO failure: Invalid argument +vfio_pci_reset (0000:00:02.0) vfio_pci_reset (0000:00:02.0) +vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled vfio_intx_disable_kvm (0000:00:02.0) KVM INTx accel disabled +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 0 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 2 mmaps enabled: 1 +vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 vfio_region_mmaps_set_enabled Region 0000:00:02.0 BAR 4 mmaps enabled: 1 +vfio_intx_disable (0000:00:02.0) vfio_intx_disable (0000:00:02.0) +vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) vfio_pci_write_config (0000:00:02.0, @0x4, 0x0, len=0x2) +vfio_listener_region_del region_del 0x0 - 0x9ffff < +vfio_listener_region_del_skip SKIPPING region_del 0xa0000 - 0xbffff < +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xbffff [0x7f5b41e00000] < +vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET vfio_pci_reset_flr 0000:00:02.0 FLR/VFIO_DEVICE_RESET +vfio_intx_enable (0000:00:02.0) vfio_intx_enable (0000:00:02.0) +vfio_listener_region_del region_del 0x0 - 0xbffff vfio_listener_region_del region_del 0x0 - 0xbffff +vfio_listener_region_del region_del 0xc0000 - 0xdffff vfio_listener_region_del region_del 0xc0000 - 0xdffff +vfio_listener_region_del region_del 0xe0000 - 0xfffff vfio_listener_region_del region_del 0xe0000 - 0xfffff +vfio_listener_region_del region_del 0x100000 - 0xbfffffff vfio_listener_region_del region_del 0x100000 - 0xbfffffff +vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f5b41e00000] | vfio_listener_region_add_ram region_add [ram] 0x0 - 0xcffff [0x7f2bb1e00000] + +We can see here, the following key lines are not printed in 5.0.0: + +vfio_pci_igd_lpc_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_host_bridge_enabled 0000:00:02.0 < +vfio_pci_igd_opregion_enabled 0000:00:02.0 < +vfio_pci_igd_bdsm_enabled 0000:00:02.0 40MB < + +Looking through the code and bisecting the problem (I can provide more detail if helpful), shows the following ifdef statement lines introduce the problem: + +https://github.com/qemu/qemu/blob/master/hw/vfio/pci-quirks.c#L1253 + + 1246 void vfio_bar_quirk_setup(VFIOPCIDevice *vdev, int nr) + 1247 { + 1248 vfio_probe_ati_bar4_quirk(vdev, nr); + 1249 vfio_probe_ati_bar2_quirk(vdev, nr); + 1250 vfio_probe_nvidia_bar5_quirk(vdev, nr); + 1251 vfio_probe_nvidia_bar0_quirk(vdev, nr); + 1252 vfio_probe_rtl8168_bar2_quirk(vdev, nr); + 1253 #ifdef CONFIG_VFIO_IGD + 1254 vfio_probe_igd_bar4_quirk(vdev, nr); + 1255 #endif + 1256 } + +This was added by the following commits: + +https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19#diff-38093e21794c7a4987feb71e498dbdc6 + +Reading through the commit message, I suspect the something may be happening with the Kconfig switches mentioned there. + + + +=== Validation/Workaround === + +I have rebuilt the package with the following two changes: + +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/pci-quirks.c +0a1 +> #define CONFIG_VFIO_IGD y +root@debian:/home/test/src# diff debian_*/qemu-5.0/hw/vfio/Kconfig +42c42 +< default y if PC_PCI +--- +> default y +root@debian:/home/test/src# + +GVTd started working fine again (Screen shows output again). + +I have tried with either change alone: + +- with only the ifdef in pci-quirks.c compilation fails with linker errors +- with only the Kconfig it compiles, but GVTd still does not work (black screen) + + + +Please take a look and thank you very much for a fantastic product! + +TheCatFelix + +I've also posted the bug and fix here: + +https://bugs.launchpad.net/qemu/+bug/1882784 + +I may be wrong but Legacy IGD assignment doesn't use GVT-g or GVT-d, which is why I missed this ticket when reporting my own. + +No problem, thanks for getting the issue resolved! + +As a note, i've been going by this guide here from Intel. They seem to describe as that GVT-d refers to the concept of attaching a "whole" GPU to a single VM through PCI PT and it has two modes of operation, "Legacy" and "UPT". + +https://github.com/intel/gvt-linux/wiki/GVTd_Setup_Guide#561-create-gvt-d-kvm-vm + diff --git a/results/classifier/118/mistranslation-risc-v/1923693 b/results/classifier/118/mistranslation-risc-v/1923693 new file mode 100644 index 00000000..183a1a69 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/1923693 @@ -0,0 +1,84 @@ +risc-v: 0.972 +mistranslation: 0.946 +debug: 0.827 +architecture: 0.722 +graphic: 0.701 +device: 0.607 +semantic: 0.534 +register: 0.534 +network: 0.509 +performance: 0.461 +permissions: 0.448 +socket: 0.447 +i386: 0.413 +files: 0.400 +arm: 0.391 +ppc: 0.373 +vnc: 0.372 +x86: 0.364 +user-level: 0.359 +virtual: 0.357 +KVM: 0.303 +kernel: 0.293 +assembly: 0.289 +PID: 0.286 +hypervisor: 0.280 +boot: 0.276 +VMM: 0.276 +peripherals: 0.272 +TCG: 0.212 +-------------------- +debug: 0.985 +architecture: 0.879 +user-level: 0.807 +hypervisor: 0.063 +risc-v: 0.058 +virtual: 0.030 +files: 0.027 +TCG: 0.024 +semantic: 0.023 +register: 0.021 +x86: 0.017 +arm: 0.004 +PID: 0.004 +boot: 0.004 +device: 0.004 +network: 0.003 +kernel: 0.002 +performance: 0.002 +socket: 0.002 +i386: 0.002 +ppc: 0.002 +assembly: 0.001 +vnc: 0.001 +peripherals: 0.001 +VMM: 0.001 +graphic: 0.001 +mistranslation: 0.001 +permissions: 0.001 +KVM: 0.000 + +Lack of architecture in gdbstub makes debugging confusing + +I spent some quality time debugging GEF and came to a conclusion here: +https://github.com/hugsy/gef/issues/598#issuecomment-819174169 + +tldr; + +* gdb_arch_name was undefined on riscv +* this bug was fixed recently via https://github.com/qemu/qemu/commit/edf647864bdab84ed4b1a4f47ea05be6bb075c69 + + +* An undefined gdb_arch_name results in qemu's gdbstub omitting the <architecture> xml. +* gdb translates a missing <architecture> as "auto" which breaks a lot of stuff. +* tracking down where "auto" comes from is a bit confusing and time consuming. + + +It might be better to report a missing / blank gdb_arch_name as "<architecture>unknown</architecture>" instead of omitting the block completely. + +Thanks for raising this. I have marked it as fixes as like you say it's fixed in mainline. + +Is there still anything left to do here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/mistranslation-risc-v/2203 b/results/classifier/118/mistranslation-risc-v/2203 new file mode 100644 index 00000000..94dd5ef1 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/2203 @@ -0,0 +1,61 @@ +mistranslation: 0.969 +risc-v: 0.944 +device: 0.865 +performance: 0.645 +graphic: 0.540 +boot: 0.517 +debug: 0.509 +network: 0.389 +architecture: 0.358 +virtual: 0.328 +semantic: 0.322 +vnc: 0.191 +arm: 0.171 +ppc: 0.139 +hypervisor: 0.129 +peripherals: 0.121 +user-level: 0.104 +permissions: 0.102 +register: 0.095 +socket: 0.090 +i386: 0.079 +x86: 0.059 +VMM: 0.034 +files: 0.030 +TCG: 0.020 +PID: 0.020 +assembly: 0.015 +kernel: 0.012 +KVM: 0.006 +-------------------- +risc-v: 0.987 +architecture: 0.925 +debug: 0.083 +virtual: 0.082 +assembly: 0.066 +register: 0.064 +kernel: 0.014 +files: 0.013 +performance: 0.011 +device: 0.007 +mistranslation: 0.006 +semantic: 0.006 +user-level: 0.006 +peripherals: 0.005 +boot: 0.004 +TCG: 0.002 +graphic: 0.002 +PID: 0.001 +VMM: 0.001 +arm: 0.001 +permissions: 0.001 +hypervisor: 0.001 +vnc: 0.001 +network: 0.001 +socket: 0.000 +KVM: 0.000 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/118/mistranslation-risc-v/53 b/results/classifier/118/mistranslation-risc-v/53 new file mode 100644 index 00000000..684f3b38 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/53 @@ -0,0 +1,61 @@ +risc-v: 0.979 +mistranslation: 0.932 +device: 0.879 +ppc: 0.541 +architecture: 0.500 +vnc: 0.410 +boot: 0.394 +arm: 0.323 +performance: 0.316 +debug: 0.297 +VMM: 0.297 +kernel: 0.281 +graphic: 0.275 +semantic: 0.271 +permissions: 0.268 +PID: 0.267 +x86: 0.183 +TCG: 0.173 +register: 0.158 +socket: 0.146 +i386: 0.141 +KVM: 0.096 +virtual: 0.082 +network: 0.082 +peripherals: 0.071 +hypervisor: 0.039 +files: 0.034 +user-level: 0.011 +assembly: 0.008 +-------------------- +risc-v: 0.996 +debug: 0.979 +mistranslation: 0.688 +assembly: 0.335 +architecture: 0.105 +virtual: 0.042 +files: 0.037 +user-level: 0.023 +TCG: 0.019 +PID: 0.017 +semantic: 0.011 +VMM: 0.009 +register: 0.008 +device: 0.005 +peripherals: 0.003 +performance: 0.003 +kernel: 0.003 +graphic: 0.002 +vnc: 0.002 +boot: 0.002 +KVM: 0.001 +arm: 0.001 +permissions: 0.000 +network: 0.000 +ppc: 0.000 +socket: 0.000 +hypervisor: 0.000 +i386: 0.000 +x86: 0.000 + +RISC-V Disassembler/translator instruction decoding disagreement diff --git a/results/classifier/118/mistranslation-risc-v/773 b/results/classifier/118/mistranslation-risc-v/773 new file mode 100644 index 00000000..fc1558b1 --- /dev/null +++ b/results/classifier/118/mistranslation-risc-v/773 @@ -0,0 +1,87 @@ +mistranslation: 0.864 +risc-v: 0.833 +user-level: 0.753 +graphic: 0.742 +peripherals: 0.739 +i386: 0.729 +register: 0.729 +hypervisor: 0.727 +virtual: 0.725 +permissions: 0.719 +device: 0.715 +ppc: 0.712 +semantic: 0.707 +VMM: 0.706 +network: 0.701 +arm: 0.700 +architecture: 0.697 +performance: 0.696 +vnc: 0.691 +TCG: 0.690 +assembly: 0.687 +debug: 0.685 +files: 0.679 +KVM: 0.672 +socket: 0.671 +x86: 0.669 +PID: 0.667 +kernel: 0.645 +boot: 0.617 +-------------------- +TCG: 0.961 +x86: 0.825 +performance: 0.643 +files: 0.303 +PID: 0.134 +debug: 0.109 +ppc: 0.090 +kernel: 0.082 +register: 0.067 +device: 0.039 +KVM: 0.033 +arm: 0.024 +semantic: 0.019 +user-level: 0.018 +network: 0.016 +VMM: 0.015 +graphic: 0.014 +peripherals: 0.014 +virtual: 0.014 +hypervisor: 0.013 +socket: 0.009 +risc-v: 0.008 +permissions: 0.008 +architecture: 0.007 +i386: 0.006 +boot: 0.006 +vnc: 0.002 +assembly: 0.001 +mistranslation: 0.001 + +TCG profiler build fails +Description of problem: +Attempting to build with --enable-profiler fails +Steps to reproduce: +1. ../../configure --enable-profiler +2. make +Additional information: +[975/3221] Compiling C object libcommon.fa.p/monitor_qmp-cmds.c.o + FAILED: libcommon.fa.p/monitor_qmp-cmds.c.o + cc -m64 -mcx16 -Ilibcommon.fa.p -I../../dtc/libfdt -I/usr/include/capstone -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libpng16 + -I/usr/include/p11-kit-1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/us + r/include/slirp -I/usr/include/virgl -I/usr/include/libusb-1.0 -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/gtk-3.0 -I/usr + /include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ + include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/vte-2.91 -fdiagnosti + cs-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote . -iquote /home/alex/lsrc/qemu.git + -iquote /home/alex/lsrc/qemu.git/include -iquote /home/alex/lsrc/qemu.git/disas/libvixl -iquote /home/alex/lsrc/qemu.git/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOUR + CE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-co + mmon -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wend + if-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_ + XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.fa.p/monitor_qmp-cmds.c.o -MF libcommon.fa.p/monitor_qmp-cmds.c.o.d -o libcommon. + fa.p/monitor_qmp-cmds.c.o -c ../../monitor/qmp-cmds.c + ../../monitor/qmp-cmds.c: In function ‘qmp_x_query_profile’: + ../../monitor/qmp-cmds.c:369:21: error: implicit declaration of function ‘tcg_cpu_exec_time’ [-Werror=implicit-function-declaration] + 369 | cpu_exec_time = tcg_cpu_exec_time(); + | ^~~~~~~~~~~~~~~~~ + ../../monitor/qmp-cmds.c:369:21: error: nested extern declaration of ‘tcg_cpu_exec_time’ [-Werror=nested-externs] + cc1: all warnings being treated as errors |