diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/106 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1060 | 48 | ||||
| -rw-r--r-- | results/classifier/108/other/1061 | 261 | ||||
| -rw-r--r-- | results/classifier/108/other/1061778 | 29 | ||||
| -rw-r--r-- | results/classifier/108/other/1062 | 31 | ||||
| -rw-r--r-- | results/classifier/108/other/1062220 | 100 | ||||
| -rw-r--r-- | results/classifier/108/other/1062411 | 114 | ||||
| -rw-r--r-- | results/classifier/108/other/1063807 | 88 | ||||
| -rw-r--r-- | results/classifier/108/other/1064 | 58 | ||||
| -rw-r--r-- | results/classifier/108/other/1065 | 20 | ||||
| -rw-r--r-- | results/classifier/108/other/1066055 | 849 | ||||
| -rw-r--r-- | results/classifier/108/other/1066909 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/1067119 | 28 | ||||
| -rw-r--r-- | results/classifier/108/other/1067517 | 96 | ||||
| -rw-r--r-- | results/classifier/108/other/1068900 | 32 |
15 files changed, 1803 insertions, 0 deletions
diff --git a/results/classifier/108/other/106 b/results/classifier/108/other/106 new file mode 100644 index 00000000..fead34f1 --- /dev/null +++ b/results/classifier/108/other/106 @@ -0,0 +1,16 @@ +device: 0.795 +graphic: 0.762 +semantic: 0.382 +performance: 0.297 +vnc: 0.210 +other: 0.206 +debug: 0.135 +boot: 0.133 +network: 0.091 +PID: 0.069 +permissions: 0.050 +socket: 0.036 +files: 0.034 +KVM: 0.023 + +qemu-git gravis ultrasound not working diff --git a/results/classifier/108/other/1060 b/results/classifier/108/other/1060 new file mode 100644 index 00000000..1c6752be --- /dev/null +++ b/results/classifier/108/other/1060 @@ -0,0 +1,48 @@ +other: 0.662 +device: 0.604 +graphic: 0.540 +semantic: 0.443 +debug: 0.343 +vnc: 0.323 +PID: 0.230 +socket: 0.226 +performance: 0.190 +boot: 0.186 +network: 0.177 +permissions: 0.166 +files: 0.131 +KVM: 0.052 + +RISC-V: mtval/stval is not correctly set to the instruction itself on illegal instructions +Description of problem: +QEMU 7.0 claims to support `stval`/`mtval` for illegal instructions, but `mtval`/`stval` is actually set to `0` +Steps to reproduce: +1. Assemble and link `mtval-illegal.elf`. The code simply sets up a trap handler and generates an illegal instruction exception + +2. Start QEMU with: + + ``` + qemu-system-riscv64 -cpu rv64,h=off -bios mtval-illegal.elf -nographic -icount shift=0 -s -S + ``` + +3. Attach with GDB: + + ``` + gdb mtval-illegal.elf + + # Within GDB + target extended-remote :1234 + break trap + disp $mtval + + # Keep single stepping until breakpoint + stepi + ``` + +4. When control flow reaches `trap`, `mtval` is written with `0` instead of the encoding of `csrw time, x0` (`0xc0101073`) +Additional information: +Writing `0` to `mtval` on a illegal instruction trap is allowed by the specs, but since the [changelog of QEMU 7.0][changelog] says it should be supported, I would consider it a bug. + +[changelog]: https://wiki.qemu.org/ChangeLog/7.0#RISC-V + +I encountered this when trying to figure out why my program worked with QEMU 6 but breaks with QEMU 7. It's more complicated, but in that case I managed to get `mtval` written with neither `0` nor the actual illegal instruction, but a different illegal instruction. I will try gathering up all the dependencies and write down the steps to reproduce if needed and if I find the time. diff --git a/results/classifier/108/other/1061 b/results/classifier/108/other/1061 new file mode 100644 index 00000000..b6283f54 --- /dev/null +++ b/results/classifier/108/other/1061 @@ -0,0 +1,261 @@ +other: 0.846 +graphic: 0.805 +debug: 0.766 +semantic: 0.757 +vnc: 0.740 +socket: 0.731 +PID: 0.718 +boot: 0.715 +device: 0.711 +performance: 0.686 +permissions: 0.678 +files: 0.643 +network: 0.635 +KVM: 0.602 + +xen/pt: Incorrect register mask for PCI passthrough prevents Linux guest from completing boot process +Description of problem: +In brief, the problem is that PCI/GPU passthrough functions normally with Xen/Qemu if the Xen HVM guest is Windows, but if the guest is Linux, the guest will not complete the booting process and it never reaches the systemd targets that allow the GUI environment to start and login to the desktop environment. The problem is that a bug in the way Qemu initializes the PCI status register of the passed through devices causes the PCI capabilities list bit of the PCI status register to be disabled instead of enabled. This in turn disables the MSI-x interrupt handling capability of the passed through PCI devices. I think the reason only Linux guests are affected is that Linux guests use a different method of delivering interrupts from the passed through PCI devices to the guest from the method used by Windows guests, and the method used by Windows does not require the MSI-x capability of the PCI devices but the method used by Linux does need the MSI-x capability of the passed through devices. I will explain this further in the additional information section with logs and other relevant information. +Steps to reproduce: +1. It might only be reproducible on specific hardware. It is very reproducible on my system, an ASRock B85M-Pro4 with BIOS version P2.50 and a Haswell core i5-4590S CPU. +2. Configure the system to pass through the Intel integrated graphics device (IGD), the on-board USB 3 controller, and the onboard PCI audio device to a Windows Xen HVM guest with Qemu running as the device model for the Windows guest in Dom0 using the Xen xl toolstack, and verify that the Windows guest boots and functions properly. This is not trivial and can probably only be done by persons familiar with Xen and its PCI and VGA/GPU passthrough feature. Here is the xl domain configuration file that the Xen xl toolstack used to create and boot the working Windows HVM domain with passthrough of three PCI devices on my hardware: +``` +builder = 'hvm' +bios = 'seabios' +memory = '3072' +vcpus = '4' +device_model_version = 'qemu-xen' +disk = ['/dev/systems/windows,,xvda,w'] +name = 'bullseye' +vif = [ 'model=e1000,script=vif-route,ip=<redacted>' ] +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'destroy' +boot = 'c' +acpi = '1' +apic = '1' +viridian = '1' +xen_platform_pci = '1' +serial = 'pty' +vga = 'none' +sdl = '0' +vnc = '0' +gfx_passthru = '1' +pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ] +``` +3. Shut down the working Windows Xen HVM and replace it with a Linux Xen HVM disk image and try to boot that in place of Windows, keeping all other configuration options the same as with the working Windows guest. To create and boot the non-working Linux HVM domain, I used the same xl domain configuration as for Windows with the exception that the disk line was replaced with: +``` +disk = ['/dev/systems/linux,,xvda,w'] +``` +which obviously points to a virtual disk that boots Linux instead of Windows. A Linux guest, such as Debian bullseye or Debian buster or Debian sid will not boot properly and instead exhibit the problem handling IRQs from the passed through PCI devices, as discussed above. +Additional information: +This problem is known by QubesOS and they have been using a patch to fix it since 2017, but they give very few details about the problem in their commit messages: + +https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c + +That same patch to hw/xen/xen_pt_config_init.c also fixes the problem on my system. + +Some logs: + +Without the QubesOS patch, I get error messages indicating problems handling IRQs like this in the Dom0: + +May 10 08:50:03 bullseye kernel: [79077.644346] pciback 0000:00:1b.0: xen_pciback: vpci: assign to virtual slot 0 +May 10 08:50:03 bullseye kernel: [79077.644478] pciback 0000:00:1b.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.644732] pciback 0000:00:14.0: xen_pciback: vpci: assign to virtual slot 1 +May 10 08:50:03 bullseye kernel: [79077.644874] pciback 0000:00:14.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.645024] pciback 0000:00:02.0: xen_pciback: vpci: assign to virtual slot 2 +May 10 08:50:03 bullseye kernel: [79077.645107] pciback 0000:00:02.0: registering for 16 +May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready +May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready +May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants +May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option) +May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 +May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015 +May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace: +May 10 08:50:44 bullseye kernel: [79119.104984] <IRQ> +May 10 08:50:44 bullseye kernel: [79119.104998] dump_stack+0x6b/0x83 +May 10 08:50:44 bullseye kernel: [79119.105008] __report_bad_irq+0x35/0xa7 +May 10 08:50:44 bullseye kernel: [79119.105014] note_interrupt.cold+0xb/0x61 +May 10 08:50:44 bullseye kernel: [79119.105024] handle_irq_event+0xa8/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105030] handle_fasteoi_irq+0x78/0x1c0 +May 10 08:50:44 bullseye kernel: [79119.105037] generic_handle_irq+0x47/0x50 +May 10 08:50:44 bullseye kernel: [79119.105044] __evtchn_fifo_handle_events+0x175/0x190 +May 10 08:50:44 bullseye kernel: [79119.105054] __xen_evtchn_do_upcall+0x66/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105063] __xen_pv_evtchn_do_upcall+0x11/0x20 +May 10 08:50:44 bullseye kernel: [79119.105069] asm_call_irq_on_stack+0x12/0x20 +May 10 08:50:44 bullseye kernel: [79119.105072] </IRQ> +May 10 08:50:44 bullseye kernel: [79119.105079] xen_pv_evtchn_do_upcall+0xa2/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105084] exc_xen_hypervisor_callback+0x8/0x10 +May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc +May 10 08:50:44 bullseye kernel: [79119.105100] RSP: e02b:ffffffff82603de8 EFLAGS: 00000246 +May 10 08:50:44 bullseye kernel: [79119.105106] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff810023aa +May 10 08:50:44 bullseye kernel: [79119.105108] RDX: 0000000009d62df2 RSI: 0000000000000000 RDI: 0000000000000001 +May 10 08:50:44 bullseye kernel: [79119.105111] RBP: ffffffff82613940 R08: 00000066a1715350 R09: 000047f57b235dc9 +May 10 08:50:44 bullseye kernel: [79119.105114] R10: 0000000000007ff0 R11: 0000000000000246 R12: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105117] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105124] ? xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105133] ? xen_safe_halt+0xc/0x20 +May 10 08:50:44 bullseye kernel: [79119.105140] ? default_idle+0xa/0x10 +May 10 08:50:44 bullseye kernel: [79119.105145] ? default_idle_call+0x38/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105152] ? do_idle+0x208/0x2b0 +May 10 08:50:44 bullseye kernel: [79119.105158] ? cpu_startup_entry+0x19/0x20 +May 10 08:50:44 bullseye kernel: [79119.105164] ? start_kernel+0x587/0x5a8 +May 10 08:50:44 bullseye kernel: [79119.105170] ? xen_start_kernel+0x625/0x631 +May 10 08:50:44 bullseye kernel: [79119.105180] ? startup_xen+0x3e/0x3e +May 10 08:50:44 bullseye kernel: [79119.105184] handlers: +May 10 08:50:44 bullseye kernel: [79119.105222] [<000000005d228d5f>] usb_hcd_irq [usbcore] +May 10 08:50:44 bullseye kernel: [79119.105245] [<00000000e534b010>] ath_isr [ath9k] +May 10 08:50:44 bullseye kernel: [79119.105257] Disabling IRQ #16 + +Also, without the patch, I get error messages about failure to handle IRQs in the Linux Xen HVM guest: + +Oct 23 18:50:32 domU kernel: irq 36: nobody cared (try booting with the "irqpoll" option) +Oct 23 18:50:32 domU kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-9-amd64 #1 Debian 5.10.70-1 +Oct 23 18:50:32 domU kernel: Hardware name: Xen HVM domU, BIOS 4.14.3 10/22/2021 +Oct 23 18:50:32 domU kernel: Call Trace: +Oct 23 18:50:32 domU kernel: <IRQ> +Oct 23 18:50:32 domU kernel: dump_stack+0x6b/0x83 +Oct 23 18:50:32 domU kernel: __report_bad_irq+0x35/0xa7 +Oct 23 18:50:32 domU kernel: note_interrupt.cold+0xb/0x61 +Oct 23 18:50:32 domU kernel: handle_irq_event+0xa8/0xb0 +Oct 23 18:50:32 domU kernel: handle_fasteoi_irq+0x78/0x1c0 +Oct 23 18:50:32 domU kernel: generic_handle_irq+0x47/0x50 +Oct 23 18:50:32 domU kernel: __evtchn_fifo_handle_events+0x175/0x190 +Oct 23 18:50:32 domU kernel: __xen_evtchn_do_upcall+0x66/0xb0 +Oct 23 18:50:32 domU kernel: __sysvec_xen_hvm_callback+0x22/0x30 +Oct 23 18:50:32 domU kernel: asm_call_irq_on_stack+0x12/0x20 +Oct 23 18:50:32 domU kernel: </IRQ> +Oct 23 18:50:32 domU kernel: sysvec_xen_hvm_callback+0x72/0x80 +Oct 23 18:50:32 domU kernel: asm_sysvec_xen_hvm_callback+0x12/0x20 +Oct 23 18:50:32 domU kernel: RIP: 0010:native_safe_halt+0xe/0x10 +Oct 23 18:50:32 domU kernel: Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d a6 6f 54 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 96 6f 54 00 f4 c3 cc cc 0f 1f 44 00 +Oct 23 18:50:32 domU kernel: RSP: 0018:ffffffff89003e48 EFLAGS: 00000246 +Oct 23 18:50:32 domU kernel: RAX: 0000000000004000 RBX: 0000000000000001 RCX: ffff8dbb7cc2c9c0 +Oct 23 18:50:32 domU kernel: RDX: ffff8dbb7cc00000 RSI: ffff8dbaf55b1400 RDI: ffff8dbaf55b1464 +Oct 23 18:50:32 domU kernel: RBP: ffff8dbaf55b1464 R08: ffffffff891b9120 R09: 0000000000000008 +Oct 23 18:50:32 domU kernel: R10: 000000000000000e R11: 000000000000000d R12: 0000000000000001 +Oct 23 18:50:32 domU kernel: R13: ffffffff891b91a0 R14: 0000000000000001 R15: 0000000000000000 +Oct 23 18:50:32 domU kernel: ? xen_sched_clock+0x11/0x20 +Oct 23 18:50:32 domU kernel: acpi_idle_do_entry+0x46/0x50 +Oct 23 18:50:32 domU kernel: acpi_idle_enter+0x86/0xc0 +Oct 23 18:50:32 domU kernel: cpuidle_enter_state+0x89/0x350 +Oct 23 18:50:32 domU kernel: cpuidle_enter+0x29/0x40 +Oct 23 18:50:32 domU kernel: do_idle+0x1ef/0x2b0 +Oct 23 18:50:32 domU kernel: cpu_startup_entry+0x19/0x20 +Oct 23 18:50:32 domU kernel: start_kernel+0x587/0x5a8 +Oct 23 18:50:32 domU kernel: secondary_startup_64_no_verify+0xb0/0xbb +Oct 23 18:50:32 domU kernel: handlers: +Oct 23 18:50:32 domU kernel: [<000000007d3a0964>] usb_hcd_irq [usbcore] +Oct 23 18:50:32 domU kernel: Disabling IRQ #36 +Oct 23 18:50:32 domU kernel: PM: Image not found (code -22) +Oct 23 18:50:32 domU kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:45:pipe A] flip_done timed out + +To prove the cause of the bug, I compare some logs without the patch +and with the patch that fixes it. + +First, relevant logs generated by Qemu in Dom0, for existing Qemu without the patch. On Debian these logs are located in /var/log/xen in the Dom0: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0280. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0080. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +Next, the same logs, but now using a version of Qemu with the patch that fixes the bug: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0290. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0090. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +To decipher what is happening here, one must refer to the definitions +in the pci/header.h file from PCI Utilities that in Debian is in the +libpci-dev package and is probably in similarly named packages on other +distros. + +The Offset of 0x0006 corresponds to the 16-bit PCI_STATUS register of +the passed through device, and the Emulated value of 0x0010 sets the desired +emulated value of the PCI_STATUS_CAP_LIST bit to 1 in the PCI_STATUS register. +The host values of 0x0290, 0x0090 correspond to the setting of the register in the +physical device for real device 00:14.0 and 00:02.0, respectively. +The syncing to value indicates the value of the register that Qemu +exposes to the guest. Notice that without the patch, the PCI_STATUS_CAP_LIST +bit is turned off for the two PCI devices (register value = 0x0280 and 0x0080 +for real device 00:14.0 and 00:02.0, respectively), but the bit is turned +on (0x0290 and 0x0090) for these devices with the patch. With the capabilities list enabled, the guest can use the MSI-x capability of the device, but with the capabilities +list disabled, the guest cannot use the MSI-x capability of the devices. +That explains why this patch is needed in Qemu to fix this problem and enable the Linux guest to use the MSI-x capability of the passed through PCI devices. + +This is the QubesOS patch thatfixes it: +``` +--- a/hw/xen/xen_pt_config_init.c ++++ b/hw/xen/xen_pt_config_init.c +@@ -1969,7 +1969,7 @@ + /* Mask out host (including past size). */ + new_val = val & host_mask; + /* Merge emulated ones (excluding the non-emulated ones). */ +- new_val |= data & host_mask; ++ new_val |= data & reg->emu_mask; + /* Leave intact host and emulated values past the size - even though + * we do not care as we write per reg->size granularity, but for the + * logging below lets have the proper value. */ +``` +The QubesOS patch that fixes it in Debian's Qemu 7.0.0 build is also attached as a file.[xen-fix-emu-mask.patch](/uploads/3bef189175549cd9854f8dc3d1affc88/xen-fix-emu-mask.patch) + +~~I will not officially submit it as a patch because I am not its author.~~ + +~~I do not know why QubesOS never officially requested that this fix +be committed to Qemu upstream, but I hope after review by the +maintainers of the code touched by this patch it will be recognized +as a necessary fix to a mistake that causes the desired merge of +the host and emulated values to be incorrect.~~ + +For reference, the commit that is fixed by the QubesOS patch is: + +Fixes: 2e87512eccf3c5e40f3142ff5a763f4f850839f4 (xen/pt: Sync up the dev.config and data values.) + +I think perhaps that commit and the patched file might need some other cleanup so I might try my hand at officially submitting a patch to Qemu that fixes this issue on my hardware without breaking something else, because it is possible that the simple QubesOS patch is not suitable as the correct fix. + +But before I do that, I wish to make one more comment. In my logs, the only other register than the PCI_STATUS register that is affected by the QubesOS patch is the PCI_HEADER_TYPE register. Without the patch, the register's value is always exposed to the guest as 0x80, and with the patch, the value is always exposed as 0x00 (PCI_HEADER_TYPE_NORMAL as defined in pci/header.h). That is because Qemu sets the initial emulated value of PCI_HEADER_TYPE register to 0x80, but Qemu also sets the emu_mask to 0x00, so after correcting the merging of the host and emulated values with the QubesOS patch, the value is synced to 0x00 instead of 0x80. What I don't understand is why the register is initialized with 0x80, but the emu_mask is 0x00. Shouldn't the emu_mask be 0x80, to pass through the initial emulated value of 0x80? ~~Also, I don't know why the initial emulated value of PCI_HEADER_TYPE is set to 0x80 but I will assume that is the correct emulated value that should be exposed to the guest.~~ Update: After doing some research, I discovered the bit that is set in the PCI_HEADER_TYPE register (0x80) because of this issue is the bit to define the device as a multifunction device. None of my devices are multifunction, and the fact that the multifunction bit is incorrectly set on my passed through devices because of this issue seems to have no effect on the operation of the device or the guest. Apparently the author of the code to initialize the PCI_HEADER_TYPE register planned to initialize every passed through device as a multifunction device, but is this needed? My testing indicates it is not needed on my system. + +I am referring to this code in hw/xen/xen_pt_config_init.c: + +``` +static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s, + XenPTRegInfo *reg, uint32_t real_offset, + uint32_t *data) +{ + /* read PCI_HEADER_TYPE */ + *data = reg->init_val | 0x80; + return 0; +} + +[...] + + /* Header Type reg */ + { + .offset = PCI_HEADER_TYPE, + .size = 1, + .init_val = 0x00, + .ro_mask = 0xFF, + .emu_mask = 0x00, + .init = xen_pt_header_type_reg_init, + .u.b.read = xen_pt_byte_reg_read, + .u.b.write = xen_pt_byte_reg_write, + }, +``` +I would appreciate any guidance that experienced Qemu or Xen contributors can give me about this question. ~~If no one gives me any guidance here in a timely manner, I plan to propose my own fix officially to Qemu as the QubesOS patch plus changing the emu_mask value of the PCI_HEADER_TYPE register from 0x00 to 0x80. I verified that fixes the problem I am seeing in the PCI_STATUS register without also causing the change that the QubesOS patch makes to the PCI_HEADER_TYPE register.~~ + +I plan to submit a patch to fix this issue, noting the effect the patch has on the PCI_HEADER_TYPE register in the commit message. diff --git a/results/classifier/108/other/1061778 b/results/classifier/108/other/1061778 new file mode 100644 index 00000000..7dbd0193 --- /dev/null +++ b/results/classifier/108/other/1061778 @@ -0,0 +1,29 @@ +network: 0.738 +performance: 0.662 +socket: 0.655 +device: 0.564 +semantic: 0.535 +graphic: 0.481 +permissions: 0.401 +vnc: 0.374 +PID: 0.291 +debug: 0.286 +boot: 0.168 +files: 0.137 +other: 0.128 +KVM: 0.043 + +signal mask not reset on exec + +Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed. + +./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd. + +./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk: 0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates. + +qemu-0.14 didn't block SIGALRM, so such scripts worked fine there. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1062 b/results/classifier/108/other/1062 new file mode 100644 index 00000000..f8ac851f --- /dev/null +++ b/results/classifier/108/other/1062 @@ -0,0 +1,31 @@ +graphic: 0.906 +device: 0.826 +performance: 0.728 +socket: 0.727 +network: 0.651 +semantic: 0.646 +permissions: 0.635 +vnc: 0.606 +other: 0.562 +PID: 0.559 +files: 0.517 +boot: 0.478 +debug: 0.476 +KVM: 0.082 + +AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32 +Description of problem: +In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support. + +This would break this EL3 code, which should run on cpu reset to attempt to return to EL1: +```asm +mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked +mov SPSR_EL3, x1 +adr x1, 1f +msr ELR_EL3, x1 +eret +1: +; something something +``` +Additional information: + diff --git a/results/classifier/108/other/1062220 b/results/classifier/108/other/1062220 new file mode 100644 index 00000000..9d1b8d99 --- /dev/null +++ b/results/classifier/108/other/1062220 @@ -0,0 +1,100 @@ +other: 0.973 +semantic: 0.956 +device: 0.953 +graphic: 0.948 +permissions: 0.942 +debug: 0.937 +boot: 0.930 +PID: 0.928 +socket: 0.925 +vnc: 0.912 +performance: 0.905 +network: 0.891 +KVM: 0.859 +files: 0.837 + +qemu-system-arm crashed with SIGABRT in cpu_abort() + +-kernel u-boot.bin + +ProblemType: Crash +DistroRelease: Ubuntu 12.10 +Package: qemu-system 1.2.0-2012.09-0ubuntu1 +ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1 +Uname: Linux 3.5.0-10-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.1-0ubuntu1 +Architecture: amd64 +CrashCounter: 1 +Date: Fri Oct 5 19:30:23 2012 +ExecutablePath: /usr/bin/qemu-system-arm +InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110804) +ProcCmdline: qemu-system-arm -M versatilepb -kernel u-boot.bin +Signal: 6 +SourcePackage: qemu-linaro +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () + ?? () + ?? () +Title: qemu-system-arm crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to quantal on 2012-08-11 (54 days ago) +UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers + + + +StacktraceTop: + cpu_abort (env=env@entry=0x7f7603204b78, fmt=fmt@entry=0x7f7600a056f0 "Trying to execute code outside RAM or ROM at 0x%08x\n") at /build/buildd/qemu-linaro-1.2.0-2012.09/exec.c:1774 + get_page_addr_code (env1=0x7f7603204b78, env1@entry=0xffffffffffff4bc2, addr=addr@entry=4294903824) at /build/buildd/qemu-linaro-1.2.0-2012.09/cputlb.c:340 + tb_find_slow (flags=<optimized out>, pc=4294903824, env=0xffffffffffff4bc2, cs_base=<optimized out>) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:96 + tb_find_fast (env=0xffffffffffff4bc2) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:152 + cpu_arm_exec (env=0xffffffffffff4bc2, env@entry=0x7f7603204b78) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:569 + + + + + + + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Marked as affecting Ubuntu's qemu package, as bug 1103405 (a dup of this one) happened with the new qemu, not qemu-linaro, package. + +qemu-system-arm -M versatilepb -kernel u-boot.bin +[...] +Trying to execute code outside RAM or ROM + +This almost always means that you tried to execute a guest binary which wasn't for the VersatilePB. Without more info about exactly what this u-boot.bin file was this bug report can't progress any further. + + +Marking incomplete pending more information about the origin of u-boot.bin per comment #8. + +Also happens on wily when running + +$ qemu-system-arm -machine realview-pb-a8 + +#10: if that's your entire command line then that's expected behaviour, and is saying "we just executed a pile of zeros and fell off the end of RAM". You need to supply a kernel to run. + + +In the upcoming QEMU 2.7 we've removed the abort() call in this code path, and instead will print an error message which hopefully is clearer at suggesting to users where they've gone wrong rather than implying that this is a QEMU bug: + +====== +qemu-system-arm: Trying to execute code outside RAM or ROM at 0x08000000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +====== + +So I'm going to mark this bug as fix-committed, at least for upstream QEMU. + + diff --git a/results/classifier/108/other/1062411 b/results/classifier/108/other/1062411 new file mode 100644 index 00000000..a02f15f8 --- /dev/null +++ b/results/classifier/108/other/1062411 @@ -0,0 +1,114 @@ +other: 0.729 +permissions: 0.686 +device: 0.685 +debug: 0.668 +semantic: 0.663 +files: 0.659 +vnc: 0.648 +KVM: 0.640 +socket: 0.636 +network: 0.635 +PID: 0.628 +performance: 0.615 +graphic: 0.605 +boot: 0.564 + +QEMU fails during migration and reports "qemu: VQ 0 size 0x80 Guest index 0x2d6 inconsistent with Host index 0x18: delta 0x2be" + +This issue is reproducing consistently on automated testing, verified on manual testing (although it may require many tries). + +Steps to reproduce: + +1) Start a linux guest. The command line used by automated testing was: + +10/05 06:48:27 INFO | kvm_vm:1605| MALLOC_PERTURB_=1 /usr/local/autotest/tests/kvm/qemu +10/05 06:48:27 INFO | kvm_vm:1605| -S +10/05 06:48:27 INFO | kvm_vm:1605| -name 'vm1' +10/05 06:48:27 INFO | kvm_vm:1605| -nodefaults +10/05 06:48:27 INFO | kvm_vm:1605| -chardev socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-062311-r6UwQhzg,server,nowait +10/05 06:48:27 INFO | kvm_vm:1605| -mon chardev=hmp_id_humanmonitor1,mode=readline +10/05 06:48:27 INFO | kvm_vm:1605| -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-062311-r6UwQhzg,server,nowait +10/05 06:48:27 INFO | kvm_vm:1605| -mon chardev=qmp_id_qmpmonitor1,mode=control +10/05 06:48:27 INFO | kvm_vm:1605| -chardev socket,id=serial_id_20121005-062311-r6UwQhzg,path=/tmp/serial-20121005-062311-r6UwQhzg,server,nowait +10/05 06:48:27 INFO | kvm_vm:1605| -device isa-serial,chardev=serial_id_20121005-062311-r6UwQhzg +10/05 06:48:27 INFO | kvm_vm:1605| -chardev socket,id=seabioslog_id_20121005-062311-r6UwQhzg,path=/tmp/seabios-20121005-062311-r6UwQhzg,server,nowait +10/05 06:48:27 INFO | kvm_vm:1605| -device isa-debugcon,chardev=seabioslog_id_20121005-062311-r6UwQhzg,iobase=0x402 +10/05 06:48:27 INFO | kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 +10/05 06:48:27 INFO | kvm_vm:1605| -drive file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0 +10/05 06:48:27 INFO | kvm_vm:1605| -device virtio-blk-pci,drive=virtio0 +10/05 06:48:27 INFO | kvm_vm:1605| -device virtio-net-pci,netdev=idbdMz8N,mac='9a:cf:d0:d1:d2:d3',id='ida0Kc7l' +10/05 06:48:27 INFO | kvm_vm:1605| -netdev tap,id=idbdMz8N,fd=21 +10/05 06:48:27 INFO | kvm_vm:1605| -m 2048 +10/05 06:48:27 INFO | kvm_vm:1605| -smp 2,cores=1,threads=1,sockets=2 +10/05 06:48:27 INFO | kvm_vm:1605| -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 +10/05 06:48:27 INFO | kvm_vm:1605| -vnc :0 +10/05 06:48:27 INFO | kvm_vm:1605| -vga std +10/05 06:48:27 INFO | kvm_vm:1605| -rtc base=utc,clock=host,driftfix=none +10/05 06:48:27 INFO | kvm_vm:1605| -boot order=cdn,once=c,menu=off +10/05 06:48:27 INFO | kvm_vm:1605| -enable-kvm + +Start a new VM in incoming mode. The example on this bug is using TCP protocol: + +10/05 07:18:56 INFO | kvm_vm:1605| MALLOC_PERTURB_=1 /usr/local/autotest/tests/kvm/qemu +10/05 07:18:56 INFO | kvm_vm:1605| -S +10/05 07:18:56 INFO | kvm_vm:1605| -name 'vm1' +10/05 07:18:56 INFO | kvm_vm:1605| -nodefaults +10/05 07:18:56 INFO | kvm_vm:1605| -chardev socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20121005-071855-5QYsCtRS,server,nowait +10/05 07:18:56 INFO | kvm_vm:1605| -mon chardev=hmp_id_humanmonitor1,mode=readline +10/05 07:18:56 INFO | kvm_vm:1605| -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20121005-071855-5QYsCtRS,server,nowait +10/05 07:18:56 INFO | kvm_vm:1605| -mon chardev=qmp_id_qmpmonitor1,mode=control +10/05 07:18:56 INFO | kvm_vm:1605| -chardev socket,id=serial_id_20121005-071855-5QYsCtRS,path=/tmp/serial-20121005-071855-5QYsCtRS,server,nowait +10/05 07:18:56 INFO | kvm_vm:1605| -device isa-serial,chardev=serial_id_20121005-071855-5QYsCtRS +10/05 07:18:56 INFO | kvm_vm:1605| -chardev socket,id=seabioslog_id_20121005-071855-5QYsCtRS,path=/tmp/seabios-20121005-071855-5QYsCtRS,server,nowait +10/05 07:18:56 INFO | kvm_vm:1605| -device isa-debugcon,chardev=seabioslog_id_20121005-071855-5QYsCtRS,iobase=0x402 +10/05 07:18:56 INFO | kvm_vm:1605| -device ich9-usb-uhci1,id=usb1 +10/05 07:18:56 INFO | kvm_vm:1605| -drive file='/tmp/kvm_autotest_root/images/rhel62-64.qcow2',if=none,cache=none,id=virtio0 +10/05 07:18:56 INFO | kvm_vm:1605| -device virtio-blk-pci,drive=virtio0 +10/05 07:18:56 INFO | kvm_vm:1605| -device virtio-net-pci,netdev=idERNnUO,mac='9a:cf:d0:d1:d2:d3',id='ideI7zfw' +10/05 07:18:56 INFO | kvm_vm:1605| -netdev tap,id=idERNnUO,fd=32 +10/05 07:18:56 INFO | kvm_vm:1605| -m 2048 +10/05 07:18:56 INFO | kvm_vm:1605| -smp 2,cores=1,threads=1,sockets=2 +10/05 07:18:56 INFO | kvm_vm:1605| -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 +10/05 07:18:56 INFO | kvm_vm:1605| -vnc :1 +10/05 07:18:56 INFO | kvm_vm:1605| -vga std +10/05 07:18:56 INFO | kvm_vm:1605| -rtc base=utc,clock=host,driftfix=none +10/05 07:18:56 INFO | kvm_vm:1605| -boot order=cdn,once=c,menu=off +10/05 07:18:56 INFO | kvm_vm:1605| -enable-kvm +10/05 07:18:56 INFO | kvm_vm:1605| -incoming tcp:0:5200 + +Start the migration, typing on monitor + +10/05 07:18:58 DEBUG|kvm_monito:0177| (monitor humanmonitor1) Sending command 'migrate -d tcp:0:5200' + +The VM will start migrating state to the new qemu instance, and at some point it will stop with: + +10/05 07:19:10 INFO | aexpect:0786| [qemu output] qemu: VQ 0 size 0x80 Guest index 0x2d6 inconsistent with Host index 0x18: delta 0x2be +10/05 07:19:10 INFO | aexpect:0786| [qemu output] qemu: warning: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +10/05 07:19:10 INFO | aexpect:0786| [qemu output] load of migration failed +10/05 07:19:10 INFO | aexpect:0786| [qemu output] (Process terminated with status 0) + +Due to the large number of migrations executed during a virt job (vm state keeps being passed back and forth many times, using many protocols), we get this problem on every single virt job. + +Latest commits we found this issue: + +Kernel (kvm.git, avi's tree) +10/05 05:38:12 INFO | git:0153| git commit ID is 1a95620f45155ac523cd1419d89150fbb4eb858b (tag kvm-3.6-2-136-g1a95620) + +Userspace (qemu.git) + +10/05 06:20:30 INFO | git:0153| git commit ID is a14c74928ba1fdaada515717f4d3c3fa3275d6f7 (tag v1.2.0-546-ga14c749) + +Have you bisected it already? + +No, I haven't. I'll do my best to reserve time this week to do so. + +FWIW this one bites me. The bug report seems fairly abandoned ... has this been fixed elsewhere perhaps? + +I meant "bites me too" ... + +Yep, I did let this one slip... + +In any case, I don't see this problem anymore, it was fixed a long while ago. Are you trying QEMU from the latest master? + +Closing this ticket now, since it has been fixed according to comment #5. + diff --git a/results/classifier/108/other/1063807 b/results/classifier/108/other/1063807 new file mode 100644 index 00000000..45038dbe --- /dev/null +++ b/results/classifier/108/other/1063807 @@ -0,0 +1,88 @@ +KVM: 0.843 +permissions: 0.842 +vnc: 0.832 +graphic: 0.818 +debug: 0.813 +other: 0.792 +boot: 0.773 +device: 0.772 +files: 0.767 +PID: 0.746 +semantic: 0.727 +performance: 0.726 +network: 0.684 +socket: 0.630 + +KVM crashes when booting a PointSec encrypted Windows 7 + +Hi all, + +KVM crashes each time the VM boots after installing PointSec. + +Steps to reproduce are: +1) install win7 64bits +2) install PointSec FDE (Full Disk Encryption => http://www.checkpoint.com/products/full-disk-encryption/index.html) +3) regardless any other qemu parameters, one gets a "KVM internal error. Suberror: 1 / emulation failure" error message and a qemu dump like this one: + +KVM internal error. Suberror: 1 +emulation failure +EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000 +ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d +EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA] +SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 00028050 00001dd8 +IDT= 00029e40 00000188 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f + + +My system info: +root@RJZ-LNX:/home/rjz# cat /proc/cpuinfo | tail -24 +cpu family : 6 +model : 37 +model name : Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz +stepping : 5 +microcode : 0x2 +cpu MHz : 1199.000 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 2 +apicid : 5 +initial apicid : 5 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid +bogomips : 5319.72 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + + + +and qemu (Ubuntu distribution) info is: + +root@RJZ-LNX:/home/rjz# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + + + +Best regards, +Rolando. + +Since this is very likely rather a KVM kernel bug than a QEMU userspace bug, could you please report it to the KVM mailing list / bug tracker instead (see http://www.linux-kvm.org/page/Bugs)? Thanks! + diff --git a/results/classifier/108/other/1064 b/results/classifier/108/other/1064 new file mode 100644 index 00000000..9fd6812f --- /dev/null +++ b/results/classifier/108/other/1064 @@ -0,0 +1,58 @@ +KVM: 0.866 +files: 0.787 +network: 0.771 +device: 0.759 +socket: 0.689 +permissions: 0.668 +graphic: 0.647 +vnc: 0.626 +performance: 0.619 +PID: 0.599 +debug: 0.593 +semantic: 0.567 +boot: 0.469 +other: 0.445 + +aarch64:qemu6.2.0 compile error +Description of problem: + +Steps to reproduce: +1. download qemu source package +`wget http://mirrors.163.com/centos-vault/centos/8-stream/AppStream/Source/SPackages/qemu-kvm-6.2.0-12.module_el8.7.0%2b1140%2bff0772f9.src.rpm` +2. install qemu source package +`rpm -ivh qemu-*.rpm` +3. build qemu +` rpmbuild --define "_topdir /xxx/src_qemu6.2.0" -bb SPECS/qemu-kvm.spec` +4. error message: +``` +In function 'dump_receive_iov', + inlined from 'filter_dump_receive_iov' at ../net/dump.c:157:5: +../net/dump.c:89:9: error: 'writev' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] + 89 | if (writev(s->fd, dumpiov, cnt + 1) != sizeof(hdr) + caplen) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from /home/xxx/src_qemu6.2.0/BUILD/qemu-kvm-6.2.0/include/qemu/osdep.h:108, + from ../net/dump.c:25: +../net/dump.c: In function 'filter_dump_receive_iov': +/usr/include/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)' + 52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count) + | ^~~~~~ +cc1: all warnings being treated as errors +``` +**gcc version** +``` +# gcc --version +gcc (GCC) 10.3.1 +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` +``` +[root]# meson -v +0.62.1 +[root]# ninja -v +ninja: error: loading 'build.ninja': No such file or directory +[root@vm77 src_qemu6.2.0]# ninja --version +1.8.2 +``` +Additional information: + diff --git a/results/classifier/108/other/1065 b/results/classifier/108/other/1065 new file mode 100644 index 00000000..a1d9eb58 --- /dev/null +++ b/results/classifier/108/other/1065 @@ -0,0 +1,20 @@ +device: 0.886 +graphic: 0.829 +permissions: 0.723 +network: 0.720 +other: 0.534 +debug: 0.512 +vnc: 0.511 +performance: 0.428 +socket: 0.422 +files: 0.350 +boot: 0.329 +semantic: 0.313 +PID: 0.302 +KVM: 0.059 + +cputlb: uninitialized local variable in tlb_set_page_with_attrs cause SIGSEGV when a CPU access an unmapped IOMMU page +Description of problem: +When a TCG cpu accesses an unmapped page within an IOMMU region that causes a translation fault, QEMU SIGSEGVs in `io_readx`. +The reason was that in `address_space_translate_for_iotlb`, `xlat` is not set on a permission fault. +As a result, `xlat` in `tlb_set_page_with_attr` is uninitialized. This in turn causes various mis-calculation and eventually crashes in `io_readx`. diff --git a/results/classifier/108/other/1066055 b/results/classifier/108/other/1066055 new file mode 100644 index 00000000..e8ebfd81 --- /dev/null +++ b/results/classifier/108/other/1066055 @@ -0,0 +1,849 @@ +other: 0.678 +graphic: 0.669 +semantic: 0.513 +debug: 0.506 +KVM: 0.472 +vnc: 0.468 +network: 0.434 +device: 0.419 +PID: 0.419 +files: 0.382 +socket: 0.381 +performance: 0.377 +permissions: 0.354 +boot: 0.318 + +Network performance regression with vde_switch + +I've noticed a significant network performance regression when using vde_switch, starting about one week ago (10/05/2012); before that date, I used to get about 1.5 Gbits host to guest, but now I can only get about 320 Mbits; I didn't find any modification in net/vde.*, just in hw/virtio*. + +My command line: + qemu-system-i386 -cdrom /bpd/bpd.iso -m 512 -boot d -enable-kvm \ + -localtime -ctrl-grab -usbdevice tablet \ + -device virtio-net-pci,mac=52:54:00:18:01:01,netdev=vde0,tx=bh,ioeventfd=on,x-txburst=32 \ + -netdev vde,id=vde0 -vga std -tb-size 2M -cpu host -clock unix + +My host runs a kernel 3.6.1 and my guest runs a kernel 3.5.4; the same problem happens with other host and guest versions, too. + +I know there are better ways of running a guest, but using vde I get a cleaner environment in the host (just one tun/tap interface to manage...), which is quite good when running some accademic experiments. + +Interestingly, at the same time I've noticed a performance enhancement of about 25~30 % when using a tun/tap interface, bridged or not. + +Thank you, very much. + +Edivaldo de Araujo Pereira + +On Fri, Oct 12, 2012 at 05:34:23PM -0000, Edivaldo de Araujo Pereira wrote: +> I've noticed a significant network performance regression when using +> vde_switch, starting about one week ago (10/05/2012); before that date, +> I used to get about 1.5 Gbits host to guest, but now I can only get +> about 320 Mbits; I didn't find any modification in net/vde.*, just in +> hw/virtio*. +> +> My command line: +> qemu-system-i386 -cdrom /bpd/bpd.iso -m 512 -boot d -enable-kvm \ +> -localtime -ctrl-grab -usbdevice tablet \ +> -device virtio-net-pci,mac=52:54:00:18:01:01,netdev=vde0,tx=bh,ioeventfd=on,x-txburst=32 \ +> -netdev vde,id=vde0 -vga std -tb-size 2M -cpu host -clock unix +> +> My host runs a kernel 3.6.1 and my guest runs a kernel 3.5.4; the same +> problem happens with other host and guest versions, too. +> +> I know there are better ways of running a guest, but using vde I get a +> cleaner environment in the host (just one tun/tap interface to +> manage...), which is quite good when running some accademic experiments. +> +> Interestingly, at the same time I've noticed a performance enhancement +> of about 25~30 % when using a tun/tap interface, bridged or not. + +Hi Edivaldo, +It would be great if you can help find the commit that caused this +regression. + +The basic process is: + +1. Identify a QEMU release or git tree that gives you 1.5 Gbit/s. +2. Double-check that qemu.git/master suffers reduced performance. +3. git bisect start <bad> <good> + where <bad> and <good> are the git commits that show differing + performance (for example, bad=HEAD good=v1.1.0) + +Then git will step through the commit history and ask you to test at +each step. (This is a binary search so even finding regressions that +happened many commits ago requires few steps.) + +You can read more about git-bisect(1) here: +http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search +http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html + +The end result is the commit introduced the regression. Please post +what you find! + +Stefan + + +Hi Stefan, + +Thank you, very much for taking the time to help me, and excuse me for not seeing your answer early... + +I've run the procedure you pointed me out, and the result is: + +0d8d7690850eb0cf2b2b60933cf47669a6b6f18f is the first bad commit +commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +Author: Amit Shah <email address hidden> +Date: Tue Sep 25 00:05:15 2012 +0530 + + virtio: Introduce virtqueue_get_avail_bytes() + + The current virtqueue_avail_bytes() is oddly named, and checks if a + particular number of bytes are available in a vq. A better API is to + fetch the number of bytes available in the vq, and let the caller do + what's interesting with the numbers. + + Introduce virtqueue_get_avail_bytes(), which returns the number of bytes + for buffers marked for both, in as well as out. virtqueue_avail_bytes() + is made a wrapper over this new function. + + Signed-off-by: Amit Shah <email address hidden> + Signed-off-by: Michael S. Tsirkin <email address hidden> + +:040000 040000 1a58b06a228651cf844621d9ee2f49b525e36c93 e09ea66ce7f6874921670b6aeab5bea921a5227d M hw + +I tried to revert that patch in the latest version, but it obviously didnt work; I'm trying to figure out the problem, but I don't know very well the souce code, so I think it's going to take some time. For now, it's all I could do. + +Thank you, again. +Edivaldo + + + +On Mon, Oct 15, 2012 at 09:46:06PM -0000, Edivaldo de Araujo Pereira wrote: +> Hi Stefan, +> +> Thank you, very much for taking the time to help me, and excuse me for +> not seeing your answer early... +> +> I've run the procedure you pointed me out, and the result is: +> +> 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f is the first bad commit +> commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +> Author: Amit Shah <email address hidden> +> Date: Tue Sep 25 00:05:15 2012 +0530 +> +> virtio: Introduce virtqueue_get_avail_bytes() +> +> The current virtqueue_avail_bytes() is oddly named, and checks if a +> particular number of bytes are available in a vq. A better API is to +> fetch the number of bytes available in the vq, and let the caller do +> what's interesting with the numbers. +> +> Introduce virtqueue_get_avail_bytes(), which returns the number of bytes +> for buffers marked for both, in as well as out. virtqueue_avail_bytes() +> is made a wrapper over this new function. +> +> Signed-off-by: Amit Shah <email address hidden> +> Signed-off-by: Michael S. Tsirkin <email address hidden> +> +> :040000 040000 1a58b06a228651cf844621d9ee2f49b525e36c93 +> e09ea66ce7f6874921670b6aeab5bea921a5227d M hw +> +> I tried to revert that patch in the latest version, but it obviously +> didnt work; I'm trying to figure out the problem, but I don't know very +> well the souce code, so I think it's going to take some time. For now, +> it's all I could do. + +After git-bisect(1) completes it is good to sanity-check the result by +manually testing 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f^ (the commit +just before the bad commit) and 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +(the bad commit). + +This will verify that the commit indeed introduces the regression. I +suggest doing this just to be sure that you've found the bad commit. + +Regarding this commit, I notice two things: + +1. We will now loop over all vring descriptors because we calculate the + total in/out length instead of returning early as soon as we see + there is enough space. Maybe this makes a difference, although I'm a + little surprised you see such a huge regression. + +2. The comparision semantics have changed from: + + (in_total += vring_desc_len(desc_pa, i)) >= in_bytes + + to: + + (in_bytes && in_bytes < in_total) + + Notice that virtqueue_avail_bytes() now returns 0 when in_bytes == + in_total. Previously, it would return 1. Perhaps we are starving or + delaying I/O due to this comparison change. You can easily change + '<' to '<=' to see if it fixes the issue. + +Stefan + + +Hi Stefan + +I finally could revert that commit in the latest snapshot; problem was I needed to revert one later, that modified hw/virtio-serial-bus.c accordingly; after that reversion, the regression in network performance went completely away; this confirms my previous identification of the commit that caused it. + +Additionally, I tested your last suggestion, to change '<' to '<=', and that didn't help; the problem was still there. + +By the way, the performance gain I observed ,of about 25~30 % when using a tun/tap, was in fact just apparent, because it was result of a greater use of cpu, so it was achieved only when the host was idle; when I stress the host, with a lot of concurrent guests generating traffic, there is no gain at all. + +Just for confirmation, this is the performance I get with latest snapshot (8b4a3df8081f3e6f1061ed5cbb303ad623ade66b) running wget in the guest: + +$ wget -O /dev/null http://172.18.1.1/bpd.iso +--2012-10-16 09:10:18-- http://172.18.1.1/bpd.iso +Connecting to 172.18.1.1:80... connected. +HTTP request sent, awaiting response... 200 OK +Length: 358979584 (342M) [application/x-iso9660-image] +Saving to: `/dev/null' +100%[======================================================>] 358.979.584 29,7M/s in 11s +2012-10-16 09:10:29 (30,3 MB/s) - `/dev/null' saved [358979584/358979584] + +The same wget, using the same snapshot, but with that commit reverted is: + +$ wget -O /dev/null http://172.18.1.1/bpd.iso +--2012-10-16 09:15:12-- http://172.18.1.1/bpd.iso +Connecting to 172.18.1.1:80... connected. +HTTP request sent, awaiting response... 200 OK +Length: 358979584 (342M) [application/x-iso9660-image] +Saving to: `/dev/null' +100%[======================================================>] 358.979.584 180M/s in 1,9s +2012-10-16 09:15:14 (180 MB/s) - `/dev/null' saved [358979584/358979584] + +So, as I can see, there is no doubt: that commit is the culprit; as it was intended to be related just to the quality of the source code (at least as I can see), but implied in such a cost in performance, I think it would be better to revert it. + +Thank you very much, again. +Edivaldo + +On Tue, Oct 16, 2012 at 2:23 PM, Edivaldo de Araujo Pereira +<email address hidden> wrote: +> Hi Stefan +> +> I finally could revert that commit in the latest snapshot; problem was I +> needed to revert one later, that modified hw/virtio-serial-bus.c +> accordingly; after that reversion, the regression in network performance +> went completely away; this confirms my previous identification of the +> commit that caused it. +> +> Additionally, I tested your last suggestion, to change '<' to '<=', and +> that didn't help; the problem was still there. +> +> By the way, the performance gain I observed ,of about 25~30 % when using +> a tun/tap, was in fact just apparent, because it was result of a greater +> use of cpu, so it was achieved only when the host was idle; when I +> stress the host, with a lot of concurrent guests generating traffic, +> there is no gain at all. +> +> Just for confirmation, this is the performance I get with latest +> snapshot (8b4a3df8081f3e6f1061ed5cbb303ad623ade66b) running wget in the +> guest: +> +> $ wget -O /dev/null http://172.18.1.1/bpd.iso +> --2012-10-16 09:10:18-- http://172.18.1.1/bpd.iso +> Connecting to 172.18.1.1:80... connected. +> HTTP request sent, awaiting response... 200 OK +> Length: 358979584 (342M) [application/x-iso9660-image] +> Saving to: `/dev/null' +> 100%[======================================================>] 358.979.584 29,7M/s in 11s +> 2012-10-16 09:10:29 (30,3 MB/s) - `/dev/null' saved [358979584/358979584] +> +> The same wget, using the same snapshot, but with that commit reverted +> is: +> +> $ wget -O /dev/null http://172.18.1.1/bpd.iso +> --2012-10-16 09:15:12-- http://172.18.1.1/bpd.iso +> Connecting to 172.18.1.1:80... connected. +> HTTP request sent, awaiting response... 200 OK +> Length: 358979584 (342M) [application/x-iso9660-image] +> Saving to: `/dev/null' +> 100%[======================================================>] 358.979.584 180M/s in 1,9s +> 2012-10-16 09:15:14 (180 MB/s) - `/dev/null' saved [358979584/358979584] +> +> So, as I can see, there is no doubt: that commit is the culprit; as it +> was intended to be related just to the quality of the source code (at +> least as I can see), but implied in such a cost in performance, I think +> it would be better to revert it. + +Hi Amit, +Edivaldo has identified the following commit responsible for a network +performance regression he sees: + +commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +Author: Amit Shah <email address hidden> +Date: Tue Sep 25 00:05:15 2012 +0530 + + virtio: Introduce virtqueue_get_avail_bytes() + +I guess this is because we now iterate the entire descriptor chain to +check available space instead of returning early. + +Do you want to propose a patch to fix it? + +Stefan + + +Dear Amit, + +On a suggestion of Stefan, I've already tested the modification in you patch, and it didn't work; but for confirmation I tested it once again, on the latest snapshot; same result, that is, it didn't work; the problem is still there. + +I didn't take enough time to uderstand the code, so unfortunately I fear there is not much I could do to solve the problem, apart from trying your suggestions. But I'll try to spend a little more time on it, until we find a solution. + +Thank you very much. + +Edivaldo + +--- Em seg, 22/10/12, Amit Shah <email address hidden> escreveu: + +> De: Amit Shah <email address hidden> +> Assunto: Re: [Qemu-devel] [Bug 1066055] Re: Network performance regression with vde_switch +> Para: "Stefan Hajnoczi" <email address hidden> +> Cc: "Bug 1066055" <email address hidden>, <email address hidden>, <email address hidden> +> Data: Segunda-feira, 22 de Outubro de 2012, 4:18 +> On (Tue) 16 Oct 2012 [09:48:09], +> Stefan Hajnoczi wrote: +> > On Mon, Oct 15, 2012 at 09:46:06PM -0000, Edivaldo de +> Araujo Pereira wrote: +> > > Hi Stefan, +> > > +> > > Thank you, very much for taking the time to help +> me, and excuse me for +> > > not seeing your answer early... +> > > +> > > I've run the procedure you pointed me out, and the +> result is: +> > > +> > > 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f is the +> first bad commit +> > > commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +> > > Author: Amit Shah <email address hidden> +> > > Date: Tue Sep 25 00:05:15 2012 +> +0530 +> > > +> > > virtio: Introduce +> virtqueue_get_avail_bytes() +> > > +> > > The current +> virtqueue_avail_bytes() is oddly named, and checks if a +> > > particular number of bytes +> are available in a vq. A better API is to +> > > fetch the number of bytes +> available in the vq, and let the caller do +> > > what's interesting with +> the numbers. +> > > +> > > Introduce +> virtqueue_get_avail_bytes(), which returns the number of +> bytes +> > > for buffers marked for +> both, in as well as out. virtqueue_avail_bytes() +> > > is made a wrapper over +> this new function. +> > > +> > > Signed-off-by: Amit Shah +> <email address hidden> +> > > Signed-off-by: Michael S. +> Tsirkin <email address hidden> +> > > +> > > :040000 040000 +> 1a58b06a228651cf844621d9ee2f49b525e36c93 +> > > e09ea66ce7f6874921670b6aeab5bea921a5227d M +> hw +> > > +> > > I tried to revert that patch in the latest +> version, but it obviously +> > > didnt work; I'm trying to figure out the problem, +> but I don't know very +> > > well the souce code, so I think it's going to take +> some time. For now, +> > > it's all I could do. +> > +> > After git-bisect(1) completes it is good to +> sanity-check the result by +> > manually testing +> 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f^ (the commit +> > just before the bad commit) and +> 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +> > (the bad commit). +> > +> > This will verify that the commit indeed introduces the +> regression. I +> > suggest doing this just to be sure that you've found +> the bad commit. +> > +> > Regarding this commit, I notice two things: +> > +> > 1. We will now loop over all vring descriptors because +> we calculate the +> > total in/out length instead of returning +> early as soon as we see +> > there is enough space. Maybe this +> makes a difference, although I'm a +> > little surprised you see such a huge +> regression. +> > +> > 2. The comparision semantics have changed from: +> > +> > (in_total += +> vring_desc_len(desc_pa, i)) >= in_bytes +> > +> > to: +> > +> > (in_bytes && in_bytes < +> in_total) +> > +> > Notice that virtqueue_avail_bytes() now +> returns 0 when in_bytes == +> > in_total. Previously, it would +> return 1. Perhaps we are starving or +> > delaying I/O due to this comparison +> change. You can easily change +> > '<' to '<=' to see if it fixes the +> issue. +> +> Hi Edivaldo, +> +> Can you try the following patch, that will confirm if it's +> the +> descriptor walk or the botched compare that's causing the +> regression. +> +> Thanks, +> +> diff --git a/hw/virtio.c b/hw/virtio.c +> index 6821092..bb08ed8 100644 +> --- a/hw/virtio.c +> +++ b/hw/virtio.c +> @@ -406,8 +406,8 @@ int virtqueue_avail_bytes(VirtQueue *vq, +> unsigned int in_bytes, +> unsigned int in_total, out_total; +> +> virtqueue_get_avail_bytes(vq, +> &in_total, &out_total); +> - if ((in_bytes && in_bytes < +> in_total) +> - || (out_bytes && +> out_bytes < out_total)) { +> + if ((in_bytes && in_bytes <= +> in_total) +> + || (out_bytes && +> out_bytes <= out_total)) { +> return 1; +> } +> return 0; +> +> +> Amit +> + + +On Mon, Oct 22, 2012 at 06:50:00AM -0700, Edivaldo de Araujo Pereira wrote: +> I didn't take enough time to uderstand the code, so unfortunately I fear there is not much I could do to solve the problem, apart from trying your suggestions. But I'll try to spend a little more time on it, until we find a solution. + +I've thought a little about how to approach this. Amit, here's a brain +dump: + +The simplest solution is to make virtqueue_avail_bytes() use the old +behavior of stopping early. + +However, I wonder if we can actually *improve* performance of existing +code by changing virtio-net.c:virtio_net_receive(). The intuition is +that calling virtio_net_has_buffers() (internally calls +virtqueue_avail_bytes()) followed by virtqueue_pop() is suboptimal +because we're repeatedly traversing the descriptor chain. + +We can get rid of this repetition. A side-effect of this is that we no +longer need to call virtqueue_avail_bytes() from virtio-net.c. Here's +how: + +The common case in virtio_net_receive() is that we have buffers and they +are large enough for the received packet. So to optimize for this case: + +1. Take the VirtQueueElement off the vring but don't increment + last_avail_idx yet. (This is essentially a "peek" operation.) + +2. If there is an error or we drop the packet because the + VirtQueueElement is too small, just bail out and we'll grab the same + VirtQueueElement again next time. + +3. When we've committed filling in this VirtQueueElement, increment + last_avail_idx. This is the point of no return. + +Essentially we're splitting pop() into peek() and consume(). Peek() +grabs the VirtQueueElement but does not increment last_avail_idx. +Consume() simply increments last_avail_idx and maybe the EVENT_IDX +optimization stuff. + +Whether this will improve performance, I'm not sure. Perhaps +virtio_net_has_buffers() pulls most descriptors into the CPU's cache and +following up with virtqueue_pop() is very cheap already. But the idea +here is to avoid the virtio_net_has_buffers() because we'll find out +soon enough when we try to pop :). + +Another approach would be to drop virtio_net_has_buffers() but continue +to use virtqueue_pop(). We'd keep the same VirtQueueElem stashed in +VirtIONet across virtio_net_receive() calls in the case where we drop +the packet. I don't like this approach very much though because it gets +tricky when the guest modifies the vring memory, resets the virtio +device, etc across calls. + +Stefan + + +On Thu, Nov 1, 2012 at 5:07 PM, Michael S. Tsirkin <email address hidden> wrote: +> Commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f introduced +> a regression in virtio-net performance because it looks +> into the ring aggressively while we really only care +> about a single packet worth of buffers. +> To fix, add parameters limiting lookahead, and +> use in virtqueue_avail_bytes. +> +> Signed-off-by: Michael S. Tsirkin <email address hidden> +> Reported-by: Edivaldo de Araujo Pereira <email address hidden> + +Nice, much simpler than the ideas I had. + +Reviewed-by: Stefan Hajnoczi <email address hidden> + + +On Fri, Nov 2, 2012 at 3:48 PM, Michael S. Tsirkin <email address hidden> wrote: +> On Fri, Nov 02, 2012 at 11:18:18AM +0100, Stefan Hajnoczi wrote: +>> On Thu, Nov 1, 2012 at 5:07 PM, Michael S. Tsirkin <email address hidden> wrote: +>> > Commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f introduced +>> > a regression in virtio-net performance because it looks +>> > into the ring aggressively while we really only care +>> > about a single packet worth of buffers. +>> > To fix, add parameters limiting lookahead, and +>> > use in virtqueue_avail_bytes. +>> > +>> > Signed-off-by: Michael S. Tsirkin <email address hidden> +>> > Reported-by: Edivaldo de Araujo Pereira <email address hidden> +>> +>> Nice, much simpler than the ideas I had. +>> +>> Reviewed-by: Stefan Hajnoczi <email address hidden> +> +> Anthony could you apply this out of band please so this stops +> biting people? + +Especially for the 1.3 release so that we don't have a virtio +performance regression. + +Stefan + + +Dear friends, + +Please excuse-me for not reporting earlier... I confirm that the patch by Michael really fixes the problem I've reported. The regression has gone away when I used it, so I think it is good to be applied. + +Thanks, + +Edivaldo de Araújo Pereira + + +--- Em ter, 27/11/12, Michael S. Tsirkin <email address hidden> escreveu: + +> De: Michael S. Tsirkin <email address hidden> +> Assunto: Re: [PATCH] virtio: limit avail bytes lookahead +> Para: "Amit Shah" <email address hidden> +> Cc: "Stefan Hajnoczi" <email address hidden>, "Edivaldo de Araujo Pereira" <email address hidden>, <email address hidden>, "Anthony Liguori" <email address hidden>, "Bug 1066055" <email address hidden> +> Data: Terça-feira, 27 de Novembro de 2012, 8:25 +> On Thu, Nov 01, 2012 at 06:07:21PM +> +0200, Michael S. Tsirkin wrote: +> > Commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f +> introduced +> > a regression in virtio-net performance because it +> looks +> > into the ring aggressively while we really only care +> > about a single packet worth of buffers. +> > To fix, add parameters limiting lookahead, and +> > use in virtqueue_avail_bytes. +> > +> > Signed-off-by: Michael S. Tsirkin <email address hidden> +> > Reported-by: Edivaldo de Araujo Pereira <email address hidden> +> +> Ping. +> Anthony - going to apply this? +> +> +> > --- +> > +> > Edivaldo could you please confirm this fixes +> regression? +> > +> > diff --git a/hw/virtio-serial-bus.c +> b/hw/virtio-serial-bus.c +> > index d20bd8b..a761cdc 100644 +> > --- a/hw/virtio-serial-bus.c +> > +++ b/hw/virtio-serial-bus.c +> > @@ -297,7 +297,7 @@ size_t +> virtio_serial_guest_ready(VirtIOSerialPort *port) +> > if (use_multiport(port->vser) +> && !port->guest_connected) { +> > return 0; +> > } +> > - virtqueue_get_avail_bytes(vq, +> &bytes, NULL); +> > + virtqueue_get_avail_bytes(vq, +> &bytes, NULL, UINT_MAX, 0); +> > return bytes; +> > } +> > +> > diff --git a/hw/virtio.c b/hw/virtio.c +> > index ec8b7d8..f40a8c5 100644 +> > --- a/hw/virtio.c +> > +++ b/hw/virtio.c +> > @@ -336,7 +336,8 @@ static unsigned +> virtqueue_next_desc(hwaddr desc_pa, +> > } +> > +> > void virtqueue_get_avail_bytes(VirtQueue *vq, +> unsigned int *in_bytes, +> > - +> +> unsigned int *out_bytes) +> > + +> +> unsigned int *out_bytes, +> > + +> +> unsigned max_in_bytes, unsigned +> max_out_bytes) +> > { +> > unsigned int idx; +> > unsigned int total_bufs, in_total, +> out_total; +> > @@ -385,6 +386,9 @@ void +> virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int +> *in_bytes, +> > } else +> { +> > +> out_total += vring_desc_len(desc_pa, i); +> > } +> > + if (in_total +> >= max_in_bytes && out_total >= max_out_bytes) +> { +> > + +> goto done; +> > + } +> > } while ((i = +> virtqueue_next_desc(desc_pa, i, max)) != max); +> > +> > if (!indirect) +> > @@ -392,6 +396,7 @@ void +> virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int +> *in_bytes, +> > else +> > +> total_bufs++; +> > } +> > +done: +> > if (in_bytes) { +> > *in_bytes = +> in_total; +> > } +> > @@ -405,12 +410,8 @@ int +> virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes, +> > { +> > unsigned int in_total, out_total; +> > +> > - virtqueue_get_avail_bytes(vq, +> &in_total, &out_total); +> > - if ((in_bytes && in_bytes < +> in_total) +> > - || (out_bytes && +> out_bytes < out_total)) { +> > - return 1; +> > - } +> > - return 0; +> > + virtqueue_get_avail_bytes(vq, +> &in_total, &out_total, in_bytes, out_bytes); +> > + return in_bytes <= in_total +> && out_bytes <= out_total; +> > } +> > +> > void virtqueue_map_sg(struct iovec *sg, hwaddr +> *addr, +> > diff --git a/hw/virtio.h b/hw/virtio.h +> > index ac482be..1278328 100644 +> > --- a/hw/virtio.h +> > +++ b/hw/virtio.h +> > @@ -150,7 +150,8 @@ int virtqueue_pop(VirtQueue *vq, +> VirtQueueElement *elem); +> > int virtqueue_avail_bytes(VirtQueue *vq, unsigned +> int in_bytes, +> > +> unsigned int +> out_bytes); +> > void virtqueue_get_avail_bytes(VirtQueue *vq, +> unsigned int *in_bytes, +> > - +> +> unsigned int *out_bytes); +> > + +> +> unsigned int *out_bytes, +> > + +> +> unsigned max_in_bytes, unsigned +> max_out_bytes); +> > +> > void virtio_notify(VirtIODevice *vdev, VirtQueue +> *vq); +> > +> + + +"Michael S. Tsirkin" <email address hidden> writes: + +> On Thu, Nov 01, 2012 at 06:07:21PM +0200, Michael S. Tsirkin wrote: +>> Commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f introduced +>> a regression in virtio-net performance because it looks +>> into the ring aggressively while we really only care +>> about a single packet worth of buffers. +>> To fix, add parameters limiting lookahead, and +>> use in virtqueue_avail_bytes. +>> +>> Signed-off-by: Michael S. Tsirkin <email address hidden> +>> Reported-by: Edivaldo de Araujo Pereira <email address hidden> +> +> Ping. +> Anthony - going to apply this? + +Yes, I've got it queued now. In the future, please top post patches. + +Regards, + +Anthony Liguori + +> +> +>> --- +>> +>> Edivaldo could you please confirm this fixes regression? +>> +>> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c +>> index d20bd8b..a761cdc 100644 +>> --- a/hw/virtio-serial-bus.c +>> +++ b/hw/virtio-serial-bus.c +>> @@ -297,7 +297,7 @@ size_t virtio_serial_guest_ready(VirtIOSerialPort *port) +>> if (use_multiport(port->vser) && !port->guest_connected) { +>> return 0; +>> } +>> - virtqueue_get_avail_bytes(vq, &bytes, NULL); +>> + virtqueue_get_avail_bytes(vq, &bytes, NULL, UINT_MAX, 0); +>> return bytes; +>> } +>> +>> diff --git a/hw/virtio.c b/hw/virtio.c +>> index ec8b7d8..f40a8c5 100644 +>> --- a/hw/virtio.c +>> +++ b/hw/virtio.c +>> @@ -336,7 +336,8 @@ static unsigned virtqueue_next_desc(hwaddr desc_pa, +>> } +>> +>> void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes, +>> - unsigned int *out_bytes) +>> + unsigned int *out_bytes, +>> + unsigned max_in_bytes, unsigned max_out_bytes) +>> { +>> unsigned int idx; +>> unsigned int total_bufs, in_total, out_total; +>> @@ -385,6 +386,9 @@ void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes, +>> } else { +>> out_total += vring_desc_len(desc_pa, i); +>> } +>> + if (in_total >= max_in_bytes && out_total >= max_out_bytes) { +>> + goto done; +>> + } +>> } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max); +>> +>> if (!indirect) +>> @@ -392,6 +396,7 @@ void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes, +>> else +>> total_bufs++; +>> } +>> +done: +>> if (in_bytes) { +>> *in_bytes = in_total; +>> } +>> @@ -405,12 +410,8 @@ int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes, +>> { +>> unsigned int in_total, out_total; +>> +>> - virtqueue_get_avail_bytes(vq, &in_total, &out_total); +>> - if ((in_bytes && in_bytes < in_total) +>> - || (out_bytes && out_bytes < out_total)) { +>> - return 1; +>> - } +>> - return 0; +>> + virtqueue_get_avail_bytes(vq, &in_total, &out_total, in_bytes, out_bytes); +>> + return in_bytes <= in_total && out_bytes <= out_total; +>> } +>> +>> void virtqueue_map_sg(struct iovec *sg, hwaddr *addr, +>> diff --git a/hw/virtio.h b/hw/virtio.h +>> index ac482be..1278328 100644 +>> --- a/hw/virtio.h +>> +++ b/hw/virtio.h +>> @@ -150,7 +150,8 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem); +>> int virtqueue_avail_bytes(VirtQueue *vq, unsigned int in_bytes, +>> unsigned int out_bytes); +>> void virtqueue_get_avail_bytes(VirtQueue *vq, unsigned int *in_bytes, +>> - unsigned int *out_bytes); +>> + unsigned int *out_bytes, +>> + unsigned max_in_bytes, unsigned max_out_bytes); +>> +>> void virtio_notify(VirtIODevice *vdev, VirtQueue *vq); +>> + + +"Michael S. Tsirkin" <email address hidden> writes: + +> On Thu, Nov 29, 2012 at 06:34:46PM +0530, Amit Shah wrote: +>> On (Wed) 28 Nov 2012 [23:53:08], Michael S. Tsirkin wrote: +>> > On Tue, Nov 27, 2012 at 06:25:04PM +0200, Michael S. Tsirkin wrote: +>> > > On Thu, Nov 01, 2012 at 06:07:21PM +0200, Michael S. Tsirkin wrote: +>> > > > Commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f introduced +>> > > > a regression in virtio-net performance because it looks +>> > > > into the ring aggressively while we really only care +>> > > > about a single packet worth of buffers. +>> > > > To fix, add parameters limiting lookahead, and +>> > > > use in virtqueue_avail_bytes. +>> > > > +>> > > > Signed-off-by: Michael S. Tsirkin <email address hidden> +>> > > > Reported-by: Edivaldo de Araujo Pereira <email address hidden> +>> > > +>> > > Ping. +>> > > Anthony - going to apply this? +>> > +>> > virtio rng was added since so naturally build broke. +>> > Here's a patch on top to fix it up. I never used virtio rng before so +>> > could not test at this hour, but it does fix the build. +>> > +>> > I'll take a look at how to test it tomorrow but any +>> > info would be appreciated. +>> > Amit could you pls review? +>> +>> Looks fine, I assume you will send a v2 of the patch to Anthony? +>> +>> Amit +> +> +> Anthony volunteered to test this so there will only be v2 if he sees +> problems. + +I need a Signed-off-by so why don't you just go ahead and send a v2 and +I'll test that. + +Regards, + +Anthony Liguori + + +The fix had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e1f7b4812eab992de46c98b +... so closing this bug now. + diff --git a/results/classifier/108/other/1066909 b/results/classifier/108/other/1066909 new file mode 100644 index 00000000..76e891f1 --- /dev/null +++ b/results/classifier/108/other/1066909 @@ -0,0 +1,33 @@ +performance: 0.609 +semantic: 0.560 +device: 0.537 +other: 0.510 +network: 0.499 +vnc: 0.456 +graphic: 0.438 +files: 0.415 +socket: 0.376 +boot: 0.345 +PID: 0.335 +permissions: 0.308 +KVM: 0.115 +debug: 0.039 + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. + +Here is a minimal test case showing the problem. + + +I accidentally posted the patch, which is here, on the wrong bug report (1068900 instead of here). Apologies. For reference here is the patch; it was committed and fixes this issue: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + +Issue # 1068900, where I mistakenly posted the patch, is unrelated and not fixed; it should be reopened and this issue (1066909) should be marked fixed. + + diff --git a/results/classifier/108/other/1067119 b/results/classifier/108/other/1067119 new file mode 100644 index 00000000..6b3c5766 --- /dev/null +++ b/results/classifier/108/other/1067119 @@ -0,0 +1,28 @@ +socket: 0.797 +graphic: 0.795 +device: 0.726 +network: 0.677 +semantic: 0.441 +performance: 0.428 +vnc: 0.409 +PID: 0.251 +boot: 0.250 +other: 0.157 +files: 0.101 +permissions: 0.100 +debug: 0.083 +KVM: 0.018 + +e1000 missing statistics + +The E1000 emulation is missing several counters that are used by other software. + +The following would be useful: + Good bytes receive counter GORCH/GORCL + Good bytes transmit counter GOTCH/GOTCL +Broadcast packets sent/received +Multicast packets sent/received. + +Looks like these counters have been implemented here: +http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=3b27430177498a1728b6 + diff --git a/results/classifier/108/other/1067517 b/results/classifier/108/other/1067517 new file mode 100644 index 00000000..e9b51935 --- /dev/null +++ b/results/classifier/108/other/1067517 @@ -0,0 +1,96 @@ +permissions: 0.817 +socket: 0.754 +graphic: 0.751 +debug: 0.715 +performance: 0.714 +other: 0.702 +device: 0.691 +PID: 0.690 +KVM: 0.681 +semantic: 0.680 +network: 0.680 +vnc: 0.649 +files: 0.582 +boot: 0.582 + +qemu dosn't save snapshots with the 'commit' command + +Usually there is the 'commit' command in qemu which is described as followed: "commit changes to the disk images (if -snapshot is used) or backing files" +From the context i though if i start a guest with the "-snapshot" option, the commit command would save all the changes back to the file. I've tried it out but i didn't get it to work. I tried a few things like first use savevm or stop and than commit all, but actually nothing works. +Interestingly, when using qcow2 files qemu doesn't show's any error at all. The changes in the guest just won't get saved. But if i'm using lvm2 partitions i would get I/O errors after execute 'commit all'. That's probably because lvm2 doesn't support this feature.?!? However i made a attachment which shows the error's in the guest (dmesg). + +Right now i started the guest with following command: +/usr/bin/qemu-system-x86_64 -name g64 -runas kvm -m 4096 -smp 2 \ +-monitor unix:/var/run/kvm/g64.sock,server,nowait -pidfile /var/run/kvm/g64.pid -daemonize -snapshot \ +-device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent \ +-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ +-drive file=/media/btrfs/g64.qcow2,if=virtio,cache=none,aio=threads \ +-netdev type=tap,id=g64_3,vhost=on,ifname=qtap3,script=no,downscript=no \ +-device virtio-net-pci,netdev=g64_3,mac=DE:AD:BE:EF:CB:22 \ +-spice port=5803,addr=192.168.2.60,password=secret -k de -cpu host \ +-usb -usbdevice tablet -vga qxl + +The system is stable gentoo: +Portage 2.1.11.9 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r2, 3.4.9-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-3.4.9-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1 +Timestamp of tree: Tue, 16 Oct 2012 03:45:01 +0000 +app-shells/bash: 4.2_p37 +dev-lang/python: 2.7.3-r2, 3.2.3 +dev-util/cmake: 2.8.8-r3 +dev-util/pkgconfig: 0.27.1 +sys-apps/baselayout: 2.1-r1 +sys-apps/openrc: 0.9.8.4 +sys-apps/sandbox: 2.5 +sys-devel/autoconf: 2.68 +sys-devel/automake: 1.11.6 +sys-devel/binutils: 2.22-r1 +sys-devel/gcc: 4.5.4 +sys-devel/gcc-config: 1.7.3 +sys-devel/libtool: 2.4-r1 +sys-devel/make: 3.82-r3 +sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) +sys-libs/glibc: 2.15-r2 +Repositories: gentoo x-local x11 sunrise virtualization +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe -march=native -fopenmp" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe -march=native -fopenmp" +DISTDIR="/usr/portage/distfiles" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS=" http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ http://gentoo.mirror.web4u.cz/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.ynet.sk/pub" +LANG="de_DE.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp" +LINGUAS="en" +MAKEOPTS="-j12" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +PORTDIR="/usr/portage" +PORTDIR_OVERLAY="/home/clown/public/overlays/local /home/clown/public/overlays/layman/x11 /home/clown/public/overlays/layman/sunrise /home/clown/public/overlays/layman/virtualization" +SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" +USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-1.1.1-r1 was built with the following: +USE="aio caps curl ncurses sasl spice vde vhost-net -alsa -bluetooth -brltty -debug -doc -fdt -opengl -pulseaudio -python -rbd -sdl -smartcard -static -tci -tls -usbredir -virtfs -xattr -xen -xfs" QEMU_SOFTMMU_TARGETS="i386 x86_64 (-alpha) (-arm) -cris (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 x86_64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel (-mips) -mipsel (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32" + + + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1068900 b/results/classifier/108/other/1068900 new file mode 100644 index 00000000..fd95a5ae --- /dev/null +++ b/results/classifier/108/other/1068900 @@ -0,0 +1,32 @@ +other: 0.744 +device: 0.738 +semantic: 0.612 +graphic: 0.588 +network: 0.588 +socket: 0.479 +vnc: 0.478 +files: 0.465 +performance: 0.442 +permissions: 0.417 +boot: 0.368 +PID: 0.319 +debug: 0.296 +KVM: 0.152 + +Thread cancellation broken in app-level emulation + +Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. + +The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host). + +Patch for the issue is available here: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + + +Arg, somehow I added the above comment on the wrong bug. Thus bug is not fixed. The other bug report I recently filed was fixed. + +The URL from comment #1 is unfortunately not valid anymore. If this issue is still pending, could you please post your patch again to the qemu-devel mailing list to get it discussed and included? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + |