diff options
Diffstat (limited to 'gitlab/issues/target_i386/host_missing/accel_missing')
149 files changed, 5700 insertions, 0 deletions
diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/101.toml b/gitlab/issues/target_i386/host_missing/accel_missing/101.toml new file mode 100644 index 000000000..8451de75b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/101.toml @@ -0,0 +1,15 @@ +id = 101 +title = "Running a virtual machine on a Haswell system produces machine check events" +state = "opened" +created_at = "2021-05-03T16:33:31.593Z" +closed_at = "n/a" +labels = ["Launchpad", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/101" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml new file mode 100644 index 000000000..c6c2f5a75 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1017.toml @@ -0,0 +1,21 @@ +id = 1017 +title = "Qemu Windows 10 restart bluescreen" +state = "opened" +created_at = "2022-05-08T10:20:10.081Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1017" +host-os = "Windows 10 20H2" +host-arch = "x86" +qemu-version = "QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)" +guest-os = "Ubuntu 20.4 TLS Server Edition" +guest-arch = "x86" +description = """after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen +with following issue - Memory Manangement or shutting down you Host system, getting bluescreen. +Only after stoppingh using qemu vm reboot system.""" +reproduce = """1. start qemu vm, ty get some operations +1. then stop the qemu vm via console comands +1. rebooting or restarting Host system +1. by shutting down, you get Bluescreen +2.""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml new file mode 100644 index 000000000..bac3dc2ca --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1035.toml @@ -0,0 +1,26 @@ +id = 1035 +title = "Hyper-V on KVM does not work on AMD CPUs" +state = "opened" +created_at = "2022-05-23T20:57:34.988Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1035" +host-os = "Proxmox 7.2" +host-arch = "x86" +qemu-version = "QEMU emulator version 6.2.0 (pve-qemu-kvm_6.2.0)" +guest-os = "Windows 11" +guest-arch = "AMD64" +description = """Can not enable hytper-v on KVM on AMD 3970x +``` +[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +```""" +reproduce = "n/a" +additional = """Related issue: +https://bugzilla.kernel.org/show_bug.cgi?id=203477""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml new file mode 100644 index 000000000..bc818b919 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1040.toml @@ -0,0 +1,18 @@ +id = 1040 +title = "Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze" +state = "opened" +created_at = "2022-05-27T14:11:02.095Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1040" +host-os = "Arch Linux." +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.0.0" +guest-os = "Windows Server 2016 Standard" +guest-arch = "x86_64" +description = """Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well. + + +""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml new file mode 100644 index 000000000..fcc8870ff --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1041.toml @@ -0,0 +1,39 @@ +id = 1041 +title = "x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel" +state = "closed" +created_at = "2022-05-27T18:11:26.561Z" +closed_at = "2022-06-24T17:49:58.495Z" +labels = ["Closed::Fixed", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1041" +host-os = "Debian GNU/Linux 11 (bullseye)" +host-arch = "x86-64" +qemu-version = "qemu-x86_64 version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1)" +guest-os = "Linux" +guest-arch = "x86-64" +description = """Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`. + +This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless""" +reproduce = """1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c) + +``` +#include <stdio.h> +#include <elf.h> + +int main(int argc, char** argv, char* envp[]) { + Elf64_auxv_t *auxv; + while(*envp++ != NULL); + + /*from stack diagram above: *envp = NULL marks end of envp*/ + int i = 0 ; + for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) + /* auxv->a_type = AT_NULL marks the end of auxv */ + { + if( auxv->a_type == AT_PLATFORM) + printf("AT_PLATFORM is: %s\\n", ((char*)auxv->a_un.a_val)); + } +} +``` +2. Run with `qemu-x86_64-static` +3. See `AT_PLATFORM is: i686` +4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64`""" +additional = """I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1042.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1042.toml new file mode 100644 index 000000000..9ce8501f2 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1042.toml @@ -0,0 +1,30 @@ +id = 1042 +title = "windows 10 guest freezes the host on shutdown" +state = "opened" +created_at = "2022-05-27T21:18:58.837Z" +closed_at = "n/a" +labels = ["hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1042" +host-os = "Gentoo" +host-arch = "x86-64" +qemu-version = "7.0.0" +guest-os = "Windows 10 Pro 21H1" +guest-arch = "x86-64" +description = """Windows 10 guest sometimes freezes the QEMU host when shutting down. + +There has been a bug reported about this in the past here: +https://bugs.launchpad.net/qemu/+bug/1580459 + +I am also using PCI Passthrough with an NVIDIA GPU. +Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists. + +This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff. + +There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit. +The host almost never freezes if I do this, and only happens very rarely. +But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this. + +I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup.""" +reproduce = """1. Start Windows 10 guest. +2. Shutdown Windows 10 guest""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml new file mode 100644 index 000000000..82d4b4aa6 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1047.toml @@ -0,0 +1,112 @@ +id = 1047 +title = "Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed." +state = "opened" +created_at = "2022-05-29T20:26:39.099Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1047" +host-os = "Debian 11" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.0.0" +guest-os = "Windows 10" +guest-arch = "x64" +description = """When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS. + +``` +qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. +```""" +reproduce = """1. Download / construct `w.img`, see above +2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm` +3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q` +4. See error message""" +additional = """The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. +Here is an interactive GDB session on my machine. + +``` +(gdb) hb *0x7c00 +Hardware assisted breakpoint 1 at 0x7c00 +(gdb) c +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) d +Delete all breakpoints? (y or n) y +(gdb) si 770 +0x000f7d7b in ?? () +(gdb) x/10i $eip +=> 0xf7d7b:\tmov $0x7d85,%ebx + 0xf7d80:\tout %al,$0xb2 + 0xf7d82:\tpause + 0xf7d84:\thlt + 0xf7d85:\tmov %bp,%sp + 0xf7d88:\tjmp 0xf7dd1 + 0xf7d8a:\tmov %cx,%si + 0xf7d8d:\tmov $0x1,%ax + 0xf7d91:\tadd %al,(%eax) + 0xf7d93:\tcallw 0x6b66 +(gdb) si +0x000f7d80 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d80 0xf7d80 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +0x000f7d82 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d82 0xf7d82 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +Remote connection closed +(gdb) +``` + +This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml new file mode 100644 index 000000000..32f1f748c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1098.toml @@ -0,0 +1,19 @@ +id = 1098 +title = "make check failed at bios-tables-test" +state = "opened" +created_at = "2022-07-04T08:00:26.571Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1098" +host-os = "CentOS Stream 8" +host-arch = "x86" +qemu-version = "version 7.0.50 (v7.0.0-2269-ge8e86b484e)" +guest-os = "n/a" +guest-arch = "n/a" +description = """run unit test "make check", failed at +3/177 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test ERROR 6.59s killed by signal 6 SIGABRT""" +reproduce = """1. ./configure --target-list=x86_64-softmmu --disable-xen --enable-sdl --enable-docs --disable-capstone +2. make -j check V=1""" +additional = """Looks like DSDT construction code has been changed but hasn't updated bios-table-test binaries. + +See attached diff file.[make_check_failure_dsdt_asl.diff](/uploads/9ed82fbb081863d8991fb0ea72446365/make_check_failure_dsdt_asl.diff)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1115.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1115.toml new file mode 100644 index 000000000..3e6de18e4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1115.toml @@ -0,0 +1,24 @@ +id = 1115 +title = "qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk" +state = "opened" +created_at = "2022-07-22T05:58:30.352Z" +closed_at = "n/a" +labels = ["hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1115" +host-os = "Manjaro fully updated" +host-arch = "x86_64" +qemu-version = "7.0.0" +guest-os = "Windows 10 21H1, Windows 10 PE iso" +guest-arch = "x86_64" +description = """When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle. +Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens. +Even after 30 minutes, the same. +Rebooted host multiple times. +Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck. +To boot the VM I have to: +- switch to UEFI (TianoCore) +- boot WinPE iso +- use proprietary software to convert the Windows disk from MBR to GPT +Then it boots just fine but I imagine not many users will be able to do this.""" +reproduce = """1. boot Windows image / WinPE iso with SeaBios""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml new file mode 100644 index 000000000..caa0131c4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1131.toml @@ -0,0 +1,28 @@ +id = 1131 +title = "Multiboot: could not move values from provided mmap to another address directly." +state = "closed" +created_at = "2022-07-30T14:42:03.649Z" +closed_at = "2022-08-17T07:25:08.613Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1131" +host-os = "Windows 11 with MSYS" +host-arch = "x86_64" +qemu-version = "master branch(fc2cc19ffa02c86ec1471ec8fdbc39d33fcec626)" +guest-os = "n/a" +guest-arch = "n/a" +description = """When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots. +```c +xxx = mmap->addr; +``` + +When moving with volatile, everything works well: +```c +volatile unsigned long long addr = mmap->addr; +xxx = addr; +```""" +reproduce = """1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32) +2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c) +3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here. +4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again. +5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly.""" +additional = """#""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml new file mode 100644 index 000000000..b68a8c9d4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1135.toml @@ -0,0 +1,20 @@ +id = 1135 +title = "Multiboot: invalid multiboot information block" +state = "opened" +created_at = "2022-08-01T14:09:39.403Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1135" +host-os = "Windows 11 with MSYS" +host-arch = "x86_64" +qemu-version = "4e06b3fc1b5e1ec03f22190eabe56891dc9c2236" +guest-os = "n/a" +guest-arch = "n/a" +description = """Breakpoint at 0x85d4, this is the entrypoint of this Multiboot loader. +According to the Multiboot specification, the EAX register should be a pointer to the Multiboot information block. When I am testing, it is 0x9500. However, when dumping the memory using `dump binary memory`, nearby memory areas are all zeros. + +When dumping some bigger memory aeras, I found that the module hasbeen loaded to the memory successfully, altough MBI was broken.""" +reproduce = """""" +additional = """multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot) + +toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/116.toml b/gitlab/issues/target_i386/host_missing/accel_missing/116.toml new file mode 100644 index 000000000..f0082616f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/116.toml @@ -0,0 +1,15 @@ +id = 116 +title = "qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974" +state = "opened" +created_at = "2021-05-04T05:45:13.039Z" +closed_at = "n/a" +labels = ["Launchpad", "Storage", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/116" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml new file mode 100644 index 000000000..bfc163892 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1164.toml @@ -0,0 +1,27 @@ +id = 1164 +title = "q35: incorrect values for PCIEXBAR masks" +state = "opened" +created_at = "2022-08-18T02:46:56.030Z" +closed_at = "n/a" +labels = ["device: PCI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1164" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = """https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/ + +In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295) + +There are two small issues in PCIEXBAR address mask handling: +- wrong bit positions for address mask bits (see PCIEXBAR description + in Q35 datasheet) +- incorrect usage of 64ADR_MASK + +Due to this, attempting to write a valid PCIEXBAR address may cause it to +shift to another address, causing memory layout corruption where emulated +MMIO regions may overlap real (passed through) MMIO ranges. Fix this +by providing correct values.""" +reproduce = "n/a" +additional = """Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address )""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1267.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1267.toml new file mode 100644 index 000000000..0c4414479 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1267.toml @@ -0,0 +1,105 @@ +id = 1267 +title = "qemu-i386 missing VDSO" +state = "closed" +created_at = "2022-10-20T16:13:04.509Z" +closed_at = "2023-10-31T07:50:33.696Z" +labels = ["Closed::Fixed", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1267" +host-os = "Asahi Linux (Arch Linux ARM)" +host-arch = "arm64" +qemu-version = "7.0.0, 5.2.0, and git (214a8da23651f2472b296b3293e619fd58d9e212)" +guest-os = "Linux" +guest-arch = "x86 (32-bit)" +description = """Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue. +I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping` + +Interestingly, qemu-x86_64 and qemu-arm appear to work just fine. + +Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct: + +``` +~/src/qemu/build$ /bin/lldb ./qemu-i386 +(lldb) target create "./qemu-i386" +Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64). +(lldb) run /home/ayke/src/tinygo/tinygo/test +Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64) +Process 97986 stopped +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 +libc.so.6`__sigsuspend: +-> 0xfffff78fb9fc <+92>: svc #0 + 0xfffff78fba00 <+96>: cmn x0, #0x1, lsl #12 ; =0x1000 + 0xfffff78fba04 <+100>: b.hi 0xfffff78fba3c ; <+156> + 0xfffff78fba08 <+104>: mov w19, w0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 + frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5 + frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13 + frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13 + frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9 + frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5 + frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160 + frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81 +(lldb) ^D +``` + +I got a better (but still not great) backtrace in Qemu 7.0.0: + +``` +~/src/tinygo/tinygo$ /bin/lldb qemu-i386 +(lldb) target create "qemu-i386" +Current executable set to 'qemu-i386' (aarch64). +(lldb) run test +Process 98106 launched: '/usr/bin/qemu-i386' (aarch64) +Process 98106 stopped +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 +qemu-i386`cpu_ldub_code: +-> 0xaaaaaac4b564 <+32>: ldrb w0, [x0, w1, uxtw] + 0xaaaaaac4b568 <+36>: str xzr, [x2] + 0xaaaaaac4b56c <+40>: ret + +qemu-i386`cpu_lduw_code: + 0xaaaaaac4b570 <+0>: mrs x2, TPIDR_EL0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 + frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72 + frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144 + frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24 + frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400 + frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72 + frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364 + frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480 + frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208 + frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020 + frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160 + frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48 +(lldb) ^D +``` + +And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable: + +``` +#0 0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170 +#1 0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#2 translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#3 x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916 +#4 0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506 +#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569 +#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>) + at ../../accel/tcg/translator.c:103 +#7 0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512) + at ../../target/i386/translate.c:8631 +#8 0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, + cflags@entry=0) at ../../accel/tcg/translate-all.c:1744 +#9 0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414 +#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770 +#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207 +#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882 +```""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml new file mode 100644 index 000000000..522647a49 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1279.toml @@ -0,0 +1,18 @@ +id = 1279 +title = "please assist resolving windows networking issue" +state = "closed" +created_at = "2022-10-27T12:45:04.889Z" +closed_at = "2022-12-11T18:07:10.636Z" +labels = ["hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1279" +host-os = "(Proxmox 7.2)" +host-arch = "(x86_86)" +qemu-version = "(QEMU emulator version 6.2.0 (pve-qemu-kvm_6.2.0)" +guest-os = "(Windows 10 22H2 and before)" +guest-arch = "(x86_64)" +description = """After Installation of Windows, for Intel E1000 , Realtek and VirtIO, Windows shows "Error Code 56: Windows is Still Setting Up the Class Configuration For This Device" in device manager and Network won't work""" +reproduce = """Install Windows 10 VM on Proxmox 7.2 with virtual hardware Version 6.1 +You get the error code above. When using virtio nic , during installation of the kvm-qemu-virtio driver/agent package, the installer get's stuck and finally fails. + +If you downgrade to virtual hardware 5.1 , the problem goes away.""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml new file mode 100644 index 000000000..4ecf738b9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1298.toml @@ -0,0 +1,27 @@ +id = 1298 +title = "virtio-pmem not working on microvm: virtio-pmem missing request data" +state = "opened" +created_at = "2022-11-03T23:10:50.472Z" +closed_at = "n/a" +labels = ["device:virtio", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1298" +host-os = "Debian 6.0.3-1" +host-arch = "amd64" +qemu-version = "QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b1)" +guest-os = "linux-5.17.15" +guest-arch = "amd64" +description = """When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. + +When using the first command is executed, qemu shows the following starts message: +``` +qemu-system-x86_64: virtio-pmem missing request data +``` + +and the kernel outputs following messages: +``` +[ 0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff] +[ 0.043923] IPI shorthand broadcast: enabled +[ 0.044022] nd_pmem: probe of namespace0.0 failed with error -16 +```""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml new file mode 100644 index 000000000..1bcec900f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1323.toml @@ -0,0 +1,25 @@ +id = 1323 +title = "qemu-system-x86_64: keyboard not available in cd boot menu" +state = "closed" +created_at = "2022-11-18T15:20:06.770Z" +closed_at = "2022-11-30T08:18:19.712Z" +labels = ["device:input", "hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1323" +host-os = "Windows 10 22H2 (Msys2/Mingw64), Debian Bullseye" +host-arch = "x86" +qemu-version = "QEMU emulator version 7.1.90 Tarball (Linux) / QEMU emulator version 7.1.91 Tarball (Windows)" +guest-os = "n/a" +guest-arch = "x86" +description = """While CD boot menu is shown, no keys input affects the CD boot menu""" +reproduce = """1. Execute qemu-system-x86_64 -m 1536 -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso +2. Wait for boot menu +3. Try to choose entry""" +additional = """Also occurs with other ISOs + + ``` + qemu-system-x86_64 -m 1536 -cdrom debian-10.8.0-amd64-netinst.iso + ``` + +Does not occur with provided edk2 firmware + +Does not occur with QEMU emulator version 7.1.0""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1328.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1328.toml new file mode 100644 index 000000000..a2cd60dae --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1328.toml @@ -0,0 +1,19 @@ +id = 1328 +title = "Cannot boot any UEFI systems after upgrade edk2-ovmf" +state = "closed" +created_at = "2022-11-21T22:15:44.840Z" +closed_at = "2022-11-26T04:34:44.821Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1328" +host-os = "Arch Linux" +host-arch = "x86-64" +qemu-version = "7.1.0" +guest-os = "(Windows 10 21H1, Fedora 34, etc.)" +guest-arch = "(x86, ARM, s390x, etc.)" +description = """After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started. + +I'm using Virtual Manager and virt-viewer with virsh.""" +reproduce = """1. Update edk2-ovmf to 202208-3 +2. Restart all running VM +3. Vm with UEFI bios cannot boot""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml new file mode 100644 index 000000000..0ea42e6a9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1348.toml @@ -0,0 +1,15 @@ +id = 1348 +title = "WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as #1115 https://gitlab.com/qemu-project/qemu/-/issues/1115 )" +state = "opened" +created_at = "2022-11-29T15:45:21.703Z" +closed_at = "n/a" +labels = ["target: i386", "workflow::Needs Info"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1348" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml new file mode 100644 index 000000000..2e84486a0 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1368.toml @@ -0,0 +1,46 @@ +id = 1368 +title = "unexpect rax value" +state = "closed" +created_at = "2022-12-15T07:54:32.732Z" +closed_at = "2023-01-15T16:30:16.041Z" +labels = ["Closed::Invalid", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1368" +host-os = "Ubuntu 22.04" +host-arch = "x86" +qemu-version = "QEMU emulator version 7.1.94 (v7.2.0-rc4)" +guest-os = "- OS/kernel version:" +guest-arch = "x86" +description = """- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less.""" +reproduce = """- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>:\tmov -0x8(%rbp),%rax + 0x2206 <vga_init+16>:\tmovq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8:\t0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>:\tmovl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml new file mode 100644 index 000000000..241830e74 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1382.toml @@ -0,0 +1,48 @@ +id = 1382 +title = "x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes" +state = "closed" +created_at = "2022-12-18T09:21:03.063Z" +closed_at = "2023-02-06T09:29:50.473Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1382" +host-os = "Ubuntu 18.04" +host-arch = "x86" +qemu-version = "2.11.1/7.2.0 (Probably all versions)" +guest-os = "N/A" +guest-arch = "x86-64" +description = """When in long mode an IDT descriptor is 16 bytes in size. When an exception is raised where an index to an IDT descriptor entry needs to be encoded in an error code's selector index field it appears that QEMU's software emulation improperly encodes the IDT descriptor index as if each entry is 8 bytes rather than 16. The effect is that the descriptor index is encoded with a value that is double what it should be. + +As an example if I have a *Segment Not Present* (#NP) exception handler (which has a selector error code pushed on the stack) that is raised when I try to generate a software interrupt 0x97 that is marked not present in its IDT descriptor entry - I expect that QEMU would properly encode the value 0x97 in the Selector Index of the Selector Error Code pushed on the stack. Instead, the value stored is actually 0x12E. 0x12E is double the expected value 0x97. + +You can observe this errant value in the output of QEMU when using the `-d int` option. I have cut out the unnecessary state information as I'm focussed on the `v=` and `e=`. + + 0: v=97 e=0000 i=1 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + 1: v=0b e=0972 i=0 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + +When I used `int 0x97` to generate the software interrupt it properly shows that `v=97` had occurred in the output above. Because 0x97 was marked not present exception 0x0b (Not Present) was raised as you can see in the second line. The problem is that `e=0972` is a Selector Error Code where *Bits 3..16* contain the value 0x12E instead of 0x97. **It isn't just the display value in QEMU's debug output that is wrong**, as the **Selector Error Code pushed on the interrupt stack is the same erroneous value**. + +This issue doesn't occur if you run QEMU with the `-enable-kvm` option; in BOCHS; or on real hardware. The value in those environments contains a Selector Error Code of 0x4ba. *Bits 3..16* of 0x4ba contains the descriptor index 0x97 as expected. See additional information for more details.""" +reproduce = """1. Put processor in long mode. 64-bit mode will suffice. +2. Load an IDT with: + - A valid Segment Not Present (#NP) 0x0B Exception Handler. Handler doesn't really need to do anything. + - At least one interrupt handler marked *Not Present* higher than 0x00. Interrupt 0x97 as an example. +3. Raise the interrupt with something like `int 0x097` for this example.""" +additional = """In order to test this problem out in other environments like real hardware and virtual machines I wrote a test program on a floppy disk image that can be run on machines and virtual machines that support legacy boot from floppy media (or emulated floppy media). The test program code can be found [in my Github repository](https://github.com/mpetch/SelectorErrorCodeTest). A pre-built [disk image](https://github.com/mpetch/SelectorErrorCodeTest/blob/main/disk.img) is also available. + +When the disk image is executed with QEMU using `qemu-system-x86_64 -fda disk.img` the result (with incorrect encoding) can be seen here: + + + +When QEMU is run with `qemu-system-x86_64 -fda disk.img -enable-kvm` the result (with correct encoding) can be seen here: + + + +Correct results are also obtained in BOCHS and real hardware. + +--- +The [Intel Software Development Manual Volume 3A](https://www.intel.ca/content/www/ca/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) documents the error code as: + + + +--- +#""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1383.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1383.toml new file mode 100644 index 000000000..ad5d67616 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1383.toml @@ -0,0 +1,15 @@ +id = 1383 +title = "Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others" +state = "opened" +created_at = "2022-12-20T00:49:40.697Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1383" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml new file mode 100644 index 000000000..abefd7dd4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1396.toml @@ -0,0 +1,15 @@ +id = 1396 +title = "Is it possible to emulate QEMU 64 Bit on Windows?" +state = "closed" +created_at = "2022-12-25T16:30:34.683Z" +closed_at = "2022-12-29T08:55:01.761Z" +labels = ["hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1396" +host-os = "Windows 10" +host-arch = "64 Bit" +qemu-version = "7.1.94" +guest-os = "ESXi 6.5" +guest-arch = "n/a" +description = """Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `.""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/141.toml b/gitlab/issues/target_i386/host_missing/accel_missing/141.toml new file mode 100644 index 000000000..f8c9ccb93 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/141.toml @@ -0,0 +1,15 @@ +id = 141 +title = "qemu-system-x86_64+gdb: unable to correctly disassemble \"real mode\" (i8086) instructions after attaching to QEMU started with \"-S -s\" options" +state = "opened" +created_at = "2021-05-05T06:56:52.542Z" +closed_at = "n/a" +labels = ["GDB", "Launchpad", "target: i386", "workflow::Needs Info"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/141" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml new file mode 100644 index 000000000..48836c452 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1410.toml @@ -0,0 +1,22 @@ +id = 1410 +title = "system_powerdown only works once" +state = "opened" +created_at = "2023-01-03T13:50:34.074Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1410" +host-os = "Debian" +host-arch = "x86_64" +qemu-version = "7.2.0" +guest-os = "Windows 10 LTS" +guest-arch = "x86_64" +description = """When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume. The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path. + +There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either.""" +reproduce = """ +1. Boot a guest configured to sleep when it receives a power button event +2. `system_powerdown` from the monitor to tell it to sleep +3. `info status` to verify that it is suspended +4. Wake the guest, either with `system_wakeup` or moving the mouse or something +5. `system_powerdown` has no effect""" +additional = """This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1437.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1437.toml new file mode 100644 index 000000000..a67ff65b9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1437.toml @@ -0,0 +1,16 @@ +id = 1437 +title = "Nitrux doesn't finish boot process" +state = "closed" +created_at = "2023-01-12T22:39:09.799Z" +closed_at = "2023-01-17T12:40:10.200Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1437" +host-os = "Linux Nitrux 2.6.0" +host-arch = "x86" +qemu-version = "n/a" +guest-os = "Linux Nitrux 2.6.0" +guest-arch = "x86" +description = """Boot process doesn't finish +""" +reproduce = """1.Load Nitrux ISO""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml new file mode 100644 index 000000000..e79f70870 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1472.toml @@ -0,0 +1,15 @@ +id = 1472 +title = "Parameter 'sgx-epc.0.node' is unexpected" +state = "closed" +created_at = "2023-02-01T02:39:24.587Z" +closed_at = "2023-02-01T16:49:18.456Z" +labels = ["target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1472" +host-os = "ubuntu22.04" +host-arch = "x86" +qemu-version = "6.2.0" +guest-os = "ubuntu18.04 server" +guest-arch = "n/a" +description = """qemu-system-x86_64: Parameter 'sgx-epc.0.node' is unexpected""" +reproduce = "n/a" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml new file mode 100644 index 000000000..28333521c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1473.toml @@ -0,0 +1,15 @@ +id = 1473 +title = "how to run qemu with sgx feature enabled" +state = "closed" +created_at = "2023-02-01T02:47:18.682Z" +closed_at = "2023-02-01T16:49:55.994Z" +labels = ["Documentation", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1473" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml new file mode 100644 index 000000000..2596f44c3 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1476.toml @@ -0,0 +1,15 @@ +id = 1476 +title = "Support for additional CMOS memory banks" +state = "opened" +created_at = "2023-02-06T06:34:05.891Z" +closed_at = "n/a" +labels = ["kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1476" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml new file mode 100644 index 000000000..5b2f550ac --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1492.toml @@ -0,0 +1,300 @@ +id = 1492 +title = "[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot" +state = "opened" +created_at = "2023-02-15T12:01:40.475Z" +closed_at = "n/a" +labels = ["linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1492" +host-os = "Gentoo Linux" +host-arch = "ppc64le (4K page size)" +qemu-version = "qemu-x86_64 version 7.2.50 (v7.2.0-1411-gf670b3eec7-dirty)" +guest-os = "Arch Linux" +guest-arch = "x86_64" +description = """qemu-x86_64 segfaults when trying to run android-studio inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. +``` +[niko@talos2 ~]$ android-studio +/usr/bin/android-studio: line 200: 117922 Segmentation fault (core dumped) "$JAVA_BIN" -classpath "$CLASS_PATH" ${VM_OPTIONS} "-XX:ErrorFile=$HOME/java_error_in_studio_%p.log" "-XX:HeapDumpPath=$HOME/java_error_in_studio_.hprof" "-Djb.vmOptionsFile=${USER_VM_OPTIONS_FILE:-${VM_OPTIONS_FILE}}" ${IDE_PROPERTIES_PROPERTY} -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main "$@" +```""" +reproduce = """1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) +2. Chroot into it using the following script: +``` +#!/bin/bash + +basedir="/home/niko/chroots/arch-x86_64" +cp /etc/resolv.conf ${basedir}/etc/ +cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ +sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> +mount --make-slave --bind ${basedir} ${basedir} +mount -t proc none ${basedir}/proc +mount -t sysfs none ${basedir}/sys/ +mount --make-rslave --rbind /dev ${basedir}/dev +mount --make-rslave --rbind /run ${basedir}/run +chroot ${basedir} /bin/bash +sleep 3 +umount -R ${basedir}/run +umount -R ${basedir}/dev +umount ${basedir}/sys +umount ${basedir}/proc +umount ${basedir} +mount | grep chroots | grep arch-x86_64 | grep -v snap +``` +3. Initialize pacaman keyring and update system: +``` +# pacman-key --init +# pacman-key --populate +# pacman -Syu +``` +4. Install android-studio from the AUR (download `PKGBUILD` and run `makepkg -s`, finally install the package with `pacman -U <packagename>`): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-studio +5. Create an unpriviledged account and run `android-studio` +6. Wait for the crash.""" +additional = """``` +Wed 2023-02-15 12:39:32 CET 117922 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +talos2 ~ # coredumpctl gdb 117922 + PID: 117922 (java) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 11 (SEGV) + Timestamp: Wed 2023-02-15 12:39:25 CET (1min 47s ago) + Command Line: /usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-studio/lib/util.jar:/opt/android-studio/lib/app.jar:/opt/android-studio/lib/3rd-party-rt.jar:/opt/android-studio/lib/jna.jar:/opt/android-studio/lib/platform-statistics-devkit.jar:/opt/android-studio/lib/jps-model.jar:/opt/android-studio/lib/rd-core.jar:/opt/android-studio/lib/rd-framework.jar:/opt/android-studio/lib/stats.jar:/opt/android-studio/lib/protobuf.jar:/opt/android-studio/lib/external-system-rt.jar:/opt/android-studio/lib/forms_rt.jar:/opt/android-studio/lib/intellij-test-discovery.jar:/opt/android-studio/lib/rd-swing.jar:/opt/android-studio/lib/annotations.jar:/opt/android-studio/lib/groovy.jar:/opt/android-studio/lib/annotations-java5.jar:/opt/android-studio/lib/byte-buddy-agent.jar:/opt/android-studio/lib/error-prone-annotations.jar:/opt/android-studio/lib/externalProcess-rt.jar:/opt/android-studio/lib/grpc-netty-shaded.jar:/opt/android-studio/lib/idea_rt.jar:/opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar:/opt/android-studio/lib/junit.jar:/opt/android-studio/lib/junit4.jar:/opt/android-studio/lib/lz4-java.jar:/opt/android-studio/lib/platform-objectSerializer-annotations.jar:/opt/android-studio/lib/pty4j.jar:/opt/android-studio/lib/rd-text.jar:/opt/android-studio/lib/resources.jar:/opt/android-studio/lib/util_rt.jar:/opt/android-studio/lib/winp.jar:/opt/android-studio/lib/ant/lib/ant.jar:/opt/android-studio/lib/dbus-java-3.2.1.jar:/opt/android-studio/lib/java-utils-1.0.6.jar:/opt/android-studio/lib/jnr-unixsocket-0.23.jar:/opt/android-studio/lib/jnr-ffi-2.1.10.jar:/opt/android-studio/lib/jffi-1.2.19.jar:/opt/android-studio/lib/jffi-1.2.19-native.jar:/opt/android-studio/lib/asm-7.1.jar:/opt/android-studio/lib/asm-commons-7.1.jar:/opt/android-studio/lib/asm-analysis-7.1.jar:/opt/android-studio/lib/asm-tree-7.1.jar:/opt/android-studio/lib/asm-util-7.1.jar:/opt/android-studio/lib/jnr-a64asm-1.0.0.jar:/opt/android-studio/lib/jnr-x86asm-1.0.2.jar:/opt/android-studio/lib/jnr-constants-0.9.12.jar:/opt/android-studio/lib/jnr-enxio-0.21.jar:/opt/android-studio/lib/jnr-posix-3.0.50.jar -Xms256m -Xmx1280m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false $'-Djdk.http.auth.tunneling.disabledSchemes=""' -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Djna.nosys=true -Djna.boot.library.path= -Didea.vendor.name=Google -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -XX:ErrorFile=/home/niko/java_error_in_studio_%p.log -XX:HeapDumpPath=/home/niko/java_error_in_studio_.hprof -Djb.vmOptionsFile=/opt/android-studio/bin/studio64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.java.1000.33cad872d21043ebbe3dd6581bdd28c6.117922.1676461165000000.zst (present) + Size on Disk: 226.7M + Message: Process 117922 (java) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /opt/android-studio/jbr/bin/java during file-backed mapping note processing + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libpthread.so.0 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/jli/libjli.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libdl.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/server/libjvm.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/librt.so.1 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libverify.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjava.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjimage.so during file-backed mapping note processing + +warning: Can't open file /tmp/hsperfdata_niko/117922 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libzip.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/modules during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnio.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnet.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/app.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/3rd-party-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jna.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-statistics-devkit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jps-model.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-core.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-framework.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/stats.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/protobuf.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/external-system-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/forms_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-test-discovery.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-swing.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/groovy.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations-java5.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/byte-buddy-agent.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/error-prone-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/externalProcess-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/grpc-netty-shaded.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/idea_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit4.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/lz4-java.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-objectSerializer-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/pty4j.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-text.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/resources.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util_rt.jar during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 117925] +[New LWP 117924] +[New LWP 117930] +[New LWP 117935] +[New LWP 117933] +[New LWP 117928] +[New LWP 117936] +[New LWP 117922] +[New LWP 117927] +[New LWP 117932] +[New LWP 117929] +[New LWP 117937] +[New LWP 117926] +[New LWP 117934] +[New LWP 117931] +[New LWP 117941] +[New LWP 117939] +[New LWP 117938] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-s'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00000000102e1c68 in sigsuspend () +[Current thread is 1 (Thread 0x3fffbab18360 (LWP 117925))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x3fffbab18360 (LWP 117925) 0x00000000102e1c68 in sigsuspend () + 2 Thread 0x3fffbb3cf360 (LWP 117924) 0x000000001033afec in syscall () + 3 Thread 0x3fffba9d3360 (LWP 117930) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 4 Thread 0x3fffba951360 (LWP 117935) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 5 Thread 0x3fffba850360 (LWP 117933) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 6 Thread 0x3fffbaa55360 (LWP 117928) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 7 Thread 0x3fffba910360 (LWP 117936) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 8 Thread 0x409e2000 (LWP 117922) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 9 Thread 0x3fffbaa96360 (LWP 117927) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 10 Thread 0x3fffba891360 (LWP 117932) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 11 Thread 0x3fffbaa14360 (LWP 117929) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 12 Thread 0x3fffba60e360 (LWP 117937) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 13 Thread 0x3fffbaad7360 (LWP 117926) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 14 Thread 0x3fffba992360 (LWP 117934) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 15 Thread 0x3fffbabce360 (LWP 117931) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 16 Thread 0x3fffba7ce360 (LWP 117941) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 17 Thread 0x3fffba80f360 (LWP 117939) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 18 Thread 0x3fffba5cd360 (LWP 117938) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +(gdb) thread 1 +[Switching to thread 1 (Thread 0x3fffbab18360 (LWP 117925))] +#0 0x00000000102e1c68 in sigsuspend () +(gdb) thread 2 +[Switching to thread 2 (Thread 0x3fffbb3cf360 (LWP 117924))] +#0 0x000000001033afec in syscall () +(gdb) thread 3 +[Switching to thread 3 (Thread 0x3fffba9d3360 (LWP 117930))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 4 +[Switching to thread 4 (Thread 0x3fffba951360 (LWP 117935))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\t../common-user/host/ppc64/safe-syscall.inc.S: No such file or directory. +(gdb) thread 5 +[Switching to thread 5 (Thread 0x3fffba850360 (LWP 117933))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 6 +[Switching to thread 6 (Thread 0x3fffbaa55360 (LWP 117928))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 7 +[Switching to thread 7 (Thread 0x3fffba910360 (LWP 117936))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 8 +[Switching to thread 8 (Thread 0x409e2000 (LWP 117922))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 9 +[Switching to thread 9 (Thread 0x3fffbaa96360 (LWP 117927))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 10 +[Switching to thread 10 (Thread 0x3fffba891360 (LWP 117932))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 11 +[Switching to thread 11 (Thread 0x3fffbaa14360 (LWP 117929))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 12 +[Switching to thread 12 (Thread 0x3fffba60e360 (LWP 117937))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 13 +[Switching to thread 13 (Thread 0x3fffbaad7360 (LWP 117926))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 14 +[Switching to thread 14 (Thread 0x3fffba992360 (LWP 117934))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 15 +[Switching to thread 15 (Thread 0x3fffbabce360 (LWP 117931))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 16 +[Switching to thread 16 (Thread 0x3fffba7ce360 (LWP 117941))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 17 +[Switching to thread 17 (Thread 0x3fffba80f360 (LWP 117939))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 18 +[Switching to thread 18 (Thread 0x3fffba5cd360 (LWP 117938))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75\tin ../common-user/host/ppc64/safe-syscall.inc.S +``` + +Download full coredump: https://drive.google.com/file/d/1t0Tm6-O6THrOFPp8uO-pbHqv8tZ6XWUe/view?usp=share_link""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1524.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1524.toml new file mode 100644 index 000000000..991ca2764 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1524.toml @@ -0,0 +1,47 @@ +id = 1524 +title = "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted" +state = "opened" +created_at = "2023-03-01T11:28:12.620Z" +closed_at = "n/a" +labels = ["Migration", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1524" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "centos8" +guest-arch = "x86" +description = """when i save and restore a guest,it report the error: "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted"""" +reproduce = """1.virsh save test ccc.img + +2.virsh restore ccc.im + + +it report error: + +[root@TOS-9772 ~]# virsh save test ccc.img + +[root@TOS-9772 ~]# virsh restore ccc.img + +error: Failed to restore domain from ccc.img + +error: internal error: qemu unexpectedly closed the monitor: qmp_cmd_name: query-hotpluggable-cpus, arguments: {} + +qmp_cmd_name: query-cpus-fast, arguments: {} + +qmp_cmd_name: query-iothreads, arguments: {} + +qmp_cmd_name: expire_password, arguments: {"protocol": "spice", "time": "never"} + +qmp_cmd_name: balloon, arguments: {"value": 1073741824} + +qmp_cmd_name: migrate-incoming, arguments: {"uri": "fd:29"} + +{"timestamp": {"seconds": 1677661413, "microseconds": 275227}, "event": "MIGRATION", "data": {"status": "setup"}} + +{"timestamp": {"seconds": 1677661413, "microseconds": 275600}, "event": "MIGRATION", "data": {"status": "active"}} + +2023-03-01T09:03:33.316549Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'kvm-tpr-opt' + +2023-03-01T09:03:33.317076Z qemu-system-x86_64: load of migration failed: Operation not permitted +{"timestamp": {"seconds": 1677661413, "microseconds": 317297}, "event": "MIGRATION", "data": {"status": "failed"}}""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml new file mode 100644 index 000000000..de41be255 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1533.toml @@ -0,0 +1,15 @@ +id = 1533 +title = "qemu-i386 should not enable feature LM with named CPU models." +state = "closed" +created_at = "2023-03-06T11:54:17.020Z" +closed_at = "2023-06-16T23:35:12.364Z" +labels = ["Closed::Duplicate", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1533" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml new file mode 100644 index 000000000..a246f98d9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1534.toml @@ -0,0 +1,15 @@ +id = 1534 +title = "usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid)" +state = "closed" +created_at = "2023-03-06T11:57:27.973Z" +closed_at = "2023-06-29T12:55:22.614Z" +labels = ["linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1534" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml new file mode 100644 index 000000000..8d0119a2c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1570.toml @@ -0,0 +1,71 @@ +id = 1570 +title = "Incorrect memory handling when booting redox" +state = "closed" +created_at = "2023-04-01T07:43:36.451Z" +closed_at = "2024-04-02T20:52:25.232Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1570" +host-os = "MacOS 12." +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.2.92 (v8.0.0-rc2-16-gf00506aeca-dirty)" +guest-os = "[Redox OS](https://www.redox-os.org/)" +guest-arch = "x86_64" +description = """During the boot of redox, I regularly get one of two errors when reading the HPET at base address `0xfed00000`: +- Incorrect translation from virtual address `0xffff8000fed00108` to random physical addresses, e.g. `0xfec00108` +- Invalid read at addr 0x0, size 8, region 'hpet', reason: invalid size (min:4 max:4)""" +reproduce = """1. Build the server version of the redox OS as per [the instructions](https://doc.redox-os.org/book/ch02-05-building-redox.html). +2. Run the qemu command line with multiple CPUs. The more CPUs the easier it is to reproduce. +3. The problem will manifest itself as a divide by zero error. See the corresponding [redox bug report](https://gitlab.redox-os.org/redox-os/kernel/-/issues/116).""" +additional = """The best evidence I have is a debug line I added to qemu before [the memory_region_dispatch_read line](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L1375): + +``` +if ((mr_offset & 0x1ff) == 0x108) fprintf(stderr, "cputlb io_readx cpu %d addr=%llx mr_offset=%llx mr=%p mr->addr=%llx\\n", current_cpu->cpu_index, addr, mr_offset, mr, mr->addr); +r = memory_region_dispatch_read(mr, mr_offset, &val, op, full->attrs); +``` + +That logs: + +``` +cputlb io_readx cpu 0 addr=ffff8000fed00108 mr_offset=108 mr=0x7fefb60d5720 mr->addr=fec00000 +``` + +The expected physical address is `0xfed00000` instead of `0xfec00000`. + +A more extensive log is this one: +``` +55027@1680283224.671665:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f0 value 0x949707cc size 4 name 'hpet' <- ok +55027@1680283224.671681:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f4 value 0x0 size 4 name 'hpet' <- ok +tlb_set_page_full: vaddr=0000000000474000 paddr=0x000000000536f000 prot=5 idx=1 +... +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +... +55027@1680283224.671951:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00108 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.671958:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec0010c value 0x0 size 4 name 'ioapic' +55027@1680283224.671967:memory_region_ops_write cpu 2 mr 0x7f994d808d30 addr 0xcf8 value 0x8000fa80 size 4 name 'pci-conf-idx' +55027@1680283224.671986:memory_region_ops_read cpu 2 mr 0x7f994d808e40 addr 0xcfc value 0x80a805 size 4 name 'pci-conf-data' +55027@1680283224.672001:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00000 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.672010:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00004 value 0x0 size 4 name 'ioapic' +``` + +Some observations +- ~I seem to be the only one having this issue. Perhaps because I am the only one developing on MacOS. Maybe it's because I'm running an older intel mac.~. I managed to reproduce this on a Asus vivobook running linux +- The redox OS [reads the HPET](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L11) at addresses `0xf4`, `0x108`, `0x00` in that order. If I change the order to `0x00`, `0xf4`, `0x108`, the problem goes away. +- Even if I work around the problem by changing the order of the reads, the OS still randomly crashes. This could be related, but I can only speculate on that right now. +- Increasing qemu debug logging tends to push the problem to the 4vs8 size problem instead of the incorrect address one. The more logging, the more difficult it is to reproduce. +- I tried to bisect the issue and found I could only reproduce it after qemu version 5.2. However, the mac build broke during this process so I could not find the causal commit. Between 5.1 and 5.2 the performance is greatly increased though and I suspect whatever changed there caused the issue. +- I can't reproduce the problem with -smp 1 +- I have seen qemu segfault occasionally, but I didn't look further into it and I don't know if it's related to this issue. +- I have attempted to rule out a bug in redox. I am fairly certain nothing strange is going on there, but I can't say for sure. +- When I trigger the incorrect address bug, I mostly get a base address of `0xfec00000` which is the IO APIC. However, I do occasionally see other addresses too +- `info tlb` at the time of the fault shows + ``` + ffff8000fd3e6000: 00000000fd3e6000 X--DA---W + ffff8000fd3e7000: 00000000fd3e7000 X--DA---W + ffff8000fed00000: 00000000fed00000 X--DAC--W + ffff8000fee00000: 00000000fee00000 X--DA---W + fffffd8000000000: 0000000001e32000 XG-DA---W + fffffd8000001000: 0000000001e36000 XG-DA---W + ```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1628.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1628.toml new file mode 100644 index 000000000..aa7b17c0e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1628.toml @@ -0,0 +1,138 @@ +id = 1628 +title = "windows 10 display scale will cause an exception" +state = "opened" +created_at = "2023-04-28T06:30:53.137Z" +closed_at = "n/a" +labels = ["GUI", "guest: Windows", "target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1628" +host-os = "centos" +host-arch = "x86" +qemu-version = "7.2.0" +guest-os = "Windows 10 21H2" +guest-arch = "x86" +description = """windows dispaly sacle 150% or higher, windows system will exception""" +reproduce = """1. windows dispaly sacle 150%""" +additional = """- code in: qemu/hw/display/qxl-render.c + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + chunk = qxl_phys2virt(qxl, chunk->next_chunk, group_id, + sizeof(QXLDataChunk) + chunk->data_size); + **// get next chunk, but the chunk size use current chunk's data size, not next chunk's data size!!!!** + **// if next chunk alloc size < current chunk's data size, there will be exception ** + + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +} + + + +- code in: qxl_wddm_dod/QXLDod.cpp exist next chunk alloc size < current chunk's data size + +NTSTATUS QxlDevice::SetPointerShape(_In_ CONST DXGKARG_SETPOINTERSHAPE* pSetPointerShape) +{ +..... + res = (Resource *)AllocMem(MSPACE_TYPE_VRAM, CURSOR_ALLOC_SIZE, TRUE); // here we all the first QXLDataChunk , and alloc_size = (CURSOR_ALLOC_SIZE - sizeof(Resource) - sizeof(InternalCursor)) = 8118 + +..... + for (; src != src_end; src += pSetPointerShape->Pitch) { + if (!PutBytesAlign(&chunk, &now, &end, src, line_size, PAGE_SIZE - PAGE_SIZE % line_size, NULL)) { // in this function ,we will alloc next QXLDataChunk + .......... + break; + } + } +} + +BOOLEAN QxlDevice::PutBytesAlign(QXLDataChunk **chunk_ptr, UINT8 **now_ptr, + UINT8 **end_ptr, UINT8 *src, int size, + size_t alloc_size, PLIST_ENTRY pDelayed) +{ + ..... + size_t maxAllocSize = BITS_BUF_MAX - BITS_BUF_MAX % size; + alloc_size = MIN(alloc_size, maxAllocSize); + void *ptr = AllocMem(MSPACE_TYPE_VRAM, alloc_size + sizeof(QXLDataChunk), bForced); *** //here will alloc next QXLDataChunk and alloc_size = (PAGE_SIZE - PAGE_SIZE % line_size) = 3876 **** +} + + +eg: +dispaly sacle 150% ，mouse size will bu change to 57* 55 ，rgba data size = 12540, we need three QXLDataChunk + +QXLDataChunk* first; +first->data_size = 8118; +first->prev_chunk = 0; +first->next_chunk=second; +first->data = [alloc_size(8118), data_size(8118)] + +QXLDataChunk* second; +second->data_size = 3876; +second->prev_chunk = first; +second->next_chunk=third; +second->data = [alloc_size(3876), data_size(3876)] + +QXLDataChunk* third; +third->data_size = 546; +third->prev_chunk =second; +third->next_chunk=0; +third->data = [alloc_size(3876), data_size(546)] + + +chunk = first; +qxl_phys2virt(qxl, second, group_id, sizeof(QXLDataChunk) + 8118) + + +this size [sizeof(QXLDataChunk) + 8118] > second QXLDataChunk's alloc size , will cause qxl_get_check_slot_offset check fail + + +for second QXLDataChunk, we actual alloc size is (sizeof(QXLDataChunk) + 3876), but we assign (8118 + sizeof(QXLDataChunk)) will cause an exception + + +suggest code : + +static void qxl_unpack_chunks(void *dest, size_t size, PCIQXLDevice *qxl, + QXLDataChunk *chunk, uint32_t group_id) +{ + uint32_t max_chunks = 32; + size_t offset = 0; + size_t bytes; + QXLPHYSICAL next_chunk_phys = 0; + for (;;) { + bytes = MIN(size - offset, chunk->data_size); + memcpy(dest + offset, chunk->data, bytes); + offset += bytes; + if (offset == size) { + return; + } + next_chunk_phys = chunk->next_chunk; + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk)); // fist time, only get the next chunk's data size; + if (!chunk) { + return; + } + chunk = qxl_phys2virt(qxl, next_chunk_phys, group_id, + sizeof(QXLDataChunk) + chunk->data_size); // second time, check data size and get data; + if (!chunk) { + return; + } + max_chunks--; + if (max_chunks == 0) { + return; + } + } +}""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1648.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1648.toml new file mode 100644 index 000000000..427b65295 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1648.toml @@ -0,0 +1,70 @@ +id = 1648 +title = "linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash" +state = "closed" +created_at = "2023-05-12T15:26:57.371Z" +closed_at = "2024-05-27T02:33:45.506Z" +labels = ["Closed::Fixed", "kind::Bug", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1648" +host-os = "Windows 11" +host-arch = "x86_64" +qemu-version = "8.0.0" +guest-os = "n/a" +guest-arch = "n/a" +description = """Corrent Print Result: + +sp: cdd3b4e8 + +SUCCEEDED! + +qemu-x86_64 Print Result: + +sp: 2804170 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Segmentation fault + +Reason of Bug: + +sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) + +For example on x86_64: + +reference to "qemu/linux-user/i386/signal.c" + +``` +# define TARGET_FPSTATE_FXSAVE_OFFSET 0 + +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + struct target_fpstate fpstate QEMU_ALIGNED(16); +}; +#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \\ + offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) +``` + +offsetof(struct rt_sigframe, fpstate) align of 16 + +TARGET_FPSTATE_FXSAVE_OFFSET is 0 + +TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 + +so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! + +Fix the bug: + +``` +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + abi_ulong unused QEMU_ALIGNED(16); + struct target_fpstate fpstate; +}; +``` + +offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64.""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml new file mode 100644 index 000000000..cbbc5c48a --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1762.toml @@ -0,0 +1,95 @@ +id = 1762 +title = "Linux RTC issues possibly with RTC_UIE_ON, RTC_UIE_OFF" +state = "opened" +created_at = "2023-07-14T17:27:02.151Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1762" +host-os = "Slackware64-current, Arch Linux, Linux Mint 21.1" +host-arch = "x86_64" +qemu-version = "n/a" +guest-os = "Slackware64-current, Arch Linux, Linux Mint 21.1" +guest-arch = "x86_64" +description = """Running: + +``` +hwclock --hctosys +``` + +as root, under the running VM using a UEFI bios image, I get: + +``` +hwclock: select() to /dev/rtc0 to wait for clock tick timed out +``` + +When running the same command on the same disk image but without UEFI, +that is, just using the SeaBIOS bios, everything works fine. + +Running + +``` +hwclock --hctosys --directisa +``` + +works fine, too. + +Running the (compiled) kernel test utility: + + +``` +/usr/src/linux/tools/testing/selftests/rtc/rtctest.c + +``` + + +``` +TAP version 13 +1..8 +# Starting 8 tests from 2 test cases. +# RUN rtc.date_read ... +# rtctest.c:49:date_read:Current RTC date/time is 10/07/2023 14:02:11. +# OK rtc.date_read +ok 1 rtc.date_read +# RUN rtc.date_read_loop ... +# rtctest.c:88:date_read_loop:Continuously reading RTC time for 30s (with 11ms breaks after every read). +# rtctest.c:115:date_read_loop:Performed 2752 RTC time reads. +# OK rtc.date_read_loop +ok 2 rtc.date_read_loop +# RUN rtc.uie_read ... +# uie_read: Test terminated by timeout +# FAIL rtc.uie_read +not ok 3 rtc.uie_read +# RUN rtc.uie_select ... +# rtctest.c:164:uie_select:Expected 0 (0) != rc (0) +# uie_select: Test terminated by assertion +# FAIL rtc.uie_select +not ok 4 rtc.uie_select +# RUN rtc.alarm_alm_set ... +# rtctest.c:202:alarm_alm_set:Alarm time now set to 14:02:52. +# rtctest.c:214:alarm_alm_set:Expected 0 (0) != rc (0) +# alarm_alm_set: Test terminated by assertion +# FAIL rtc.alarm_alm_set +not ok 5 rtc.alarm_alm_set +# RUN rtc.alarm_wkalm_set ... +# rtctest.c:258:alarm_wkalm_set:Alarm time now set to 10/07/2023 14:02:57. +# rtctest.c:268:alarm_wkalm_set:Expected 0 (0) != rc (0) +# alarm_wkalm_set: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set +not ok 6 rtc.alarm_wkalm_set +# RUN rtc.alarm_alm_set_minute ... +# rtctest.c:304:alarm_alm_set_minute:Alarm time now set to 14:03:00. +# rtctest.c:316:alarm_alm_set_minute:Expected 0 (0) != rc (0) +# alarm_alm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_alm_set_minute +not ok 7 rtc.alarm_alm_set_minute +# RUN rtc.alarm_wkalm_set_minute ... +# rtctest.c:360:alarm_wkalm_set_minute:Alarm time now set to 10/07/2023 14:05:00. +# rtctest.c:370:alarm_wkalm_set_minute:Expected 0 (0) != rc (0) +# alarm_wkalm_set_minute: Test terminated by assertion +# FAIL rtc.alarm_wkalm_set_minute +not ok 8 rtc.alarm_wkalm_set_minute +# FAILED: 2 / 8 tests passed. +# Totals: pass:2 fail:6 xfail:0 xpass:0 skip:0 error:0 +#""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/189.toml b/gitlab/issues/target_i386/host_missing/accel_missing/189.toml new file mode 100644 index 000000000..b9c30d676 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/189.toml @@ -0,0 +1,15 @@ +id = 189 +title = "Intel GVT-g works in X11, segfaults in wayland" +state = "closed" +created_at = "2021-05-06T08:58:19.132Z" +closed_at = "2025-01-13T17:52:32.283Z" +labels = ["Launchpad", "VFIO", "device:graphics", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/189" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/191.toml b/gitlab/issues/target_i386/host_missing/accel_missing/191.toml new file mode 100644 index 000000000..2828ffb87 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/191.toml @@ -0,0 +1,15 @@ +id = 191 +title = "qemu64 CPU model is incorrect" +state = "closed" +created_at = "2021-05-06T08:58:45.366Z" +closed_at = "2021-06-02T10:41:58.632Z" +labels = ["Launchpad", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/191" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml new file mode 100644 index 000000000..88fbac4b4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1919.toml @@ -0,0 +1,28 @@ +id = 1919 +title = "UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura" +state = "closed" +created_at = "2023-10-03T11:58:14.876Z" +closed_at = "2023-10-18T10:14:26.000Z" +labels = ["hostos: macOS", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1919" +host-os = "MacOS ventura 13.6" +host-arch = "x86_64`, `ARM` - problem tested on devices with Intel and Apple silicon" +qemu-version = "QEMU emulator version 8.1.1" +guest-os = "None - hangs during UEFI bios load" +guest-arch = "x86_64" +description = """Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load.""" +reproduce = """1. Run mentioned command - it should display OVMF logo - but it hangs""" +additional = """* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not +* Tested with swtpm and without - doesn't matter +* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works + +To enable TPM: +``` + -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \\ + -tpmdev emulator,id=tpm0,chardev=chrtpm \\ + -device tpm-tis,tpmdev=tpm0 \\ +``` +and run swtpm +``` +swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/192.toml b/gitlab/issues/target_i386/host_missing/accel_missing/192.toml new file mode 100644 index 000000000..6ac9f7919 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/192.toml @@ -0,0 +1,15 @@ +id = 192 +title = "xv6 Bootloop" +state = "opened" +created_at = "2021-05-06T08:58:57.762Z" +closed_at = "n/a" +labels = ["Launchpad", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/192" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml new file mode 100644 index 000000000..ee5b67726 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1932.toml @@ -0,0 +1,22 @@ +id = 1932 +title = "Broken grab on hover setting" +state = "opened" +created_at = "2023-10-11T13:53:03.500Z" +closed_at = "n/a" +labels = ["GUI", "device:input", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1932" +host-os = "Arch Linux" +host-arch = "x86_64" +qemu-version = "8.1.1" +guest-os = "Kali Linux" +guest-arch = "x86_64" +description = """It seems that now qemu implements "static" grab on hover, i.e., it can only be disabled by + +1. setting `vmport=off` in `-M` (btw, `pc` or `q35`, doesn't matter) +2. emulating a usb mouse *and* blacklist/unload the `psmouse` driver on the guest side + +while grab on hover setting in the gtk display backend (or frontend?) is seemingly bogus now either way. + +Can this be fixed (again?) so that the setting (which can be toggled in the menu "dynamically") can be used to tell this "vmport" thing whether or not it should grab on hover?""" +reproduce = "n/a" +additional = """NIL""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml new file mode 100644 index 000000000..db1fdb2f2 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1947.toml @@ -0,0 +1,28 @@ +id = 1947 +title = "ACPI (Stop code 0x000000A5) BSOD During Windows XP Professional x64 Edition Setup" +state = "opened" +created_at = "2023-10-16T20:46:57.066Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1947" +host-os = "Linux Mint 21.1 Cinnamon" +host-arch = "x86_64" +qemu-version = "8.1.1" +guest-os = "Windows XP Professional x64 Edition SP2" +guest-arch = "x86_64" +description = """When attempting to launch Windows XP Professional x64 Edition setup, the setup crashes with BSOD stop code 0x000000A5 and the following message: +``` +A problem has been detected and Windows has been shut down to prevent damage to your computer. + +If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps: + +The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated BIOS. If you are unable to obtain an updated BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI mode during textmode setup. To do this, press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 key was pressed - it will silently disable ACPI and allow you to continue your installation. + +Technical information: + +*** STOP: 0x000000A5 (0x0000000000000014, 0xFFFFFA80000CBFC6, 0x000000000000008A, 0xFFFFFADFC8E31A90) +```""" +reproduce = """1. Obtain a copy of Windows XP Professional x64 Edition SP2. +2. Run QEMU using the provided command line (with the name & location of your ISO in place of "Windows XP Professional x64 Edition.iso")""" +additional = """It appears the bug may be dependent on KVM, I've seen some conflicting results, but with the provided command line removing "accel=kvm" or replacing it with "accel=tcg" changes the BSOD to one about lack of disk space. +Also, a similar bug occurs with Windows 2000 SP4, but the setup will hang instead of crash. (The hang can be avoided by pressing F5 and selecting "Standard PC" instead of either ACPI option during setup.)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1952.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1952.toml new file mode 100644 index 000000000..2e9460959 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1952.toml @@ -0,0 +1,104 @@ +id = 1952 +title = "elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader" +state = "closed" +created_at = "2023-10-19T17:05:29.704Z" +closed_at = "2023-11-21T21:39:18.528Z" +labels = ["Closed::Fixed", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1952" +host-os = "NixOS 22.05" +host-arch = "x86_64`" +qemu-version = "latest master" +guest-os = "NixOS 22.05" +guest-arch = "x86_64`" +description = """Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this + +``` +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +```""" +reproduce = """1. Obtain latest Zig nightly +2. Compile simple static C program using Zig's ELF linker: + +``` +$ echo "int main() { return 0 };" > simple.c +$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000 +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +```""" +additional = """Note that running `simple` directly it's correctly mmaped and executed by the kernel: + +``` +$ ./simple +$ echo $status +0 +``` + +The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely: + +``` +vaddr2 - vaddr1 >= off2 - off1 +``` + +Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault: + +```diff +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index f21e2e0c3d..eabb4fed03 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd, + for (i = 0; i < ehdr->e_phnum; ++i) { + struct elf_phdr *eppnt = phdr + i; + if (eppnt->p_type == PT_LOAD) { +- abi_ulong a = eppnt->p_vaddr - eppnt->p_offset; ++ abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1); + if (a < loaddr) { + loaddr = a; + } +``` + +The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig: + +``` +$ readelf -l simple + +Elf file type is EXEC (Executable file) +Entry point 0x1002000 +There are 7 program headers, starting at offset 64 + +Program Headers: + Type Offset VirtAddr PhysAddr + FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000001000040 0x0000000001000040 + 0x0000000000000188 0x0000000000000188 R 0x8 + LOAD 0x0000000000000000 0x0000000001000000 0x0000000001000000 + 0x00000000000001c8 0x00000000000001c8 R 0x1000 + LOAD 0x0000000000021000 0x0000000001001000 0x0000000001001000 + 0x0000000000000078 0x0000000000000078 R 0x1000 + LOAD 0x0000000000022000 0x0000000001002000 0x0000000001002000 + 0x000000000000065a 0x000000000000065a R E 0x1000 + LOAD 0x0000000000023000 0x0000000001003000 0x0000000001003000 + 0x0000000000000060 0x0000000000000278 RW 0x1000 + GNU_EH_FRAME 0x0000000000021064 0x0000000001001064 0x0000000001001064 + 0x0000000000000014 0x0000000000000014 R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 + 0x0000000000000000 0x0000000000000000 RW 0x1 + + Section to Segment mapping: + Segment Sections... + 00 + 01 + 02 .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr + 03 .text .init .fini + 04 .data .got .bss + 05 .eh_frame_hdr + 06 +``` + +As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get + +``` +a := 0x1001000 - 0x21000 = 0xfe000 +``` + +and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1956.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1956.toml new file mode 100644 index 000000000..7bc25d748 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1956.toml @@ -0,0 +1,15 @@ +id = 1956 +title = "[x86,microvm] Update microvm documentation with ACPI option" +state = "opened" +created_at = "2023-10-24T13:25:11.937Z" +closed_at = "n/a" +labels = ["ACPI", "Documentation", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1956" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml new file mode 100644 index 000000000..3e6512d9c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1986.toml @@ -0,0 +1,22 @@ +id = 1986 +title = "windows install fails with error 0x80070001" +state = "opened" +created_at = "2023-11-18T08:16:00.014Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1986" +host-os = "Gentoo" +host-arch = "x86_64" +qemu-version = "8.1.2" +guest-os = "Windows 11 (22H2_x64v1, Win11_23H2_x64)" +guest-arch = "x86_64" +description = """I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used. +if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage +I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all. +I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win.""" +reproduce = """1. define a sata virtio controller +2. pass a physical sata drive to the guest attached to the sata controller define in step 1 +3. define a windows iso as cdrom +4. try to install windows on the device""" +additional = """[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt) +[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml b/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml new file mode 100644 index 000000000..b89e94f32 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/1998.toml @@ -0,0 +1,35 @@ +id = 1998 +title = "acpihp does not work with some common guest kernels" +state = "opened" +created_at = "2023-11-22T19:32:07.015Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/1998" +host-os = "Fedora Linux 38" +host-arch = "x86 64" +qemu-version = "QEMU emulator version 7.2.6 (qemu-7.2.6-1.fc38)" +guest-os = "Fedora 39" +guest-arch = "x86 64" +description = """for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs. +So basically only guest kernel >= 6.5 can make it work so far. +But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed? +I also don't know is this qemu bug? bios bug? or actually ACPIA's bug? + +journal -k report error like following: +``` +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io 0xa000-0xa07f] +Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003) +Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: + NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0) +Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1 +```""" +reproduce = """1. run the instance as I described above +2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8 +3. login to the vm console then nvidia-smi to see the failure + +workaround: +`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work.""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml new file mode 100644 index 000000000..d2c4f47d8 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2008.toml @@ -0,0 +1,22 @@ +id = 2008 +title = "querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry" +state = "closed" +created_at = "2023-11-28T14:44:32.801Z" +closed_at = "2024-03-18T10:34:30.833Z" +labels = ["guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2008" +host-os = "Proxmox VE 8 (but using upstream build of QEMU)" +host-arch = "x86" +qemu-version = "QEMU emulator version 8.1.0 (v8.1.0)" +guest-os = "Windows Server 2022 (also affects Windows Server 2019 and Windows 10)" +guest-arch = "x86" +description = """Querying the UUID in Powershell with +`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID` +will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present. + +Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part. + +It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS.""" +reproduce = "n/a" +additional = """Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths): +https://forum.proxmox.com/threads/136942/""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2020.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2020.toml new file mode 100644 index 000000000..b2656826f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2020.toml @@ -0,0 +1,21 @@ +id = 2020 +title = "qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed." +state = "opened" +created_at = "2023-12-06T11:58:15.102Z" +closed_at = "n/a" +labels = ["kind::Bug", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2020" +host-os = "Debian 12.2" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.2.5 (Debian 1:7.2+dfsg-7+deb12u2)" +guest-os = "Windows Server 2016" +guest-arch = "x86_64" +description = """VM just crashed, likely because of a time / NTP change +``` +qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed. +2023-12-04 15:51:40.571+0000: shutting down, reason=crashed +```""" +reproduce = """1. N/A + +/label ~"kind::Bug"""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml new file mode 100644 index 000000000..e45eef08b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2064.toml @@ -0,0 +1,20 @@ +id = 2064 +title = "QEMU v8.2.0-rc4 and above will not take SMI" +state = "closed" +created_at = "2024-01-02T21:46:05.776Z" +closed_at = "2024-02-17T07:54:07.106Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2064" +host-os = "Windows 11 and WSL" +host-arch = "x64" +qemu-version = "v8.2.0-rc4" +guest-os = "N/A, still in UEFI firmware" +guest-arch = "x86" +description = """Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step. + +After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change: + +1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior. +2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors.""" +reproduce = """1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic.""" +additional = """I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml new file mode 100644 index 000000000..292fc49f5 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2070.toml @@ -0,0 +1,17 @@ +id = 2070 +title = "TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2" +state = "closed" +created_at = "2024-01-04T14:40:25.218Z" +closed_at = "2024-01-20T15:04:15.194Z" +labels = ["target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2070" +host-os = "Arch Linux" +host-arch = "x86-64" +qemu-version = "qemu-8.2" +guest-os = "Fedora" +guest-arch = "x86" +description = """Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware.""" +reproduce = """1. `git clone https://github.com/systemd/mkosi` +2. `cd mkosi` +3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu`""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml new file mode 100644 index 000000000..3fc7e2b94 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2079.toml @@ -0,0 +1,15 @@ +id = 2079 +title = "flaky test: tcg tests, cross-i686-tci runner, \"run-memory\" test" +state = "closed" +created_at = "2024-01-08T11:39:45.375Z" +closed_at = "2024-03-11T14:45:56.595Z" +labels = ["CI", "Tests", "flaky-ci", "kind::Bug", "target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2079" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml new file mode 100644 index 000000000..c52750f72 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2218.toml @@ -0,0 +1,20 @@ +id = 2218 +title = "MIDI playback issue on Windows 98 / 2000 / XP guest" +state = "opened" +created_at = "2024-03-10T00:13:10.649Z" +closed_at = "n/a" +labels = ["Audio", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2218" +host-os = "Windows 11 (23H2)" +host-arch = "x64" +qemu-version = "8.2.0" +guest-os = "Windows 98 SE, Windows 2000 SP4, Windows XP SP3" +guest-arch = "x86" +description = """In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow. + +In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK.""" +reproduce = """1. In Windows XP guest, open C:\\WINDOWS\\Media\\Flourish.mid using Windows Media Player. +2. In Windows XP guest, open C:\\WINDOWS\\System32\\OOBE\\images\\title.wma using Windows Media Player. +3. In Windows 98 guest, open C:\\WINDOWS\\Media\\Passport.mid using Windows Media Player. +4. In Windows 98 guest, open C:\\WINDOWS\\Application Data\\Microsoft\\WELCOME\\WELCOM98.WAV using Windows Media Player.""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/223.toml b/gitlab/issues/target_i386/host_missing/accel_missing/223.toml new file mode 100644 index 000000000..0ff3c7e56 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/223.toml @@ -0,0 +1,15 @@ +id = 223 +title = "guest migration 100% cpu freeze bug" +state = "closed" +created_at = "2021-05-09T15:10:54.510Z" +closed_at = "2024-03-14T15:55:21.758Z" +labels = ["Launchpad", "Migration", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/223" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml new file mode 100644 index 000000000..c87471a92 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2244.toml @@ -0,0 +1,54 @@ +id = 2244 +title = "Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed" +state = "closed" +created_at = "2024-03-24T08:59:26.554Z" +closed_at = "2024-04-03T16:45:37.265Z" +labels = ["device:graphics", "kind::Bug", "target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2244" +host-os = "Debian Bookworm (and Windows 10 22H2, too)" +host-arch = "x86_64" +qemu-version = "8.2.90 - commit determined by git bisect: 973a724eb006f674301a0c45f34b3c08dee0fe49" +guest-os = "ETH Native Oberon" +guest-arch = "i386" +description = """On executing the image from QEMU advent calendar 2014, door 12 the following error is shown and QEMU exists. + +On Debian (built on git-repo) +``` +$ qemu-system-i386 oberon/oberon.qcow2 +qemu-system-i386: ../system/physmem.c:948: cpu_physical_memory_snapshot_get_dirty: Zusicherung »start + length <= snap->end« nicht erfüllt. +Abgebrochen +``` +On Windows (built on qemu-9.0.0-rc0.tar.xz) +``` +$ qemu-system-i386 oberon/oberon.qcow2 +ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end) +Bail out! ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end) +```""" +reproduce = """1. Retrieve oberon.tar.xz with `wget http://qemu-advent-calendar.org/2014/download/oberon.tar.xz` +2. Extract with `tar -xf oberon.tar.xz` +3. Execute with `qemu-system-i386 oberon/oberon.qcow2`""" +additional = """The same error is shown for QEMU advent calendar 2014, door 15 (Plan 9 from Bell Labs) soon after switch to graphical mode. + +git bisect result: +``` +973a724eb006f674301a0c45f34b3c08dee0fe49 is the first bad commit +commit 973a724eb006f674301a0c45f34b3c08dee0fe49 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Mon Dec 29 14:48:14 2014 +0100 + + vga: implement horizontal pel panning in graphics modes + + This implements smooth scrolling, as used for example by Commander Keen + and Second Reality. + + Unfortunately, this is not enough to avoid tearing in Commander Keen, + because sometimes the wrong start address is used for a frame. + On real EGA, the panning register is sampled on every line, while + the display start is latched for the next frame at the start of the + vertical retrace. On real VGA, the panning register is also latched, + but at the end of the vertical retrace. It looks like Keen exploits + this by only waiting for horizontal retrace when setting the display + start, but implementing it breaks the 256-color Keen games... + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml new file mode 100644 index 000000000..215adbc8e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2263.toml @@ -0,0 +1,36 @@ +id = 2263 +title = "guest panics when attempting to perform loadvm operation on x86_64 platform with kvm_intel ept=0" +state = "opened" +created_at = "2024-04-02T11:41:11.302Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2263" +host-os = "Ubuntu 22.04.3 LTS" +host-arch = "x86" +qemu-version = "QEMU emulator version 8.2.50 (v8.2.0-1871-g158a054c4d-dirty)" +guest-os = "Ubuntu 22.04.3 LTS" +guest-arch = "x86" +description = """The guest experiences a panic when attempting to perform the `loadvm` operation after it has been running for a while on the x86_64 platform with `kvm_intel ept=0`. I'm unsure if this operation is permitted or not, but it functions properly when using `kvm_intel ept=1`.""" +reproduce = """1. Load the `kvm-intel` module with the parameter `ept=0`. +2. savevm +Boot the first guest using the previous command line and switch to the QEMU console to execute the `savevm` operation. After that, proceed to shutting down the guest. +3. loadvm +Boot the second guest using the same command line and switch to the QEMU console to execute the `loadevm` operation. After that, the guest panics.""" +additional = """I have performed some debugging and it seems that the issue lies in the fact that the VMM modifies the guest memory without informing the KVM module. Upon further investigation, I noticed that the `loadvm` operation only restores the memory and does not execute any ioctl to modify the user memory region recorded in the KVM module. + +The KVM module calls `kvm_mmu_reset_context()` to unload the current EPT or SPT page table when guest system registers (CR0/CR3/CR4) are restored. However, for EPT, the EPT page table is released directly and can be reconstructed at a later stage. In contrast, for SPT, the KVM only decreases the reference count and retains the outdated SPT page table in the active list that is maintained by the KVM. As a result, this outdated SPT page table is reused later, leading to incorrect mapping. + +To address this, I attempted to call `kvm_arch_flush_shadow_all()` to zap all the page tables in `kvm_mmu_reset_context()`, which allowed the guest to function properly with SPT after the `loadvm` operation. + +Therefore, I believe that QEMU should notify the KVM to clear all the page tables if the KVM is using shadow paging. However, it appears that there is no appropriate ioctl available for the VMM to achieve this. + +guest panic output: + + +Trace the `kvm_mmu_get_page()` event and observe that only one record indicates that the outdated page table is reused instead of being recreated. + + +```shell +perf record -a -e kvmmmu:kvm_mmu_get_page +``` +""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2266.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2266.toml new file mode 100644 index 000000000..aad4513b8 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2266.toml @@ -0,0 +1,77 @@ +id = 2266 +title = "qemu-system-x86_64: stuck on watchpoint hit" +state = "opened" +created_at = "2024-04-04T10:01:04.687Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2266" +host-os = "Ubuntu 2022.04" +host-arch = "x86" +qemu-version = "8.2.92 (v9.0.0-rc2-7-g786fd793b8" +guest-os = "Yocto current build" +guest-arch = "x86" +description = """""" +reproduce = """1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +```""" +additional = """* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; +\tl1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2270.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2270.toml new file mode 100644 index 000000000..8fe1a826f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2270.toml @@ -0,0 +1,15 @@ +id = 2270 +title = "CPU topology recognition for Ryzen 9 7950X3D" +state = "opened" +created_at = "2024-04-06T13:45:12.995Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2270" +host-os = "Debian Trixie" +host-arch = "x86" +qemu-version = "QEMU emulator version 8.2.2 (Debian 1:8.2.2+ds-2+b1)" +guest-os = "Windows 11 22H2" +guest-arch = "x86" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml new file mode 100644 index 000000000..ecfaf2b35 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2320.toml @@ -0,0 +1,15 @@ +id = 2320 +title = "-Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc" +state = "opened" +created_at = "2024-05-01T11:02:22.629Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2320" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml new file mode 100644 index 000000000..80672b103 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2330.toml @@ -0,0 +1,81 @@ +id = 2330 +title = "acpi-erst: divide by zero in make_erst_storage_header()" +state = "opened" +created_at = "2024-05-07T05:17:35.268Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2330" +host-os = "Ubuntu" +host-arch = "x86" +qemu-version = "9.0.50" +guest-os = "n/a" +guest-arch = "n/a" +description = """When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero. + +```c +static void make_erst_storage_header(ERSTDeviceState *s) + ... + header->magic = cpu_to_le64(ERST_STORE_MAGIC); + header->record_size = cpu_to_le32(s->default_record_size); + header->version = cpu_to_le16(0x0100); + header->reserved = cpu_to_le16(0x0000); + + /* Compute mapsize */ + mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs +``` + +`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0. + +```c +static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp) + ... + /* + * Check if header is uninitialized; HostMemoryBackend inits to 0 + */ + if (le64_to_cpu(header->magic) == 0UL) { + make_erst_storage_header(s); + } + + /* Validity check record_size */ + record_size = le32_to_cpu(header->record_size); + if (!( + (record_size) && /* non zero */ + (record_size >= UEFI_CPER_RECORD_MIN_SIZE) && + (((record_size - 1) & record_size) == 0) && /* is power of 2 */ + (record_size >= 4096) /* PAGE_SIZE */ + )) { + error_setg(errp, "ERST record_size %u is invalid", record_size); + return; + } +```""" +reproduce = """1. make sure `acpi-erst.backing` doesn't exist in current folder. +2. run qemu command. +```bash +./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0 +```""" +additional = """I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows: +```bash +AddressSanitizer:DEADLYSIGNAL +================================================================= +==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0) + #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401 + #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431 + #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973 + #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093 + #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510 + #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362 + #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471 + #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28 + #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541 + #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719 + #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738 + #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203 + #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135 + #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640 + #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709 + #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742 + #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47 + #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24) +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2334.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2334.toml new file mode 100644 index 000000000..0c05bca7d --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2334.toml @@ -0,0 +1,264 @@ +id = 2334 +title = "[9.0.0] qemu breaks mac os vm" +state = "closed" +created_at = "2024-05-08T07:31:09.954Z" +closed_at = "2024-11-10T07:57:41.796Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2334" +host-os = "Manjaro kernel 5.15.158-1" +host-arch = "x86_64" +qemu-version = "9.0.0-1" +guest-os = "Mac OS Monterey 12.7.4" +guest-arch = "x86_64" +description = """Mac OS Monterey vm not able to boot after upgrading qemu to v. 9.0.0; no issue with qemu 8.2.2. +This vm is booted with opencore latest version. +The vm is not able to boot, apple logo is displayed on the screen for a bit, then the vm shutdowns, this is quite strange. +I can't see anything useful in the logs. +Changing machine type from q35-9.0 back to 8.2 doesn't solve the issue. +The vm is booted via libvirt (latest version) and it's not a quite "base" vm, it has multiple passthroughs and other things. +Before testing into details and starting to run base vms to see if it boots,maybe someone can see something wrong or maybe someone has the same issue. +Reverting back to qemu 8.2.2 fixes all the issues and the vm is able to boot again. +No issues with a windows 11 vm and with a kali vm. +I can say that it's not a DSDT issue (a problem I was having in the past was related with DSTD), because injecting the DSDT of the vm started from v 8.2.2 doesn't boot it. + +This is the xml of the vm: + +``` +<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <name>Monterey</name> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' current='28'>32</vcpu> + <vcpus> + <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> + <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> + <vcpu id='2' enabled='yes' hotpluggable='yes' order='3'/> + <vcpu id='3' enabled='yes' hotpluggable='yes' order='4'/> + <vcpu id='4' enabled='yes' hotpluggable='yes' order='5'/> + <vcpu id='5' enabled='yes' hotpluggable='yes' order='6'/> + <vcpu id='6' enabled='yes' hotpluggable='yes' order='7'/> + <vcpu id='7' enabled='yes' hotpluggable='yes' order='8'/> + <vcpu id='8' enabled='yes' hotpluggable='yes' order='9'/> + <vcpu id='9' enabled='yes' hotpluggable='yes' order='10'/> + <vcpu id='10' enabled='yes' hotpluggable='yes' order='11'/> + <vcpu id='11' enabled='yes' hotpluggable='yes' order='12'/> + <vcpu id='12' enabled='yes' hotpluggable='yes' order='13'/> + <vcpu id='13' enabled='yes' hotpluggable='yes' order='14'/> + <vcpu id='14' enabled='yes' hotpluggable='yes' order='15'/> + <vcpu id='15' enabled='yes' hotpluggable='yes' order='16'/> + <vcpu id='16' enabled='yes' hotpluggable='yes' order='17'/> + <vcpu id='17' enabled='yes' hotpluggable='yes' order='18'/> + <vcpu id='18' enabled='yes' hotpluggable='yes' order='19'/> + <vcpu id='19' enabled='yes' hotpluggable='yes' order='20'/> + <vcpu id='20' enabled='yes' hotpluggable='yes' order='21'/> + <vcpu id='21' enabled='yes' hotpluggable='yes' order='22'/> + <vcpu id='22' enabled='yes' hotpluggable='yes' order='23'/> + <vcpu id='23' enabled='yes' hotpluggable='yes' order='24'/> + <vcpu id='24' enabled='yes' hotpluggable='yes' order='25'/> + <vcpu id='25' enabled='yes' hotpluggable='yes' order='26'/> + <vcpu id='26' enabled='yes' hotpluggable='yes' order='27'/> + <vcpu id='27' enabled='yes' hotpluggable='yes' order='28'/> + <vcpu id='28' enabled='no' hotpluggable='yes'/> + <vcpu id='29' enabled='no' hotpluggable='yes'/> + <vcpu id='30' enabled='no' hotpluggable='yes'/> + <vcpu id='31' enabled='no' hotpluggable='yes'/> + </vcpus> + <iothreads>2</iothreads> + <iothreadids> + <iothread id='1'/> + <iothread id='2'/> + </iothreadids> + <cputune> + <vcpupin vcpu='0' cpuset='1'/> + <vcpupin vcpu='1' cpuset='2'/> + <vcpupin vcpu='2' cpuset='3'/> + <vcpupin vcpu='3' cpuset='4'/> + <vcpupin vcpu='4' cpuset='5'/> + <vcpupin vcpu='5' cpuset='6'/> + <vcpupin vcpu='6' cpuset='7'/> + <vcpupin vcpu='7' cpuset='9'/> + <vcpupin vcpu='8' cpuset='10'/> + <vcpupin vcpu='9' cpuset='11'/> + <vcpupin vcpu='10' cpuset='12'/> + <vcpupin vcpu='11' cpuset='13'/> + <vcpupin vcpu='12' cpuset='14'/> + <vcpupin vcpu='13' cpuset='15'/> + <vcpupin vcpu='14' cpuset='17'/> + <vcpupin vcpu='15' cpuset='18'/> + <vcpupin vcpu='16' cpuset='19'/> + <vcpupin vcpu='17' cpuset='20'/> + <vcpupin vcpu='18' cpuset='21'/> + <vcpupin vcpu='19' cpuset='22'/> + <vcpupin vcpu='20' cpuset='23'/> + <vcpupin vcpu='21' cpuset='25'/> + <vcpupin vcpu='22' cpuset='26'/> + <vcpupin vcpu='23' cpuset='27'/> + <vcpupin vcpu='24' cpuset='28'/> + <vcpupin vcpu='25' cpuset='29'/> + <vcpupin vcpu='26' cpuset='30'/> + <vcpupin vcpu='27' cpuset='31'/> + <emulatorpin cpuset='0,8,16,24'/> + </cputune> + <os> + <type arch='x86_64' machine='pc-q35-8.2'>hvm</type> + <loader readonly='yes' type='pflash'>/opt/macos/AUDK_CODE.fd</loader> + <nvram>/opt/macos/AUDK_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='2' dies='1' clusters='1' cores='8' threads='2'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x8' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x9' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0xc' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13' hotplug='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='c8:2a:14:66:2c:a1'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='c8:2a:14:31:32:e2'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <audio id='1' type='none'/> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </source> + <rom file='/opt/gpu-bios/6900xt.rom'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x06' slot='0x00' function='0x1'/> + </source> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <driver name='vfio'/> + <source> + <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> + </source> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x046d'/> + <product id='0x0892'/> + </source> + <address type='usb' bus='0' port='2'/> + </hostdev> + <hostdev mode='subsystem' type='usb' managed='no'> + <source> + <vendor id='0x148f'/> + <product id='0x3070'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <watchdog model='itco' action='reset'/> + <memballoon model='none'/> + </devices> + <qemu:commandline> + <qemu:arg value='-smbios'/> + <qemu:arg value='type=2'/> + <qemu:arg value='-global'/> + <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-speed=8'/> + <qemu:arg value='-global'/> + <qemu:arg value='pcie-root-port.x-width=16'/> + <qemu:arg value='-cpu'/> + <qemu:arg value='host,+hypervisor,migratable=no,-erms,kvm=on,+invtsc,+topoext,+avx,+aes,+xsave,+xsaveopt,+ssse3,+sse4_2,+popcnt,+arat,+pclmuldq,+pdpe1gb,+rdtscp,+vme,+umip,check'/> + </qemu:commandline> +</domain> +``` + +06:00.0/1 --> gpu +00:1b.0 --> audio +0c:00.0 --> sata controller +84:00.0 --> usb controller +0x046d 0x0892 --> usb webcam +0x148f 0x3070 --> usb wifi""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/237.toml b/gitlab/issues/target_i386/host_missing/accel_missing/237.toml new file mode 100644 index 000000000..c1f7039e1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/237.toml @@ -0,0 +1,15 @@ +id = 237 +title = "[Feature request] x86: dump MSR features in human form" +state = "closed" +created_at = "2021-05-09T15:45:03.220Z" +closed_at = "2022-08-16T07:07:12.789Z" +labels = ["Closed::UnbackedFeature", "Launchpad", "kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/237" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2381.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2381.toml new file mode 100644 index 000000000..285238f50 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2381.toml @@ -0,0 +1,15 @@ +id = 2381 +title = "Modern x86 TSC features under TCG" +state = "opened" +created_at = "2024-06-04T14:03:41.171Z" +closed_at = "n/a" +labels = ["kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2381" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """I may be able to find a volunteer to implement this. If this feature does not appear to be a good first task, please let me know.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2383.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2383.toml new file mode 100644 index 000000000..6703ca8a1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2383.toml @@ -0,0 +1,15 @@ +id = 2383 +title = "Support SMRR for x86 emulation" +state = "opened" +created_at = "2024-06-06T19:53:34.671Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2383" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2393.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2393.toml new file mode 100644 index 000000000..901be8739 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2393.toml @@ -0,0 +1,28 @@ +id = 2393 +title = "qemu: seabios hangs for 10~15 sec at boot with `-machine q35`" +state = "closed" +created_at = "2024-06-16T16:31:17.808Z" +closed_at = "2024-09-19T17:45:06.501Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2393" +host-os = "Gentoo Linux" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 9.0.1" +guest-os = "Gentoo Linux" +guest-arch = "x86_64" +description = """Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%. +This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying. +Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used. + +This means: +- 15 sec delay: qemu-system-x86_64 -machine q35 +- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso + +Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue. +Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain. +Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant)""" +reproduce = """1. qemu-system-x86_64 -machine q35 +2. wait about 10-15sec before boot continues""" +additional = """I was thinking to add an Screenshot of the hanging boot process, but the only text written there is: +SeaBIOS (version 1.16.0-20220807_005459-localhost) +with a blinking cursor below""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2420.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2420.toml new file mode 100644 index 000000000..0b27e010a --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2420.toml @@ -0,0 +1,52 @@ +id = 2420 +title = "Error: Deprecated CPU topology (considered invalid): Unsupported cluster parameter musn't be specified as 1" +state = "closed" +created_at = "2024-07-02T19:47:59.490Z" +closed_at = "2024-07-31T10:56:41.669Z" +labels = ["target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2420" +host-os = "OpenSuse Tumbleweed" +host-arch = "x86" +qemu-version = "9.0.0" +guest-os = "Windows 11" +guest-arch = "x86" +description = """warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1 +VM does not start + +What I've tried so far to fix: + +- Removed the offending `clusters="1"` parameter in the XML, both via virsh edit and virt-manager but the sucker comes back every time! + +- Creating a completely new VM from scratch, just keeping the qcow2 for Windows. What happens then is funny: The initial setup goes well. Machine type automatically gets set to q35 version 9.0. After setting up my cores (pinning) for the VM (7C/14T for the VM 1C/2T for host), there is no "clusters" parameter anymore. So the first start went well. After a RESTART of the whole host machine and subsequent launch of the VM guess what happened? The "clusters" thing is back in full swing.""" +reproduce = """1. Create Windows 11 VM with virt-manager +2. Try to do core pinning and setting up the following in virt manager before +- Copy CPU configuration from host (host-passthrough) +- Manually set CPU structure via GUI to 1 Socket, 7 Cores, 2 Threads on an 8 Core (in my case 11900k) +3. Observe result in XML being: + `<topology sockets="1" dies="1" clusters="1" cores="7" threads="2"/>` + +Again, the "clusters" entry leads to the VM not starting. Removing it doesn't work, it comes back straight away. I tried in virt-manager as well as with virsh edit.""" +additional = """My core pinning for reference: + +``` +<vcpu placement="static">14</vcpu> + <iothreads>1</iothreads> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="8"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="9"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="10"/> + <vcpupin vcpu="6" cpuset="3"/> + <vcpupin vcpu="7" cpuset="11"/> + <vcpupin vcpu="8" cpuset="4"/> + <vcpupin vcpu="9" cpuset="12"/> + <vcpupin vcpu="10" cpuset="5"/> + <vcpupin vcpu="11" cpuset="13"/> + <vcpupin vcpu="12" cpuset="6"/> + <vcpupin vcpu="13" cpuset="14"/> + <emulatorpin cpuset="7,15"/> + <iothreadpin iothread="1" cpuset="7,15"/> + </cputune> +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2426.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2426.toml new file mode 100644 index 000000000..2b6e3b813 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2426.toml @@ -0,0 +1,15 @@ +id = 2426 +title = "How to determine which cpu microarchitecture is suitable for use on Windows 11?" +state = "opened" +created_at = "2024-07-04T13:25:22.890Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2426" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/243.toml b/gitlab/issues/target_i386/host_missing/accel_missing/243.toml new file mode 100644 index 000000000..8a44e5979 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/243.toml @@ -0,0 +1,15 @@ +id = 243 +title = "Qemu refuses to multiboot Elf64 kernels" +state = "closed" +created_at = "2021-05-09T16:10:57.457Z" +closed_at = "2022-08-17T06:58:58.422Z" +labels = ["ACPI", "Launchpad", "kind::Feature Request", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/243" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2452.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2452.toml new file mode 100644 index 000000000..39e27c82f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2452.toml @@ -0,0 +1,15 @@ +id = 2452 +title = "memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb()" +state = "closed" +created_at = "2024-07-23T06:31:44.021Z" +closed_at = "2024-08-01T21:57:22.327Z" +labels = ["target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2452" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2509.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2509.toml new file mode 100644 index 000000000..bf4bfbad4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2509.toml @@ -0,0 +1,34 @@ +id = 2509 +title = "With qemu-system-i386 certain iso images cause looping crashes" +state = "opened" +created_at = "2024-08-17T06:00:08.697Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2509" +host-os = "Linux" +host-arch = "x86_64" +qemu-version = "QEMU emulator version min. since 7.2.11 (Debian 1:7.2+dfsg-7+deb12u6) until 9.0.92 (v9.1.0-rc2-dirty)" +guest-os = "n/a" +guest-arch = "n/a" +description = """Soon after start seabios tries to boot, a crash followed by a loop occurs. Last line seen before crash and loop: + ``` +Booting from DVD/CD... + ```""" +reproduce = """1. Download https://www.qemu-advent-calendar.org/2018/download/day10.tar.xz +2. Execute QEMU command line""" +additional = """Starting VM with qemu-system-x86_64 works + ``` + qemu-system-x86_64 -cdrom gamebro.iso + ``` +Starting VM with qemu-system-i386 using KVM causes looping + ``` + qemu-system-i386 -accel kvm -cdrom gamebro.iso + ``` +Starting VM with qemu-system-i386 on Windows using WHPX works + ``` + qemu-system-i386.exe -accel whpx -cdrom gamebro.iso + ``` +Starting other iso images works, e.g. https://cdimage.debian.org/mirror/cdimage/archive/10.8.0/i386/iso-cd/debian-10.8.0-i386-netinst.iso + ``` + qemu-system-i386 -cdrom debian-10.8.0-i386-netinst.iso + ```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2520.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2520.toml new file mode 100644 index 000000000..e281903bd --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2520.toml @@ -0,0 +1,19 @@ +id = 2520 +title = "qemu-system-x86_64 : No Display when system wakeup from suspend" +state = "opened" +created_at = "2024-08-20T12:29:49.680Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2520" +host-os = "Ubuntu 22.04.4 LTS" +host-arch = "x86" +qemu-version = "9.0.92 (v9.1.0-rc2-53-g075fd020)" +guest-os = "Linux" +guest-arch = "x86" +description = """Qemu display window is blank with message `Display output is not active.`""" +reproduce = """1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem > /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. System resumes in shell, but no output in display""" +additional = """Same behavior, if I try standard ubuntu22.04.qcow2 image. Before suspend GUI is there and after wakeup from suspend blank display with message `Display output is not active.`""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2530.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2530.toml new file mode 100644 index 000000000..9843ef452 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2530.toml @@ -0,0 +1,25 @@ +id = 2530 +title = "Duplicate ACPI _SUN" +state = "opened" +created_at = "2024-08-22T17:49:34.327Z" +closed_at = "n/a" +labels = ["ACPI", "device: PCI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2530" +host-os = "Fedora 40" +host-arch = "x86" +qemu-version = "qemu-8.2.2-1.fc40" +guest-os = "Centos 9 stream (any recent Linux should do)" +guest-arch = "x86" +description = """ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique +https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524""" +reproduce = """1. Create a linux VM with 2 virtio NICs +2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun) + +Both virtio-pci devices have _SUN == 0 +``` +#""" +additional = """In systemd we recently introduced code to use firmware_node/sun information for NIC naming +https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb + +but having duplicate _SUN is of course problematic +https://github.com/systemd/systemd/issues/34082""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2555.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2555.toml new file mode 100644 index 000000000..277a56947 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2555.toml @@ -0,0 +1,30 @@ +id = 2555 +title = "Can't start a guest with 2 IOAPICs" +state = "opened" +created_at = "2024-09-04T07:57:28.018Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2555" +host-os = "Ubuntu 22.04" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.22)" +guest-os = "Ubuntu 18.04" +guest-arch = "x86_64" +description = """For a host with multiple IOAPICs, I want to start a guest with 2 IOAPICs. I saw this commit about this function: **[x86: add support for second ioapic]**: + https://gitlab.com/qemu-project/qemu/-/commit/94c5a606379ddd04beecdb11fb34b51b4b28c7f2 + +But after I started a guest in a host with multiple IOAPICs, there was still only one IOAPIC in guest. How should I enable this feature?""" +reproduce = "n/a" +additional = """Host IOAPICs Info: + ``` +[ 1.268280] IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23 +[ 1.268286] IOAPIC[1]: apic_id 1, version 33, address 0xfec20000, GSI 24-55 +[ 1.268291] IOAPIC[2]: apic_id 2, version 33, address 0xd9000000, GSI 56-87 +[ 4.415313] ACPI: Using IOAPIC for interrupt routing + ``` + +Guest IOAPIC Info: + ``` +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.255045] ACPI: Using IOAPIC for interrupt routing + ```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2556.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2556.toml new file mode 100644 index 000000000..bff5d6606 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2556.toml @@ -0,0 +1,22 @@ +id = 2556 +title = "memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes)" +state = "opened" +created_at = "2024-09-04T09:03:38.657Z" +closed_at = "n/a" +labels = ["guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2556" +host-os = "Debian-12 GNU/Linux" +host-arch = "amd64` (AMD Ryzen-5800X, 32 GB memory)" +qemu-version = "9.0.2" +guest-os = "Windows 11` ([Developer VM Image \"WinDev2407Eval.VirtualBox.zip\"](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/), seems to need no TPM emulation :-))" +guest-arch = "amd64" +description = """When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off.""" +reproduce = """1. wait until Windows has booted +2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_ +3. Shut down (or reboot) Windows + +The system shows the boot screen at shutdown for a long time. + +It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB. +So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes**""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2562.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2562.toml new file mode 100644 index 000000000..3c8dd4977 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2562.toml @@ -0,0 +1,64 @@ +id = 2562 +title = "Booting EFI shell from GRUB using \"chainloader\" in Qemu with UEFI boot shows video artifacts if we have all_video, gfxterm" +state = "closed" +created_at = "2024-09-07T21:06:39.381Z" +closed_at = "2024-09-10T08:30:34.749Z" +labels = ["target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2562" +host-os = "Debian trixie (as on 2024-09-07)" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-2+b1)" +guest-os = "GRUB 2.12-5, EFI shell from tianocore 2024.05-1" +guest-arch = "x86_64" +description = "n/a" +reproduce = """- Start Qemu in UEFI mode, i. e. `qemu-system-x86_64 -bios OVMF.fd ...` +- Qemu should load GRUB from the disk as the first thing after firmware +- GRUB should run commands `loadfont unicode; insmod all_video; terminal_output gfxterm` (note: this is perfectly ordinary sequence executed by Debian's default configuration) +- Then GRUB should execute EFI shell using `chainloader` command + +If we do all this, then instead of EFI shell we will see broken image. I. e. video output will be completely broken/mangled/damaged. But EFI shell will still respond to commands. If we type "exit", then we will exit from EFI shell back to GRUB. + +I will repeat: my configuration is not special at all. `loadfont unicode; insmod all_video; terminal_output gfxterm` are absolutely ordinary commands executed by Debian's GRUB default setup. So, essentially this bug means this: if I add EFI shell to GRUB menu in Debian, then this new menu entry will not work properly if I try to boot in Qemu in UEFI mode. + +Okay, now let me give you more detailed steps to reproduce. + +- Execute the following script on Linux x86_64 host: +```bash +#!/bin/bash +# This script was tested on Debian trixie (as on 2024-09-07) with the following packages installed: +# dosfstools grub-efi-amd64-bin qemu-system-x86 ovmf efi-shell-x64 +set -e +DIR="$(mktemp -d /tmp/qemu-bug-XXXXXX)" +truncate --size=100M "$DIR/disk" +echo ',+,' | sfdisk --label gpt "$DIR/disk" +LOOP="$(losetup --find --show --partscan --nooverlap "$DIR/disk")" +sleep 1 +mkfs.vfat "${LOOP}p1" +mkdir "$DIR/root" +mount "${LOOP}p1" "$DIR/root" +losetup --detach "$LOOP" +mkdir -p "$DIR/root/EFI/boot" "$DIR/root/boot/grub/fonts" +grub-mkimage --format=x86_64-efi --output="$DIR/root/EFI/boot/bootx64.efi" --prefix=/boot/grub part_gpt fat +cp -r /usr/lib/grub/x86_64-efi "$DIR/root/boot/grub" +cp /usr/share/efi-shell-x64/shellx64.efi "$DIR/root/boot" +cp /usr/share/grub/unicode.pf2 "$DIR/root/boot/grub/fonts" +cat << "EOF" > "$DIR/root/boot/grub/grub.cfg" +loadfont unicode +insmod all_video +terminal_output gfxterm +menuentry "EFI shell" { + chainloader /boot/shellx64.efi +} +EOF +umount "$DIR/root" +qemu-system-x86_64 -m 2048 -bios OVMF.fd -drive file="$DIR/disk",format=raw +``` +- When you see Qemu window, choose "EFI shell" menu entry in GRUB menu +- You will immediately see damaged video output instead of proper EFI shell + +This bug doesn't reproduce on real hardware, i. e. without Qemu!!! I. e. this is Qemu bug. Qemu task is to duplicate real hardware behaviour. On real hardware there is no this bug, so Qemu should not have it, either. + +Note: if I remove `loadfont unicode; insmod all_video; terminal_output gfxterm`, then the bug disappears. + +Also note: if I replace `all_video` with `efi_gop`, then the bug disappears, too. So, workaround is to use `efi_gop` instead of `all_video` in UEFI mode. But I still believe the bug is in Qemu, because `all_video` doesn't cause any problems on real hardware, so Qemu should work, too.""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2583.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2583.toml new file mode 100644 index 000000000..b5c91ed23 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2583.toml @@ -0,0 +1,33 @@ +id = 2583 +title = "libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/ in fresh install of 9.1.50" +state = "opened" +created_at = "2024-09-22T02:24:10.861Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2583" +host-os = "debian 12.7" +host-arch = "x86_64 Genuine Intel" +qemu-version = "9.1.50 (downloaded 2024-09-21)" +guest-os = "n/a" +guest-arch = "n/a" +description = """Library libvfio-user.so.0 is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library. + +```` +root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 +-rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64 +root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 +\tlinux-vdso.so.1 (0x00007fff511de000) +\tlibvfio-user.so.0 => not found +\tlibslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000) +\tlibxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000) +\tlibxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000) +\tlibxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000) + ... +````""" +reproduce = """1. Fresh OS install, including all packages necessary to build from source. +2. Download source from gitlab and proceed with documented build instructions. +3. make install +4. Attempt to run /usr/local/bin/qemu-system-x86_64 fails, due to missing library.""" +additional = """Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu resolves the issue: + +(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0 /lib/x86_64-linux-gnu/libvfio-user.so.0""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2586.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2586.toml new file mode 100644 index 000000000..0b9c1520d --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2586.toml @@ -0,0 +1,15 @@ +id = 2586 +title = "qemu-system-x86_64: IGD \"legacy mode\" support with Q35?" +state = "opened" +created_at = "2024-09-23T12:40:51.316Z" +closed_at = "n/a" +labels = ["device:graphics", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2586" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """Detailed discussion on https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12103""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2590.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2590.toml new file mode 100644 index 000000000..5cc970535 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2590.toml @@ -0,0 +1,31 @@ +id = 2590 +title = "qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries." +state = "opened" +created_at = "2024-09-25T15:40:08.888Z" +closed_at = "n/a" +labels = ["GDB", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2590" +host-os = "Kali Linux" +host-arch = "ARM64" +qemu-version = "v9.1.0-452-ga5dd9ee060" +guest-os = "n/a" +guest-arch = "x86_64" +description = """GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work.""" +reproduce = """1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +```""" +additional = """This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2593.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2593.toml new file mode 100644 index 000000000..ed024e54e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2593.toml @@ -0,0 +1,67 @@ +id = 2593 +title = "-netdev user,smb=/path doesn't work with old Windows versions anymore" +state = "opened" +created_at = "2024-09-25T21:28:11.400Z" +closed_at = "n/a" +labels = ["Networking", "guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2593" +host-os = "current Arch Linux and Ubuntu 22.04" +host-arch = "x86_64" +qemu-version = "9.1.0 and 6.2.0" +guest-os = "Windows 98SE, probably all Windows versions before Vista and potentially other older operating systems" +guest-arch = "x86 (probably any)" +description = """I'm running Windows 98 in qemu and wasn't able to access the share. After finding `/tmp/qemu-smb.*/` and increasing the log level (setting `log level = 10` in the temporary smb.conf) it became clear, that the smbd server didn't support any of the protocols offered by Win98: + +<details> + +``` +[2024/09/25 23:04:25.871072, 10, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../lib/util/util.c:580(dump_data) + [0000] 02 50 43 20 4E 45 54 57 4F 52 4B 20 50 52 4F 47 .PC NETW ORK PROG + [0010] 52 41 4D 20 31 2E 30 00 02 4D 49 43 52 4F 53 4F RAM 1.0. .MICROSO + [0020] 46 54 20 4E 45 54 57 4F 52 4B 53 20 33 2E 30 00 FT NETWO RKS 3.0. + [0030] 02 44 4F 53 20 4C 4D 31 2E 32 58 30 30 32 00 02 .DOS LM1 .2X002.. + [0040] 44 4F 53 20 4C 41 4E 4D 41 4E 32 2E 31 00 02 57 DOS LANM AN2.1..W + [0050] 69 6E 64 6F 77 73 20 66 6F 72 20 57 6F 72 6B 67 indows f or Workg + [0060] 72 6F 75 70 73 20 33 2E 31 61 00 02 4E 54 20 4C roups 3. 1a..NT L + [0070] 4D 20 30 2E 31 32 00 M 0.12. +[2024/09/25 23:04:25.871241, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [PC NETWORK PROGRAM 1.0] +[2024/09/25 23:04:25.871247, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [MICROSOFT NETWORKS 3.0] +[2024/09/25 23:04:25.871252, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LM1.2X002] +[2024/09/25 23:04:25.871256, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [DOS LANMAN2.1] +[2024/09/25 23:04:25.871260, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [Windows for Workgroups 3.1a] +[2024/09/25 23:04:25.871264, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1154(smb2_multi_protocol_reply_negprot) + Requested protocol [NT LM 0.12] +... +[2024/09/25 23:04:25.871315, 6, pid=40892, effective(1000, 1000), real(1000, 1000)] ../../source3/param/loadparm.c:2442(lp_file_list_changed) + lp_file_list_changed() + file /tmp/qemu-smb.TU2YU2/smb.conf -> /tmp/qemu-smb.TU2YU2/smb.conf last mod_time: 2024-09-25 23:04:20.374500597 +[2024/09/25 23:04:25.871325, 3, pid=40892, effective(1000, 1000), real(1000, 1000), class=smb2] ../../source3/smbd/smb2_negprot.c:1201(smb2_multi_protocol_reply_negprot) + smb2_multi_protocol_reply_negprot: No protocol supported ! + +``` + +</details> + +(`smb2_multi_protocol_reply_negprot: No protocol supported !`). + +Manually adding the line `server min protocol = LANMAN1` under `[global]` in the temporary `smb.conf` fixed the issue. +I think qemu should add that line by default. + +The behavior was the same with smbd 4.15.13-Ubuntu from Ubuntu 22.04 and 4.21.0 from current Arch Linux.""" +reproduce = """1. Set up qemu VM with Win98 (or presumably any Windows version up to XP) + * at least on my machine I had to use `tcg`, with `kvm` Win98 is very unstable on Ryzen CPUs + * I roughly followed this tutorial: https://computernewb.com/wiki/QEMU/Guests/Windows_98 incl. using that Windows 98 QuickInstall ISO and the softgpu driver + * enable user-mode networking with smb share (`-netdev user,id=lan,smb=/path/to/share -device pcnet,netdev=lan`) +2. Edit `C:\\Windows\\LMHOSTS` as described in the qemu documentation (add line `10.0.2.4 smbserver`) +3. Probably reboot the Windows VM + * Actually, rebooting Win98 doesn't work for me, it then hangs while booting. Shutting down and starting the VM again works though. +4. Open the Windows Explorer and enter `\\\\smbserver` in the address bar - it will fail with some unhelpful error. +5. Edit `/tmp/qemu-smb.*/smb.conf` and add the line `server min protocol = LANMAN1` under `[global]` + - `server min protocol = NT1` also works for Win98, but with `LANMAN1` even older operating systems like Win3.11 should also work +6. Retry step 4 - it should work now.""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2594.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2594.toml new file mode 100644 index 000000000..f0e56e49d --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2594.toml @@ -0,0 +1,43 @@ +id = 2594 +title = "Migration fails with 'get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0' after hotplugging a CPU" +state = "closed" +created_at = "2024-09-26T14:57:34.774Z" +closed_at = "2025-01-27T17:13:01.907Z" +labels = ["Migration", "device: PCI", "device:virtio", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2594" +host-os = "Ubuntu 24.04 LTS (also tested on Ubuntu 22.04 LTS)" +host-arch = "x86-64" +qemu-version = "QEMU emulator version 9.1.50 (v9.1.0-475-ga53b931645) (compiled from source)" +guest-os = "-" +guest-arch = "x86" +description = """After hotplugging a CPU and finishing a migration from node 1 to node 2, the instance on node 2 crashes when virtio block devices are used: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load virtio-blk:virtio +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +qemu-system-x86_64: load of migration failed: Invalid argument +``` + +I found the problem also exhibits when using `scsi-hd` in combination with `virtio-scsi`, but not when using IDE hard disks or SCSI disks with an LSI controller. VMs with network cards aren't affected either, as are VMs without virtio disks. + + +Interestingly, the latest QEMU version shipped with Ubuntu 20.04 (4.2.1-Debian 1:4.2-3ubuntu6.29) is able to migrate this VM just fine.""" +reproduce = """1. Start a VM using the first command line +2. Start another VM using the second command line +3. Hotplug a CPU in QMP: + ``` + {"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"}} + ``` +4. Start a migration by executing the following QMP command (again substituting `<ip:port>` with the IP:port combination of node 2 + ``` + {"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"}} + ``` + +(For steps 3 and 4 I used this): +``` +echo '{"execute":"qmp_capabilities"} +{"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"},"id":1} +{"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"},"id":2}' | nc -U /tmp/vm1.sock +```""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2597.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2597.toml new file mode 100644 index 000000000..6ff539844 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2597.toml @@ -0,0 +1,15 @@ +id = 2597 +title = "qemu-i386 crashes on ppc64el" +state = "closed" +created_at = "2024-09-27T09:03:23.653Z" +closed_at = "2024-10-09T19:11:08.730Z" +labels = ["Closed::Fixed", "kind::Bug", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2597" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2616.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2616.toml new file mode 100644 index 000000000..87004f853 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2616.toml @@ -0,0 +1,19 @@ +id = 2616 +title = "crashout on any storage operation on SCO OpenServer 6" +state = "opened" +created_at = "2024-10-11T16:32:43.424Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2616" +host-os = "Arch Linux, last updated October 11th, 2024" +host-arch = "AMD64" +qemu-version = "QEMU version 9.1.50 (05adb388)" +guest-os = "SCO OpenServer 6 (2006 build)" +guest-arch = "i86 (honestly not specified, likely 486 and above)" +description = """it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing.""" +reproduce = """1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server. +2. attach it in your config. +3. go through initial setup stages (eg. entering a licence or deferring from such). +4. wait for the disk initialisation to begin.""" +additional = """ +""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2626.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2626.toml new file mode 100644 index 000000000..3f9be11be --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2626.toml @@ -0,0 +1,18 @@ +id = 2626 +title = "QEMU crashes after host time moves backwards" +state = "opened" +created_at = "2024-10-18T06:27:46.932Z" +closed_at = "n/a" +labels = ["Security", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2626" +host-os = "Ubuntu 18.04" +host-arch = "x86" +qemu-version = "4.2.1 (also reproduced for 6.2.0)" +guest-os = "windows 2016" +guest-arch = "x86" +description = """QEMU process crashes after time synchronized and moved backwards on the host.""" +reproduce = """As detailed in the [thread](https://bugzilla.redhat.com/show_bug.cgi?id=2228406) + +1. create a virtual machine and change tick period in the guest +2. executing `while [ 1 ];do hwclock --systohc; hwclock --hctosys;done` on the host""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2631.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2631.toml new file mode 100644 index 000000000..d11450548 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2631.toml @@ -0,0 +1,89 @@ +id = 2631 +title = "qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed." +state = "opened" +created_at = "2024-10-21T05:06:13.988Z" +closed_at = "n/a" +labels = ["Fuzzer", "device: PCI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2631" +host-os = "Ubuntu" +host-arch = "ARM" +qemu-version = "9.0.94" +guest-os = "n/a" +guest-arch = "n/a" +description = """While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality.""" +reproduce = """Here is qtest reproducer: +```bash +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \\ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +``` + +and execution log: +``` +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \\ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +[I 0.000001] OPENED +[R +0.067760] outl 0xcf8 0x80001020 +[S +0.067795] OK +OK +[R +0.067821] outl 0xcfc 0xe0800000 +[S +0.067959] OK +OK +[R +0.067993] outl 0xcf8 0x80001004 +[S +0.068005] OK +OK +[R +0.068020] outw 0xcfc 0x02 +[S +0.068520] OK +OK +[R +0.068554] write 0xe0800010 0x4 0x6100 +qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Aborted +``` + +If you need more information, let me know so I can discuss more about this issue.""" +additional = """```c +int msix_init(PCIDevice *dev, unsigned short nentries, + MemoryRegion *table_bar, uint8_t table_bar_nr, + unsigned table_offset, MemoryRegion *pba_bar, + uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos, + Error **errp); +int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries, + uint8_t bar_nr, Error **errp); +``` + +`msix_init` accepts `nentries` as `unsigned short` type. + +```c +static void virtio_pci_device_plugged(DeviceState *d, Error **errp): + + ... + + if (proxy->nvectors) { + int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors, + proxy->msix_bar_idx, NULL); + if (err) { + /* Notice when a system that supports MSIx can't initialize it */ + if (err != -ENOTSUP) { + warn_report("unable to init msix vectors to %" PRIu32, + proxy->nvectors); + } + proxy->nvectors = 0; + } + } +``` + +When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`. +This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash. + +While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2654.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2654.toml new file mode 100644 index 000000000..3d196fc51 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2654.toml @@ -0,0 +1,22 @@ +id = 2654 +title = "qemu-system-i386 no longer boots NetBSD" +state = "closed" +created_at = "2024-11-05T08:04:54.045Z" +closed_at = "2024-11-13T13:45:48.732Z" +labels = ["kind::Bug", "target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2654" +host-os = "Debian 12" +host-arch = "amd64" +qemu-version = "QEMU emulator version 9.1.50 (v9.1.0-1334-gdaaf51001a)" +guest-os = "NetBSD" +guest-arch = "i386" +description = """Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.""" +reproduce = """``` +wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso +qemu-system-i386 -cdrom NetBSD-10.0-i386.iso +``` + +Expected behavior: Boots into the NetBSD installer + +Observed incorrect behavior: Boot hangs with a black screen""" +additional = """This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2657.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2657.toml new file mode 100644 index 000000000..55149fed6 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2657.toml @@ -0,0 +1,19 @@ +id = 2657 +title = "Kernel crashed when installing OpenServer 6 D2M2a" +state = "opened" +created_at = "2024-11-06T03:30:27.652Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2657" +host-os = "macOS 15.1" +host-arch = "arm64" +qemu-version = "9.1.1" +guest-os = "SCO OpenServe 6 Definitive 2018 Update Pack 1, Maintenance Pack 1" +guest-arch = "x86" +description = """The kernel crashed when finishing installation.""" +reproduce = """1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done) +2. Create new virtual hard drive +3. Boot the installation ISO +4. Install with all default settings and all packages, evaluate license is okay. +5. Boom!""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2666.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2666.toml new file mode 100644 index 000000000..6130bd8c1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2666.toml @@ -0,0 +1,32 @@ +id = 2666 +title = "OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974" +state = "opened" +created_at = "2024-11-11T06:59:29.848Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2666" +host-os = "Slackware 15.0" +host-arch = "x86" +qemu-version = "QEMU emulator version 9.0.3 (v9.0.3-dirty)" +guest-os = "OPENSTEP 4.2 for Intel" +guest-arch = "x86" +description = """Get OPENSTEP 4.2 installation media from +https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/ + +Boot qemu like command line above + +Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor""" +reproduce = "n/a" +additional = """ + +driver select screen + + + +it boots .. + + + +find a bit too much LUNs and eventually give up after scanning them all + +Note there is 0-sized disk "detected" in there somewhere""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/267.toml b/gitlab/issues/target_i386/host_missing/accel_missing/267.toml new file mode 100644 index 000000000..bd78a3831 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/267.toml @@ -0,0 +1,15 @@ +id = 267 +title = "qemu-x86_64 segment prefixes error" +state = "opened" +created_at = "2021-05-11T05:37:06.937Z" +closed_at = "n/a" +labels = ["Launchpad", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/267" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2739.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2739.toml new file mode 100644 index 000000000..6c9653a85 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2739.toml @@ -0,0 +1,15 @@ +id = 2739 +title = "Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation" +state = "opened" +created_at = "2024-12-21T13:48:13.989Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2739" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2769.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2769.toml new file mode 100644 index 000000000..8d672d41f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2769.toml @@ -0,0 +1,15 @@ +id = 2769 +title = "Ability to set smbios type 3 field \"Type\"" +state = "opened" +created_at = "2025-01-08T19:38:58.706Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2769" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """That's all :)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2779.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2779.toml new file mode 100644 index 000000000..5996476d9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2779.toml @@ -0,0 +1,49 @@ +id = 2779 +title = "Segmentation fault when introspecting machine properties" +state = "closed" +created_at = "2025-01-16T10:03:04.141Z" +closed_at = "2025-02-21T23:15:13.450Z" +labels = ["kind::Bug", "target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2779" +host-os = "Fedora" +host-arch = "x86" +qemu-version = "master branch (commit 7433709a147706ad7d1956b15669279933d0f82b)" +guest-os = "n/a" +guest-arch = "x86" +description = """QEMU currrently crashes when trying to list the properties of the q35 machine type while QEMU has been started with the i440fx machine type. Introspecting QOM objects for their properties should always be possible, but apparently there is currently something causing a crash in this case.""" +reproduce = """1. Start QEMU with: qemu-system-x86_64 -M pc -qmp stdio +2. Enter these commands in the QMP monitor: + +``` + { "execute": "qmp_capabilities" } + { "execute": "qom-list-properties","arguments": { "typename": "pc-q35-10.0-machine"}} +```""" +additional = """Backtrace looks like this: +``` +mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +738\t s->cmos_data[addr] = val; +--Type <RET> for more, q to quit, c to continue without paging--#0 mc146818rtc_set_cmos_data (s=0x0, addr=95, val=-1) at ../../devel/qemu/hw/rtc/mc146818rtc.c:738 +#1 0x0000555555bf15d2 in pc_machine_done (notifier=0x555557f40750, data=<optimized out>) at ../../devel/qemu/hw/i386/pc.c:632 +#2 0x0000555555d4f7a2 in object_init_with_type (obj=obj@entry=0x555557f40320, ti=ti@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:424 +#3 0x0000555555d49c7e in object_initialize_with_type (obj=0x555557f40320, size=<optimized out>, type=type@entry=0x5555579c3c60) + at ../../devel/qemu/qom/object.c:570 +#4 0x0000555555d4a660 in object_new_with_type (type=0x5555579c3c60) at ../../devel/qemu/qom/object.c:774 +#5 object_new (typename=typename@entry=0x555558672b30 "pc-q35-10.0-machine") at ../../devel/qemu/qom/object.c:789 +#6 0x0000555555e825c5 in qmp_qom_list_properties (typename=0x555558672b30 "pc-q35-10.0-machine", errp=errp@entry=0x7fffffffd988) + at ../../devel/qemu/qom/qom-qmp-cmds.c:205 +#7 0x0000555555ef0525 in qmp_marshal_qom_list_properties (args=<optimized out>, ret=0x7fffeda9af00, errp=0x7fffeda9af08) + at qapi/qapi-commands-qom.c:288 +#8 0x0000555555f1edc1 in do_qmp_dispatch_bh (opaque=0x7fffeda9aed0) at ../../devel/qemu/qapi/qmp-dispatch.c:128 +#9 0x0000555555f40e28 in aio_bh_poll (ctx=ctx@entry=0x5555579f2930) at ../../devel/qemu/util/async.c:219 +#10 0x0000555555f2886f in aio_dispatch (ctx=0x5555579f2930) at ../../devel/qemu/util/aio-posix.c:424 +#11 0x0000555555f41cbb in aio_ctx_dispatch (source=0x0, callback=0x5f, user_data=<optimized out>) at ../../devel/qemu/util/async.c:361 +#12 0x00007ffff6d98e8c in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0 +#13 0x00007ffff6d99155 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#14 0x0000555555f42540 in glib_pollfds_poll () at ../../devel/qemu/util/main-loop.c:287 +#15 os_host_main_loop_wait (timeout=<optimized out>) at ../../devel/qemu/util/main-loop.c:310 +#16 main_loop_wait (nonblocking=nonblocking@entry=0) at ../../devel/qemu/util/main-loop.c:589 +#17 0x0000555555ae1207 in qemu_main_loop () at ../../devel/qemu/system/runstate.c:835 +#18 0x0000555555e85d57 in qemu_default_main (opaque=<optimized out>) at ../../devel/qemu/system/main.c:48 +#19 0x0000555555e85d2f in main (argc=<optimized out>, argv=<optimized out>) at ../../devel/qemu/system/main.c:76 +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2783.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2783.toml new file mode 100644 index 000000000..620279c50 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2783.toml @@ -0,0 +1,25 @@ +id = 2783 +title = "Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install)" +state = "opened" +created_at = "2025-01-18T23:50:54.885Z" +closed_at = "n/a" +labels = ["guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2783" +host-os = "Ubuntu 24.04" +host-arch = "x86_64" +qemu-version = "8.2.2" +guest-os = "Windows 7 SP1 32-bit" +guest-arch = "x86" +description = """When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed.""" +reproduce = """1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso +2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type +3. Click Begin Installation +4. See the Windows 7 installer screen show up +5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear""" +additional = """I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc. + + +Notice the lack of cursor in the screenshot above on Q35. + +When using a i440FX machine, the white Windows cursor will appear: +""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2813.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2813.toml new file mode 100644 index 000000000..c0ee96750 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2813.toml @@ -0,0 +1,17 @@ +id = 2813 +title = "Cannot emulate Windows 95 / 98" +state = "opened" +created_at = "2025-02-17T03:37:02.246Z" +closed_at = "n/a" +labels = ["guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2813" +host-os = "Windows 11 (24H2)" +host-arch = "x64" +qemu-version = "9.2.50" +guest-os = "Windows 95 / 98" +guest-arch = "x86" +description = """If install Windows 95 / 98 on that configuration, Windows 95 / 98 crashed on "While initializing device NDIS: Windows protection error." message, or QEMU crashed. With this command line Windows 95 / 98 can worked on previous QEMU 7.<br>And please don't allow IME input on CJK (Chinese / Japanese / Korean) host system (that relied IME to input some text). Such input process is done by the IME in CJK operating system guest.""" +reproduce = """1. +2. +3.""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2816.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2816.toml new file mode 100644 index 000000000..2387fa418 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2816.toml @@ -0,0 +1,22 @@ +id = 2816 +title = "qemu-9.2.1 windows can not load files if kernel is linux-6.13.x" +state = "opened" +created_at = "2025-02-17T15:47:09.129Z" +closed_at = "n/a" +labels = ["guest: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2816" +host-os = "linux" +host-arch = "x86_64" +qemu-version = "9.2.1" +guest-os = "Windows 10" +guest-arch = "## Description of problem" +description = """qemu-9.2 and 9.2.1 emulating windows-10 both gave this +bug "externe exception 80000004." emulating windows-10 +when a program tries to load a file. +qemu emulating windows-10 runs without this bug when using +kernel linux-6.12.14 and older.""" +reproduce = """1.start a prog, in my case sprint-layout-6.0, try to open/load a file. +2. +3.""" +additional = """Im not shure if the bug is with qemu or kernel. +You can decide better what causes this bug.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2817.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2817.toml new file mode 100644 index 000000000..aa1af6f23 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2817.toml @@ -0,0 +1,63 @@ +id = 2817 +title = "Strange floating-point behaviour under Windows with some CPU models" +state = "opened" +created_at = "2025-02-18T12:02:17.591Z" +closed_at = "n/a" +labels = ["Softfloat", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2817" +host-os = "Debian 12" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 7.2.13 (Debian 1:7.2+dfsg-7+deb12u7)" +guest-os = "Windows 10, Windows Server 2022" +guest-arch = "x86_64" +description = """I'm encountering a very weird bug with some floating-point maths code, but only under very specific configurations. First I thought it was a Clang bug, but then further digging eventually showed it to only occur under Windows VMs with specific QEMU CPU options, I'm not certain whether it is a QEMU/KVM bug or a Windows bug, but thought starting here would be easiest. + +When compiled under MSVC Clang with modern CPU instructions disabled (e.g. `-march=pentium3` or `-march=pentium-mmx`), the `floorf()` call in the following program always returns 0.0, while the truncation works correctly: + +``` +#include <math.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char **argv) +{ +\tfloat n = atof(argv[1]); +\tprintf("n = %f\\n", n); +\t +\tfloat f = floorf(n); +\tprintf("f = %f\\n", f); +\t +\tfloat c = (int)(n); +\tprintf("c = %f\\n", c); +\t +\treturn 0; +} +``` + +Example output on an affected VM: + +``` +C:\\Users\\Administrator> floorf-p3.exe 10 +n = 10.000000 +f = 0.000000 +c = 10.000000 + +C:\\Users\\Administrator> floorf-p4.exe 10 +n = 10.000000 +f = 10.000000 +c = 10.000000 +``` + +(`floorf-p3.exe` was compiled with `-march=pentium3` and `floorf-p4.exe` with `-march=pentium4` above) + +I've tried a few QEMU CPU models on a variety of Intel/AMD VM hosts and two different Windows versions (10 and Server 2022), and observed the following: + +* `host-passthrough` - works (on AMD and Intel hosts) +* `qemu64` - broken +* `EPYC-Milan` - works +* `Westmere` - works +* `Penryn` - broken + +(I also reported this via the mailing list, but I think it might've swallowed my post)""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2832.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2832.toml new file mode 100644 index 000000000..2ab6d6902 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2832.toml @@ -0,0 +1,107 @@ +id = 2832 +title = "Random kernel panic (2/3) in github macOS runner: IO-APIC + timer doesn't work!" +state = "opened" +created_at = "2025-02-23T01:08:40.332Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2832" +host-os = "macOS 13.7.2" +host-arch = "x86_64" +qemu-version = "qemu--9.2.0" +guest-os = "Ubuntu 24.10" +guest-arch = "x86_64" +description = """Random kernel panic (2/3 runs average) with this traceback: + +``` +[ 0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. +[ 0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu +[ 0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024 +[ 0.020000] Call Trace: +[ 0.020000] <TASK> +[ 0.020000] show_stack+0x49/0x60 +[ 0.020000] dump_stack_lvl+0x5f/0x90 +[ 0.020000] dump_stack+0x10/0x18 +[ 0.020000] panic+0x16a/0x328 +[ 0.020000] check_timer+0x4d1/0x570 +[ 0.020000] setup_IO_APIC+0x1e5/0x210 +[ 0.020000] apic_intr_mode_init+0xd0/0xf0 +[ 0.020000] x86_late_time_init+0x24/0x40 +[ 0.020000] start_kernel+0x3f9/0x4a0 +[ 0.020000] x86_64_start_reservations+0x24/0x30 +[ 0.020000] x86_64_start_kernel+0xf2/0x100 +[ 0.020000] common_startup_64+0x13e/0x141 +[ 0.020000] </TASK> +[ 0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. ]--- +```""" +reproduce = """1. Start qemu in macos-13 github runner""" +additional = """Example failed build: +https://github.com/nirs/vmnet-helper/actions/runs/13477646025/job/37658748139 + +serial.log: +``` +3h3hBdsDxe: failed to load Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x1,0x0)/Scsi(0x0,0x0): Not Found +BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0) +BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0) +EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path +[ 0.000000] Linux version 6.11.0-14-generic (buildd@lcy02-amd64-032) (x86_64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2) 14.2.0, GNU ld (GNU Binutils for Ubuntu) 2.43.1) #15-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 10 23:48:25 UTC 2025 (Ubuntu 6.11.0-14.15-generic 6.11.0) +[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.0-14-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] AMD AuthenticAMD +[ 0.000000] Hygon HygonGenuine +[ 0.000000] Centaur CentaurHauls +[ 0.000000] zhaoxin Shanghai +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080afff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000080b000-0x000000000080bfff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x000000000080c000-0x0000000000810fff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000811000-0x00000000008fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000003ee41fff] usable +[ 0.000000] BIOS-e820: [mem 0x000000003ee42000-0x000000003ef02fff] reserved +[ 0.000000] BIOS-e820: [mem 0x000000003ef03000-0x000000003f8ecfff] usable +[ 0.000000] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] RCU Tasks Rude: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. +[ 0.000000] NR_IRQS: 524544, nr_irqs: 256, preallocated irqs: 16 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] Console: colour dummy device 80x25 +[ 0.000000] printk: legacy console [tty1] enabled +[ 0.000000] printk: legacy console [ttyS0] enabled +[ 0.000000] ACPI: Core revision 20240322 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.001000] APIC: Switch to symmetric I/O mode setup +[ 0.003000] x2apic: IRQ remapping doesn't support X2APIC mode +[ 0.011000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.013000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC +[ 0.013000] ...trying to set up timer (IRQ0) through the 8259A ... +[ 0.013000] ..... (found apic 0 pin 2) ... +[ 0.014000] ....... failed. +[ 0.014000] ...trying to set up timer as Virtual Wire IRQ... +[ 0.018000] ..... failed. +[ 0.018000] ...trying to set up timer as ExtINT IRQ... +[ 0.020000] ..... failed :(. +[ 0.020000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. +[ 0.020000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-14-generic #15-Ubuntu +[ 0.020000] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202408-prebuilt.qemu.org 08/13/2024 +[ 0.020000] Call Trace: +[ 0.020000] <TASK> +[ 0.020000] show_stack+0x49/0x60 +[ 0.020000] dump_stack_lvl+0x5f/0x90 +[ 0.020000] dump_stack+0x10/0x18 +[ 0.020000] panic+0x16a/0x328 +[ 0.020000] check_timer+0x4d1/0x570 +[ 0.020000] setup_IO_APIC+0x1e5/0x210 +[ 0.020000] apic_intr_mode_init+0xd0/0xf0 +[ 0.020000] x86_late_time_init+0x24/0x40 +[ 0.020000] start_kernel+0x3f9/0x4a0 +[ 0.020000] x86_64_start_reservations+0x24/0x30 +[ 0.020000] x86_64_start_kernel+0xf2/0x100 +[ 0.020000] common_startup_64+0x13e/0x141 +[ 0.020000] </TASK> +[ 0.020000] ---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. ]--- +``` + +Same Ubuntu image never fail with vfkit vm on the same macos-13 github runners.""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2833.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2833.toml new file mode 100644 index 000000000..ede591867 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2833.toml @@ -0,0 +1,27 @@ +id = 2833 +title = "Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET" +state = "opened" +created_at = "2025-02-23T02:26:20.856Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2833" +host-os = "NixOS" +host-arch = "x86_64" +qemu-version = "9.20" +guest-os = "Custom hobby OS: https://github.com/ChocolateLoverRaj/code-runner" +guest-arch = "x86_64" +description = """In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says: +> Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field. +> +> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0. + + +> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values. + +In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows. + +The HPET should show that it works with more than just IRQ 2.""" +reproduce = """1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859 +2. `nix develop` +3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int`""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2834.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2834.toml new file mode 100644 index 000000000..8b11643b9 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2834.toml @@ -0,0 +1,27 @@ +id = 2834 +title = "qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]" +state = "opened" +created_at = "2025-02-23T06:18:59.616Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2834" +host-os = "ubuntu20.04" +host-arch = "x86" +qemu-version = "QEMU emulator version 8.2.9" +guest-os = "ubuntu20.04" +guest-arch = "x86" +description = """when run `./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic` warning `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]`. +Tried adding level/min-level=0x14, but still received a warning.""" +reproduce = """run command +``` +./qemu-system-x86_64 -cpu host,intel_pt -m 8192M -smp 4 -hda ubuntu.qcow2 --enable-kvm --nographic +```""" +additional = """- CPU i5-13600kf +``` +~$ sudo rdmsr 0x485 -f 14:14 # MSR_IA32_VMX_MISC_INTEL_PT +1 +~$ sudo rdmsr 0x48B -f 56:56 # SECONDARY_EXEC_PT_USE_GPA +1 +~$ sudo rdmsr 0x484 -f 50:50 # VM_ENTRY_LOAD_IA32_RTIT_CTL +1 +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2848.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2848.toml new file mode 100644 index 000000000..6904fe5ab --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2848.toml @@ -0,0 +1,25 @@ +id = 2848 +title = "i386 max_cpus off by one" +state = "opened" +created_at = "2025-03-02T00:58:09.053Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2848" +host-os = "NixOS" +host-arch = "x86" +qemu-version = "9.1.2" +guest-os = "n/a" +guest-arch = "x86" +description = """X86 VMs are currently limited to 255 vCPUs (`mc->max_cpus = 255;` in `pc.c`). +The first occurrence i can find of this limit is in d3e9db933f416c9f1c04df4834d36e2315952e42 from 2005 where both `MAX_APICS` and `MAX_CPUS` was set to 255. This is becoming relevant for some people as servers with 256 cores become more available. + +**Can we increase the limit to 256 vCPUs?** +I think so. + +Today, the APIC id limit (see `apic_id_limit` in `x86-common.c`) is based on the CPU id limit. +According to the a comment for `typdef uint32_t apic_id_t;` (see `topology.h`), we can have 256 APICs, but more APICs require x2APIC support. +APIC seems to be no hindrance to increase max_cpus to 256. + +**Can we increase the limit to 512?** Maybe not? We need x2APIC support of which i have no clue. Also there is always a performance risk of exceeding the size at which current data structures work efficiently.""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2868.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2868.toml new file mode 100644 index 000000000..ccbdd866f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2868.toml @@ -0,0 +1,15 @@ +id = 2868 +title = "amd iommu pte is only 32bits not 64bits." +state = "opened" +created_at = "2025-03-18T07:11:52.667Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2868" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2869.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2869.toml new file mode 100644 index 000000000..47c72741b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2869.toml @@ -0,0 +1,15 @@ +id = 2869 +title = "enable guest mode at amd iommu" +state = "opened" +created_at = "2025-03-18T07:33:55.880Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2869" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2874.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2874.toml new file mode 100644 index 000000000..1c2278019 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2874.toml @@ -0,0 +1,19 @@ +id = 2874 +title = "AMD Ryzen 9950x with -smp option yields \"warning: This family of AMD CPU doesn't support hyperthreading\"" +state = "opened" +created_at = "2025-03-19T16:29:51.347Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2874" +host-os = "Guix System" +host-arch = "x86_64" +qemu-version = "9.1.3" +guest-os = "n/a" +guest-arch = "n/a" +description = """When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints: +``` +qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature. +``` +This is unexpected. This CPU should support hyperthreading out of the box, it seems.""" +reproduce = """1. Run command above on Ryzen 9950X or similar CPU.""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2882.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2882.toml new file mode 100644 index 000000000..fb77185ad --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2882.toml @@ -0,0 +1,98 @@ +id = 2882 +title = "Reading ACPI info via fw_cfg in SVSM causes Linux to panic" +state = "opened" +created_at = "2025-03-25T15:57:54.938Z" +closed_at = "n/a" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2882" +host-os = "Fedora 40" +host-arch = "x86_64 (AMD SEV-SNP capable)" +qemu-version = "9.1.50" +guest-os = "Fedora 41" +guest-arch = "x86_64" +description = """We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem, +working on Coconut SVSM. + +**See https://github.com/coconut-svsm/svsm/issues/646** + +Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that. +That code has been used in the past, but since igvm became the default launch method for SVSM, it +was only used in corner-cases, while the information were obtained in some other way (igmv parameter). +Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but +strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. +There is no direct way how SVSM can influence the ACPI related behavior of the Linux +guest kernel. + +The problem seems to be caused by simply reading the ACPI data. + +Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux.""" +reproduce = """Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics: +``` +[...] +[ 1.857709] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53) +[ 1.862709] ACPI: Unable to start the ACPI Interpreter +[ 1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251) +[ 1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT +X_Namespace] (0x1) (20240827/utmutex-252) +[ 1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252) +[ 1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240 +827/utmutex-289) +[ 1.870826] iommu: Default domain type: Translated +[ 1.871710] iommu: DMA domain TLB invalidation policy: lazy mod +[...] +[ 2.672635] io scheduler bfq registered +[ 2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE +[ 2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.679264] ------------[ cut here ]------------ +[ 2.680284] refcount_t: addition on 0; use-after-free. +[ 2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 +[ 2.683261] Modules linked in: +[ 2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1 +[ 2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb +483f751 02/02/2022 +[ 2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110 +[ 2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c + c6 05 e5 9e 23 02 01 e8 +[ 2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282 +[ 2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448 +[ 2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 +[ 2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720 +[ 2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80 +[ 2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df +[ 2.701461] FS: 0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000 +[ 2.703179] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0 +[ 2.705910] Call Trace: +[ 2.706451] <TASK> +[ 2.706922] ? srso_return_thunk+0x5/0x5f +[ 2.707820] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.708783] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.709712] ? kobject_get+0x68/0x70 +[ 2.710492] ? refcount_warn_saturate+0xe5/0x110 +[ 2.711480] ? __warn.cold+0x93/0xfa +[ 2.712268] ? refcount_warn_saturate+0xe5/0x110 +[ 2.713262] ? report_bug+0xff/0x140 +[ 2.714036] ? handle_bug+0x58/0x90 +[ 2.714779] ? exc_invalid_op+0x17/0x70 +[ 2.715617] ? asm_exc_invalid_op+0x1a/0x20 +[ 2.716526] ? refcount_warn_saturate+0xe5/0x110 +[ 2.717507] kobject_get+0x68/0x70 +[ 2.718266] kobject_add_internal+0x32/0x250 +[ 2.719196] kobject_add+0x96/0xc0 +[ 2.719923] kobject_create_and_add+0xa3/0xc0 +[ 2.720851] bgrt_init+0x77/0xc0 +[ 2.721578] ? __pfx_bgrt_init+0x10/0x10 +[ 2.722418] do_one_initcall+0x5b/0x310 +[ 2.723272] do_initcalls+0x147/0x170 +[ 2.724086] ? __pfx_kernel_init+0x10/0x10 +[ 2.725174] kernel_init_freeable+0xfb/0x130 +[ 2.726114] kernel_init+0x1a/0x140 +[ 2.726883] ret_from_fork+0x34/0x50 +[ 2.727679] ? __pfx_kernel_init+0x10/0x10 +[ 2.728580] ret_from_fork_asm+0x1a/0x30 +[ 2.729429] </TASK> +[ 2.729926] ---[ end trace 0000000000000000 ]--- +```""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2892.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2892.toml new file mode 100644 index 000000000..d7f985d28 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2892.toml @@ -0,0 +1,15 @@ +id = 2892 +title = "Outdated documentation about MicroVMs" +state = "opened" +created_at = "2025-03-30T21:30:40.319Z" +closed_at = "n/a" +labels = ["Documentation", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2892" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2894.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2894.toml new file mode 100644 index 000000000..b5c7f8e2f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2894.toml @@ -0,0 +1,33 @@ +id = 2894 +title = "There is a bug in versions 2025-02-10 and later that causes virtual machines to be created with incorrect SMP settings with warnings about TCG features when setting more than 2 cores with the smp option in the default TCG acceleration (see main text)." +state = "opened" +created_at = "2025-03-31T08:23:25.359Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2894" +host-os = "Windows" +host-arch = "x86_64" +qemu-version = "9.2.50 or later" +guest-os = "Not applicable" +guest-arch = "x86_64" +description = """When using qemu-system-x86_64 in versions 9.2.50 and later, if you create a virtual machine with 2 or more cores using the smp option, + +``` +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1] +``` +The log will be displayed as many as the number of cores you have enabled, and the created virtual machine will be displayed as having a 1-core CPU with the number of cores you have enabled. +* I have not tested whether the same symptom occurs on versions 9.2.50 and later for other environments (Linux and the WoA version released on March 26th).""" +reproduce = """1. Create a virtual machine with more than two cores using TCG acceleration, which is the default acceleration, by using options such as 'qemu-system-x86_64 -smp 2' or 'qemu-system-x86_64 -smp sockets=1,cores=2,threads=1'. +2. 'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]' and +'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]' +The log is generated as many as the number of cores set and the virtual machine is created. +3. When checking the CPU information of the booted virtual machine, it does not show that there is one CPU with the specified number of cores, but rather that there is a single core CPU with the specified number of cores.""" +additional = """``` +>qemu-system-x86_64 -M q35 -smp 2 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\\Program Files\\qemu\\share\\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` + +``` +>qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\\Program Files\\qemu\\share\\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` +""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2897.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2897.toml new file mode 100644 index 000000000..989083814 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2897.toml @@ -0,0 +1,22 @@ +id = 2897 +title = "Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl" +state = "closed" +created_at = "2025-03-31T22:08:46.797Z" +closed_at = "2025-04-02T02:33:29.981Z" +labels = ["GUI", "GUI::GTK", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2897" +host-os = "Debian 12 and Ubuntu 22.04 (and probably everything else)" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 9.2.91 (But... I did just build 10.0.0-rc1)" +guest-os = "n/a" +guest-arch = "n/a" +description = """When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot.""" +reproduce = """1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST. +2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST.""" +additional = """This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. + +I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction. + +There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk` + +#""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2922.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2922.toml new file mode 100644 index 000000000..b43b95b65 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2922.toml @@ -0,0 +1,17 @@ +id = 2922 +title = "x86 reverse-debugging test is unreliable" +state = "opened" +created_at = "2025-04-14T09:30:51.441Z" +closed_at = "n/a" +labels = ["kind::Bug", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2922" +host-os = "Fedora 41" +host-arch = "x86" +qemu-version = "v10.0-rc3" +guest-os = "n/a" +guest-arch = "n/a" +description = """The reverse-debugging test for the x86 target is not working reliably. If the host system is under load, the test simply hangs and finally times out.""" +reproduce = """1. ``make check-venv`` +2. Run something in the background that keeps all CPUs busy +3. ``for ((x=0;x<10;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc ; done``""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2954.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2954.toml new file mode 100644 index 000000000..ffb2def93 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2954.toml @@ -0,0 +1,31 @@ +id = 2954 +title = "SD card is not visible by UEFI" +state = "opened" +created_at = "2025-05-07T15:52:54.552Z" +closed_at = "n/a" +labels = ["efi", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2954" +host-os = "Fedora 42" +host-arch = "x86_64" +qemu-version = "qemu-9.1.2-3.fc41" +guest-os = "n/a" +guest-arch = "x86_64" +description = """SD card is not visible by OVMF UEFI, so it's not possible to boot from it: +``` +UEFI Interactive Shell v2.2 +EDK II +UEFI v2.70 (EDK II, 0x00010000) +Mapping table + BLK0: Alias(s): + PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) +Press ESC in 1 seconds to skip startup.nsh or any other key to continue. +Shell> +``` +It is visible by SeaBIOS though, if we remove the OVMF part from the commandline: +``` +qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1 +``` + +@philmd""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/2961.toml b/gitlab/issues/target_i386/host_missing/accel_missing/2961.toml new file mode 100644 index 000000000..9032c2a52 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/2961.toml @@ -0,0 +1,41 @@ +id = 2961 +title = "isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others)" +state = "opened" +created_at = "2025-05-10T22:47:14.851Z" +closed_at = "n/a" +labels = ["target: i386", "workflow::Patch available"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/2961" +host-os = "Experienced on MacOS, reproed on Linux" +host-arch = "x86" +qemu-version = "every version since 8.2, reproed in current HEAD: v10.0.0-807-g7be29f2f1a" +guest-os = "Xenix" +guest-arch = "x86" +description = """I've been playing a bit with retro UNIXes and wanted to try a Xenix install. + +There are several webpages giving hints for installing Xenix under old versions of QEMU. The good news: most of the workarounds and tweaks they mention seem to be no longer needed. Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that. + +The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the... +``` +Boot +: +``` +...prompt. It doesn't respond to any keystrokes at this point. This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary. + +To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem! + +I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not. I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit. + +Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured. I was able to confirm that before this commit I could boot, but after it I could not. + +I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader. + +I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well. + +I don't know enough about the qemu internals to judge whether the original change made sense. Therefore, I won't claim that reverting it is the correct approach to fix the bug. However, it did work for me. + +The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward. Here is the diff I used: +[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch)""" +reproduce = """1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras +2. After some enjoyable floppy juggling, be amazed at how smoothly the install went +3. Try to boot from the harddrive afterwards and weep""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/320.toml b/gitlab/issues/target_i386/host_missing/accel_missing/320.toml new file mode 100644 index 000000000..5172eff9b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/320.toml @@ -0,0 +1,15 @@ +id = 320 +title = "Corsair iCUE Install Fails, qemu VM Reboots" +state = "opened" +created_at = "2021-05-15T14:05:25.014Z" +closed_at = "n/a" +labels = ["Launchpad", "hostos: Windows", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/320" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/331.toml b/gitlab/issues/target_i386/host_missing/accel_missing/331.toml new file mode 100644 index 000000000..5fd392d03 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/331.toml @@ -0,0 +1,15 @@ +id = 331 +title = "Incorrect feature negotiation for vhost-vdpa netdevice" +state = "opened" +created_at = "2021-05-17T14:33:05.982Z" +closed_at = "n/a" +labels = ["Networking", "linux-user", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/331" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/368.toml b/gitlab/issues/target_i386/host_missing/accel_missing/368.toml new file mode 100644 index 000000000..5212b06ed --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/368.toml @@ -0,0 +1,15 @@ +id = 368 +title = "virtiofsd: doesn't garant write access at users allowed by group permission" +state = "opened" +created_at = "2021-05-30T17:01:15.824Z" +closed_at = "n/a" +labels = ["Storage", "hostos: Linux", "kind::Bug", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/368" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/375.toml b/gitlab/issues/target_i386/host_missing/accel_missing/375.toml new file mode 100644 index 000000000..356c0358e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/375.toml @@ -0,0 +1,15 @@ +id = 375 +title = "MacOS 11.4 (x86_64) Host - USB passthrough appears to be broken" +state = "opened" +created_at = "2021-05-31T06:13:46.297Z" +closed_at = "n/a" +labels = ["USB", "hostos: macOS", "kind::Feature Request", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/375" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/387.toml b/gitlab/issues/target_i386/host_missing/accel_missing/387.toml new file mode 100644 index 000000000..2f27303ac --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/387.toml @@ -0,0 +1,15 @@ +id = 387 +title = "SD-Card not working anymore on x86 targets" +state = "closed" +created_at = "2021-06-03T15:42:33.049Z" +closed_at = "2021-06-04T08:27:59.620Z" +labels = ["Closed::Invalid", "Storage", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/387" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/389.toml b/gitlab/issues/target_i386/host_missing/accel_missing/389.toml new file mode 100644 index 000000000..62d31b3ff --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/389.toml @@ -0,0 +1,15 @@ +id = 389 +title = "Add multiboot2 support" +state = "opened" +created_at = "2021-06-04T13:21:17.160Z" +closed_at = "n/a" +labels = ["ACPI", "Launchpad", "kind::Feature Request", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/389" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/475.toml b/gitlab/issues/target_i386/host_missing/accel_missing/475.toml new file mode 100644 index 000000000..1d92ad77a --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/475.toml @@ -0,0 +1,15 @@ +id = 475 +title = "4.2 regression: ReactOS crashes on boot" +state = "opened" +created_at = "2021-07-12T15:45:00.472Z" +closed_at = "n/a" +labels = ["Launchpad", "device:graphics", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/475" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/508.toml b/gitlab/issues/target_i386/host_missing/accel_missing/508.toml new file mode 100644 index 000000000..76d9ec7c0 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/508.toml @@ -0,0 +1,15 @@ +id = 508 +title = "x86_64 cmpxchg behavior in qemu tcg does not match the real CPU" +state = "closed" +created_at = "2021-07-28T11:28:29.670Z" +closed_at = "2022-11-15T23:54:16.306Z" +labels = ["Closed::Fixed", "kind::Bug", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/508" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/510.toml b/gitlab/issues/target_i386/host_missing/accel_missing/510.toml new file mode 100644 index 000000000..e8c0b1146 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/510.toml @@ -0,0 +1,15 @@ +id = 510 +title = "QEMU registers support on x64" +state = "opened" +created_at = "2021-08-03T01:17:41.840Z" +closed_at = "n/a" +labels = ["GDB", "kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/510" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/512.toml b/gitlab/issues/target_i386/host_missing/accel_missing/512.toml new file mode 100644 index 000000000..dfe6501b2 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/512.toml @@ -0,0 +1,15 @@ +id = 512 +title = "6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration" +state = "closed" +created_at = "2021-08-03T18:42:20.421Z" +closed_at = "2021-08-15T10:13:55.092Z" +labels = ["Regression", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/512" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/525.toml b/gitlab/issues/target_i386/host_missing/accel_missing/525.toml new file mode 100644 index 000000000..2d4706c01 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/525.toml @@ -0,0 +1,22 @@ +id = 525 +title = "missing features with CPU `qemu64`" +state = "closed" +created_at = "2021-08-13T07:34:25.731Z" +closed_at = "2022-04-06T14:40:40.259Z" +labels = ["Migration", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/525" +host-os = "Ubuntu 20.04" +host-arch = "x86_64" +qemu-version = "4.2.1 (Debian 1:4.2-3ubuntu6.17)" +guest-os = "Debian 10" +guest-arch = "x86_64" +description = """The live migration complains about a missing feature when using the CPU qemu64, which is _guaranteed to work_.""" +reproduce = """1. start the VM with qemu64 on the CPU: Intel(R) Xeon(R) CPU E5-2620 v4 +2. live-migrate the VM to a CPU: Intel(R) Xeon(R) CPU E5-2670 0""" +additional = """The migration fails: +``` +root@covid21:~# virsh migrate --verbose --live --persistent --undefinesource myvm.local qemu+ssh://covid24/system +error: operation failed: guest CPU doesn't match specification: missing features: abm +``` + +This should not happen on a generic CPU, which should always work. Note, that the migration succeeds when using `-cpu qemu64,abm=off …`""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/536.toml b/gitlab/issues/target_i386/host_missing/accel_missing/536.toml new file mode 100644 index 000000000..7af519ce0 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/536.toml @@ -0,0 +1,15 @@ +id = 536 +title = "Null-ptr dereference in ich9_apm_ctrl_changed" +state = "opened" +created_at = "2021-08-21T00:59:43.326Z" +closed_at = "n/a" +labels = ["Fuzzer", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/536" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/538.toml b/gitlab/issues/target_i386/host_missing/accel_missing/538.toml new file mode 100644 index 000000000..c1f346c5b --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/538.toml @@ -0,0 +1,15 @@ +id = 538 +title = "Memory Leak in hpet_timer results in unusable machine" +state = "opened" +created_at = "2021-08-21T01:03:25.975Z" +closed_at = "n/a" +labels = ["Fuzzer", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/538" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/554.toml b/gitlab/issues/target_i386/host_missing/accel_missing/554.toml new file mode 100644 index 000000000..9fb643d60 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/554.toml @@ -0,0 +1,15 @@ +id = 554 +title = "q35 machine type cdrom device not discovered by freedos" +state = "opened" +created_at = "2021-08-22T05:30:06.294Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/554" +host-os = "linux, Debian Bullseye 11.0" +host-arch = "x86_64" +qemu-version = "5.2" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/561.toml b/gitlab/issues/target_i386/host_missing/accel_missing/561.toml new file mode 100644 index 000000000..45df8301f --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/561.toml @@ -0,0 +1,15 @@ +id = 561 +title = "Q35 - ACPI PCI hot-plug issue with Windows guest" +state = "closed" +created_at = "2021-08-25T08:25:41.089Z" +closed_at = "2021-10-05T23:30:21.442Z" +labels = ["ACPI", "Regression", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/561" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/627.toml b/gitlab/issues/target_i386/host_missing/accel_missing/627.toml new file mode 100644 index 000000000..106eaac18 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/627.toml @@ -0,0 +1,15 @@ +id = 627 +title = "VI.EXE crashes on start under QEMU; works under BOCHS" +state = "opened" +created_at = "2021-09-18T05:13:24.464Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/627" +host-os = "Debian Bullseye x64" +host-arch = "x64" +qemu-version = "QEMU emulator version 6.1.0" +guest-os = "MS-DOS" +guest-arch = "x86" +description = """vi.exe hangs on startup; can be verified to work in bochs""" +reproduce = """1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up""" +additional = """Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :(""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/629.toml b/gitlab/issues/target_i386/host_missing/accel_missing/629.toml new file mode 100644 index 000000000..d85b5c490 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/629.toml @@ -0,0 +1,20 @@ +id = 629 +title = "Trying to use EGA or VGA functions from QBASIC doesn't work" +state = "opened" +created_at = "2021-09-19T22:27:34.059Z" +closed_at = "n/a" +labels = ["device:graphics", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/629" +host-os = "debian bullseye" +host-arch = "x64" +qemu-version = "QEMU emulator version 6.1.0" +guest-os = "MS-DOS" +guest-arch = "x86_16" +description = """QBASIC can't start any graphics mode beyond CGA + +Some other programs that default to EGA crash trying to start graphics; none that I've tried can start EGA at all; believe to be the same bug; will file separately if it turns out to not be""" +reproduce = """1. Boot +2. Start QBASIC +3. Run a program consisting of only "SCREEN 12" for VGA or "SCREEN 9" for EGA +4. Get error message "Illegal Function Call"""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/641.toml b/gitlab/issues/target_i386/host_missing/accel_missing/641.toml new file mode 100644 index 000000000..cee4eb901 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/641.toml @@ -0,0 +1,15 @@ +id = 641 +title = "6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports" +state = "closed" +created_at = "2021-09-27T08:58:17.854Z" +closed_at = "2021-11-19T12:46:50.526Z" +labels = ["ACPI", "Regression", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/641" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/673.toml b/gitlab/issues/target_i386/host_missing/accel_missing/673.toml new file mode 100644 index 000000000..4357c23a2 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/673.toml @@ -0,0 +1,18 @@ +id = 673 +title = "I can no longer boot with -kernel and -initrd" +state = "closed" +created_at = "2021-10-16T07:24:36.205Z" +closed_at = "2021-10-18T15:20:22.076Z" +labels = ["target: i386", "workflow::Needs Info"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/673" +host-os = "Kubuntu 20.04" +host-arch = "(x86_64/amd64)" +qemu-version = "QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.18)" +guest-os = "(Linux 5.14.4)" +guest-arch = "(x86, x86_64)" +description = """The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated""" +reproduce = """I have put it all in the git repo of my project +1. git clone https://github.com/oknowaen/ltl-initramfs.git +2. cd ltl-initramfs +3. make (will start automatically)!""" +additional = """[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png)""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/705.toml b/gitlab/issues/target_i386/host_missing/accel_missing/705.toml new file mode 100644 index 000000000..9858872b4 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/705.toml @@ -0,0 +1,39 @@ +id = 705 +title = "Failed to acpi hotplug on pcie root ports in case of q35+ovmf+machine type 6.1" +state = "closed" +created_at = "2021-11-02T06:48:55.540Z" +closed_at = "2021-11-29T05:55:24.389Z" +labels = ["ACPI", "Regression", "device:virtio", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/705" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "v6.1.0-1861-gaf531756d2" +guest-os = "n/a" +guest-arch = "n/a" +description = """Hotplug on multifunction bridges use ACPI hotplug instead of Native since machine type 6.1 +In this case, Hotplug works well on q35 with bios fireware, But doesn't work on q35 with ovmf firmware. +E.g: +/usr/bin/qemu-system-x86_64 \\ +-machine pc-q35-6.1,accel=kvm,pflash0=...... \\ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \\ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \\ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \\ +...... + +(qemu) netdev_add bridge,br=br0,id=hostnet1 +(qemu) device_add virtio-net-pci,netdev=hostnet1,id=net1,bus=pci.3 + +Error message in guest kernel: +kernel: pci 0000:03:00.0: [1af4:1041] type 00 class 0x020000 +kernel: pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x00000fff] +kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] +kernel: pci 0000:03:00.0: reg 0x30: [mem 0x00000000-0x0003ffff pref] +kernel: pci 0000:03:00.0: BAR 6: no space for [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 6: failed to assign [mem size 0x00040000 pref] +kernel: pci 0000:03:00.0: BAR 4: no space for [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref] +kernel: pci 0000:03:00.0: BAR 1: no space for [mem size 0x00001000] +kernel: pci 0000:03:00.0: BAR 1: failed to assign [mem size 0x00001000] +kernel: virtio-pci 0000:03:00.0: virtio_pci: leaving for legacy driver""" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/745.toml b/gitlab/issues/target_i386/host_missing/accel_missing/745.toml new file mode 100644 index 000000000..c38bd7fe7 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/745.toml @@ -0,0 +1,44 @@ +id = 745 +title = "NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive" +state = "closed" +created_at = "2021-11-24T15:51:36.662Z" +closed_at = "2021-12-06T17:38:13.294Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/745" +host-os = "Pop!_OS 21.04 (Ubuntu / hirsute)" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 6.2.91 (v6.2.0-rc1-94-g35133781bd)" +guest-os = "N/A" +guest-arch = "x86_64" +description = """NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive.""" +reproduce = """Without hard drive: +1. Start VM as above ("without hard drive attached"), and enter EFI shell. +2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents. +3. Edit the contents of that variable. +4. Shutdown and restart the VM (cold reboot), and enter the EFI shell. +5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2. + +With hard drive: +1. Start VM as above ("with hard drive attached"), and enter EFI shell. +2. Navigate to the hard drive filesystem, e.g. FS0. +3. List the files in the filesystem. If NvVars exists, note the modification time. +4. Edit the contents of a NVRAM variable, e.g. Lang. +5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3.""" +additional = """OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf) + +Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command `reset`. + +I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default. + +Without HDD attached, before cold reboot: + + +Without HDD attached, after cold reboot: + + +With HDD attached (note modification date / time of NvVars): + + +This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process. + +Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of).""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/752.toml b/gitlab/issues/target_i386/host_missing/accel_missing/752.toml new file mode 100644 index 000000000..d60b4db7c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/752.toml @@ -0,0 +1,23 @@ +id = 752 +title = "vmmouse device gets attached twice, one without i8042 associated" +state = "closed" +created_at = "2021-11-28T22:53:30.554Z" +closed_at = "2021-12-20T04:46:00.143Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/752" +host-os = "Fedora 34" +host-arch = "amd64" +qemu-version = "6.1.92 (v6.2.0-rc1-96-gdd4b0de459)" +guest-os = "Windows, MS-DOS" +guest-arch = "i386" +description = """I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too. + +[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is: + +* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time +* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler +* obviously, a crash because ISAKBDDevice should never be null""" +reproduce = """1. Load VMware mouse driver +2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading) +3. Crash""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/77.toml b/gitlab/issues/target_i386/host_missing/accel_missing/77.toml new file mode 100644 index 000000000..08dc7a5fc --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/77.toml @@ -0,0 +1,15 @@ +id = 77 +title = "msmouse not recognized in guest" +state = "closed" +created_at = "2021-05-01T17:58:54.894Z" +closed_at = "2023-02-06T09:16:51.716Z" +labels = ["Launchpad", "device:input", "hostos: Windows", "kind::Bug", "target: i386", "workflow::In Progress"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/77" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/770.toml b/gitlab/issues/target_i386/host_missing/accel_missing/770.toml new file mode 100644 index 000000000..1d57e00b1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/770.toml @@ -0,0 +1,15 @@ +id = 770 +title = "READ memory access in /hw/acpi/pcihp.c" +state = "closed" +created_at = "2021-12-12T15:03:49.510Z" +closed_at = "2022-01-08T04:59:35.867Z" +labels = ["Fuzzer", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/770" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/771.toml b/gitlab/issues/target_i386/host_missing/accel_missing/771.toml new file mode 100644 index 000000000..67315483e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/771.toml @@ -0,0 +1,22 @@ +id = 771 +title = "No interrupts are delivered to the guest after rebooting Windows 98" +state = "opened" +created_at = "2021-12-13T16:30:39.299Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/771" +host-os = "Debian" +host-arch = "x86-64" +qemu-version = "QEMU emulator version 6.1.0 (Debian 1:6.1+dfsg-8+b1)" +guest-os = "Windows 98 Second Edition (the issue can be reproduced with the first edition as well)" +guest-arch = "x86-32" +description = """After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts. The guest performs fine before the reboot. + +Closer examination reveals that no hardware interrupts are delivered to the guest. BIOS Data Area variables like the keyboard buffer and the system clock are not updated. Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor. + +The only remedy seems to be to exit the QEMU process entirely and launch it again.""" +reproduce = """0. Install Windows 98 into the guest. (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.) +1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load. (I managed sometimes to reproduce the bug without the system having loaded fully.) +2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent) +3. Observe the system freeze.""" +additional = """None""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/78.toml b/gitlab/issues/target_i386/host_missing/accel_missing/78.toml new file mode 100644 index 000000000..817b6069a --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/78.toml @@ -0,0 +1,15 @@ +id = 78 +title = "msmouse serial mouse emulation broken? No id byte sent on reset" +state = "opened" +created_at = "2021-05-01T17:59:02.052Z" +closed_at = "n/a" +labels = ["Launchpad", "device:input", "hostos: Windows", "kind::Bug", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/78" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/780.toml b/gitlab/issues/target_i386/host_missing/accel_missing/780.toml new file mode 100644 index 000000000..e976951ba --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/780.toml @@ -0,0 +1,62 @@ +id = 780 +title = "qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race" +state = "opened" +created_at = "2021-12-16T15:46:30.683Z" +closed_at = "n/a" +labels = ["Migration", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/780" +host-os = "(Redhat.)" +host-arch = "(x86)" +qemu-version = "( QEMU emulator version 6.2.91 (v6.2.0-rc1-25-g44a3aa06))" +guest-os = "AMD(Linux)" +guest-arch = "(x86)" +description = """machine under continuous pressure, at the end of the migration phase. +Libvirtd construction exception at the same time. +In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread; + +While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush. +If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock""" +reproduce = """1.migrate the machine and let machine under continuous pressure; +2.gdb to qemu and make break point to virtio_blk_data_plane_stop; +3.when hit virtio_blk_data_plane_stop, kill libvirtd; +4.let live_migration thread to poll job_exit""" +additional = """``` +#0 0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112 +#1 0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#2 0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778 +#3 0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073 +#4 0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335 +#5 0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676 +#6 0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516 +#7 0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203 +#8 0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776 +#9 0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804 +#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680 +#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758 +#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873 +#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118 +#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71 +#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985 +#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050 +#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172 +#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040 +#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145 +#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948 +#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980 +#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305 +#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247 +#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423 +#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196 +#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130 +#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207 +#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267 +#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976 +#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039 +#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571 +#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801 +#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519 +#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486 +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/786.toml b/gitlab/issues/target_i386/host_missing/accel_missing/786.toml new file mode 100644 index 000000000..950e4272c --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/786.toml @@ -0,0 +1,25 @@ +id = 786 +title = "assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)" +state = "closed" +created_at = "2021-12-20T05:28:18.092Z" +closed_at = "2022-01-08T04:59:35.425Z" +labels = ["ACPI", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/786" +host-os = "Arch linux" +host-arch = "x86" +qemu-version = "6.2.0" +guest-os = "Windows 10 21H1" +guest-arch = "x86" +description = """assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. + +The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant. + +The assert with -acpitable is a regression since it worked with version 6.1.0 + +The actual error message in qemu 6.2.0 is + +qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen)""" +reproduce = """1. +2. +3.""" +additional = """""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/791.toml b/gitlab/issues/target_i386/host_missing/accel_missing/791.toml new file mode 100644 index 000000000..b9e06d788 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/791.toml @@ -0,0 +1,15 @@ +id = 791 +title = "unable to execute QEMU command - SGX VM using libvirtd" +state = "opened" +created_at = "2021-12-23T10:57:58.795Z" +closed_at = "n/a" +labels = ["target: i386", "workflow::Confirmed"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/791" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/810.toml b/gitlab/issues/target_i386/host_missing/accel_missing/810.toml new file mode 100644 index 000000000..e243b4ae2 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/810.toml @@ -0,0 +1,79 @@ +id = 810 +title = "i386/sev: Crash in pc_system_parse_ovmf_flash caused by bad firmware file" +state = "opened" +created_at = "2022-01-11T13:06:26.582Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/810" +host-os = "Ubuntu 20.04.1" +host-arch = "x86_64 (with AMD SEV)" +qemu-version = "6.2.50 (v6.2.0-240-g212a33d3b0)" +guest-os = "-" +guest-arch = "x86_64 with AMD SEV" +description = """A specially-crafted flash file can cause the `memcpy()` call in +`pc_system_parse_ovmf_flash` (`hw/i386/pc_sysfw_ovmf.c`) to READ out-of-bounds +memory, because there's no check on the `tot_len` field which is read +from the flash file. In such case, `ptr - tot_len` will point to a +memory location *below* `flash_ptr` (hence the out-of-bounds read). + +This path is only taken when SEV is enabled (which requires +KVM and x86_64).""" +reproduce = """1. Create `bad_ovmf.fd` using the following python script: + ``` + from uuid import UUID + OVMF_TABLE_FOOTER_GUID = "96b582de-1fb2-45f7-baea-a366c55a082d" + b = bytearray(4096) + b[4046:4048] = b'\\xff\\xff' # tot_len field + b[4048:4064] = UUID("{" + OVMF_TABLE_FOOTER_GUID + "}").bytes_le + with open("bad_ovmf.fd", "wb") as f: + f.write(b) + ``` +2. Build QEMU with `--enable-sanitizers` +3. Start QEMU with SEV and the bad flash file: + ``` + qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \\ + -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \\ + -machine confidential-guest-support=sev0 \\ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0 + ``` +4. QEMU crashes with: `SUMMARY: AddressSanitizer: stack-buffer-underflow`""" +additional = """Crash example: + +``` +$ sudo build/qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \\ + -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \\ + -machine confidential-guest-support=sev0 \\ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0 +==523314==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==523314==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f05305fb180 at pc 0x7f0548d89480 bp 0x7ffed44a1980 sp 0x7ffed44a1128 +READ of size 65517 at 0x7f05305fb180 thread T0 + #0 0x7f0548d8947f (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f) + #1 0x556127c3331e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 + #2 0x556127c3331e in pc_system_parse_ovmf_flash ../hw/i386/pc_sysfw_ovmf.c:82 + #3 0x556127c21a0c in pc_system_flash_map ../hw/i386/pc_sysfw.c:203 + #4 0x556127c21a0c in pc_system_firmware_init ../hw/i386/pc_sysfw.c:258 + #5 0x556127c1ddd9 in pc_memory_init ../hw/i386/pc.c:902 + #6 0x556127bdc387 in pc_q35_init ../hw/i386/pc_q35.c:207 + #7 0x5561273bfdd6 in machine_run_board_init ../hw/core/machine.c:1181 + #8 0x556127f77de1 in qemu_init_board ../softmmu/vl.c:2652 + #9 0x556127f77de1 in qmp_x_exit_preconfig ../softmmu/vl.c:2740 + #10 0x556127f7f24d in qemu_init ../softmmu/vl.c:3775 + #11 0x556126f947ac in main ../softmmu/main.c:49 + #12 0x7f05470e80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + #13 0x556126fa639d in _start (/home/dmurik/git/qemu/build/qemu-system-x86_64+0x2a5739d) + +Address 0x7f05305fb180 is located in stack of thread T3 at offset 0 in frame + #0 0x556128a96f1f in qemu_sem_timedwait ../util/qemu-thread-posix.c:293 + + + This frame has 1 object(s): + [32, 48) 'ts' (line 295) <== Memory access at offset 0 partially underflows this variable +HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork + (longjmp and C++ exceptions *are* supported) +Thread T3 created by T0 here: + #0 0x7f0548d28805 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a805) + #1 0x556128a97ecf in qemu_thread_create ../util/qemu-thread-posix.c:596 + +SUMMARY: AddressSanitizer: stack-buffer-underflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f) +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/837.toml b/gitlab/issues/target_i386/host_missing/accel_missing/837.toml new file mode 100644 index 000000000..2af3ee599 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/837.toml @@ -0,0 +1,40 @@ +id = 837 +title = "x86 user: icebp/int1 raises wrong signal" +state = "closed" +created_at = "2022-01-24T05:02:44.865Z" +closed_at = "2022-03-15T04:43:46.057Z" +labels = ["Closed::WontFix", "linux-user", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/837" +host-os = "MX Linux 21/Debian 11" +host-arch = "x86_64" +qemu-version = "6.2.0" +guest-os = "linux-user" +guest-arch = "i386, x86_64" +description = """This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. + +Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. + +This also happens on an AArch64 host. +``` +$ ./icebp +Trace/breakpoint trap +$ qemu-x86_64 ./icebp +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +```""" +reproduce = """1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 +``` + .globl _start +_start: + .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it +#ifdef __x86_64__ + mov $60, %eax + syscall +#else + mov $1, %eax + int $0x80 +#endif +``` +2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message +3. Run on qemu-user. Notice how it raises `SIGILL`.""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/855.toml b/gitlab/issues/target_i386/host_missing/accel_missing/855.toml new file mode 100644 index 000000000..c6fca9cfe --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/855.toml @@ -0,0 +1,25 @@ +id = 855 +title = "Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0" +state = "closed" +created_at = "2022-02-03T16:59:03.685Z" +closed_at = "2023-08-02T14:32:06.642Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/855" +host-os = "Ubuntu 21.10" +host-arch = "x86" +qemu-version = "6.0.0" +guest-os = "FreeBSD 10.0-RELEASE" +guest-arch = "x86" +description = """FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. +I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. +I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. +But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. +At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package. + +My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package. + +""" +reproduce = """1. Compile any version after the mentioned commit using the precompiled seabios binaries +2. Try to boot freebsd 10.0-RELEASE +3. Kernel panic because of a page vault during the vesa module load.""" +additional = """https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/871.toml b/gitlab/issues/target_i386/host_missing/accel_missing/871.toml new file mode 100644 index 000000000..2a78e0775 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/871.toml @@ -0,0 +1,24 @@ +id = 871 +title = "qemu-x86_64 don't support unshare(CLONE_NEWUSER)" +state = "opened" +created_at = "2022-02-14T10:04:43.103Z" +closed_at = "n/a" +labels = ["linux-user", "target: i386", "workflow::Triaged"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/871" +host-os = "Ubuntu 20.04" +host-arch = "x86" +qemu-version = "qemu-x86_64 -version" +guest-os = "n/a" +guest-arch = "n/a" +description = """Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +```""" +reproduce = """1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that?""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/877.toml b/gitlab/issues/target_i386/host_missing/accel_missing/877.toml new file mode 100644 index 000000000..0cc896c83 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/877.toml @@ -0,0 +1,114 @@ +id = 877 +title = "qemu-system-x86_64: Linux kernel warning when CONFIG_NUMA_EMU is enabled" +state = "opened" +created_at = "2022-02-15T18:53:50.985Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/877" +host-os = "Linux" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 6.2.0 (v6.2.0-dirty)`, commit `44f28df24767cf9dca1ddc9b23157737c4cbb645" +guest-os = "Linux" +guest-arch = "x86" +description = """When Linux kernel is run on qemu 6.2, it prints a warning when `NUMA_EMU` is used. When the same kernel is run on qemu 6.1.1 (`54e1f5be86dd11744e45da8be6afad01d01d59e7`) or earlier, no such warning is printed. + +``` +[ 0.341924] smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +[ 0.342371] Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only. +[ 0.343302] rcu: Hierarchical SRCU implementation. +[ 0.344470] smp: Bringing up secondary CPUs ... +[ 0.345349] x86: Booting SMP configuration: +[ 0.345945] .... node #1, CPUs: #1 +[ 0.014099] ------------[ cut here ]------------ +[ 0.014099] sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. +[ 0.014099] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/smpboot.c:423 topology_sane.isra.0+0x62/0x70 +[ 0.014099] Modules linked in: +[ 0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6 +[ 0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 +[ 0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70 +[ 0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f +[ 0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086 +[ 0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000 +[ 0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff +[ 0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff +[ 0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001 +[ 0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 0.014099] FS: 0000000000000000(0000) GS:ffffa335fdc00000(0000) knlGS:0000000000000000 +[ 0.014099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 0.014099] CR2: 0000000000000000 CR3: 0000000112a0c000 CR4: 00000000000006e0 +[ 0.014099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 0.014099] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 0.014099] Call Trace: +[ 0.014099] <TASK> +[ 0.014099] set_cpu_sibling_map+0x16a/0x560 +[ 0.014099] start_secondary+0x42/0xf0 +[ 0.014099] secondary_startup_64_no_verify+0xc2/0xcb +[ 0.014099] </TASK> +[ 0.014099] Kernel panic - not syncing: panic_on_warn set ... +[ 0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6 +[ 0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 +[ 0.014099] Call Trace: +[ 0.014099] <TASK> +[ 0.014099] dump_stack_lvl+0x34/0x44 +[ 0.014099] panic+0xef/0x2a6 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] __warn.cold+0x26/0x30 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] report_bug+0x9a/0xc0 +[ 0.014099] handle_bug+0x3c/0x60 +[ 0.014099] exc_invalid_op+0x14/0x70 +[ 0.014099] asm_exc_invalid_op+0x12/0x20 +[ 0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70 +[ 0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f +[ 0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086 +[ 0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000 +[ 0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff +[ 0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff +[ 0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001 +[ 0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] set_cpu_sibling_map+0x16a/0x560 +[ 0.014099] start_secondary+0x42/0xf0 +[ 0.014099] secondary_startup_64_no_verify+0xc2/0xcb +[ 0.014099] </TASK> +[ 0.014099] ---[ end Kernel panic - not syncing: panic_on_warn set ... ]--- +```""" +reproduce = """1. Check out the Linux kernel: +``` +git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git +cd linux-stable +git checkout v5.16.9 +``` +2. Generate the configuration file: +``` +make defconfig +./scripts/config -e NUMA_EMU -e CMDLINE_BOOL --set-str CMDLINE "numa=fake=2 panic_on_warn=1" -d CONFIG_CMDLINE_OVERRIDE +``` +3. Build the kernel +``` +make -j32 +``` +4. Run qemu and wait for a couple of seconds: +``` +./qemu-system-x86_64 -m 4G -smp 2 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot +```""" +additional = """With explicit NUMA configuration, it boots fine: +``` +./qemu-system-x86_64 -m 4G -smp 2 -object memory-backend-ram,size=8G,id=m0 -numa node,cpus=0-1,nodeid=0,memdev=m0 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot +``` + +On the host machine: +``` +$ numactl -H +available: 2 nodes (0-1) +node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 +node 0 size: 95259 MB +node 0 free: 1767 MB +node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 +node 1 size: 96757 MB +node 1 free: 2407 MB +node distances: +node 0 1 + 0: 10 21 + 1: 21 10 +```""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/91.toml b/gitlab/issues/target_i386/host_missing/accel_missing/91.toml new file mode 100644 index 000000000..1d513da72 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/91.toml @@ -0,0 +1,15 @@ +id = 91 +title = "RFE: Implement support for SMBIOS Type 41 structures" +state = "closed" +created_at = "2021-05-03T11:19:57.521Z" +closed_at = "2022-08-16T07:17:39.100Z" +labels = ["Closed::Fixed", "Launchpad", "kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/91" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/921.toml b/gitlab/issues/target_i386/host_missing/accel_missing/921.toml new file mode 100644 index 000000000..cfe618de1 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/921.toml @@ -0,0 +1,633 @@ +id = 921 +title = "qemu 7.0-rc0 warning: cannot get sys attribute capabilities 0" +state = "closed" +created_at = "2022-03-20T11:08:29.433Z" +closed_at = "2022-11-18T08:52:30.630Z" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/921" +host-os = "(Windows 10 21H1, Fedora 34, etc.)" +host-arch = "(x86, ARM, s390x, etc.)" +qemu-version = "(e.g. `qemu-system-x86_64 --version`)" +guest-os = "(Windows 10 21H1, Fedora 34, etc.)" +guest-arch = "x86_64" +description = """The guest fp not working properly""" +reproduce = """1. Start the docker +``` +docker run -it --name qemu --rm \\ + --privileged \\ + --ipc=host \\ + -v /dev/log:/dev/log \\ + -v /dev/vhost-net:/dev/vhost-net \\ + -v /sys/kernel/debug:/sys/kernel/debug \\ + -v $ROOT:$ROOT \\ + -p 2222:22 \\ + -p 1234:1234 \\ + -p 1235:1235 \\ + -e ROOT=$ROOT \\ + -e XDG_RUNTIME_DIR=/tmp \\ + -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \\ + -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \\ + qemu +``` +2.This is in the docker +``` ++ build/docker/qemu-system-x86_64 -enable-kvm -M q35 -smp 1 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::22-:22,hostfwd=tcp::1234-:1234 -hda /data/xemu-opengl/image/ubuntu.qcow2 -initrd /data/xemu-opengl/image/rootfs.cpio.gz -kernel /data/xemu-opengl/kernel/arch/x86_64/boot/bzImage -append 'root=/dev/sda3 nokaslr' -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -device virtio-vga-gl,context_init=true,blob=true,hostmem=1G -vga none -display sdl,gl=on,show-cursor=on -d guest_errors +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 1] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 2] +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +``` + +3. In geust +``` +dmesg +[ 0.000000] Linux version 5.16.14 (root@5bc45822eca9) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Sun Mar 13 23:24:16 UTC 2022 +[ 0.000000] Command line: root=/dev/sda3 nokaslr +[ 0.000000] x86/fpu: FP/SSE not present amongst the CPU's xstate features: 0x1. +[ 0.000000] signal: max sigframe size: 1440 +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffddfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007ffde000-0x000000007fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 +[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000000] last_pfn = 0x180000 max_arch_pfn = 0x400000000 +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.000000] last_pfn = 0x7ffde max_arch_pfn = 0x400000000 +[ 0.000000] found SMP MP-table at [mem 0x000f5b70-0x000f5b7f] +[ 0.000000] Using GB pages for direct mapping +[ 0.000000] RAMDISK: [mem 0x7ffcf000-0x7ffcffff] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F5980 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000007FFE22CB 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000007FFE20C3 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000007FFE0040 002083 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000007FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000007FFE21B7 000078 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000007FFE222F 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: MCFG 0x000000007FFE2267 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: WAET 0x000000007FFE22A3 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x7ffe20c3-0x7ffe21b6] +[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x7ffe0040-0x7ffe20c2] +[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x7ffe0000-0x7ffe003f] +[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x7ffe21b7-0x7ffe222e] +[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x7ffe222f-0x7ffe2266] +[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x7ffe2267-0x7ffe22a2] +[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x7ffe22a3-0x7ffe22ca] +[ 0.000000] No NUMA configuration found +[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff] +[ 0.000000] NODE_DATA(0) allocated [mem 0x17fffa000-0x17fffdfff] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] +[ 0.000000] Normal [mem 0x0000000100000000-0x000000017fffffff] +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] +[ 0.000000] node 0: [mem 0x0000000000100000-0x000000007ffddfff] +[ 0.000000] node 0: [mem 0x0000000100000000-0x000000017fffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000017fffffff] +[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA: 97 pages in unavailable ranges +[ 0.000000] On node 0, zone Normal: 34 pages in unavailable ranges +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] ACPI: Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] TSC deadline timer available +[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x7ffde000-0x7fffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x80000000-0xafffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xb0000000-0xbfffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xc0000000-0xfed1bfff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfeffbfff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfeffc000-0xfeffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xfffbffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfffc0000-0xffffffff] +[ 0.000000] [mem 0xc0000000-0xfed1bfff] available for PCI devices +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns +[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1 +[ 0.000000] percpu: Embedded 52 pages/cpu s174744 r8192 d30056 u2097152 +[ 0.000000] pcpu-alloc: s174744 r8192 d30056 u2097152 alloc=1*2097152 +[ 0.000000] pcpu-alloc: [0] 0 +[ 0.000000] Fallback order for Node 0: 0 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1031902 +[ 0.000000] Policy zone: Normal +[ 0.000000] Kernel command line: root=/dev/sda3 nokaslr +[ 0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space. +[ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.000000] Memory: 4019736K/4193776K available (16398K kernel code, 2621K rwdata, 5052K rodata, 1252K init, 1332K bss, 173784K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +[ 0.000000] Dynamic Preempt: full +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU event tracing is enabled. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 +[ 0.000000] NR_IRQS: 4352, nr_irqs: 256, preallocated irqs: 16 +[ 0.000000] random: get_random_bytes called from start_kernel+0x492/0x65f with crng_init=0 +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] printk: console [tty0] enabled +[ 0.000000] ACPI: Core revision 20210930 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.001000] APIC: Switch to symmetric I/O mode setup +[ 0.002000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.010000] tsc: Unable to calibrate against PIT +[ 0.011000] tsc: using HPET reference calibration +[ 0.012000] tsc: Detected 3699.687 MHz processor +[ 0.000260] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6aa85c29371, max_idle_ns: 881590506582 ns +[ 0.001636] Calibrating delay loop (skipped), value calculated using timer frequency.. 7399.37 BogoMIPS (lpj=3699687) +[ 0.002617] pid_max: default: 32768 minimum: 301 +[ 0.003888] LSM: Security Framework initializing +[ 0.004744] SELinux: Initializing. +[ 0.006672] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +[ 0.007869] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +[ 0.014682] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.016974] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.017603] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.018602] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.018623] Spectre V2 : Mitigation: Retpolines +[ 0.019603] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.020637] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.021603] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl +[ 0.083192] Freeing SMP alternatives memory: 44K +[ 0.086287] smpboot: CPU0: AMD Ryzen Threadripper 3970X 32-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.088185] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.088635] ... version: 0 +[ 0.089365] ... bit width: 48 +[ 0.089610] ... generic registers: 6 +[ 0.090332] ... value mask: 0000ffffffffffff +[ 0.090611] ... max period: 00007fffffffffff +[ 0.091424] ... fixed-purpose events: 0 +[ 0.091614] ... event mask: 000000000000003f +[ 0.092889] rcu: Hierarchical SRCU implementation. +[ 0.095245] smp: Bringing up secondary CPUs ... +[ 0.095612] smp: Brought up 1 node, 1 CPU +[ 0.096340] smpboot: Max logical packages: 1 +[ 0.096609] smpboot: Total of 1 processors activated (7399.37 BogoMIPS) +[ 0.169912] devtmpfs: initialized +[ 0.175284] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns +[ 0.175676] futex hash table entries: 256 (order: 2, 16384 bytes, linear) +[ 0.177611] PM: RTC time: 10:29:46, date: 2022-03-20 +[ 0.183040] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 0.187536] audit: initializing netlink subsys (disabled) +[ 0.191857] thermal_sys: Registered thermal governor 'step_wise' +[ 0.191877] thermal_sys: Registered thermal governor 'user_space' +[ 0.192675] audit: type=2000 audit(1647772186.201:1): state=initialized audit_enabled=0 res=1 +[ 0.194185] cpuidle: using governor menu +[ 0.198008] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.198662] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.200081] PCI: Using configuration type 1 for base access +[ 0.204517] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible. +[ 0.205408] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.206698] ACPI: Added _OSI(Module Device) +[ 0.207453] ACPI: Added _OSI(Processor Device) +[ 0.207610] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.208402] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.208611] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.209375] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.209614] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.212597] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.215363] ACPI: Interpreter enabled +[ 0.215779] ACPI: PM: (supports S0 S3 S4 S5) +[ 0.216543] ACPI: Using IOAPIC for interrupt routing +[ 0.216649] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.217739] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 0.221429] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.221679] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.222638] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 0.223563] acpi PNP0A08:00: _OSC: OS now controls [PME PCIeCapability] +[ 0.223907] PCI host bridge to bus 0000:00 +[ 0.224612] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.225562] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.225610] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.226616] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.227610] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.228611] pci_bus 0000:00: root bus resource [mem 0x180000000-0x97fffffff window] +[ 0.229611] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.230749] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.233477] pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000 +[ 0.234636] pci 0000:00:01.0: reg 0x10: [io 0xc040-0xc05f] +[ 0.236087] pci 0000:00:01.0: reg 0x14: [mem 0xfebd0000-0xfebd0fff] +[ 0.239084] pci 0000:00:01.0: reg 0x20: [mem 0x1c0000000-0x1c0003fff 64bit pref] +[ 0.240327] pci 0000:00:01.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +[ 0.242540] pci 0000:00:02.0: [1af4:1050] type 00 class 0x030000 +[ 0.245344] pci 0000:00:02.0: reg 0x10: [mem 0xfe000000-0xfe7fffff pref] +[ 0.247587] pci 0000:00:02.0: reg 0x14: [mem 0xfebd1000-0xfebd1fff] +[ 0.250649] pci 0000:00:02.0: reg 0x18: [mem 0x1c0004000-0x1c0007fff 64bit pref] +[ 0.253628] pci 0000:00:02.0: reg 0x20: [mem 0x180000000-0x1bfffffff 64bit pref] +[ 0.256753] pci 0000:00:02.0: reg 0x30: [mem 0xfebc0000-0xfebcffff pref] +[ 0.258570] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] +[ 0.263325] pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300 +[ 0.265363] pci 0000:00:1d.0: reg 0x20: [io 0xc060-0xc07f] +[ 0.266765] pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300 +[ 0.269437] pci 0000:00:1d.1: reg 0x20: [io 0xc080-0xc09f] +[ 0.270732] pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300 +[ 0.273371] pci 0000:00:1d.2: reg 0x20: [io 0xc0a0-0xc0bf] +[ 0.274696] pci 0000:00:1d.7: [8086:293a] type 00 class 0x0c0320 +[ 0.276035] pci 0000:00:1d.7: reg 0x10: [mem 0xfebd2000-0xfebd2fff] +[ 0.279317] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.280866] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.282331] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.284903] pci 0000:00:1f.2: reg 0x20: [io 0xc0c0-0xc0df] +[ 0.286143] pci 0000:00:1f.2: reg 0x24: [mem 0xfebd3000-0xfebd3fff] +[ 0.287991] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.290370] pci 0000:00:1f.3: reg 0x20: [io 0x0700-0x073f] +[ 0.293435] ACPI: PCI: Interrupt link LNKA configured for IRQ 10 +[ 0.293726] ACPI: PCI: Interrupt link LNKB configured for IRQ 10 +[ 0.294744] ACPI: PCI: Interrupt link LNKC configured for IRQ 11 +[ 0.295723] ACPI: PCI: Interrupt link LNKD configured for IRQ 11 +[ 0.296740] ACPI: PCI: Interrupt link LNKE configured for IRQ 10 +[ 0.297763] ACPI: PCI: Interrupt link LNKF configured for IRQ 10 +[ 0.298722] ACPI: PCI: Interrupt link LNKG configured for IRQ 11 +[ 0.299743] ACPI: PCI: Interrupt link LNKH configured for IRQ 11 +[ 0.300662] ACPI: PCI: Interrupt link GSIA configured for IRQ 16 +[ 0.301579] ACPI: PCI: Interrupt link GSIB configured for IRQ 17 +[ 0.301618] ACPI: PCI: Interrupt link GSIC configured for IRQ 18 +[ 0.302625] ACPI: PCI: Interrupt link GSID configured for IRQ 19 +[ 0.303570] ACPI: PCI: Interrupt link GSIE configured for IRQ 20 +[ 0.303617] ACPI: PCI: Interrupt link GSIF configured for IRQ 21 +[ 0.304524] ACPI: PCI: Interrupt link GSIG configured for IRQ 22 +[ 0.304617] ACPI: PCI: Interrupt link GSIH configured for IRQ 23 +[ 0.307401] iommu: Default domain type: Translated +[ 0.307611] iommu: DMA domain TLB invalidation policy: lazy mode +[ 0.309801] pci 0000:00:02.0: vgaarb: setting as boot VGA device +[ 0.310602] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none +[ 0.310612] pci 0000:00:02.0: vgaarb: bridge control possible +[ 0.311469] vgaarb: loaded +[ 0.312823] SCSI subsystem initialized +[ 0.314995] libata version 3.00 loaded. +[ 0.315348] ACPI: bus type USB registered +[ 0.315984] usbcore: registered new interface driver usbfs +[ 0.316671] usbcore: registered new interface driver hub +[ 0.317497] usbcore: registered new device driver usb +[ 0.317760] pps_core: LinuxPPS API ver. 1 registered +[ 0.318568] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.318672] PTP clock support registered +[ 0.320169] Advanced Linux Sound Architecture Driver Initialized. +[ 0.322001] NetLabel: Initializing +[ 0.322614] NetLabel: domain hash size = 128 +[ 0.323353] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.323799] NetLabel: unlabeled traffic allowed by default +[ 0.324864] PCI: Using ACPI for IRQ routing +[ 0.486511] PCI: pci_cache_line_size set to 64 bytes +[ 0.487017] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff] +[ 0.487056] e820: reserve RAM buffer [mem 0x7ffde000-0x7fffffff] +[ 0.488868] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 +[ 0.489610] hpet0: 3 comparators, 64-bit 100.000000 MHz counter +[ 0.493993] clocksource: Switched to clocksource tsc-early +[ 0.595279] VFS: Disk quotas dquot_6.6.0 +[ 0.604747] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 0.606192] pnp: PnP ACPI init +[ 0.607564] system 00:05: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.612917] pnp: PnP ACPI: found 6 devices +[ 0.630876] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.635819] NET: Registered PF_INET protocol family +[ 0.639137] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 0.648315] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear) +[ 0.649938] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.656731] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear) +[ 0.668799] TCP: Hash tables configured (established 32768 bind 32768) +[ 0.670725] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear) +[ 0.675922] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear) +[ 0.677641] NET: Registered PF_UNIX/PF_LOCAL protocol family +[ 0.683489] RPC: Registered named UNIX socket transport module. +[ 0.684419] RPC: Registered udp transport module. +[ 0.685233] RPC: Registered tcp transport module. +[ 0.686051] RPC: Registered tcp NFSv4.1 backchannel transport module. +[ 0.690218] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.691147] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.692046] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.695623] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.702621] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.703550] pci_bus 0000:00: resource 9 [mem 0x180000000-0x97fffffff window] +[ 0.709679] ACPI: \\_SB_.GSIA: Enabled at IRQ 16 +[ 0.711527] ACPI: \\_SB_.GSIB: Enabled at IRQ 17 +[ 0.717245] ACPI: \\_SB_.GSIC: Enabled at IRQ 18 +[ 0.718745] ACPI: \\_SB_.GSID: Enabled at IRQ 19 +[ 0.720153] PCI: CLS 0 bytes, default 64 +[ 0.725883] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.726841] software IO TLB: mapped [mem 0x000000007bfcf000-0x000000007ffcf000] (64MB) +[ 0.728264] Unpacking initramfs... +[ 0.744075] Freeing initrd memory: 4K +[ 0.756363] Initialise system trusted keyrings +[ 0.758663] workingset: timestamp_bits=56 max_order=20 bucket_order=0 +[ 0.764972] NFS: Registering the id_resolver key type +[ 0.767942] Key type id_resolver registered +[ 0.768863] Key type id_legacy registered +[ 0.770030] 9p: Installing v9fs 9p2000 file system support +[ 0.775964] Key type asymmetric registered +[ 0.776761] Asymmetric key parser 'x509' registered +[ 0.777862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) +[ 0.779862] io scheduler mq-deadline registered +[ 0.780675] io scheduler kyber registered +[ 0.782859] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 0.787721] ACPI: button: Power Button [PWRF] +[ 0.791799] ACPI: \\_SB_.GSIF: Enabled at IRQ 21 +[ 0.795895] ACPI: \\_SB_.GSIG: Enabled at IRQ 22 +[ 0.802029] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled +[ 0.803727] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 0.806289] Non-volatile memory driver v1.3 +[ 0.807110] Linux agpgart interface v0.103 +[ 0.808280] ACPI: bus type drm_connector registered +[ 0.810106] [drm] pci: virtio-vga detected at 0000:00:02.0 +[ 0.811033] virtio-pci 0000:00:02.0: vgaarb: deactivate vga console +[ 0.812950] Console: switching to colour dummy device 80x25 +[ 0.814010] [drm] Host memory window: 0x180000000 +0x40000000 +[ 0.814014] [drm] features: +virgl +edid +resource_blob +host_visible +[ 0.814015] [drm] features: +context_init +[ 0.815749] [drm] number of scanouts: 1 +[ 0.815764] [drm] number of cap sets: 1 +[ 0.822421] [drm] cap set 0: id 4, max-version 0, max-size 20 +[ 0.823816] [drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0 +[ 0.835655] loop: module loaded +[ 0.836198] ahci 0000:00:1f.2: version 3.0 +[ 0.838738] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode +[ 0.838743] ahci 0000:00:1f.2: flags: 64bit ncq only +[ 0.844268] scsi host0: ahci +[ 0.845062] scsi host1: ahci +[ 0.845675] scsi host2: ahci +[ 0.846482] scsi host3: ahci +[ 0.847257] scsi host4: ahci +[ 0.847860] scsi host5: ahci +[ 0.848240] ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 27 +[ 0.848266] ata2: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3180 irq 27 +[ 0.848281] ata3: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3200 irq 27 +[ 0.848295] ata4: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3280 irq 27 +[ 0.848310] ata5: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3300 irq 27 +[ 0.848324] ata6: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3380 irq 27 +[ 0.854343] e100: Intel(R) PRO/100 Network Driver +[ 0.854365] e100: Copyright(c) 1999-2006 Intel Corporation +[ 0.854401] e1000: Intel(R) PRO/1000 Network Driver +[ 0.854403] e1000: Copyright (c) 1999-2006 Intel Corporation. +[ 0.854505] e1000e: Intel(R) PRO/1000 Network Driver +[ 0.854506] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +[ 0.854562] sky2: driver version 1.30 +[ 0.855224] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.855227] ehci-pci: EHCI PCI platform driver +[ 0.856209] ehci-pci 0000:00:1d.7: EHCI Host Controller +[ 0.856447] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 1 +[ 0.857195] ehci-pci 0000:00:1d.7: irq 19, io mem 0xfebd2000 +[ 0.863684] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00 +[ 0.863941] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.16 +[ 0.863946] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.863948] usb usb1: Product: EHCI Host Controller +[ 0.863950] usb usb1: Manufacturer: Linux 5.16.14 ehci_hcd +[ 0.863952] usb usb1: SerialNumber: 0000:00:1d.7 +[ 0.864286] hub 1-0:1.0: USB hub found +[ 0.864294] hub 1-0:1.0: 6 ports detected +[ 0.864919] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.864953] ohci-pci: OHCI PCI platform driver +[ 0.865050] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.865658] uhci_hcd 0000:00:1d.0: UHCI Host Controller +[ 0.865792] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 +[ 0.866072] uhci_hcd 0000:00:1d.0: irq 16, io port 0x0000c060 +[ 0.866256] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.866259] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.866262] usb usb2: Product: UHCI Host Controller +[ 0.866263] usb usb2: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.866265] usb usb2: SerialNumber: 0000:00:1d.0 +[ 0.866537] hub 2-0:1.0: USB hub found +[ 0.866542] hub 2-0:1.0: 2 ports detected +[ 0.867382] uhci_hcd 0000:00:1d.1: UHCI Host Controller +[ 0.867567] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 +[ 0.867827] uhci_hcd 0000:00:1d.1: irq 17, io port 0x0000c080 +[ 0.868033] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.868037] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.868039] usb usb3: Product: UHCI Host Controller +[ 0.868040] usb usb3: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.868042] usb usb3: SerialNumber: 0000:00:1d.1 +[ 0.868240] hub 3-0:1.0: USB hub found +[ 0.868245] hub 3-0:1.0: 2 ports detected +[ 0.869174] uhci_hcd 0000:00:1d.2: UHCI Host Controller +[ 0.869321] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 +[ 0.869553] uhci_hcd 0000:00:1d.2: irq 18, io port 0x0000c0a0 +[ 0.869959] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.869963] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.869965] usb usb4: Product: UHCI Host Controller +[ 0.870002] usb usb4: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.870003] usb usb4: SerialNumber: 0000:00:1d.2 +[ 0.870149] hub 4-0:1.0: USB hub found +[ 0.870153] hub 4-0:1.0: 2 ports detected +[ 0.870910] usbcore: registered new interface driver usblp +[ 0.870991] usbcore: registered new interface driver usb-storage +[ 0.871112] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 +[ 0.873033] serio: i8042 KBD port at 0x60,0x64 irq 1 +[ 0.873240] serio: i8042 AUX port at 0x60,0x64 irq 12 +[ 0.874086] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 +[ 0.878739] rtc_cmos 00:04: RTC can wake from S4 +[ 0.880210] rtc_cmos 00:04: registered as rtc0 +[ 0.880321] rtc_cmos 00:04: alarms up to one day, y3k, 242 bytes nvram, hpet irqs +[ 0.880886] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt +[ 0.881236] i2c i2c-0: 1/1 memory slots populated (from DMI) +[ 0.881239] i2c i2c-0: Memory type 0x07 not supported yet, not instantiating SPD +[ 0.881737] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com +[ 0.882038] hid: raw HID events driver (C) Jiri Kosina +[ 0.882495] usbcore: registered new interface driver usbhid +[ 0.882498] usbhid: USB HID core driver +[ 0.890838] Initializing XFRM netlink socket +[ 0.891351] NET: Registered PF_INET6 protocol family +[ 0.893594] Segment Routing with IPv6 +[ 0.893647] In-situ OAM (IOAM) with IPv6 +[ 0.893870] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver +[ 0.894342] NET: Registered PF_PACKET protocol family +[ 0.894821] 9pnet: Installing 9P2000 support +[ 0.894914] Key type dns_resolver registered +[ 0.895481] IPI shorthand broadcast: enabled +[ 0.895672] sched_clock: Marking stable (908022380, -12397814)->(1044483817, -148859251) +[ 0.895978] registered taskstats version 1 +[ 0.895980] Loading compiled-in X.509 certificates +[ 0.897126] cryptomgr_test (53) used greatest stack depth: 15480 bytes left +[ 0.897149] cryptomgr_test (54) used greatest stack depth: 15448 bytes left +[ 0.898086] cryptomgr_test (69) used greatest stack depth: 15392 bytes left +[ 0.900491] PM: Magic number: 14:469:477 +[ 0.901051] printk: console [netcon0] enabled +[ 0.901053] netconsole: network logging started +[ 0.901456] cfg80211: Loading compiled-in X.509 certificates for regulatory database +[ 0.903159] kworker/u2:6 (76) used greatest stack depth: 14656 bytes left +[ 0.903680] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' +[ 0.903771] ALSA device list: +[ 0.903773] No soundcards found. +[ 0.904412] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 +[ 0.904450] cfg80211: failed to load regulatory.db +[ 1.094640] usb 1-1: new high-speed USB device number 2 using ehci-pci +[ 1.146521] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) +[ 1.146780] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 +[ 1.146785] ata1.00: 33554432 sectors, multi 16: LBA48 NCQ (depth 32) +[ 1.146810] ata1.00: applying bridge limits +[ 1.147076] ata1.00: configured for UDMA/100 +[ 1.147318] ata2: SATA link down (SStatus 0 SControl 300) +[ 1.154178] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) +[ 1.154371] ata3.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 +[ 1.154375] ata3.00: applying bridge limits +[ 1.154673] ata3.00: configured for UDMA/100 +[ 1.155258] ata4: SATA link down (SStatus 0 SControl 300) +[ 1.155530] ata5: SATA link down (SStatus 0 SControl 300) +[ 1.155833] ata6: SATA link down (SStatus 0 SControl 300) +[ 1.157704] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 +[ 1.158268] sd 0:0:0:0: [sda] 33554432 512-byte logical blocks: (17.2 GB/16.0 GiB) +[ 1.158307] sd 0:0:0:0: [sda] Write Protect is off +[ 1.158309] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 +[ 1.158316] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 1.158993] sd 0:0:0:0: Attached scsi generic sg0 type 0 +[ 1.165858] scsi 2:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 1.175815] sda: sda1 sda2 sda3 +[ 1.176475] sd 0:0:0:0: [sda] Attached SCSI disk +[ 1.181093] sr 2:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[ 1.181149] cdrom: Uniform CD-ROM driver Revision: 3.20 +[ 1.197445] sr 2:0:0:0: Attached scsi CD-ROM sr0 +[ 1.197689] sr 2:0:0:0: Attached scsi generic sg1 type 5 +[ 1.224877] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 +[ 1.224885] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=10 +[ 1.224887] usb 1-1: Product: QEMU USB Tablet +[ 1.224889] usb 1-1: Manufacturer: QEMU +[ 1.224891] usb 1-1: SerialNumber: 28754-0000:00:1d.7-1 +[ 1.231334] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4 +[ 1.231474] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0 +[ 1.484028] random: fast init done +[ 1.486085] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 +[ 1.486277] md: Waiting for all devices to be available before autodetect +[ 1.486280] md: If you don't use raid, use raid=noautodetect +[ 1.486308] md: Autodetecting RAID arrays. +[ 1.486310] md: autorun ... +[ 1.486311] md: ... autorun DONE. +[ 1.489760] EXT4-fs (sda3): INFO: recovery required on readonly filesystem +[ 1.489764] EXT4-fs (sda3): write access will be enabled during recovery +[ 1.549515] EXT4-fs (sda3): recovery complete +[ 1.551218] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. +[ 1.551395] VFS: Mounted root (ext4 filesystem) readonly on device 8:3. +[ 1.552185] devtmpfs: mounted +[ 1.564828] Freeing unused kernel image (initmem) memory: 1252K +[ 1.565429] Write protecting the kernel read-only data: 24576k +[ 1.588472] Freeing unused kernel image (text/rodata gap) memory: 2032K +[ 1.599305] Freeing unused kernel image (rodata/data gap) memory: 1092K +[ 1.600131] Run /sbin/init as init process +[ 1.600145] with arguments: +[ 1.600145] /sbin/init +[ 1.600145] nokaslr +[ 1.600146] with environment: +[ 1.600146] HOME=/ +[ 1.600146] TERM=linux +[ 1.719163] systemd[1]: systemd 248.3-1ubuntu8.2 running in system mode. (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) +[ 1.719924] systemd[1]: Detected virtualization kvm. +[ 1.719999] systemd[1]: Detected architecture x86-64. +[ 1.721691] systemd[1]: Hostname set to <lygstate-Standard-PC-Q35-ICH9-2009>. +[ 1.742316] (sd-executor) (84) used greatest stack depth: 13744 bytes left +[ 1.747792] tsc: Refined TSC clocksource calibration: 3699.944 MHz +[ 1.747936] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6aaa423949d, max_idle_ns: 881591081251 ns +[ 1.748220] clocksource: Switched to clocksource tsc +[ 1.804055] friendly-recove (87) used greatest stack depth: 13736 bytes left +[ 1.857049] openvpn-generat (89) used greatest stack depth: 13672 bytes left +[ 1.857104] ls (104) used greatest stack depth: 13616 bytes left +[ 2.049195] systemd[1]: Queued start job for default target Graphical Interface. +[ 2.053399] systemd[1]: Created slice system-modprobe.slice. +[ 2.055075] systemd[1]: Created slice system-systemd\\x2dfsck.slice. +[ 2.055330] systemd[1]: Created slice User and Session Slice. +[ 2.055443] systemd[1]: Started Forward Password Requests to Wall Directory Watch. +[ 2.057210] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. +[ 2.057325] systemd[1]: Reached target User and Group Name Lookups. +[ 2.057352] systemd[1]: Reached target Remote File Systems. +[ 2.057371] systemd[1]: Reached target Slices. +[ 2.057397] systemd[1]: Reached target Local Verity Integrity Protected Volumes. +[ 2.058182] systemd[1]: Listening on Syslog Socket. +[ 2.058530] systemd[1]: Listening on fsck to fsckd communication Socket. +[ 2.058768] systemd[1]: Listening on initctl Compatibility Named Pipe. +[ 2.059725] systemd[1]: Listening on Journal Audit Socket. +[ 2.059946] systemd[1]: Listening on Journal Socket (/dev/log). +[ 2.060156] systemd[1]: Listening on Journal Socket. +[ 2.060815] systemd[1]: Listening on udev Control Socket. +[ 2.060970] systemd[1]: Listening on udev Kernel Socket. +[ 2.065155] systemd[1]: Mounting Huge Pages File System... +[ 2.069417] systemd[1]: Mounting POSIX Message Queue File System... +[ 2.079658] systemd[1]: Mounting Kernel Debug File System... +[ 2.082741] systemd[1]: Mounting Kernel Trace File System... +[ 2.083848] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling. +[ 2.083853] systemd[1]: (This warning is only shown for the first unit using IP firewalling.) +[ 2.089029] systemd[1]: Starting Journal Service... +[ 2.275345] systemd[1]: Starting Set the console keyboard layout... +[ 2.331794] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped. +[ 2.373032] systemd[1]: Starting Load Kernel Module configfs... +[ 2.390012] systemd[1]: Starting Load Kernel Module drm... +[ 2.401425] systemd[1]: Starting Load Kernel Module fuse... +[ 2.418703] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. +[ 2.420064] systemd[1]: Starting File System Check on Root Device... +[ 2.432087] systemd[1]: Starting Load Kernel Modules... +[ 2.452273] systemd[1]: Starting Coldplug All udev Devices... +[ 2.468269] systemd[1]: Starting Uncomplicated firewall... +[ 2.518424] systemd[1]: Mounted Huge Pages File System. +[ 2.518764] systemd[1]: Mounted POSIX Message Queue File System. +[ 2.518974] systemd[1]: Mounted Kernel Debug File System. +[ 2.519140] systemd[1]: Mounted Kernel Trace File System. +[ 2.530711] systemd[1]: modprobe@configfs.service: Deactivated successfully. +[ 2.531730] systemd[1]: Finished Load Kernel Module configfs. +[ 2.538860] systemd[1]: modprobe@drm.service: Deactivated successfully. +[ 2.544760] systemd[1]: Finished Load Kernel Module drm. +[ 2.545030] systemd[1]: modprobe@fuse.service: Deactivated successfully. +[ 2.546685] systemd[1]: Finished Load Kernel Module fuse. +[ 2.546931] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE +[ 2.546980] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. +[ 2.549652] systemd[1]: Failed to start Load Kernel Modules. +[ 2.552638] systemd[1]: Finished Uncomplicated firewall. +[ 2.553148] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 2.553189] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. +[ 2.557719] systemd[1]: Started File System Check Daemon to report status. +[ 2.566265] systemd[1]: Starting Apply Kernel Variables... +[ 2.579756] systemd[1]: Started Journal Service. +[ 2.641573] random: crng init done +[ 2.718179] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro. Quota mode: none. +[ 2.732681] Adding 752916k swap on /swapfile. Priority:-2 extents:3 across:769300k +[ 2.733844] swapon (132) used greatest stack depth: 13568 bytes left +[ 2.735312] systemd-journald[110]: Received client request to flush runtime journal. +[ 2.743169] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/system.journal corrupted or uncleanly shut down, renaming and replacing. +[ 2.811309] loop0: detected capacity change from 0 to 203424 +[ 2.815025] loop1: detected capacity change from 0 to 126632 +[ 2.815152] loop2: detected capacity change from 0 to 8 +[ 2.827343] loop3: detected capacity change from 0 to 307976 +[ 2.841748] loop0: detected capacity change from 0 to 133552 +[ 2.843903] loop4: detected capacity change from 0 to 496320 +[ 2.847378] loop1: detected capacity change from 0 to 111048 +[ 2.914163] journal-offline (149) used greatest stack depth: 13344 bytes left +[ 3.788267] virtio_net virtio0 enp0s1: renamed from eth0 +[ 9.114766] language-option (340) used greatest stack depth: 12992 bytes left +[ 12.965077] loop0: detected capacity change from 0 to 8 +[ 15.602770] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/user-1000.journal corrupted or uncleanly shut down, renaming and replacing. +[ 19.878209] virtio_gpu virtio1: [drm] drm_plane_enable_fb_damage_clips() not called +[ 313.191235] loop0: detected capacity change from 0 to 8 +[ 334.252458] loop0: detected capacity change from 0 to 126760 +[ 336.575589] loop0: detected capacity change from 0 to 226664 +[ 613.230337] loop0: detected capacity change from 0 to 8 +[ 660.444496] kworker/dying (50) used greatest stack depth: 12400 bytes left +[ 809.013491] clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 65260ns +[ 809.013577] clocksource: wd-tsc-wd read-back delay of 1983150ns, clock-skew test skipped! +[ 913.163318] loop0: detected capacity change from 0 to 8 +[ 1213.159179] loop0: detected capacity change from 0 to 8 +[ 1513.151818] loop0: detected capacity change from 0 to 8 +[ 1813.150457] loop0: detected capacity change from 0 to 8 +```""" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/928.toml b/gitlab/issues/target_i386/host_missing/accel_missing/928.toml new file mode 100644 index 000000000..25c2dd78e --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/928.toml @@ -0,0 +1,92 @@ +id = 928 +title = "QEMU/TCG generates #GP instead #SS for RBP/RSP based faults" +state = "opened" +created_at = "2022-03-22T17:37:55.341Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/928" +host-os = "Debian 11.2" +host-arch = "x86-64" +qemu-version = "QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1); also current git: QEMU emulator version 6.2.90 (v7.0.0-rc0-59-g5791de9d4874)" +guest-os = "Debian" +guest-arch = "x86-64" +description = """Setting RSP/RBP to a non-canonical address and trying to access a memory location based on RSP/RBP generates a #GP under QEMU/TCG while it should generate an #SS exception instead. This difference in behavior triggers a [Xen selftest](https://github.com/xen-project/xen/blob/1145d94c738e/xen/arch/x86/extable.c#L142-L144) violation as can be seen below. + +- A successful run should look like this, e.g. when run under KVM: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #SS[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +``` + +- Under QEMU/TCG it triggers this scary warning: + +``` +(XEN) Running stub recovery selftests... +(XEN) Fixup #UD[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +(XEN) Fixup #GP[0000]: ffff82d07fffe040 [ffff82d07fffe040] -> ffff82d04038b9e7 +(XEN) Selftest 2 failed: Opc 02 04 04 c3 expected 12[0000], got 13[0000] +(XEN) Fixup #BP[0000]: ffff82d07fffe041 [ffff82d07fffe041] -> ffff82d04038b9e7 +[...] +(XEN) *************************************************** +(XEN) SELFTEST FAILURE: CORRECT BEHAVIOR CANNOT BE GUARANTEED +(XEN) *************************************************** +(XEN) 3... 2... 1... +```""" +reproduce = """The attached program ([noncanon.c](/uploads/34599a2fe23c6bbf1e9efd8cb8704537/noncanon.c)) generates the following output when run on native hardware or under KVM: + +```shell-session +minipli@bell:~$ for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGBUS, signo 7, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGBUS, signo 7, error 0, code 128, addr (nil) +``` + +However, when run under QEMU using TCG, I get the following output: + +```shell-session +root@box:~# for i in "" -sp -bp; do ./noncanon $i; done +Non-canonical acces via RAX: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RSP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +Non-canonical acces via RBP: SIGSEGV, signo 11, error 0, code 128, addr (nil) +``` + +Please note how RSP/RBP based access generates SIGSEGV instead of the expected SIGBUS.""" +additional = """The problem seems to be that QEMU always generates a #GP for non-canonical addresses, while it should differentiate, based on the register that led to the non-canonical address: #SS if RSP/RBP is involved, #GP otherwise. However, short of an instruction decoder, I don't see how this can easily be told apart. + +```diff +diff --git a/target/i386/tcg/sysemu/excp_helper.c b/target/i386/tcg/sysemu/excp_helper.c +index e1b6d8868338..ac4a6351a49d 100644 +--- a/target/i386/tcg/sysemu/excp_helper.c ++++ b/target/i386/tcg/sysemu/excp_helper.c +@@ -386,6 +386,7 @@ static int handle_mmu_fault(CPUState *cs, vaddr addr, int size, + sext = (int64_t)addr >> (pg_mode & PG_MODE_LA57 ? 56 : 47); + if (sext != 0 && sext != -1) { + env->error_code = 0; ++ // XXX: or EXCP0C_STACK for SP/BP bassed error + cs->exception_index = EXCP0D_GPF; + return 1; + } +``` + +Relevant excerpt from the Intel SDM: + +> **6.15 EXCEPTION AND INTERRUPT REFERENCE** +> [...] +> **Interrupt 12—Stack Fault Exception (#SS)** +> [...] +> - A canonical violation is detected in 64-bit mode during an operation that reference memory using the stack pointer register containing a non-canonical memory address. + +Please note the lack of mentioning the base pointer register, but tests on real hardware show it's subject to this as well. + +The AMD manual is more precise about that: +> **8.2.13 #SS—Stack Exception (Vector 12)** +> An #SS exception can occur in the following situations: +> - Implied stack references in which the stack address is not in canonical form. Implied stack references include all push and pop instructions, and any instruction using RSP or RBP as a base register +> [...] + +It explicitly mentions "any instruction using RSP or RBP as a base register".""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/930.toml b/gitlab/issues/target_i386/host_missing/accel_missing/930.toml new file mode 100644 index 000000000..e133f1864 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/930.toml @@ -0,0 +1,15 @@ +id = 930 +title = "Impossible to make windows 98 work on Qemu ver. 5.2" +state = "opened" +created_at = "2022-03-22T22:57:34.141Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/930" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/975.toml b/gitlab/issues/target_i386/host_missing/accel_missing/975.toml new file mode 100644 index 000000000..696bce819 --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/975.toml @@ -0,0 +1,46 @@ +id = 975 +title = "LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration" +state = "opened" +created_at = "2022-04-11T08:58:04.775Z" +closed_at = "n/a" +labels = ["target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/975" +host-os = "Ubuntu Jammy" +host-arch = "x86_64" +qemu-version = "QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu5) (and also custom build of 7.0.0-rc3)" +guest-os = "Ubuntu Focal" +guest-arch = "x86_64" +description = """""" +reproduce = """``` +sudo snap install --lxd +sudo lxd init --auto +lxc init images:ubuntu/20.04/cloud v1 --vm +Creating v1 +lxc config device override v1 root size.state=2GiB +Device root overridden for v1 +lxc config set v1 migration.stateful=true +lxc start v1 +sleep 10 +lxc exec v1 -- uptime + 22:05:54 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 +lxc snapshot v1 --stateful +Error: Migration call failed +lxc snapshot v1 --stateful +Error: Monitor is disconnected +``` + +The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output: + +``` +qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1) +``` + +The second attempt caused this: + +``` +qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +``` + +Which crashed QEMU completely and caused the VM to die. +Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue.""" +additional = """Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875""" diff --git a/gitlab/issues/target_i386/host_missing/accel_missing/990.toml b/gitlab/issues/target_i386/host_missing/accel_missing/990.toml new file mode 100644 index 000000000..541426fec --- /dev/null +++ b/gitlab/issues/target_i386/host_missing/accel_missing/990.toml @@ -0,0 +1,15 @@ +id = 990 +title = "support for vIOMMU and vSR-IOV together in L1 as virtual machine" +state = "opened" +created_at = "2022-04-17T15:05:01.276Z" +closed_at = "n/a" +labels = ["kind::Feature Request", "target: i386"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/990" +host-os = "n/a" +host-arch = "n/a" +qemu-version = "n/a" +guest-os = "n/a" +guest-arch = "n/a" +description = "n/a" +reproduce = "n/a" +additional = "n/a" |