diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/246 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2461 | 71 | ||||
| -rw-r--r-- | results/classifier/108/other/2462 | 54 | ||||
| -rw-r--r-- | results/classifier/108/other/2463 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/2464 | 26 | ||||
| -rw-r--r-- | results/classifier/108/other/2465 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2466 | 39 | ||||
| -rw-r--r-- | results/classifier/108/other/2469 | 16 |
8 files changed, 262 insertions, 0 deletions
diff --git a/results/classifier/108/other/246 b/results/classifier/108/other/246 new file mode 100644 index 000000000..7ca83aeb5 --- /dev/null +++ b/results/classifier/108/other/246 @@ -0,0 +1,16 @@ +performance: 0.720 +graphic: 0.683 +device: 0.561 +network: 0.367 +debug: 0.311 +KVM: 0.216 +semantic: 0.205 +socket: 0.192 +vnc: 0.180 +permissions: 0.146 +other: 0.137 +files: 0.081 +PID: 0.039 +boot: 0.019 + +Build fails with 64 bits time_t diff --git a/results/classifier/108/other/2461 b/results/classifier/108/other/2461 new file mode 100644 index 000000000..d07639dc7 --- /dev/null +++ b/results/classifier/108/other/2461 @@ -0,0 +1,71 @@ +debug: 0.902 +network: 0.849 +other: 0.846 +semantic: 0.841 +graphic: 0.837 +permissions: 0.816 +performance: 0.801 +device: 0.799 +KVM: 0.788 +PID: 0.787 +boot: 0.784 +vnc: 0.776 +socket: 0.750 +files: 0.742 + +Qemu with -accel whpx doesn't set WRMSR permissions, which blocks nested virtualization +Description of problem: +This bug blocks https://gitlab.com/qemu-project/qemu/-/issues/628 + +Qemu doesn't set the host's Hyper-V permissions for WRMSR command to allow using SVM or VMX. Unset permissions lead to `unchecked MSR access error: WRMSR to 0xc0000080` inside Linux VM when trying to launch nested VM on real AMD cpu. Intel users do not see guest VMX feature at all. Please see **Additional info** section to understand how Hyper-V permissions for nested virtualization work in Windows. +Steps to reproduce: +1. Turn on VT-x (for Intel) or AMD-V virtualization in your real hardware BIOS/EFI. This was tested only on AMD cpu and Qemu 9, Intel \*may\* behave differently. + 2. Install any distro in qemu disk c:\\linux_disk.qcow2 with MSR enabled in kernel, for example, Ubuntu 22.04 LTS. + 3. Run qemu using `qemu-system-x86_64.exe -m 2048 -machine q35 -accel whpx -cpu Opteron_G5,check,+svm -hda c:\linux_disk.qcow2` + + To check if your distro has MSR mod enabled, run `grep -i msr /boot/config-$(uname -r)` and it should return `CONFIG_X86_MSR=m` or `CONFIG_X86_MSR=y`. If not, recompile and reinstall your kernel. + 4. Run `sudo modprobe msr` and then `sudo rdmsr 0xc0000080 #EFER`. You should see `d01` on modern AMD models. \[Untested\] For intel, run `sudo modprobe msr`, then `sudo rdmsr 0x3A`. You should see `5` or `0x5` or `0x100005`. d01 for AMD and 5 for Intel in output are necessary to enable nested VM. If RDMSR returns non-zero value, it means that qemu developers implemented this part of functionality and your Hyper-V on Windows is not broken. + 5. Run `cat /proc/cpuinfo | grep -c svm` on AMD cpu, which should output a positive digit. + 6. Run `sudo dmesg | grep kvm` and note: + + `[1.924036] kvm_amd: Nested Virtualization enabled` + + `[1.924038] kvm_amd: Nested Paging disabled`\ + `[1.924040] kvm_amd: PMU virtualization is disabled` + 7. This, in theory, is sufficient for KVM-acclelerated qemu to start a nested VM. + 8. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error + 9. Run `sudo qemu-system-x86_64 -accel kvm`. A black window with "Guest has not initialized the display (yet)." appears. +10. Run `sudo dmesg` and note qemu crash starting with `unchecked MSR access error: WRMSR` + + \* Steps 1-4 are only required for diagnostics, and KVM works (in native Windows Hyper-V manager) without the necessarity to enter these commands in usual usage scenarios. If you run <span dir="">`cat /proc/cpuinfo | grep -c vmx` on Intel cpu</span> on Step 5, you may get zero. See Step 5 of Additional Info to understand why. + + \ + Microsoft released useful info about how to look into Hyper-V MSR access problems:\ + WRMSR research in Hyper-V - https://msrc.microsoft.com/blog/2018/12/first-steps-in-hyper-v-research/ +Additional information: +By default, Hyper-V manager in Windows does not allow nested virtualization.\ +To see what happens, do the following: + + 1. Open Hyper-V manager built in the host Windows and create default Ubuntu 22.04 LTS suggested. Upon installation, shut down the VM. Note the name of the VM ("Ubuntu 22.04 LTS" by default). + 2. Open Powershell console in the host and run `Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $false` + 3. Launch guest Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. No output. + 4. Run `sudo rdmsr 0xc0000080 #EFER` that outputs d01, which means that Hyper-V manager allows this **ring 0 level** operation. + 5. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `0`. + 6. Shut the VM down. + 7. Now, Open Powershell console and `run Set-VMProcessor -VMName "Ubuntu 22.04 LTS" -ExposeVirtualizationExtensions $true` + 8. Launch Ubuntu 22.04 LTS, open its terminal and run `sudo dmesg | grep kvm`. Output: + + `[2.369144] kvm: Nested Virtualization enabled` + + `[2.369146] SVM: kvm: Nested Paging enabled` + + `[2.369148] SVM: kvm: Hyper-V enlightened NPT TLB flush enabled` + + `[2.369149] SVM: kvm: Hyper-V Direct TLB flush enabled` + + `[2.369153] SVM: Virtual VMLOAD VMSAVE supported` + 9. Run `cat /proc/cpuinfo | grep -c svm` for AMD or `cat /proc/cpuinfo | grep -c vmx` for Intel. Note that output is `1` or other positive digit, depending on the number of cpus you've assigned to the VM. +10. Run `xhost si:localuser:root` to prevent `gtk initialization failed` error +11. Run `sudo qemu-system-x86_64 -accel kvm` and it successfully boots into qemu BIOS. +12. Running `sudo qemu-system-x86_64 -accel kvm` calls WRMSR in background, so if you see\ + booted qemu BIOS in KVM, wrmsr was successfully called. diff --git a/results/classifier/108/other/2462 b/results/classifier/108/other/2462 new file mode 100644 index 000000000..083abf0a6 --- /dev/null +++ b/results/classifier/108/other/2462 @@ -0,0 +1,54 @@ +other: 0.928 +performance: 0.919 +PID: 0.832 +graphic: 0.811 +permissions: 0.753 +debug: 0.737 +network: 0.716 +device: 0.712 +semantic: 0.672 +files: 0.653 +socket: 0.584 +vnc: 0.569 +boot: 0.497 +KVM: 0.421 + +QEMU SIFIVE reading from stdin hangs +Description of problem: +I have a simple test program (C and ASM) that reads from stdin. When i was using the qemu provided by Ubuntu, QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5), my test was working, and was able to read bytes from stdin. + +Using the latest Qemu from git, breaks my test. I can still print, but now reading hangs, like its always waiting for input but never getting it. + +My guess is that this commit breaks my code: +https://github.com/qemu/qemu/commit/6ee7ba1b8a10bd8eb1d3b918eaaf9f832a51adb4 + +Before the above commit, `qemu_chr_fe_set_handlers` was being called, and that is what allowed the default behavior of reading from stdin is on by default? + +from sifive_uart.c +``` + qemu_chr_fe_set_handlers(&s->chr, sifive_uart_can_rx, sifive_uart_rx, + sifive_uart_event, sifive_uart_be_change, s, + NULL, true); +``` +Steps to reproduce: +1. compile simple C program that calls `read` reading a single byte from stdin +2. do not initialize UART options +3. run in QEMU, send input, hangs. +Additional information: +Other examples online, like riscv-probe, use a uart init function like below: +``` +static void sifive_uart_init() +{ + uart = (int *)(void *)getauxval(SIFIVE_UART0_CTRL_ADDR); + uint32_t uart_freq = getauxval(UART0_CLOCK_FREQ); + uint32_t baud_rate = getauxval(UART0_BAUD_RATE); + uint32_t divisor = uart_freq / baud_rate - 1; + uart[UART_REG_DIV] = divisor; + uart[UART_REG_TXCTRL] = UART_TXEN; + uart[UART_REG_RXCTRL] = UART_RXEN; + uart[UART_REG_IE] = 0; +} +``` + +However, when I was using QEMU 8.0.4, i did not have to write a function like above to init UART, because stdin and stdout were working out of the box. +Below is my C and ASM: diff --git a/results/classifier/108/other/2463 b/results/classifier/108/other/2463 new file mode 100644 index 000000000..28b31865e --- /dev/null +++ b/results/classifier/108/other/2463 @@ -0,0 +1,24 @@ +device: 0.760 +graphic: 0.752 +semantic: 0.578 +permissions: 0.519 +performance: 0.512 +socket: 0.454 +boot: 0.363 +PID: 0.362 +network: 0.338 +other: 0.326 +vnc: 0.307 +debug: 0.290 +files: 0.210 +KVM: 0.091 + +allow sifive_e to use more RAM +Description of problem: +For users like me that are still learning RISC bare-metal assembly, searching online you will find many tutorials and examples using sifive_e with Qemu, so it is the easy way to get started. + +I quickly ran into crashes with my tests because I did not realize that sifive_e is limited to 16K of RAM. +I realize the 16K limit is hard coded so that it matches the real hardware, but that makes it very hard to run a variety of tests. +Additional information: +My fork of Qemu changes sifive_e to allow 256MB. +https://github.com/panjea/qemu/commit/97cb89d778ebe3407a969b8282e2e7adb4be2971 diff --git a/results/classifier/108/other/2464 b/results/classifier/108/other/2464 new file mode 100644 index 000000000..8cf133a5c --- /dev/null +++ b/results/classifier/108/other/2464 @@ -0,0 +1,26 @@ +device: 0.784 +boot: 0.732 +vnc: 0.609 +performance: 0.534 +semantic: 0.518 +socket: 0.485 +network: 0.461 +files: 0.427 +PID: 0.416 +permissions: 0.271 +debug: 0.236 +graphic: 0.151 +KVM: 0.148 +other: 0.041 + +"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens +Description of problem: +The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log. +Steps to reproduce: +1. Download a Windows NT 3.5x/4.0 ISO. +2. Create a disk image ≤2GB in size. +3. Enter the command above. +4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``) +5. Launch the installer by running ``cd:\mips\setupldr``. +Additional information: + diff --git a/results/classifier/108/other/2465 b/results/classifier/108/other/2465 new file mode 100644 index 000000000..42a18a908 --- /dev/null +++ b/results/classifier/108/other/2465 @@ -0,0 +1,16 @@ +device: 0.822 +other: 0.820 +performance: 0.766 +network: 0.682 +permissions: 0.495 +PID: 0.375 +semantic: 0.368 +debug: 0.308 +vnc: 0.285 +socket: 0.284 +boot: 0.275 +files: 0.257 +graphic: 0.256 +KVM: 0.024 + +QEMU does not stop other threads when hitting a breakpoint diff --git a/results/classifier/108/other/2466 b/results/classifier/108/other/2466 new file mode 100644 index 000000000..188cb8fd3 --- /dev/null +++ b/results/classifier/108/other/2466 @@ -0,0 +1,39 @@ +files: 0.894 +performance: 0.820 +other: 0.803 +graphic: 0.794 +semantic: 0.757 +device: 0.665 +vnc: 0.645 +debug: 0.637 +network: 0.592 +permissions: 0.493 +socket: 0.465 +KVM: 0.463 +boot: 0.459 +PID: 0.458 + +I'm not sure. But I Think I could cause the err(include/qemu/queue.h). +Description of problem: +At file "include/qemu/queue.h", Maybe I Think QTAILQ_REMOVE could cause a Error. + +``` +#define QTAILQ_REMOVE(head, elm, field) do { \ + if (((elm)->field.tqe_next) != NULL) \ + (elm)->field.tqe_next->field.tqe_circ.tql_prev = \ + (elm)->field.tqe_circ.tql_prev; \ + else \ + (head)->tqh_circ.tql_prev = (elm)->field.tqe_circ.tql_prev; \ + (elm)->field.tqe_circ.tql_prev->tql_next = (elm)->field.tqe_next; \ + (elm)->field.tqe_circ.tql_prev = NULL; \ + (elm)->field.tqe_circ.tql_next = NULL; \ + (elm)->field.tqe_next = NULL; \ +} while (/*CONSTCOND*/0) +``` +If the length of the que is one, line 7 cause a segmentation fault. +Steps to reproduce: +1. Create a Que with QTAILQ_INIT +2. Add one element to que. +3. Remove the element with QTAILQ_REMOVE +Additional information: +queue.h file is located at "inclue/qemu/queue.h" diff --git a/results/classifier/108/other/2469 b/results/classifier/108/other/2469 new file mode 100644 index 000000000..92e3afc09 --- /dev/null +++ b/results/classifier/108/other/2469 @@ -0,0 +1,16 @@ +performance: 0.781 +device: 0.776 +network: 0.680 +graphic: 0.414 +semantic: 0.291 +debug: 0.250 +other: 0.229 +files: 0.199 +boot: 0.136 +socket: 0.118 +PID: 0.075 +vnc: 0.048 +permissions: 0.035 +KVM: 0.034 + +/s390x/migration/precopy/tcp/plain/switchover-ack may hang |