[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?
This bug was fixed in the package qemu - 1:4.2-3ubuntu6.19 --- qemu (1:4.2-3ubuntu6.19) focal; urgency=medium * d/p/u/lp-1749393-linux-user-Reserve-space-for-brk.patch: fix static use cases needing a lot of brk space (LP: #1749393) * d/p/u/lp-1929926-target-s390x-Fix-translation-exception-on-illegal-in.patch: fix uretprobe in s390x TCG (LP: #1929926) -- Christian Ehrhardt Mon, 26 Apr 2021 11:11:19 +0200 ** Changed in: qemu (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1749393 Title: sbrk() not working under qemu-user with a PIE-compiled binary? Status in QEMU: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Focal: Fix Released Bug description: [Impact] * The current space reserved can be too small and we can end up with no space at all for BRK. It can happen to any case, but is much more likely with the now common PIE binaries. * Backport the upstream fix which reserves a bit more space while loading and giving it back after interpreter and stack is loaded. [Test Plan] * On x86 run: sudo apt install -y qemu-user-static docker.io sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget' ... Running hooks in /etc/ca-certificates/update.d... done. Errors were encountered while processing: libc-bin E: Sub-process /usr/bin/dpkg returned an error code (1) Second test from bug 1928075 $ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64 http://ftp.debian.org/debian In the bad case this is failing like W: Failure trying to run: /sbin/ldconfig W: See //debootstrap/debootstrap.log for detail And in that log file you'll see the segfault $ tail -n 2 bullseye-arm64/debootstrap/debootstrap.log qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) [Where problems could occur] * Regressions would be around use-cases of linux-user that is emulation not of a system but of binaries. Commonly uses for cross-tests and cross-builds so that is the space to watch for regressions [Other Info] * n/a --- In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). $ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) bash has its own malloc implementation based on sbrk(): https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 You can find the problematic bash binary in that .deb file: http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb The version of qemu I have been using is 2.11 (Debian package qemu- user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). Here are the related Debian bug reports: https://bugs.debian.org/889869 https://bugs.debian.org/865599 It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1749393/+subscriptions
[Bug 1761798] Re: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8"
[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.] ** Changed in: nova Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1761798 Title: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8" Status in OpenStack Compute (nova): Expired Status in QEMU: Expired Bug description: Seen here: http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm- multinode-live- migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-0002.txt.gz 2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to /dev/pts/0 (label charserial0) warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] 2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8 2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load virtio-blk:virtio 2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for instance 0x0 of device ':00:04.0/virtio-blk' 2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: Operation not permitted 2018-04-05 21:48:43.198+: shutting down, reason=crashed And in the n-cpu logs on the other host: http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm- multinode-live-migration/8de6e74/logs/screen-n- cpu.txt.gz#_Apr_05_21_48_43_257541 There is a related Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1450524 The CI job failures are at present using the Pike UCA: ii libvirt-bin 3.6.0-1ubuntu6.2~cloud0 ii qemu-system-x86 1:2.10+dfsg-0ubuntu3.5~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1761798/+subscriptions
[Bug 1761798] Re: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8"
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1761798 Title: live migration intermittently fails in CI with "VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8" Status in OpenStack Compute (nova): Expired Status in QEMU: Expired Bug description: Seen here: http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm- multinode-live- migration/8de6e74/logs/subnode-2/libvirt/qemu/instance-0002.txt.gz 2018-04-05T21:48:38.205752Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on: char device redirected to /dev/pts/0 (label charserial0) warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] 2018-04-05T21:48:43.153268Z qemu-system-x86_64: VQ 0 size 0x80 Guest index 0x12c inconsistent with Host index 0x134: delta 0xfff8 2018-04-05T21:48:43.153288Z qemu-system-x86_64: Failed to load virtio-blk:virtio 2018-04-05T21:48:43.153292Z qemu-system-x86_64: error while loading state for instance 0x0 of device ':00:04.0/virtio-blk' 2018-04-05T21:48:43.153347Z qemu-system-x86_64: load of migration failed: Operation not permitted 2018-04-05 21:48:43.198+: shutting down, reason=crashed And in the n-cpu logs on the other host: http://logs.openstack.org/37/522537/20/check/legacy-tempest-dsvm- multinode-live-migration/8de6e74/logs/screen-n- cpu.txt.gz#_Apr_05_21_48_43_257541 There is a related Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1450524 The CI job failures are at present using the Pike UCA: ii libvirt-bin 3.6.0-1ubuntu6.2~cloud0 ii qemu-system-x86 1:2.10+dfsg-0ubuntu3.5~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1761798/+subscriptions
[Bug 1921664] Re: Coroutines are racy for risc64 emu on arm64 - crash on Assertion
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921664 Title: Coroutines are racy for risc64 emu on arm64 - crash on Assertion Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: Note: this could as well be "riscv64 on arm64" for being slow@slow and affect other architectures as well. The following case triggers on a Raspberry Pi4 running with arm64 on Ubuntu 21.04 [1][2]. It might trigger on other environments as well, but that is what we have seen it so far. $ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz $ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz $ ./run_riscvVM.sh (wait ~2 minutes) [ OK ] Reached target Local File Systems (Pre). [ OK ] Reached target Local File Systems. Starting udev Kernel Device Manager... qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed. This is often, but not 100% reproducible and the cases differ slightly we see either of: - qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed. - qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed. Rebuilding working cases has shown to make them fail, as well as rebulding (or even reinstalling) bad cases has made them work. Also the same builds on different arm64 CPUs behave differently. TL;DR: The full list of conditions influencing good/bad case here are not yet known. [1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview [2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz --- --- original report --- --- I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion: OpenSBI v0.6 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| ... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 618 bytes read in 2 ms (301.8 KiB/s) RISC-V Qemu Boot Options 1: Linux kernel-5.5.0-dirty 2: Linux kernel-5.5.0-dirty (recovery mode) Enter choice: 1:Linux kernel-5.5.0-dirty Retrieving file: /boot/initrd.img-5.5.0-dirty qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed. ./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated). Think you have everything already, but just in case: $ lsb_release -rd Description:Ubuntu Hirsute Hippo (development branch) Release:21.04 $ uname -a Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux (note this is a VM running on macOS/M1) $ apt-cache policy qemu qemu: Installed: 1:5.2+dfsg-9ubuntu1 Candidate: 1:5.2+dfsg-9ubuntu1 Version table: *** 1:5.2+dfsg-9ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: qemu 1:5.2+dfsg-9ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic aarch64 ApportVersion: 2.20.11-0ubuntu61 Architecture: arm64 CasperMD5CheckResult: unknown CurrentDmesg: Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie Error executing command as another user: Not authorized This incident has been reported. Date: Mon Mar 29 02:33:25 2021 Dependencies: KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND Lspci-vt: -[:00]-+-00.0 Apple Inc. Device f020 +-01.0 Red Hat, Inc. Virtio network device +-05.0
[Bug 1921664] Re: Coroutines are racy for risc64 emu on arm64 - crash on Assertion
[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] ** Changed in: qemu (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921664 Title: Coroutines are racy for risc64 emu on arm64 - crash on Assertion Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: Note: this could as well be "riscv64 on arm64" for being slow@slow and affect other architectures as well. The following case triggers on a Raspberry Pi4 running with arm64 on Ubuntu 21.04 [1][2]. It might trigger on other environments as well, but that is what we have seen it so far. $ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz $ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz $ ./run_riscvVM.sh (wait ~2 minutes) [ OK ] Reached target Local File Systems (Pre). [ OK ] Reached target Local File Systems. Starting udev Kernel Device Manager... qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed. This is often, but not 100% reproducible and the cases differ slightly we see either of: - qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed. - qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed. Rebuilding working cases has shown to make them fail, as well as rebulding (or even reinstalling) bad cases has made them work. Also the same builds on different arm64 CPUs behave differently. TL;DR: The full list of conditions influencing good/bad case here are not yet known. [1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview [2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz --- --- original report --- --- I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion: OpenSBI v0.6 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| ... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 618 bytes read in 2 ms (301.8 KiB/s) RISC-V Qemu Boot Options 1: Linux kernel-5.5.0-dirty 2: Linux kernel-5.5.0-dirty (recovery mode) Enter choice: 1:Linux kernel-5.5.0-dirty Retrieving file: /boot/initrd.img-5.5.0-dirty qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed. ./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated). Think you have everything already, but just in case: $ lsb_release -rd Description:Ubuntu Hirsute Hippo (development branch) Release:21.04 $ uname -a Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux (note this is a VM running on macOS/M1) $ apt-cache policy qemu qemu: Installed: 1:5.2+dfsg-9ubuntu1 Candidate: 1:5.2+dfsg-9ubuntu1 Version table: *** 1:5.2+dfsg-9ubuntu1 500 500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: qemu 1:5.2+dfsg-9ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic aarch64 ApportVersion: 2.20.11-0ubuntu61 Architecture: arm64 CasperMD5CheckResult: unknown CurrentDmesg: Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie Error executing command as another user: Not authorized This incident has been reported. Date: Mon Mar 29 02:33:25 2021 Dependencies: KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND Lspci-vt: -[:00]-+-00.0 Apple Inc. Device f020 +-01.0 Red Hat, Inc. Virtio network device
[Bug 1770417] Re: Qemu can not parse long fqdns during drive-mirror
[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] ** Changed in: qemu (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1770417 Title: Qemu can not parse long fqdns during drive-mirror Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: During migration of an openstack booted instance, I got the following error: Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud- mk.local:49153' A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939 To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block- operations.rst#id21. On dest and source compute nodes, I launched an instance: qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node- TargetDisk,driver=qcow2,file.driver=file,file.node- name=file,file.filename=./test-instance-mirror.qcow2 -device virtio- blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost: Then on dest node I launched nbd server: (qemu) nbd_server_start cmp0:49153 (qemu) nbd_server_add -w node-TargetDisk On the source node: (qemu) drive_mirror -n node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153' When using short host name instead of FQDN address seems to be parsed fine: (qemu) drive_mirror -n node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2 Image is not in qcow2 format (not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated) QEMU version is 2.11.1 from bionic To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1770417/+subscriptions
[Bug 1770417] Re: Qemu can not parse long fqdns during drive-mirror
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1770417 Title: Qemu can not parse long fqdns during drive-mirror Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: During migration of an openstack booted instance, I got the following error: Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud- mk.local:49153' A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939 To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block- operations.rst#id21. On dest and source compute nodes, I launched an instance: qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node- TargetDisk,driver=qcow2,file.driver=file,file.node- name=file,file.filename=./test-instance-mirror.qcow2 -device virtio- blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost: Then on dest node I launched nbd server: (qemu) nbd_server_start cmp0:49153 (qemu) nbd_server_add -w node-TargetDisk On the source node: (qemu) drive_mirror -n node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153' When using short host name instead of FQDN address seems to be parsed fine: (qemu) drive_mirror -n node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2 Image is not in qcow2 format (not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated) QEMU version is 2.11.1 from bionic To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1770417/+subscriptions
[Bug 1858814] Re: 'make -C roms efi' does not update edk2 submodules
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1858814 Title: 'make -C roms efi' does not update edk2 submodules Status in QEMU: Expired Bug description: On a fresh clone, 'make -C roms efi' fails because submodule is not initialized [1]: /builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(-1): error 000E: File/directory not found in workspace /builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/e_os.h - Failed - Laszlo suggested [2] it is possibly a regression from commit f3e330e3c319: "roms/Makefile.edk2: don't pull in submodules when building from tarball" [1] https://gitlab.com/philmd/qemu/-/jobs/395644357#L436 [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg668929.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1858814/+subscriptions
[Bug 1880763] Re: Missing page crossing check in use_goto_tb() for rx target
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1880763 Title: Missing page crossing check in use_goto_tb() for rx target Status in QEMU: Expired Bug description: Currently the rx target doesn't have the page crossing check in its use_goto_tb() function. This is a required feature for stable system mode emulations that all other targets implement. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1880763/+subscriptions
[Bug 1913668] Re: FPE in npcm7xx_pwm_calculate_freq
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1913668 Title: FPE in npcm7xx_pwm_calculate_freq Status in QEMU: Expired Bug description: Reproducer: cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ -accel qtest -qtest stdio write 0xf0103008 0x4 0x0900 write 0xf010300c 0x4 0x EOF Trace: ../hw/misc/npcm7xx_pwm.c:94:17: runtime error: division by zero SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_pwm.c:94:17 in AddressSanitizer:DEADLYSIGNAL = ==717868==ERROR: AddressSanitizer: FPE on unknown address 0x5597c7190150 (pc 0x5597c7190150 bp 0x7fffcb17c5d0 sp 0x7fffcb17c4e0 T0) #0 0x5597c7190150 in npcm7xx_pwm_calculate_freq /hw/misc/npcm7xx_pwm.c:94:17 #1 0x5597c7190150 in npcm7xx_pwm_update_freq /hw/misc/npcm7xx_pwm.c:122:21 #2 0x5597c718f06d in npcm7xx_pwm_write /hw/misc/npcm7xx_pwm.c #3 0x5597c8d241fe in memory_region_write_accessor /softmmu/memory.c:491:5 #4 0x5597c8d23bfb in access_with_adjusted_size /softmmu/memory.c:552:18 #5 0x5597c8d23467 in memory_region_dispatch_write /softmmu/memory.c #6 0x5597c90b3ffb in flatview_write_continue /softmmu/physmem.c:2759:23 #7 0x5597c90a971b in flatview_write /softmmu/physmem.c:2799:14 #8 0x5597c90a971b in address_space_write /softmmu/physmem.c:2891:18 #9 0x5597c8d11eee in qtest_process_command /softmmu/qtest.c:539:13 #10 0x5597c8d0eb97 in qtest_process_inbuf /softmmu/qtest.c:797:9 #11 0x5597c955f286 in fd_chr_read /chardev/char-fd.c:68:9 #12 0x7f994c124aae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) #13 0x5597c9bba363 in glib_pollfds_poll /util/main-loop.c:232:9 #14 0x5597c9bba363 in os_host_main_loop_wait /util/main-loop.c:255:5 #15 0x5597c9bba363 in main_loop_wait /util/main-loop.c:531:11 #16 0x5597c8c75599 in qemu_main_loop /softmmu/runstate.c:721:9 #17 0x5597c6f021fd in main /softmmu/main.c:50:5 #18 0x7f994bbc9cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 #19 0x5597c6e55bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913668/+subscriptions
[Bug 1878054] Re: Hang with high CPU usage in sdhci_data_transfer
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1878054 Title: Hang with high CPU usage in sdhci_data_transfer Status in QEMU: Expired Bug description: Hello, While fuzzing, I found an input that causes QEMU to hang with 100% CPU usage. I have waited several minutes, and QEMU is still unresponsive. Using gdb, It appears that it is stuck in an sdhci_data_transfer: #0 memory_region_access_valid (mr=, addr=0x10284920, size=, is_write=0xff, attrs=...) at /home/alxndr/Development/qemu/memory.c:1378 #1 memory_region_dispatch_write (mr=, addr=, data=, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1463 #2 flatview_write_continue (fv=, addr=0x10284920, attrs=..., ptr=, len=0xb7, addr1=0x582798e0, l=, mr=0x582798e0 ) at /home/alxndr/Development/qemu/exec.c:3137 #3 flatview_write (fv=0x60645da0, addr=, attrs=..., buf=, len=) at /home/alxndr/Development/qemu/exec.c:3177 #4 address_space_write (as=, addr=, attrs=..., buf=0xb04f325, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 #5 address_space_rw (as=0x572509ac , addr=0x582798e0, attrs=..., attrs@entry=..., buf=0xb04f325, len=0x4, is_write=0xb8, is_write@entry=0x1) at /home/alxndr/Development/qemu/exec.c:3278 #6 dma_memory_rw_relaxed (as=0x572509ac , addr=0x582798e0, buf=0xb04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:87 #7 dma_memory_rw (as=0x572509ac , addr=0x582798e0, buf=0xb04f325, len=0x4, dir=DMA_DIRECTION_FROM_DEVICE) at /home/alxndr/Development/qemu/include/sysemu/dma.h:110 #8 dma_memory_write (as=0x572509ac , addr=0x582798e0, buf=0xb04f325, len=0x4) at /home/alxndr/Development/qemu/include/sysemu/dma.h:122 #9 sdhci_sdma_transfer_multi_blocks (s=) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:618 #10 sdhci_data_transfer (opaque=0x61e21080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:891 #11 sdhci_send_command (s=0x61e21080) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:364 #12 sdhci_write (opaque=, offset=0xc, val=, size=) at /home/alxndr/Development/qemu/hw/sd/sdhci.c:1158 #13 memory_region_write_accessor (mr=, addr=, value=, size=, shift=, mask=, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 #14 access_with_adjusted_size (addr=, value=, size=, access_size_min=, access_size_max=, access_fn=, mr=0x61e219f0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 #15 memory_region_dispatch_write (mr=, addr=, data=0x1ffe0ff, op=, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 #16 flatview_write_continue (fv=, addr=0xe106800c, attrs=..., ptr=, len=0xff3, addr1=0x582798e0, l=, mr=0x61e219f0) at /home/alxndr/Development/qemu/exec.c:3137 #17 flatview_write (fv=0x60645da0, addr=, attrs=..., buf=, len=) at /home/alxndr/Development/qemu/exec.c:3177 #18 address_space_write (as=, addr=, attrs=..., attrs@entry=..., buf=0xb04f325, buf@entry=0x6218ad00, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 #19 qtest_process_command (chr=, chr@entry=0x5827c040 , words=) at /home/alxndr/Development/qemu/qtest.c:567 #20 qtest_process_inbuf (chr=0x5827c040 , inbuf=0x6190f640) at /home/alxndr/Development/qemu/qtest.c:710 I am attaching the qtest commands for reproducing it. I can reproduce it in a qemu 5.0 build using: qemu-system-i386 -M pc-q35-5.0 -qtest stdio -device sdhci-pci,sd-spec- version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic -serial none -monitor none < attachment Please let me know if I can provide any further info. -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1878054/+subscriptions
[Bug 721825] Re: VDI block driver bugs
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721825
Title:
VDI block driver bugs
Status in QEMU:
Expired
Bug description:
Chunqiang Tang reports the following issues with the VDI block driver,
these are present in QEMU 0.14:
"Bug 1. The most serious bug is caused by race condition in updating a new
bmap entry in memory and on disk. Considering the following operation
sequence.
O1: VM issues a write to sector X
O2: VDI allocates a new bmap entry and updates in-memory s->bmap
O3: VDI writes data to disk
O4: The disk I/O for writing sector X fails
O5: VDI reports error to VM and returns.
Note that the bmap entry is updated in memory, but not persisted on disk.
Now consider another write that immediately follows:
P1: VM issues a write to sector X+1, which locates in the same block as
the previously used sector X.
P2: s->bmap already has one entry for the block, and hence VDI writes
data directly without persisting the new s->bmap entry on disk.
P3: The write disk I/O succeeds
P4: VDI report success to VM, but the bitmap entry is still not
persisted on disk.
Now suppose the VM powers off gracefully (i.e., the QEMU process quits)
and reboots. The second write to sector X+1, which is reported as finished
successfully, is simply lost, because the corresponding in-memory s->bmap
entry is never persisted on disk. This is exactly what FVD's testing tool
discovers. After the block device is closed and then re-opened, disk
content verification fails.
This is just one example of the problem. Race condition plus host crash
also causes problems. Consider another example below.
Q1: VM issues a write to sector X
Q2: VDI allocates a new bmap entry and updates in-memory s->bmap
Q3: VDI writes sector X to disk and waits for the callback
Q4: VM issues a write to another sector X+1, which is in the same block
as sector X.
Q5: VDI sees the bitmap entry in s->bmap is already allocated, and
writes sector X+1 to disk.
Q6: Write to sector X+1 finishes, and VDI's callback is invoked.
Q7: VDI acknowledges to the VM the completion of writing sector X+1
Q8: After observing the completion of writing sector X+1, VM issues a
flush to ensure that sector X+1 is persisted on disk.
Q9: VDI finishes the flush and acknowledge the completion of the
operation.
Q10: ... (some other arbitrary operations, but the disk I/O for writing
sector X is still not finished)
Q11: The host crashes
Now the new bitmap entry is not persisted on disk, while both writing to
sector X+1 and the flush has been acknowledged as finished. Sector X+1 is
lost, which is a corruption. This problem exists even if it uses O_DSYNC.
The root cause of the problem is that, if a request updates in-memory
s->bmap, another request that sees this update assumes that the update is
already persisted on disk, which is not.
Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are
several cases of the code below on failure handling path without setting
error return code, which mistakenly reports failure as success. This
mistake is caught by FVD when doing image content validation.
if (acb->hd_aiocb == NULL) {
/* missing ret = -EIO; */
goto done;
}
Bug 3: Similar to the bugs the FVD testing tool found for QCOW2,
vdi_aio_cancel does not perform a complete clean up and there are several
related bugs. First, memory buffer is not freed, acb->orig_buf and
acb->block_buffer. Second, acb->bh is not cancelled. Third,
vdi_aio_setup() does not initialize acb->bh to NULL so that when a request
acb is cancelled and then later reused for another request, its acb->bh !=
NULL and the new request fails in vdi_schedule_bh(). This is caught by
FVD's testing tool, when it observes that no I/O failure is injected but
VDI reports a failed I/O request, which indicates a bug in the driver."
http://permalink.gmane.org/gmane.comp.emulators.qemu/94340
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/721825/+subscriptions
[Bug 1885350] Re: RISCV dynamic rounding mode is not behaving correctly
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1885350
Title:
RISCV dynamic rounding mode is not behaving correctly
Status in QEMU:
Expired
Bug description:
Hello,
I’ve gone through the RISC-V code in latest QEMU release
(qemu-5.0.0-rc2) and when checking the Floating point encodings I
found the rounding mode is only updated if the opcode field “rm” is
changed “ctx->frm == rm”. But according to RISC-V Volume I:
Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding
mode is set with frm value.
So for the same rm value (=7) and when changing frm value seeking
different rounding modes, and according to the below code, the
rounding mode won’t be updated. Please correct me if I got this
implementation wrong.
static void gen_set_rm(DisasContext *ctx, int rm)
{
TCGv_i32 t0;
if (ctx->frm == rm) {
return;
}
ctx->frm = rm;
t0 = tcg_const_i32(rm);
gen_helper_set_rounding_mode(cpu_env, t0);
tcg_temp_free_i32(t0);
}
My testcase:
I set statically the rm field in the instruction to 7 and before this
execution I changed the value of frm field in fcsr register. For the 1st time
it worked (according to the code above, the rm is updated so the round mode
will also be updated). But when changing fcsr register an re-execute the
instruction, there's no difference and the rounding mode is the same like the
previous frm value.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1885350/+subscriptions
[Bug 1886306] Re: qemu running slow when the window is in background
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886306 Title: qemu running slow when the window is in background Status in QEMU: Expired Bug description: Reported by on IRC: QEMU almost freezes when running with `GDK_BACKEND=x11` set and the parameter `gl=on` added to the `-display` option. GDK_BACKEND=x11 qemu-system-x86_64 -nodefaults -no-user-config -enable-kvm -machine q35 -cpu host -m 4G -display gtk,gl=on -vga std -usb -device usb-kbd -drive file=/tmp/Win10.qcow2,media=disk,format=qcow2 -drive file=~/Downloads/Win10_2004_EnglishInternational_x64.iso,media=cdrom Leaving out `GDK_BACKEND=x11` or `gl=on` fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886306/+subscriptions
[Bug 1924738] Re: Failed to restore domain - error load load virtio-balloon:virtio
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924738 Title: Failed to restore domain - error load load virtio-balloon:virtio Status in QEMU: Expired Bug description: I noticed a domain restore error on my virtual machines. I can't reproduce the error on a test virtual machine. sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated Please use server=on instead qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated Please use wait=off instead qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated Please use disable-ticketing=on instead 2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0x 2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio 2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device ':00:02.0/virtio-balloon' 2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted If in the machine configuration replace hvm to hvm the virtual machine is recovering normally To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924738/+subscriptions
[Bug 1926996] Re: qemu-user clone syscall fails
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1926996 Title: qemu-user clone syscall fails Status in QEMU: Expired Bug description: qemu-user fails to emulate clone() (https://linux.die.net/man/2/clone). The architecture doesn't seem to matter, tho I've mostly been testing aarch64. Attached is clone_test.c that demonstrates the problem. Running it natively looks like this: $ bin/x86_64/clone_test The variable was 9 clone returned 4177: 0 Success The variable is now 42 However, running it via qemu looks like: $ qemu-aarch64-static --version qemu-aarch64 version 5.2.0 (v5.2.0) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers $ qemu-aarch64-static bin/aarch64/clone_test The variable was 9 clone returned -1: 22 Invalid argument The variable is now 9 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1926996/+subscriptions
[Bug 1907952] Re: qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0
This bug was fixed in the package qemu - 1:6.0+dfsg-1~ubuntu3 --- qemu (1:6.0+dfsg-1~ubuntu3) impish; urgency=medium * d/p/u/lp-1935617-target-ppc-Fix-load-endianness-for-lxvwsx-lxvdsx.patch: fix TCG emulation for ppc64 (LP: #1935617) qemu (1:6.0+dfsg-1~ubuntu2) impish; urgency=medium * d/control: remove fuse2 trial-build (LP 1934510) qemu (1:6.0+dfsg-1~ubuntu1) impish; urgency=medium * Merge with Debian experimental, Among many other things this fixes LP Bugs: (LP: #1907952) broken arrow keys in -display gtk on aarch64 - qemu-kvm to systemd unit - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, hugepages and architecture specifics - d/qemu-system-common.qemu-kvm.service: systemd unit to call qemu-kvm-init - d/qemu-system-common.install: install helper script - d/qemu-system-common.qemu-kvm.default: defaults for /etc/default/qemu-kvm - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm - Distribution specific machine type (LP: 1304107 1621042 1776189 1761372 1761372 1776189) - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine types containing release versioned machine attributes - d/qemu-system-x86.NEWS Info on fixed machine type defintions for host-phys-bits=true - Add an info about -hpb machine type in debian/qemu-system-x86.NEWS - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type - Enable nesting by default - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default in qemu64 on amd [ No more strictly needed, but required for backward compatibility ] - improved dependencies - Make qemu-system-common depend on qemu-block-extra - Make qemu-utils depend on qemu-block-extra - Let qemu-utils recommend sharutils - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490) - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types reference 256k path - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to handle incoming migrations from former releases. - d/control-in: Disable capstone disassembler library support (universe) - d/qemu-system-x86.README.Debian: add info about updated nesting changes - d/control*, d/rules: disable xen by default, but provide universe package qemu-system-x86-xen as alternative [includes compat links changes of 5.0-5ubuntu4] - Fix upgrade module handling (LP 1905377) --enable-module-upgrades for qemu-xen which doesn't exist in Debian * Dropped Changes [in 6.0]: - d/p/ubuntu/lp-1907789-build-no-pie-is-no-functional-liker-flag.patch: fix ld usage of -no-pie (LP 1907789) - d/p/u/lp-1916230-hw-s390x-fix-build-for-virtio-9p-ccw.patch: fix virtio-9p-ccw being missing (LP 1916230) - d/p/u/lp-1916705-disas-Fix-build-with-glib2.0-2.67.3.patch: Fix FTFBS due to glib2.0 >=2.67.3 (LP 1916705) - d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails on some HW/Guest combinations e.g. Windows 10 on Threadripper chips (LP 1921754) - d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support (LP 1921880) - d/p/u/lp-1922010-linux-user-s390x-Use-the-guest-pointer-for-the-sigre*: fix go in qemu-s390x-static (LP 1922010) * Dropped Changes [in Debian]: - Allow qemu to load old modules post upgrade (LP 1847361) - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in - d/rules: Drop generating package version into maintainer scripts * Dropped Changes [No more needed >21.04]: - d/qemu-system-gui.prerm: add no-op prerm to overcome upgrade issues on the bad old prerm (LP 1906245 1905377) * Added Changes - Disable fuse export (universe dependency) - d/p/ubuntu/enable-svm-by-default.patch: update to match v6.0 - d/p/ubuntu/define-ubuntu-machine-types.patch: add ubuntu machine types for v6.0 - d/p/ubuntu/lp-1929926-*: avoid segfaults by uretprobes (LP: #1929926) - Ease the use of module retention on upgrades (LP: #1913421) - d/run-qemu.mount, d/rules: provide run-qemu.mount in qemu-block-extra - d/rules: only save modules if /run/qemu isn't noexec - d/rules: clear all (current and former) modules on purge - debian/qemu-block-extra.postinst: enable mount unit on install/upgrade - d/control: qemu 6.0 broke libvirt <7.2 add a breaks to avoid partial upgrade issues (LP: #1932264) - Enable SDL as secondary UI backend (LP: #1256185) - d/control: add build dependency libsdl2-dev - d/control: enable sdl graphics on build - d/qemu-system-gui.install: add ui-sdl.so - d/control: add runtime dependency to libgl1 - d/rules: qemu-system-x86-xen builds modules as well now (follows the other packages) qemu (1:6.0+dfsg-1~exp0) experimental;
[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: Expired Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1924987] Re: Storage | Two decimal digits precision
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924987 Title: Storage | Two decimal digits precision Status in QEMU: Expired Bug description: Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64 Hello. A two decimal digits precision is most appropriated on systems whose storage capacities have to be saved. That is one of the reason why such precision is supported in the context of creation of virtual machines in several Unix/Linux virtualization platforms; virt-manager is one of them. That last exhibits virtual disks size values with such precision – 128.00 GiB – nevertheless it lacks yet a mention illustrating physical disks size values. Storage values exhibited in qemu-img and virt-manager are already according to a clear format; thus, values are not attached to their measure units (#value# #units#). $ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n '2,4p' file format: qcow2 virtual size: 128 GiB (137438953472 bytes) disk size: 147 MiB To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924987/+subscriptions
[Bug 1925094] Re: DISCARD support for Crypto Block Devices
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1925094 Title: DISCARD support for Crypto Block Devices Status in QEMU: Expired Bug description: It appears that running `fstrim` or similar is useless when the VM is on a LUKS-encrypted device using QEMU's native LUKS support. Looking at the source, it seems that block/crypto.c lacks an implementation for bdrv_co_pdiscard, which probably needs to delegate to a per-crypto type discard helper. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1925094/+subscriptions
[Bug 1920934] Re: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920934 Title: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes Status in QEMU: Expired Bug description: qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0 We've encountered that booting the Linux kernel in TCG mode, results in a racy heap-use-after-free. The bug can be detected by ASan [A], but in the majority of runs results in a crashing kernel [B]. To reproduce, the following command line was used: $> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1 panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done The crashes in the kernel [B] appear to receive an interrupt in a code location where the instructions are periodically patched (via the jump_label infrastructure). [A]: = ==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 READ of size 8 at 0x6190007fef50 thread T4 [4.616506][T1] pci :00:02.0: reg 0x18: [mem 0xfebf-0xfebf0fff] [4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe pref] [4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02 [4.701540][T1] pci :00:03.0: reg 0x10: [mem 0xfebc-0xfebd] [4.711076][T1] pci :00:03.0: reg 0x14: [io 0xc000-0xc03f] [4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb pref] [4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444 #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 [4.820927][T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) #3 0x7f843cedf8dc ()
[Bug 1925109] Re: usbredirparser: bulk transfer length exceeds limits
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1925109 Title: usbredirparser: bulk transfer length exceeds limits Status in QEMU: Expired Bug description: 2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! 2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! 2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! host: Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 + guest: win10 20H2 usb device: Bus 002 Device 007: ID 0781:55ab SanDisk Corp. SanDisk 3.2Gen1 size 250G https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1925109/+subscriptions
[Bug 1926202] Re: qemu-user can't run some ppc binaries
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1926202 Title: qemu-user can't run some ppc binaries Status in QEMU: Expired Bug description: qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: $ uname -m x86_64 $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes $ docker build -t qemu-bug:centos -f Dockerfile.centos . $ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . $ qemu-ppc-static --version qemu-ppc version 5.2.95 (v6.0.0-rc5) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers $ qemu-ppc-static ./helloworld-centos.static.ppc emu: uncaught target signal 4 (Illegal instruction) - core dumped [1]16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1926202/+subscriptions
[Bug 1925966] Re: Win10 guest freezes randomly
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1925966 Title: Win10 guest freezes randomly Status in QEMU: Expired Bug description: In addition to bug #1916775, my Win10 Home guest freezes randomly and infrequently. Unlike bug #1916775, this is unrecoverable and I see on the host (Debian 4.19.171-2) via iotop that all disk IO has stopped. My only recourse is a hard reset of the guest. My setup uses PCI-pass-through graphics (GTX 1650), host cpu (Ryzen 7 3800XT). It seems to occur more frequently (every few hours) after switching from "kvm=off,vendor=GenuineIntel" to "kvm=on" and maybe using 3 monitors rather than 2 on the pass-through graphics card further increases frequency. The switch to "kvm=on" was necessary to enable nested virtualization, which now works. It occurs whether or not I use the qcow disk drive. qemu-system-x86_64 -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy -smp 8 -rtc clock=host,base=localtime -machine type=q35,accel=kvm,kernel_irqchip=on -enable-kvm -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd -m 32G -usb -device usb-tablet -vga none -serial none -parallel none -boot cd -nographic -device usb-host,vendorid=0x045e,productid=0x00db -device usb-host,vendorid=0x1bcf,productid=0x0005 -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on -device vfio-pci,host=09:00.1,addr=0x02.0x1 -device vfio-pci,host=09:00.2,addr=0x02.0x2 -device vfio-pci,host=09:00.3,addr=0x02.0x3 -netdev tap,id=netid,ifname=taplan,script=no,downscript=no -device e1000,netdev=netid,mac=52:54:00:01:02:03 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1925966/+subscriptions
[Bug 1926596] Re: qemu-monitor-event command gets stuck randomly
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1926596 Title: qemu-monitor-event command gets stuck randomly Status in QEMU: Expired Bug description: We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command For eg:- /usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process. Can you suggest how can we debug this further to find the actual issue. /usr/bin/virsh version Compiled against library: libvirt 4.5.0 Using library: libvirt 4.5.0 Using API: QEMU 4.5.0 Running hypervisor: QEMU 2.0.0 cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/; BUG_REPORT_URL="https://bugs.centos.org/; CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1926596/+subscriptions
[Bug 1926231] Re: SCSI passthrough of SATA cdrom -> errors & performance issues
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926231
Title:
SCSI passthrough of SATA cdrom -> errors & performance issues
Status in QEMU:
Expired
Bug description:
qemu 5.0, compiled from git
I am passing through a SATA cdrom via SCSI passthrough, with this
libvirt XML:
It seems to mostly work, I have written discs with it, except I am
getting errors that cause reads to take about 5x as long as they
should, under certain circumstances. It appears to be based on the
guest's read block size.
I found that if on the guest I run, say `dd if=$some_large_file
bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much
is being read by a factor of about 2. Also many kernel messages like
this happen on the guest:
[ 190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE cmd_age=0s
[ 190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command
[current]
[ 190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated
[ 190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00
00 80 00
[ 190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op
0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
If I change to bs=131072 the errors stop and performance is normal.
(262144 happens to be the block size ultimately used by md5sum, which
is how I got here)
I also ran strace on the qemu process while it was happening, and
noticed SG_IO calls like this:
21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S',
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10,
cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0,
dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO
21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S',
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10,
cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0,
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO
21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S',
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10,
cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0,
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO
[etc]
I suspect qemu is the culprit because I have tried a 4.19 guest kernel
as well as a 5.9 one, with the same result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926231/+subscriptions
[Bug 1922773] Re: RISCV32 illegal instruction exception
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1922773 Title: RISCV32 illegal instruction exception Status in QEMU: Expired Bug description: I'm running a machine learning model on qemu riscv32 and I ran into illegal instruction exception for some reason. I wasn't sure if this is a bug and if so whether it is related to zephyr or qemu, however I'll try to provide as much as information to get a better understanding. Here is the assembly code that I'm running: 0x8000bd74 <+0>: lw a4,0(a0) 0x8000bd76 <+2>: lw a5,8(a0) 0x8000bd78 <+4>: lw a0,0(a4) 0x8000bd7a <+6>: lw a1,0(a5) 0x8000bd7c <+8>: li a3,0 0x8000bd7e <+10>: j 0x8000bda4 0x8000bd80 <+12>: addia5,a3,-2 0x8000bd84 <+16>: li a2,27 0x8000bd86 <+18>: bgeua2,a5,0x8000bdae => 0x8000bd8a <+22>: fmv.w.x fa5,zero 0x8000bd8e <+26>: sllia5,a3,0x5 0x8000bd92 <+30>: add a5,a5,a4 0x8000bd94 <+32>: sllia5,a5,0x2 0x8000bd96 <+34>: add a5,a5,a1 0x8000bd98 <+36>: fsw fa5,0(a5) 0x8000bd9a <+38>: addia4,a4,1 0x8000bd9c <+40>: li a5,31 0x8000bd9e <+42>: bge a5,a4,0x8000bd80 0x8000bda2 <+46>: addia3,a3,1 0x8000bda4 <+48>: li a5,31 0x8000bda6 <+50>: blt a5,a3,0x8000bde0 0x8000bdaa <+54>: li a4,0 0x8000bdac <+56>: j 0x8000bd9c 0x8000bdae <+58>: li a5,1 0x8000bdb0 <+60>: bge a5,a4,0x8000bdd4 0x8000bdb4 <+64>: li a5,29 0x8000bdb6 <+66>: blt a5,a4,0x8000bdda 0x8000bdba <+70>: li a5,28 0x8000bdbc <+72>: mul a5,a3,a5 0x8000bdc0 <+76>: add a5,a5,a4 0x8000bdc2 <+78>: lui a2,0x4 0x8000bdc6 <+82>: addia2,a2,-58 # 0x3fc6 0x8000bdca <+86>: add a5,a5,a2 0x8000bdcc <+88>: sllia5,a5,0x2 0x8000bdce <+90>: add a5,a5,a0 0x8000bdd0 <+92>: flw fa5,0(a5) 0x8000bdd2 <+94>: j 0x8000bd8e 0x8000bdd4 <+96>: fmv.w.x fa5,zero 0x8000bdd8 <+100>: j 0x8000bd8e 0x8000bdda <+102>: fmv.w.x fa5,zero 0x8000bdde <+106>: j 0x8000bd8e 0x8000bde0 <+108>: li a0,0 0x8000bde2 <+110>: ret My code breaks on line 0x8000bd8a and then the mcause register is loaded with value 0x02 which translates to illegal instruction. Please let me know if you need more information about this. I also posted this on ZephyrProject in case it is related to the Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026 I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same code on qemu riscv64 and didn't have the same problem. Here is the assembly code that is generated for the same operation: => 0x8000b446 <+0>: ld a4,0(a0) 0x8000b448 <+2>: ld a5,8(a0) 0x8000b44a <+4>: ld a0,0(a4) 0x8000b44c <+6>: ld a1,0(a5) 0x8000b44e <+8>: li a3,0 0x8000b450 <+10>: j 0x8000b476 0x8000b452 <+12>: addiw a5,a3,-2 0x8000b456 <+16>: li a2,27 0x8000b458 <+18>: bgeua2,a5,0x8000b480 0x8000b45c <+22>: li a2,0 0x8000b460 <+26>: slliw a5,a3,0x5 0x8000b464 <+30>: addwa5,a5,a4 0x8000b466 <+32>: sllia5,a5,0x2 0x8000b468 <+34>: add a5,a5,a1 0x8000b46a <+36>: sw a2,0(a5) 0x8000b46c <+38>: addiw a4,a4,1 0x8000b46e <+40>: li a5,31 0x8000b470 <+42>: bge a5,a4,0x8000b452 0x8000b474 <+46>: addiw a3,a3,1 0x8000b476 <+48>: li a5,31 0x8000b478 <+50>: blt a5,a3,0x8000b4ac 0x8000b47c <+54>: li a4,0 0x8000b47e <+56>: j 0x8000b46e 0x8000b480 <+58>: li a5,1 0x8000b482 <+60>: bge a5,a4,0x8000b4a0 0x8000b486 <+64>: li a5,29 0x8000b488 <+66>: blt a5,a4,0x8000b4a6 0x8000b48c <+70>: li a5,28 0x8000b48e <+72>: mulwa5,a5,a3 0x8000b492 <+76>: addwa5,a5,a4 0x8000b494 <+78>: addiw a5,a5,-58 0x8000b498 <+82>: sllia5,a5,0x2 0x8000b49a <+84>: add a5,a5,a0 0x8000b49c <+86>: lw a2,0(a5) 0x8000b49e <+88>: j 0x8000b460 0x8000b4a0 <+90>: li a2,0 0x8000b4a4 <+94>: j 0x8000b460 0x8000b4a6 <+96>: li a2,0 0x8000b4aa <+100>: j 0x8000b460
[Bug 1926782] Re: configure script --extra-cflags not passed to config-meson.cross
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926782
Title:
configure script --extra-cflags not passed to config-meson.cross
Status in QEMU:
Expired
Bug description:
Since qemu 5.2, when building, the configure would not finish, but
would return this error instead:
qemu ../meson.build:852:2: ERROR: C header 'sasl/sasl.h' not found
This is for a cross build, and I invoke qemu with the --extra-cflags
and --extra-ldflags containing all the proper paths to the headers,
libraries etc. It worked properly with qemu 3.1 to 5.1.
After looking into the configure script, it seems that meson is passed
the CFLAGS environment variable instead of QEMU_CFLAGS, and only the
latter contains the --extra-cflags argument:
echo "c_args = [${CFLAGS:+$(meson_quote $CFLAGS)}]" >> $cross
Using the CFLAGS and LDFLAGS environment variable instead of --extra-
cflags and --extra-ldflags fixes the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926782/+subscriptions
[Bug 1926952] Re: SPICE support broken with 6.0
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1926952
Title:
SPICE support broken with 6.0
Status in QEMU:
Expired
Bug description:
Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE
for usb redirection Qemu won't start:
qemu-system-x86_64: The console requires display DMABUF support.
However just patching ui/console.c:
if (flags & GRAPHIC_FLAGS_DMABUF &&
!displaychangelistener_has_dmabuf(dcl)) {
error_setg(errp, "The console requires display DMABUF support.");
return false;
}
to always return true for dmabuf part works just fine:
if (flags & GRAPHIC_FLAGS_DMABUF &&
!displaychangelistener_has_dmabuf(dcl)) {
error_setg(errp, "The console requires display DMABUF support.");
return true;
}
This behavior wasn't in qemu 5.x version.
To reproduce this bug need to use:
/usr/bin/qemu-system-x86_64 \
-machine q35 \
-enable-kvm \
-no-user-config \
-nodefaults \
-no-hpet \
-display gtk,gl=on \
-device
pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1
\
-device
vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci:00/:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2
\
-spice port=5900,addr=127.0.0.1,disable-ticketing=on
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1926952/+subscriptions
[Bug 1926174] Re: Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1926174 Title: Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM Status in QEMU: Expired Bug description: This weekend I tried to get a CloudReady (Chrome OS) VM running on qemu 5.2. This seems to wok quite well, performance seems to be great in fact. Only problem is mouse input. Using SDL display, there is no visible mouse unless I set "show- cursor=on". After that the mouse pointer flickers a bit and most of the time is displaced so I need to press below a button in order to hit it. After switching to fullscreen and back using ctrl-alt-f this effect seems to be fixed for a while but the mouse pointer does not reach all parts of the emulated screen anymore. Using SPICE instead the mouse pointer is drawn, but it is *very* laggy. In fact it is only drawn every few seconds so it is unusable but placement seems to be correct. Text input is instant, so general emulation speed is not an issue here. To reproduce, download the free image from https://www.neverware.com/freedownload#home-edition-install Then run one of the following commands: qemu-system-x86_64 -drive driver=raw,file=cloudready- free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio- vga,virgl=on -display sdl,gl=on,show-cursor=on -usb -device usb-mouse -device intel-hda -device hda-duplex qemu-system-x86_64 -drive driver=raw,file=cloudready- free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio- vga,virgl=on -display spice-app,gl=on -usb -device usb-mouse -device intel-hda -device hda-duplex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1926174/+subscriptions
[Bug 1926497] Re: dp83932 stops working after a short while
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1926497 Title: dp83932 stops working after a short while Status in QEMU: Expired Bug description: Following the instructions here https://wiki.qemu.org/Documentation/Platforms/m68k I was able to successfully install debian. However, running apt-get update stalls after the first 1-2MB. root@debian:~# apt-get update Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] 18% [2 Packages 2,155 kB/8,735 kB 25%] After running apt-get update. I don't seem to be able to send any packets anymore. ping host lookups fail and a subsequent apt-get update makes no progress. I'm launching qemu with: qemu-system-m68k -boot c \ -M q800 -serial none -serial mon:stdio -m 1000M \ -net nic,model=dp83932 -net user \ -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ -kernel vmlinux-4.16.0-1-m68k \ -initrd initrd.img-4.16.0-1-m68k \ -drive file=m68k-deb10.qcow2,format=qcow2 \ -nographic I see this with qemu v6.0.0-rc5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1926497/+subscriptions
[Bug 1921082] Re: VM crash when process broadcast MCE
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921082 Title: VM crash when process broadcast MCE Status in QEMU: Expired Bug description: When i do memory SRAR test for VM, I meet the following issue: My VM has 16 vCPU, I will inject one UE error to memory which is accessed by VM, Then host MCE is raised and SIGBUS is send to VM, and qemu take control. Qemu will check the broadcast attribute by following cpu_x86_support_mca_broadcast(); Then Qemu may inject MCE to all vCPU, as vCPU is just one process for HOST, we can't guarantee all the vCPUs will enter MCE hander in 1S sync time, and the VM may panic. This issue will be easily fixed by expand monarch_timeout configuration, but the exact monarch_timeout can't be easily got, as it will depand on the num of vCPUs and current system schedule status. I am wondering why VM need broadcast attribute for MCE, When qeme process MCE event form host, it will always be signaled for one vCPU? If so, why does qemu need boradcast the MCE event to all vCPUs? Can weu just deliver LMCE to one specifc vCPU and make this behavior default? If anything wrong, Please point out. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1921082/+subscriptions
[Bug 1918084] Re: Build fails on macOS 11.2.2
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1918084 Title: Build fails on macOS 11.2.2 Status in QEMU: Expired Bug description: Hi, I got the latest version from git. I have pre-compiled the dependency libraries. All good. configure creates the necessary files. When I build I got the following error: [1368/6454] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o ninja: build stopped: subcommand failed. make[1]: *** [run-ninja] Error 1 make: *** [all] Error 2 I've ran make as make -j 8 original config: PKG_CONFIG_PATH="$SERVERPLUS_DIR/dependencies/glib/lib/pkgconfig:$SERVERPLUS_DIR/dependencies/pixman/lib/pkgconfig:$SERVERPLUS_DIR/dependencies/cyrus- sasl/lib/pkgconfig" ./configure --prefix="$SERVERPLUS_DIR" --enable- hvf --enable-cocoa --enable-vnc-sasl --enable-auth-pam --ninja=/opt/build/build/stage/tools/ninja/ninja --python="$SERVERPLUS_DIR/dependencies/python/bin/python3" --enable- bsd-user if I build with --target-list=x86_64-softmmu then it will build but I will get only the x86_64 QEMU built. With 5.0 I could build all emulators. $SERVERPLUS_DIR is my target dir. Thanks, Eddy To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1918084/+subscriptions
[Bug 1920211] Re: shrink option for discard (for bad host-filesystems and -backup solutions)
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920211 Title: shrink option for discard (for bad host-filesystems and -backup solutions) Status in QEMU: Expired Bug description: When using discard=unmap for virtio or scsi devices with QCOW2 images, space discarded by the guest will be unmaped on the host, which is basically great! This will turn the QCOW2 image into a sparse file which is efficient for most scenarios. But it may be that you need to avoid big sparse files on your host. For example because you need to use a backup solution which doesn't support sparse files well. Or maybe the QCOW2 image is on a filesystem mount which doesn't support sparse files at all. For those scenarios an alternative option for the discard setting (discard=shrink) would be great, so that the QCOW2 file itself gets shrunken again. I'm not sure about how the initial growing* of QCOW2 images is implemented and if there are maybe limitations. But I hope it may be possible do the inverse and actually shrink (not sparse) an QCOW2 image with internally discarded blocks. I'm using Qemu-5.2.0 and Linux >= 5.3 (host and guest). *If you use "qemu-img create -f qcow2 ..." withOUT the "preallocation" option. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920211/+subscriptions
[Bug 1918149] Re: qemu-user reports wrong fault_addr in signal handler
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1918149 Title: qemu-user reports wrong fault_addr in signal handler Status in QEMU: Expired Bug description: When a SEGV signal occurs and si_addr of the info struct is nil, qemu still tries to translate the address from host to guest (handle_cpu_signal in accel/tcg/user-exec.c). This means, that the actual signal handler, will receive a fault_addr that is something like 0xbf709000. I was able to get this to happen, by branching to a non canonical address on aarch64. I used 5.2 (commit: 553032db17). However, building from source, this only seems to happen, if I use the same configure flags as the debian build: ../configure --static --target-list=aarch64-linux-user --disable- system --enable-trace-backends=simple --disable-linux-io-uring --disable-pie --extra-cflags="-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --extra- ldflags="-Wl,-z,relro -Wl,--as-needed" Let me know, if you need more details. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1918149/+subscriptions
[Bug 1920871] Re: netperf UDP_STREAM high packet loss on QEMU tap network
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1920871 Title: netperf UDP_STREAM high packet loss on QEMU tap network Status in QEMU: Expired Bug description: Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge- helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 65507 10.00 144710 07583.56 212992 10.00 32 1.68 We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,x". I can got: Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 65507 10.00 18351 0 961.61 212992 10.00 18350961.56 most of UDP packets are recived. And If we check the tap qemu used, we can see: ifconfig tap0 tap0: flags=4419 mtu 1500 inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20 ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) RX packets 282 bytes 30097 (29.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9086214 bytes 12731596673 (11.8 GiB) TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 lots of TX packets are dropped. list other packet size: ➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 1 10.00 2297941 0 1.84 212992 10.00 1462024 1.17 ➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 128 10.00 2311547 0 236.70 212992 10.00 1359834139.25 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920871/+subscriptions
[Bug 1921280] Re: OpenIndiana stuck in boot loop when using hvf
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921280 Title: OpenIndiana stuck in boot loop when using hvf Status in QEMU: Expired Bug description: I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO: qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host It gets to "Booting...", stays there for a bit, and then restarts. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1921280/+subscriptions
[Bug 1921444] Re: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921444 Title: Q35 doesn't support to hot add the 2nd PCIe device to KVM guest Status in QEMU: Expired Bug description: KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git branch: next, commit: 4a98623d Qemu: https://git.qemu.org/git/qemu.git branch: master, commit: 9e2e9fe3 Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add. If guest chipset is legacy i440fx, the 2 device can be added successfully. 1. Enable VT-d in BIOS 2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel 3. Bind 2 device to vfio-pci echo :b1:00.0 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id echo :b1:00.1 > /sys/bus/pci/drivers/i40e/unbind echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 4. create guest with Q35 chipset: qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize 5. hot add the 1st device to guest successfully in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1" 6. hot add the 2nd device to guest in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1" The 2nd device doesn't be added in guest, and the 1st device is removed from guest. Guest partial log: [ 110.452272] pcieport :00:04.0: pciehp: Slot(0): Attention button pressed [ 110.453314] pcieport :00:04.0: pciehp: Slot(0) Powering on due to button press [ 110.454156] pcieport :00:04.0: pciehp: Slot(0): Card present [ 110.454792] pcieport :00:04.0: pciehp: Slot(0): Link Up [ 110.580927] pci :01:00.0: [8086:1572] type 00 class 0x02 [ 110.582560] pci :01:00.0: reg 0x10: [mem 0x-0x007f 64bit pref] [ 110.583453] pci :01:00.0: reg 0x1c: [mem 0x-0x7fff 64bit pref] [ 110.584278] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref] [ 110.585051] pci :01:00.0: Max Payload Size set to 128 (was 512, max 2048) [ 110.586621] pci :01:00.0: PME# supported from D0 D3hot D3cold [ 110.588140] pci :01:00.0: BAR 0: no space for [mem size 0x0080 64bit pref] [ 110.588954] pci :01:00.0: BAR 0: failed to assign [mem size 0x0080 64bit pref] [ 110.589797] pci :01:00.0: BAR 6: assigned [mem 0xfe80-0xfe87 pref] [ 110.590703] pci :01:00.0: BAR 3: assigned [mem 0xfe00-0xfe007fff 64bit pref] [ 110.592085] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.592755] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.594403] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.595847] pcieport :00:04.0: bridge window [mem 0xfe00-0xfe1f 64bit pref] [ 110.597867] PCI: No. 2 try to assign unassigned res [ 110.597870] release child resource [mem 0xfe00-0xfe007fff 64bit pref] [ 110.597871] pcieport :00:04.0: resource 15 [mem 0xfe00-0xfe1f 64bit pref] released [ 110.598881] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.600789] pcieport :00:04.0: BAR 15: assigned [mem 0x18000-0x180bf 64bit pref] [ 110.601731] pci :01:00.0: BAR 0: assigned [mem 0x18000-0x1807f 64bit pref] [ 110.602849] pci :01:00.0: BAR 3: assigned [mem 0x18080-0x180807fff 64bit pref] [ 110.604069] pcieport :00:04.0: PCI bridge to [bus 01] [ 110.604941] pcieport :00:04.0: bridge window [io 0x1000-0x1fff] [ 110.606237] pcieport :00:04.0: bridge window [mem 0xfe80-0xfe9f] [ 110.607401] pcieport :00:04.0: bridge window [mem 0x18000-0x180bf 64bit pref] [ 110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 110.655314] i40e :01:00.0: enabling device (0140 -> 0142) [ 110.672396] i40e :01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008] [ 110.750054] i40e :01:00.0: MAC address: 3c:fd:fe:c0:59:98 [ 110.751792] i40e :01:00.0: FW LLDP is enabled [ 110.764644] i40e :01:00.0 eth1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None [ 110.779390] i40e :01:00.0: PCI-Express: Speed 8.0GT/s Width x8 [ 110.789841] i40e :01:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 4 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA [ 111.817553] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[Bug 1921635] Re: ESP SCSI adapter not working with DOS ASPI drivers
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1921635 Title: ESP SCSI adapter not working with DOS ASPI drivers Status in QEMU: Expired Bug description: I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways. The following things appear to be problematic: * The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues. * The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work. - ASPI.SYS (creative name) loads - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes. - TRMCD.SYS loads, but can not detect any CD drives. The various permutations: am53c974 hang on ASPI driver load: (CD only attached) ~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached) ~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash) ~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected ~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img -bios /home/hp/src/seabios/out/bios.bin -boot a -trace 'scsi*' -trace 'esp*' -D log All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one. The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results. I will attach all of the above images. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1921635/+subscriptions
[Bug 1915327] Re: x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1915327
Title:
x86_64 cmpxchg behavior in qemu tcg does not match the real CPU
Status in QEMU:
Expired
Bug description:
QEMU version:
1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch
'remotes/nvme/tags/nvme-next-pull-request' into staging
Consider the following little program:
$ cat 1.c
#include
int main() {
int mem = 0x12345678;
register long rax asm("rax") = 0x1234567812345678;
register int edi asm("edi") = 0x;
asm("cmpxchg %[edi],%[mem]"
: [ mem ] "+m"(mem), [ rax ] "+r"(rax)
: [ edi ] "r"(edi));
long rax2 = rax;
printf("rax2 = %lx\n", rax2);
}
According to the Intel Manual, cmpxchg should not touch the
accumulator in case the values are equal, which is indeed the case on
the real CPU:
$ gcc 1.c
$ ./a.out
rax2 = 1234567812345678
However, QEMU appears to zero extend EAX to RAX:
$ qemu-x86_64 ./a.out
rax2 = 12345678
This is also the case for lock cmpxchg.
Found in BPF development context:
https://lore.kernel.org/bpf/b1792bb3c51eb3e94b9d27e67665d3f2209bba7e.ca...@linux.ibm.com
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1915327/+subscriptions
[Bug 1914986] Re: KVM internal error. Suberror: 1 - OVMF / Audio related
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914986 Title: KVM internal error. Suberror: 1 - OVMF / Audio related Status in QEMU: Expired Bug description: This is latest release QEMU-5.2.0 on Arch Linux running kernel 5.10.13, latest OVMF etc. I'm seeing the following crash when loading an audio driver from the OpenCore[1] project in the UEFI shell: KVM internal error. Suberror: 1 emulation failure RAX= RBX= RCX= RDX= RSI= RDI=7e423628 RBP=7fee6a90 RSP=7fee6a08 R8 = R9 =0080 R10= R11= R12=7eeaf828 R13= R14= R15=7fee6a67 RIP=000b RFL=0246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0030 00c09300 DPL=0 DS [-WA] CS =0038 00a09b00 DPL=0 CS64 [-RA] SS =0030 00c09300 DPL=0 DS [-WA] DS =0030 00c09300 DPL=0 DS [-WA] FS =0030 00c09300 DPL=0 DS [-WA] GS =0030 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 7f9ee698 0047 IDT= 7f27a018 0fff CR0=80010033 CR2= CR3=7fc01000 CR4=0668 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0d00 Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Here's the QEMU command line I'm using: qemu-system-x86_64 \ -machine q35,accel=kvm \ -cpu host,+topoext,+invtsc \ -smp 4,sockets=1,cores=2 \ -m 4096 \ -drive file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,readonly=on \ -drive file=OVMF_VARS.fd,if=pflash,format=raw \ -usb -device usb-tablet -device usb-kbd \ -drive file=OpenCore-0.6.6.img,format=raw \ -device ich9-intel-hda,bus=pcie.0,addr=0x1b \ -device hda-micro,audiodev=hda \ -audiodev pa,id=hda,server=/run/user/1000/pulse/native The driver loads fine when using the "no connect" switch. eg: Shell> load -nc fs0:\efi\oc\drivers\audiodxe.efi Shell> Image 'fs0:\EFI\OC\Drivers\AudioDxe.efi' loaded at 7E3C7000 - Success However, the crash occurs when loading normally. Any ideas? Thanks. [1]: https://github.com/acidanthera/OpenCorePkg/releases To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914986/+subscriptions
[Bug 1915431] Re: QEMU processes started by Acceptance Tests are left running
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1915431 Title: QEMU processes started by Acceptance Tests are left running Status in QEMU: Expired Bug description: Every now and then, QEMU processes started by the Acceptance Tests (thus by Avocado) will be left running. From Avocado's perspective, when everything "goes well" and a test reaches completion, there's no attempt to terminate any processes it indirectly started. Some frameworks and tests built on top of Avocado, for instance Avocado-VT, will keep processes running between various tests. When a job (and consequently a test) is manually interrupted, then Avocado tries to terminate the entire process tree. It may be possible to improve the situation in which, at the very least, the user is: * notified of left over processes * have a configuration option that will attempt to kill all processes at the end of the test execution To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1915431/+subscriptions
[Bug 1917542] Re: qemu-img crash on M1 Mac
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1917542
Title:
qemu-img crash on M1 Mac
Status in QEMU:
Expired
Bug description:
1. Symptom
$ qemu-img create -f qcow2 disk.qcow2 10G
[1] 72373 killed qemu-img create -f qcow2 disk.qcow2 10G
2. System environment
CPU: Apple M1
OS: Big Sur 11.2.2
qemu: stable 5.2.0 (Binary installed by homebrew)
3. Kernel logs
$ sudo log show --predicate ‘eventMessage LIKE “qemu”’ --debug
ntID Dirty: 1 Event: com.apple.stability.crash
{“appVersion”:"???",“exceptionType”:1,“logwritten”:1,“process”:“qemu-img”,“responsibleApp”:“iTerm2”,“timestamp”:1614666875993238}
2021-03-02 15:36:52.728210+0900 0xfb308 Default 0x0 0 0 kernel: CODE SIGNING:
cs_invalid_page(0x10293): p=72373[qemu-img] final status 0x23000200,
denying page sending SIGKILL
2021-03-02 15:36:52.728222+0900 0xfb308 Default 0x0 0 0 kernel: CODE SIGNING:
process 72373[qemu-img]: rejecting invalid page at address 0x10293 from
offset 0x0 in file “/opt/homebrew/Cellar/libssh/0.9.5_1/lib/libssh.4.8.6.dylib”
(cs_mtime:1614297740.413435328 == mtime:1614297740.413435328) (signed:1
validated:1 tainted:1 nx:0 wpmapped:0 dirty:0 depth:0)
2021-03-02 15:36:52.728477+0900 0xfab09 Default 0x0 919 0 ReportCrash:
Parsing corpse data for process qemu-img [pid 72373]
2021-03-02 15:36:52.884736+0900 0xfab09 Default 0x0 919 0 ReportCrash:
(CrashReporterSupport) Saved crash report for qemu-img[72373] version 0 to
qemu-img_2021-03-02-153652_.crash
4. Crash logs
$ sudo cat
/Users//Library/Logs/DiagnosticReports/qemu-img_2021-03-02-153652_.crash
Process: qemu-img [72373]
Path: /opt/homebrew/*/qemu-img
Identifier: qemu-img
Version: 0
Code Type: ARM-64 (Native)
Parent Process: zsh [67484]
Responsible: iTerm2 [556]
User ID: 501
Date/Time: 2021-03-02 15:36:52.710 +0900
OS Version: macOS 11.2.2 (20D80)
Report Version: 12
Anonymous UUID: AF87D5F0-2BED-EB72-1DC8-26F63A24DA7C
Sleep/Wake UUID: 3862EA39-132E-42BD-A4BB-5A36F36607F1
Time Awake Since Boot: 89000 seconds
Time Since Wake: 520 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes: 0x0032, 0x00010293
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 0x2
kernel messages:
VM Regions Near 0x10293:
__LINKEDIT 102908000-10293 [ 160K] r–/r-- SM=COW /opt/homebrew/*
→ mapped file 10293-102934000 [ 16K] r–/r-x SM=PRV Object_id=fc8cc3db
__TEXT 1029bc000-102a38000 [ 496K] r-x/r-x SM=COW /usr/lib/dyld
Application Specific Information:
dyld: launch, loading dependent libraries
/opt/homebrew/opt/libssh/lib/libssh.4.dylib
Thread 0 Crashed:
0 dyld 0x000102a18780 bcmp + 16
1 dyld 0x0001029d9408
ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int,
unsigned char const*, unsigned long, long long, ImageLoader::LinkContext
const&) + 136
2 dyld 0x0001029e03b8
ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char
const*, unsigned long, unsigned long long, unsigned long long, stat const&,
unsigned int, unsigned int, linkedit_data_command const*,
encryption_info_command const*, ImageLoader::LinkContext const&) + 268
3 dyld 0x0001029d7ffc ImageLoaderMachO::instantiateFromFile(char const*,
int, unsigned char const*, unsigned long, unsigned long long, unsigned long
long, stat const&, ImageLoader::LinkContext const&) + 172
4 dyld 0x0001029c0290 dyld::loadPhase6(int, stat const&, char const*,
dyld::LoadContext const&) + 668
5 dyld 0x0001029c8dd8 dyld::loadPhase5(char const*, char const*,
dyld::LoadContext const&, unsigned int&, std::__1::vector >) + 1328
6 dyld 0x0001029c8824 dyld::loadPhase4(char const, char const*,
dyld::LoadContext const&, unsigned int&, std::__1::vector >) + 208
7 dyld 0x0001029c8530 dyld::loadPhase3(char const, char const*,
dyld::LoadContext const&, unsigned int&, std::__1::vector >) + 1100
8 dyld 0x0001029c7cf0 dyld::loadPhase1(char const, char const*,
dyld::LoadContext const&, unsigned int&, std::__1::vector >) + 212
9 dyld 0x0001029bfe0c dyld::loadPhase0(char const, char const*,
dyld::LoadContext const&, unsigned int&, std::__1::vector >) + 468
10 dyld 0x0001029bf9b0 dyld::load(char const, dyld::LoadContext const&,
unsigned int&) + 196
11 dyld 0x0001029c977c dyld::libraryLocator(char const*, bool, char
const*, ImageLoader::RPathChain const*, unsigned int&) + 56
12 dyld 0x0001029d39d4
ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool,
ImageLoader::RPathChain const&, char const*) + 344
13 dyld 0x0001029d21ac
[Bug 1916269] Re: TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1916269
Title:
TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction
Status in QEMU:
Expired
Bug description:
If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get
a FPU exception when executing crc32
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is
not a problem with the default CPU (or KVM) since that does not
support SSE 4.2.
Attaching GDB shows this is triggered in
target/i386/tcg/translate.c:3067
/* simple MMX/SSE operation */
if (s->flags & HF_TS_MASK) {
gen_exception(s, EXCP07_PREX, pc_start - s->cs_base);
return;
}
However, according to
https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf,
page 61 the CRC32 instruction works no matter what the value of the TS
bit.
The code sequence in question is:
0x8105a4de <+126>:f2 48 0f 38 f1 de crc32q %rsi,%rbx
0x8105a4e4 <+132>:f2 48 0f 38 f1 ca crc32q %rdx,%rcx.
This should work even with the FPU disabled.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1916269/+subscriptions
[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: Expired Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1917940] Re: -bios edk2-$arch-code doesn't work for x86
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1917940 Title: -bios edk2-$arch-code doesn't work for x86 Status in QEMU: Expired Bug description: Whilst creating a flash device is recommended, -bios is extremely useful in many cases as it automatically searches $PREFIX/share/qemu rather than requiring the caller (be it a human or a script) to work out where that directory is for the QEMU being called and prepend it to the file name. Currently, all the x86 EDK2 FD code files are 3653632 bytes in size, or 0x37c000 bytes. However, for some reason I cannot find the answer to (I traced the code back to 7587cf44019d593bb12703e7046bd7738996c55c), x86's -bios only allows files that are multiples of 64K in size (x86_bios_rom_init), which would require the EDK2 ROMs to be rounded up to 0x38 bytes. If I delete the check, QEMU is able to load the only-16K-multiple-sized EDK2 and boot an OS just fine. If I pad EDK2 with 16K of zeroes at the *start* (since the ROM gets mapped counting backwards), it also works just fine (but padding at the *end* doesn't). Please therefore either relax the check in x86_bios_rom_init or ensure the EDK2 binary is suitably padded. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1917940/+subscriptions
[Bug 1915682] Re: i386-linux-user wine exception regression tests fail
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1915682 Title: i386-linux-user wine exception regression tests fail Status in QEMU: Expired Bug description: When trying to run wine (latest devel from git) regression tests for ntdll in a statically linked qemu-i386 (commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8) on arm32 (raspberry pi 4) in a debian buster chroot, the exception tests fail at the first test with an infinite exception loop. WINEDEBUG=+seh wine wine/dlls/ntdll/tests/ntdll_test.exe exception Working x86_64 system running 32-bit code 0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c005) raised 0024:trace:seh:dispatch_exception eax= ebx=7ffc2000 ecx=004e0ef4 edx=003c0004 esi=003c edi= 0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c005 flags=0 0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c005 flags=0 0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 0024:trace:seh:dispatch_exception call_stack_handlers continuing 0024:trace:seh:NtGetContextThread 0xfffe: dr0=42424240 dr1= dr2=126bb070 dr3=0badbad0 dr6= dr7=0115 Non-working qemu 0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c005) raised 0024:trace:seh:dispatch_exception eax= ebx=3ffe2000 ecx=004e0ef4 edx=003c0004 esi=003c edi= 0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=003b gs=0033 flags=0246 0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c005 flags=0 0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c005 flags=0 0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 0024:trace:seh:dispatch_exception call_stack_handlers continuing 0024:trace:seh:dispatch_exception call_stack_handlers ret status = 0 0024:trace:seh:dispatch_exception code=0 flags=1 addr=7BC2389C ip=7bc2389c tid=0024 The non-working verion is never managing to set the CPU context using NtContinue/SetContextThread back to the correct running thread stack and IP. It executes as if the context restore just returns to the function that called NtContinue() (dispatch_exception(), not the function that raised the exception or one of its parent exception handlers). It looks like NtSetContextThread(), specifically the asm function set_full_cpu_context() is being handled incorrectly. wine code below. note interesting use of iret with no previous interrupt call. The exception handler is called with a jmp. /*** * set_full_cpu_context * * Set the new CPU context. */ extern void set_full_cpu_context( const CONTEXT *context ); __ASM_GLOBAL_FUNC( set_full_cpu_context, "movl $0,%fs:0x1f8\n\t" /* x86_thread_data()->syscall_frame = NULL */ "movl 4(%esp),%ecx\n\t" "movw 0x8c(%ecx),%gs\n\t" /* SegGs */ "movw 0x90(%ecx),%fs\n\t" /* SegFs */ "movw 0x94(%ecx),%es\n\t" /* SegEs */ "movl 0x9c(%ecx),%edi\n\t" /* Edi */ "movl 0xa0(%ecx),%esi\n\t" /* Esi */ "movl 0xa4(%ecx),%ebx\n\t" /* Ebx */ "movl 0xb4(%ecx),%ebp\n\t" /* Ebp */ "movw %ss,%ax\n\t" "cmpw 0xc8(%ecx),%ax\n\t" /* SegSs */ "jne 1f\n\t" /* As soon as we have switched stacks the context structure could * be invalid (when signal handlers are executed for example). Copy * values on the target stack before changing ESP. */ "movl 0xc4(%ecx),%eax\n\t" /* Esp */ "leal -4*4(%eax),%eax\n\t" "movl 0xc0(%ecx),%edx\n\t" /* EFlags */ ".byte 0x36\n\t" "movl %edx,3*4(%eax)\n\t" "movl 0xbc(%ecx),%edx\n\t" /* SegCs */ ".byte 0x36\n\t" "movl %edx,2*4(%eax)\n\t" "movl 0xb8(%ecx),%edx\n\t" /* Eip */ ".byte 0x36\n\t" "movl %edx,1*4(%eax)\n\t" "movl 0xb0(%ecx),%edx\n\t" /* Eax */ ".byte 0x36\n\t"
[Bug 1908416] Re: qemu-system-aarch64 can't run Windows 10 for ARM version 2004
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1908416 Title: qemu-system-aarch64 can't run Windows 10 for ARM version 2004 Status in QEMU: Expired Bug description: Problem: qemu-system-aarch64 can't run Windows 10 for ARM version 2004 (20H2) or newer Host OS: Windows 10 x64 version 20H2 CPU: Intel Pentium Dual-core T4300 (no vt-x) QEMU : QEMU version 5.1.0 from qemu.org cmdline: qemu-system-aarch64.exe -M virt -cpu cortex-a72 -smp 3 --accel tcg,thread=multi -m 2048 -pflash QEMU_EFI.img -pflash QEMU_VARS.img -device VGA -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-storage,drive=cdrom -drive file="isofile.iso",media=cdrom,if=none,id=cdrom Note: QEMU_VARS and QEMU_EFI are taken from edk2 Details: From this post (https://kitsunemimi.pw/notes/posts/running- windows-10-for-arm64-in-a-qemu-virtual-machine.html) and from what I have tried, QEMU can't run Windows ARM newer or equal to the 2004 version. When we boot a 2004 iso (made from uupdump.ml), it stuck as the boot screen with the Windows ARM logo and nothing else. When I check the machine state and registers through the QEMU monitor, it shows that the VM is still running, but the registers are completely frozen! But if I try the older version, like 19H2, it works! Please help! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1908416/+subscriptions
[Bug 1916506] Re: make check-venv may leave stale and incomplete tests/venv directory directory
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916506 Title: make check-venv may leave stale and incomplete tests/venv directory directory Status in QEMU: Expired Bug description: As reported by "Philippe Mathieu-Daudé" , a "make check-venv" can be run and fail to properly create a suitable virtual environment, leaving the tests/venv directory which is the target for "make check-venv" itself. This means that on a subsequent run: > $ make check-venv > GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3 > tests/fp/berkeley-softfloat-3 dtc capstone slirp > make: Nothing to be done for 'check-venv'. And the venv will still be incomplete. The causes of such failures to create a suitable virtual environment are too many (in the reported case it was because of missing *required* Python packages). Some more evolved virtual environments + Python packaging systems exist that could probably be used here (Pipenv) but would add further core requirements. The current mitigation is to run "make check-clean" when the venv appears to be incomplete. The goal of this bug is to attempt to make the venv setup atomic and more reliable. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916506/+subscriptions
[Bug 1917591] Re: qemu-i386 under aarch64: Segfaulting on Steamcmd
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1917591 Title: qemu-i386 under aarch64: Segfaulting on Steamcmd Status in QEMU: Expired Bug description: I am trying to set up a Valheim server on my Raspberry Pi 4 (8GB). I have installed the aarch64 image of Arm Arch Linux. I installed qemu-user-static (version 5.2.0 at this time of writing) from the AUR: https://aur.archlinux.org/packages/qemu-user-static/ I have correctly set up binfmt support: https://aur.archlinux.org/packages/binfmt-qemu-static-all-arch/ This allows me to successfully run i386 and amd64 docker images: [alarm@server ~]$ sudo docker run --rm i386/debian uname -a WARNING: The requested image's platform (linux/386) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested Linux 9fd8d345b0aa 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 i686 GNU/Linux and [alarm@server ~]$ sudo docker run --rm amd64/debian uname -a WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested Linux 4f50fd228ab6 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 x86_64 GNU/Linux However, when I try to run the docker image that is going to host the server, the download of Valheim never succeeds because the used steamcmd application segfaults: The following command successfully runs the server: sudo docker run -d --name valheim-server -p 2456-2458:2456-2458/udp -e SERVER_NAME="My Server" -e WORLD_NAME="Neotopia" -e SERVER_PASS="secret" lloesche /valheim-server However, when we look into the container's logs via this command: sudo docker logs valheim-server We see the following entry in the log file: ./steamcmd.sh: line 38: 86 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@" This means that the download never completes, and therefor the Valheim server is never actually started. Any help would be much appreciated. If there is anything unclear or if you need more details, please let me know! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1917591/+subscriptions
[Bug 1917661] Re: qemu gdb wrong registers group for riscv64
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1917661 Title: qemu gdb wrong registers group for riscv64 Status in QEMU: Expired Bug description: Step to reproduce: 1. run qemu-system-riscv64 in gdb mode 2. attach gdb 3. set a breakpoint and run 4. print register-groups using "maintenance print register-groups" command ... sbadaddr 4162 4162 1628 8 longall,general msounteren 4163 4163 1636 8 longall,general mbadaddr 4164 4164 1644 8 longall,general htimedeltah 4165 4165 1652 8 longall,general These registers don't belong to general group, instead they belong to all, system and csr groups. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1917661/+subscriptions
[Bug 1917565] Re: Windows 10 fails with "Boot device inaccessible"
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1917565
Title:
Windows 10 fails with "Boot device inaccessible"
Status in QEMU:
Expired
Bug description:
The issue is happening on all versions I tried after the following
commit. I can also remove this individual change from master and it
starts to work.
OVMF_CODE.fd is what comes with Ubuntu 20.04 through package manager.
git diff af1b80ae56c9495999e8ccf7b70ef894378de642~
af1b80ae56c9495999e8ccf7b70ef894378de642
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b7bc2a..7a5a8b3521 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
dev = aml_device("PCI0");
aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
-aml_append(dev, aml_name_decl("_UID", aml_int(1)));
+aml_append(dev, aml_name_decl("_UID", aml_int(0)));
aml_append(sb_scope, dev);
aml_append(dsdt, sb_scope);
@@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
-aml_append(dev, aml_name_decl("_UID", aml_int(1)));
+aml_append(dev, aml_name_decl("_UID", aml_int(0)));
aml_append(dev, build_q35_osc_method());
aml_append(sb_scope, dev);
aml_append(dsdt, sb_scope);
The virtual machine start command:
x86_64-softmmu/qemu-system-x86_64 -name guest=win10-dev,debug-threads=on
-blockdev
'{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
-blockdev
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win10-dev_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
-blockdev
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
-machine
pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
-cpu
Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff
-m 6144 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid
5646e540-5022-4ace-8d6a-d7c4b61a6d3d -no-user-config -nodefaults -rtc
base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet
-global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev
'{"driver":"host_device","filename":"/dev/disk/by-id/scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}'
-blockdev
'{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}'
-device
ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1,write-cache=on
-device ide-cd,bus=ide.1,id=sata0-0-1 -netdev user,id=hostnet0 -device
e1000e,netdev=hostnet0,id=net0,mac=52:54:00:10:5b:55,bus=pci.1,addr=0x0
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-device usb-tablet,id=input0,bus=usb.0,port=1 -spice
port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on
-device
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
-device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
[Bug 1910696] Re: Qemu fails to start with error " There is no option group 'spice'"
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1910696 Title: Qemu fails to start with error " There is no option group 'spice'" Status in QEMU: Expired Bug description: After upgrade from 5.1.0 to 5.2.0, qemu fails on start with error: ` /usr/bin/qemu-system-x86_64 -S -name trinti -uuid f8ad2ff6-8808-4f42-8f0b-9e23acd20f84 -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-reboot -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -readconfig /var/log/lxd/trinti/qemu.conf -pidfile /var/log/lxd/trinti/qemu.pid -D /var/log/lxd/trinti/qemu.log -chroot /var/lib/lxd/virtual-machines/trinti -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas nobody: qemu-system-x86_64:/var/log/lxd/trinti/qemu.conf:27: There is no option group 'spice' qemu-system-x86_64: -readconfig /var/log/lxd/trinti/qemu.conf: read config /var/log/lxd/trinti/qemu.conf: Invalid argument ` Bisected to first bad commit: https://github.com/qemu/qemu/commit/cbe5fa11789035c43fd2108ac6f45848954954b5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1910696/+subscriptions
[Bug 1907969] Re: linux-user/i386: Segfault when mixing threads and signals
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907969
Title:
linux-user/i386: Segfault when mixing threads and signals
Status in QEMU:
Expired
Bug description:
Given the following C program, qemu-i386 will surely and certainly segfault
when executing it.
The problem is only noticeable if the program is statically linked to musl's
libc and, as written
in the title, it only manifests when targeting i386.
Removing the pthread calls or the second raise() makes it not
segfault.
The crash is in some part of the TCG-generated code, right when it tries to
perform a
%gs-relative access.
If you want a quick way of cross-compiling this binary:
* Download a copy of the Zig compiler from https://ziglang.org/download/
* Compile it with
`zig cc -target i386-linux-musl -o `
```
#include
#include
#include
#include
#include
#include
#include
#include
void sig_func(int sig)
{
write(1, "hi!\n", strlen("hi!\n"));
}
void func(void *p) { }
typedef void *(*F)(void *);
int main()
{
pthread_t tid;
struct sigaction action;
action.sa_flags = 0;
action.sa_handler = sig_func;
if (sigaction(SIGUSR1, , NULL) == -1) {
return 1;
}
// This works.
raise(SIGUSR1);
pthread_create(, NULL, (F)func, NULL);
pthread_join(tid, NULL);
// This makes qemu segfault.
raise(SIGUSR1);
}
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907969/+subscriptions
[Bug 1908781] Re: x86-64 not faulting when CS.L = 1 and CS.D = 1
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1908781 Title: x86-64 not faulting when CS.L = 1 and CS.D = 1 Status in QEMU: Expired Bug description: In a UEFI application I accidentally created a code segment descriptor where both the L and D bits were 1. This is supposed to generate a GP fault (e.g. see page 2942 of https://software.intel.com/sites/default/files/managed/39/c5/325462 -sdm-vol-1-2abcd-3abcd.pdf). When running with KVM a fault did indeed occur, but when not specifying any acceleration, no fault occurred. Let me know if you need me to develop a minimum example to debug from. At the moment it's all part of a slightly more complicated bit of code. Version: 5.2.0 (compiled from source) Command line options: -smp cores=4 -m 8192 (plus whatever uefi-run adds to plug in OVMF and my UEFI application). Environment: Ubuntu 20.04 on Ryzen 3700X To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1908781/+subscriptions
[Bug 1910605] Re: qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1910605 Title: qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address Status in QEMU: Expired Bug description: Snippet of code sample: struct usbdevfs_bulktransfer Bulk; Bulk.ep = hUsb->UsbOut; Bulk.len = Len; Bulk.data = (void *)pData; Bulk.timeout = Timeout; Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, ) The above code sample return -1 (EFAULT) Bad address when using qemu- arm-static but is running ok when on qemu-aarch64-static. I use a 64-bit intel laptop To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1910605/+subscriptions
[Bug 1912170] Re: NUMA nodes created with memory-backend-ram shows size different than requested
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1912170 Title: NUMA nodes created with memory-backend-ram shows size different than requested Status in QEMU: Expired Bug description: I created system with 7 NUMA nodes where nodes 0-3 should have 268435456 bytes size and nodes 4-6 exactly 1610612736 bytes size, but when I run "numactl -H" I got different (smaller) sizes. It is essential for me to be able to emulate a system with nodes of exact size - is it possible? QEMU version: QEMU emulator version 5.1.0 Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers QEMU command: qemu-system-x86_64 -hda qemu-image/ubuntu-1804.img -enable-kvm -cpu Cascadelake-Server -vnc :5 -netdev user,id=net0,hostfwd=tcp::10022-:22 -device virtio-net,netdev=net0 -boot c -m 5632.0M -object memory- backend-ram,id=ram-node0,size=268435456 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-ram,id =ram-node1,size=268435456 -numa node,nodeid=1,cpus=4-7,memdev=ram- node1 -object memory-backend-ram,id=ram-node2,size=268435456 -numa node,nodeid=2,cpus=8-11,memdev=ram-node2 -object memory-backend-ram,id =ram-node3,size=268435456 -numa node,nodeid=3,cpus=12-15,memdev=ram- node3 -object memory-backend-ram,id=ram-node4,size=1610612736 -numa node,nodeid=4,memdev=ram-node4 -object memory-backend-ram,id=ram- node5,size=1610612736 -numa node,nodeid=5,memdev=ram-node5 -object memory-backend-ram,id=ram-node6,size=1610612736 -numa node,nodeid=6,memdev=ram-node6 -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=31 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=17 -numa dist,src=0,dst=5,val=38 -numa dist,src=0,dst=6,val=28 -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=31 -numa dist,src=1,dst=4,val=28 -numa dist,src=1,dst=5,val=17 -numa dist,src=1,dst=6,val=38 -numa dist,src=2,dst=0,val=31 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=28 -numa dist,src=2,dst=5,val=28 -numa dist,src=2,dst=6,val=28 -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=31 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=28 -numa dist,src=3,dst=5,val=28 -numa dist,src=3,dst=6,val=17 -numa dist,src=4,dst=0,val=17 -numa dist,src=4,dst=1,val=28 -numa dist,src=4,dst=2,val=28 -numa dist,src=4,dst=3,val=28 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=28 -numa dist,src=4,dst=6,val=28 -numa dist,src=5,dst=0,val=38 -numa dist,src=5,dst=1,val=17 -numa dist,src=5,dst=2,val=28 -numa dist,src=5,dst=3,val=28 -numa dist,src=5,dst=4,val=28 -numa dist,src=5,dst=5,val=10 -numa dist,src=5,dst=6,val=28 -numa dist,src=6,dst=0,val=38 -numa dist,src=6,dst=1,val=28 -numa dist,src=6,dst=2,val=28 -numa dist,src=6,dst=3,val=17 -numa dist,src=6,dst=4,val=28 -numa dist,src=6,dst=5,val=28 -numa dist,src=6,dst=6,val=10 -smp 16,sockets=4,dies=1,cores=4,threads=1 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/mysuser/share -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=share_host -daemonize output from numactl -H: $ numactl -H available: 7 nodes (0-6) node 0 cpus: 0 1 2 3 node 0 size: 250 MB node 0 free: 191 MB node 1 cpus: 4 5 6 7 node 1 size: 251 MB node 1 free: 199 MB node 2 cpus: 8 9 10 11 node 2 size: 251 MB node 2 free: 218 MB node 3 cpus: 12 13 14 15 node 3 size: 251 MB node 3 free: 118 MB node 4 cpus: node 4 size: 1511 MB node 4 free: 1507 MB node 5 cpus: node 5 size: 1447 MB node 5 free: 1443 MB node 6 cpus: node 6 size: 1489 MB node 6 free: 1484 MB node distances: node 0 1 2 3 4 5 6 0: 10 21 31 21 17 38 28 1: 21 10 21 31 28 17 38 2: 31 21 10 21 28 28 28 3: 21 31 21 10 28 28 17 4: 17 28 28 28 10 28 28 5: 38 17 28 28 28 10 28 6: 38 28 28 17 28 28 10 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1912170/+subscriptions
[Bug 1911188] Re: qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911188 Title: qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument Status in QEMU: Expired Bug description: QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32) on Fedora 32. When writing a script to start qemu automatically, I ran into a very confusing error message due to a bug in my script and had trouble understanding it. I isolated the problem to the following: $ qemu-system-x86_64 "" qemu-system-x86_64: Initialization of device ide-hd failed: Device needs media, but drive is empty As you can see, running qemu with an empty argument prints a seemingly random and unrelated error message about an ide-hd device, and the program immediately exits with code 1. This happens when an empty argument appears anywhere in the arguments list, always causing the program to immediately die with this error. This is a simply baffling message to be encountering when the problem is really an empty argument. Expected behaviour: Either flatly ignore the empty argument, or at most trigger a warning (eg, "warning: saw empty argument"). It should not at all prevent the program from running. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911188/+subscriptions
[Bug 1908626] Re: Atomic test-and-set instruction does not work on qemu-user
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1908626 Title: Atomic test-and-set instruction does not work on qemu-user Status in QEMU: Expired Bug description: I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: ``` host: CentOS7 x86_64 container: centos:centos7.9.2009 --platform linux/arm64/v8 qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ ``` However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock has something wrong. ``` https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c ``` So I extract its spinlock implementation into one test C source file (see attachment file), and get reprodcued: ``` $ gcc spinlock_qemu.c $ ./a.out C -- slock inited, lock value is: 0 parent 139642, child 139645 P -- slock lock before, lock value is: 0 P -- slock locked, lock value is: 1 P -- slock unlock after, lock value is: 0 C -- slock lock before, lock value is: 1 P -- slock lock before, lock value is: 1 C -- slock locked, lock value is: 1 C -- slock unlock after, lock value is: 0 C -- slock lock before, lock value is: 1 P -- slock locked, lock value is: 1 P -- slock unlock after, lock value is: 0 P -- slock lock before, lock value is: 1 C -- slock locked, lock value is: 1 C -- slock unlock after, lock value is: 0 P -- slock locked, lock value is: 1 C -- slock lock before, lock value is: 1 P -- slock unlock after, lock value is: 0 C -- slock locked, lock value is: 1 P -- slock lock before, lock value is: 1 C -- slock unlock after, lock value is: 0 P -- slock locked, lock value is: 1 C -- slock lock before, lock value is: 1 P -- slock unlock after, lock value is: 0 C -- slock locked, lock value is: 1 P -- slock lock before, lock value is: 1 C -- slock unlock after, lock value is: 0 P -- slock locked, lock value is: 1 C -- slock lock before, lock value is: 1 P -- slock unlock after, lock value is: 0 P -- slock lock before, lock value is: 1 spin timeout, lock value is 1 (pid 139642) spin timeout, lock value is 1 (pid 139645) spin timeout, lock value is 1 (pid 139645) spin timeout, lock value is 1 (pid 139642) spin timeout, lock value is 1 (pid 139645) spin timeout, lock value is 1 (pid 139642) ... ... ... ``` NOTE: this code always works on PHYSICAL ARM64 server. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1908626/+subscriptions
[Bug 1913913] Re: i386-linux-user returns -1 in sigcontext->trapno
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1913913 Title: i386-linux-user returns -1 in sigcontext->trapno Status in QEMU: Expired Bug description: QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. Certain 16-bit windows programs crash WINE under QEMU linux-user with: 0084:err:seh:segv_handler Got unexpected trap -1 wine: Unhandled illegal instruction at address 6D65 (thread 0084), starting debugger... They run correctly on native i386. Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913913/+subscriptions
[Bug 1913315] Re: qemu-system-x86_64 crash: in memory_region_access_valid+0x13
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1913315 Title: qemu-system-x86_64 crash: in memory_region_access_valid+0x13 Status in QEMU: Expired Bug description: Recently we started to get intermittent qemu crashes. There is catchsegv report: ``` + qemu-system-x86_64 -m 77766M -smp 8 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-rt-buildroot/boot/vmlinuz-4.19.165-rt-alt1.rt70 -initrd /usr/src/tmp/initramfs-4.19.165-rt-alt1.rt70.img -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr quiet panic=-1 no_timer_check' *** signal 11 Register dump: RAX: RBX: 03400340 RCX: 0001 RDX: 0004 RSI: 0300 RDI: 03400340 RBP: 0300 R8 : R9 : 03400340 R10: 0370 R11: 0002 R12: 0004 R13: 0004 R14: 55b473fef5e0 R15: 0002 RSP: 7fd7edffae90 RIP: 55b4717ef653 EFLAGS: 00010206 CS: 0033 FS: GS: Trap: 000e Error: 0004 OldMask: 7ffbfa77 CR2: 0388 FPUCW: 037f FPUSW: TAG: RIP: RDP: ST(0) ST(1) ST(2) ST(3) ST(4) ST(5) ST(6) ST(7) mxcsr: 1fa0 XMM0: XMM1: XMM2: XMM3: XMM4: XMM5: XMM6: XMM7: XMM8: XMM9: XMM10: XMM11: XMM12: XMM13: XMM14: XMM15: Backtrace: qemu-system-x86_64(memory_region_access_valid+0x13)[0x55b4717ef653] qemu-system-x86_64(memory_region_dispatch_write+0x48)[0x55b4717ef8c8] qemu-system-x86_64(+0x69fdfc)[0x55b471851dfc] qemu-system-x86_64(helper_le_stl_mmu+0x2c5)[0x55b471858995] [0x7feaed070925] ``` QEMU release 5.2.0. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913315/+subscriptions
[Bug 1913926] Re: [QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker Image
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913926
Title:
[QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker
Image
Status in QEMU:
Expired
Bug description:
# System Details
AMD Ryzen 7 3700U
Ubuntu 20.04 Focal Focus
# Dockerfile
FROM arm32v7/debian:bullseye
RUN apt-get update && apt-get install -y mesa-utils
ENTRYPOINT glxgears
# Instructions For Reproduction
1. Install Docker
2. Build Docker Image: docker build --tag mesa-arm-test .
3. Run: docker run -v /tmp/.X11-unix:/tmp/.X11-unix --device
/dev/dri:/dev/dri -e "DISPLAY=${DISPLAY}" mesa-arm-test
The Output Is:
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-38)
amdgpu: amdgpu_device_initialize failed.
libGL error: failed to create dri screen
libGL error: failed to load driver: radeonsi
libGL error: failed to get magic
libGL error: failed to load driver: radeonsi
It then appears to run using software rendering.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1913926/+subscriptions
[Bug 1912857] Re: virtio-serial blocks hostfwd ssh on windows 10 host
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1912857 Title: virtio-serial blocks hostfwd ssh on windows 10 host Status in QEMU: Expired Bug description: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> THIS WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev socket,id=cid0,host=localhost,port=55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev file,id=cid0,path=mypath No matter which character device I use for my virtserialport communication (socket or udp or file or pipe), the hostfwd doesn't work. Also, if I enable the display, I am unable to type anything in the emulator window when I use virtserialport. Host: Windows 10 Guest: archlinux QEMU version 5.2 The same thing works just fine on a Mac OS X host (tested on Big Sur) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1912857/+subscriptions
[Bug 1913505] Re: Windows XP slow on Apple M1
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1913505 Title: Windows XP slow on Apple M1 Status in QEMU: Expired Bug description: Qemu installed by using brew install qemu -s on M1 QEMU emulator version 5.2.0 XP image from: https://archive.org/details/WinXPProSP3x86 Commands run: $ qemu-img create -f qcow2 xpsp3.img 10G $ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913505/+subscriptions
[Bug 1914294] Re: Windows XP displays black screen when smp option is used
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914294 Title: Windows XP displays black screen when smp option is used Status in QEMU: Expired Bug description: When I use Windows XP with the -smp option, the screen goes black. The only thing I can see is a cursor. I have tried -smp 2, -smp cores=4, and -smp cores=2. My info: Host: M1 Mac Mac OS 11.1 QEMU 5.2 at cf7ca7d5b9faca13f1f8e3ea92cfb2f741eb0c0e. Guest: 32-bit Windows XP SP3 build 2600. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914294/+subscriptions
[Bug 1914021] Re: qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914021 Title: qemu: uncaught target signal 4 (Illegal instruction) but gdb remote- debug exited normally Status in QEMU: Expired Bug description: I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. readelf -h a.out_err ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x8220 Start of program headers: 52 (bytes into file) Start of section headers: 54228 (bytes into file) Flags: 0x5000200, Version5 EABI, soft-float ABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 3 Size of section headers: 40 (bytes) Number of section headers: 16 Section header string table index: 15 qemu-arm version 4.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914021/+subscriptions
[Bug 1914667] Re: High cpu usage when guest is idle on qemu-system-i386
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1914667 Title: High cpu usage when guest is idle on qemu-system-i386 Status in QEMU: Expired Bug description: When running Windows XP in qemu-system-i386, the cpu usage of QEMU is about 100% even when the guest CPU usage is close to 2%. The host cpu usage should be low when the guest cpu usage is low. Command: qemu-system-i386 -hda Using this command also shows around 100% host CPU usage: qemu-system-i386 -m 700 -hda -usb -device usb-audio -net nic,model=rtl8139 -net user -hdb mountable.img -soundhw pcspk Using the Penryn CPU option also saw this problem: qemu-system-i386 -hda -m 700 -cpu Penryn-v1 Using "-cpu pentium2" saw the same high host cpu usage. My Info: M1 MacBook Air Mac OS 11.1 qemu-system-i386 version 5.2 (1ba089f2255bfdb071be3ce6ac6c3069e8012179) Windows XP SP3 Build 2600 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914667/+subscriptions
[Bug 1779955] Re: qemu linux-user requires read permissions on memory passed to syscalls that should only need write access
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779955
Title:
qemu linux-user requires read permissions on memory passed to syscalls
that should only need write access
Status in QEMU:
Expired
Bug description:
When read() function takes an mmap'ed address as output buffer, it
returns EFAULT. The expected behavior is it should just work.
The following code works for qemu-system-arm, but not for qemu-arm-
static.
QEMU version affected: latest release 2.12.0.
Steps to reproduce (please substitute /path/to/qemu-arm-static with
the path of the binary, and /tmp/a.cpp with the example source code
attached):
# First register binfmt_misc
[hidden]$ docker run --rm --privileged multiarch/qemu-user-static:register
--reset
# Compile the code and run
[hidden]$ docker run --rm -it -v /tmp/a.cpp:/tmp/a.cpp -v
/path/to/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/ubuntu:18.04 bash -c
'{ apt update -y && apt install -y g++; } >& /dev/null && g++ -std=c++14
/tmp/a.cpp -o /tmp/a.out && echo hehe > /tmp/haha.txt && /tmp/a.out'
ofd=3
ftruncate=0
mmap=0xff3f5000
fd=4
0xff3f5023 -1 14
The expected result in qemu-system-arm as well as natively on x86_64 host:
hidden$ ./a.out
ofd=3
ftruncate=0
mmap=0xb6fb7000
fd=4
0xb6fb7023 5 0
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1779955/+subscriptions
[Bug 1785734] Re: movdqu partial write at page boundary
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1785734 Title: movdqu partial write at page boundary Status in QEMU: Expired Bug description: In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example. Tested on the qemu-3.0.0-rc1 release. % gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out [snip] page fault: addr=0x70001000 err=0x7 *(0x7ff8+ 0) = aa *(0x7ff8+ 1) = aa *(0x7ff8+ 2) = aa *(0x7ff8+ 3) = aa *(0x7ff8+ 4) = aa *(0x7ff8+ 5) = aa *(0x7ff8+ 6) = aa *(0x7ff8+ 7) = aa *(0x7ff8+ 8) = 55 *(0x7ff8+ 9) = 55 *(0x7ff8+10) = 55 *(0x7ff8+11) = 55 *(0x7ff8+12) = 55 *(0x7ff8+13) = 55 *(0x7ff8+14) = 55 *(0x7ff8+15) = 55 [snip] page fault: addr=0x70001000 err=0x6 *(0x7ff8+ 0) = 77 *(0x7ff8+ 1) = 66 *(0x7ff8+ 2) = 55 *(0x7ff8+ 3) = 44 *(0x7ff8+ 4) = 33 *(0x7ff8+ 5) = 22 *(0x7ff8+ 6) = 11 *(0x7ff8+ 7) = 0 *(0x7ff8+ 8) = 55 *(0x7ff8+ 9) = 55 *(0x7ff8+10) = 55 *(0x7ff8+11) = 55 *(0x7ff8+12) = 55 *(0x7ff8+13) = 55 *(0x7ff8+14) = 55 *(0x7ff8+15) = 55 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1785734/+subscriptions
[Bug 1862874] Re: java may stuck for a long time in system mode with "-cpu max"
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1862874
Title:
java may stuck for a long time in system mode with "-cpu max"
Status in QEMU:
Expired
Bug description:
Bug Description:
Run "java -version" in guest VM, java may stuck for a long time (several
hours) and then recover.
Steps to reproduce:
1. Launch VM by attached simple script: launch.sh
2. Execute "java -version" and then print "date" in a loop
while :
do
/home/bot/jdk/bin/java -version
date
done
3. A long time gap will be observed: may > 24 hours.
Technical details:
* host: x86_64 Linux 4.15.0-70-generic
* qemu v4.2.0
* java: tried two versions: openjdk-11-jre-headless or compiled java-13
* command-line: (See details in launch.sh)
/home/bot/qemu/qemu-build/qemu-4.2.0/binaries/bin/qemu-system-x86_64 \
-drive "file=${img},format=qcow2" \
-drive "file=${user_data},format=raw" \
-cpu max \
-m 24G \
-serial mon:stdio \
-smp 8 \
-nographic \
;
* Observed by java core dump generated by "kill -SIGSEGV" when java stucked:
Different pthreads are blocked on their own condition variables:
Id Target Id Frame
1Thread 0x7f48a041a080 (LWP 22470) __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:51
2Thread 0x7f487197d700 (LWP 22473) 0x7f489f5c49f3 in
futex_wait_cancelable (private=, expected=0,
futex_word=0x7f48980197c0)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
3Thread 0x7f4861b89700 (LWP 22483) 0x7f489f5c4ed9 in
futex_reltimed_wait_cancelable (private=,
reltime=0x7f4861b88960, expected=0,
futex_word=0x7f489801b084)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
4Thread 0x7f4861e8c700 (LWP 22480) 0x7f489f5c76d6 in
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0,
futex_word=0x7f48980107c0)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
5Thread 0x7f4861c8a700 (LWP 22482) 0x7f489f5c4ed9 in
futex_reltimed_wait_cancelable (private=,
reltime=0x7f4861c89800, expected=0,
futex_word=0x7f489801ed44)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
6Thread 0x7f48a0418700 (LWP 22471) 0x7f4880b13200 in ?? ()
7Thread 0x7f48703ea700 (LWP 22478) 0x7f489f5c49f3 in
futex_wait_cancelable (private=, expected=0,
futex_word=0x7f489801dfc0)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
8Thread 0x7f48702e9700 (LWP 22479) 0x7f489f5c49f3 in
futex_wait_cancelable (private=, expected=0,
futex_word=0x7f489838cd84)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
9Thread 0x7f4870f71700 (LWP 22475) 0x7f489f5c49f3 in
futex_wait_cancelable (private=, expected=0,
futex_word=0x7f489801a300)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
10 Thread 0x7f487187b700 (LWP 22474) 0x7f489f5c76d6 in
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0,
futex_word=0x7f48980cf770)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
11 Thread 0x7f4871a7f700 (LWP 22472) 0x7f489f5c76d6 in
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0,
futex_word=0x7f489809ba30)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
12 Thread 0x7f4861d8b700 (LWP 22481) 0x7f489f5c4ed9 in
futex_reltimed_wait_cancelable (private=,
reltime=0x7f4861d8a680, expected=0,
futex_word=0x7f489801ed44)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
13 Thread 0x7f48704ec700 (LWP 22477) 0x7f489f5c4ed9 in
futex_reltimed_wait_cancelable (private=,
reltime=0x7f48704eb910, expected=0,
futex_word=0x7f489801d120)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
14 Thread 0x7f4870e6f700 (LWP 22476) 0x7f489f5c4ed9 in
futex_reltimed_wait_cancelable (private=,
reltime=0x7f4870e6eb20, expected=0,
futex_word=0x7f489828abd0)
at ../sysdeps/unix/sysv/linux/futex-internal.h:142
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1862874/+subscriptions
[Bug 1870331] Re: default nic device created even though supplied by configfile
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1870331 Title: default nic device created even though supplied by configfile Status in QEMU: Expired Bug description: QEMU emulator version 4.1.94 Documentation states that qemu will create a default nic as long as not explicitly forbidden (-nic none) or defined ( e.g. -nic ). Observation: Even though qemu-system-ppc is started with "-readconfig" (which defines a nic), another nic gets created. When additionally suppling "-nic none", only the nic of the config file is created. As matter of fact, if all items that are defined in config file are supplied as command line arguments, no further nic is created. Expectation: When a nic is defined in config file, the default guest-nic should not get created. That would match behavior when all items, defined in config file are supplied as command line arguments. Attached config file. (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 1057:0002 PCI subsystem 1af4:1100 id "" Bus 0, device 1, function 0: VGA controller: PCI device 1234: PCI subsystem 1af4:1100 BAR0: 32 bit prefetchable memory at 0x8000 [0x80ff]. BAR2: 32 bit memory at 0x8100 [0x81000fff]. BAR6: 32 bit memory at 0x [0xfffe]. id "" Bus 0, device 2, function 0: Ethernet controller: PCI device 10ec:8029 PCI subsystem 1af4:1100 IRQ 23. BAR0: I/O at 0x1000 [0x10ff]. BAR6: 32 bit memory at 0x [0x0007fffe]. id "" Bus 0, device 3, function 0: Ethernet controller: PCI device 10ec:8029 PCI subsystem 1af4:1100 IRQ 24. BAR0: I/O at 0x1100 [0x11ff]. BAR6: 32 bit memory at 0x [0x0007fffe]. id "" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1870331/+subscriptions
[Bug 1897481] Re: qemu crashes with VGA pass-through, e-GPU, nvidia 1060
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1897481
Title:
qemu crashes with VGA pass-through, e-GPU, nvidia 1060
Status in QEMU:
Expired
Bug description:
I try to pass-through nvidia 1060 6gb card, which is connected via
ExpressCard (EXP-GDC converter).
I can successfully run my virtual machine without pass-through, but
when I try to add the devices, qemu crashes.
The coredump contains:
Stack trace of thread 3289311:
#0 0x00614c49 memory_region_update_container_subregions
(qemu-system-x86_64 + 0x214c49)
#1 0x005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 +
0x1c0e8c)
#2 0x005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0)
#3 0x0079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423)
#4 0x006facda device_set_realized (qemu-system-x86_64 + 0x2facda)
#5 0x00887e57 property_set_bool (qemu-system-x86_64 + 0x487e57)
#6 0x0088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48)
#7 0x0088d1d2 object_property_set_qobject (qemu-system-x86_64 +
0x48d1d2)
#8 0x0088b1f7 object_property_set_bool (qemu-system-x86_64 +
0x48b1f7)
#9 0x00693785 qdev_device_add (qemu-system-x86_64 + 0x293785)
#10 0x0061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0)
#11 0x0098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b)
#12 0x006211cb qemu_init (qemu-system-x86_64 + 0x2211cb)
#13 0x005002aa main (qemu-system-x86_64 + 0x1002aa)
#14 0x7fce8af21152 __libc_start_main (libc.so.6 + 0x28152)
#15 0x0050087e _start (qemu-system-x86_64 + 0x10087e)
The whole running command is pretty long, since I use libvirt to
manage my machines:
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
HOME=/var/lib/libvirt/qemu/domain-2-Win10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \
QEMU_AUDIO_DRV=spice \
/usr/bin/qemu-system-x86_64 \
-name guest=Win10,debug-threads=on \
-S \
-blockdev
'{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
\
-machine
pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
\
-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \
-m 8192 \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid 7043c77b-4903-4527-8089-9679d9a17fee \
-no-user-config \
-nodefaults \
-chardev stdio,mux=on,id=charmonitor \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
\
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox
VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}'
\
-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \
-blockdev
'{"driver":"file","filename":"/home/sergiy/Downloads/Win10_2004_Ukrainian_x64.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}'
\
-device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1 \
-chardev pty,id=charserial0 \
-device
[Bug 1869006] Re: PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg)
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1869006
Title:
PCIe cards passthrough to TCG guest works on 2GB of guest memory but
fails on 4GB (vfio_dma_map invalid arg)
Status in QEMU:
Expired
Bug description:
During one meeting coworker asked "did someone tried to passthrough
PCIe card to other arch guest?" and I decided to check it.
Plugged SATA and USB3 controllers into spare slots on mainboard and
started playing. On 1GB VM instance it worked (both cold- and hot-
plugged). On 4GB one it did not:
Błąd podczas uruchamiania domeny: internal error: process exited while
connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22
2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio :29:00.0:
failed to setup container for group 28: memory listener initialization failed:
Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x4000, 0x1,
0x7fb2a3e0) = -22 (Invalid argument)
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line
66, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in
startup
self._backend.create()
File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: process exited while connecting to
monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22
2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio :29:00.0:
failed to setup container for group 28: memory listener initialization failed:
Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x4000, 0x1,
0x7fb2a3e0) = -22 (Invalid argument)
I played with memory and 3054 MB is maximum value possible to boot VM with
coldplugged host PCIe cards.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1869006/+subscriptions
[Bug 1902306] Re: Allow setting usb storage device ID parameters
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1902306 Title: Allow setting usb storage device ID parameters Status in QEMU: Expired Bug description: Some stubborn software requires certain VID/PID/Serial to authenticate and refuses to start in emulation. This poses a problem with unsupported programs which often require keeping an ancient hardware praying that the USB stick will not die before the (often defunct) company making it. Virtualizing such environment is desired. However, QEMU doesn't allow setting VID/PID/Serial/Name of emulated USB devices, but instead uses hardcoded values: https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb /dev-storage.c#L95 This request (including a patch) was already made in 2015 on the list but never got any response: https://lists.nongnu.org/archive/html /qemu-discuss/2015-07/msg00072.html WDYT of adding such functionality? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1902306/+subscriptions
[Bug 1873769] Re: SB16 audio playback freezes emulation in Windows 95 guest
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1873769 Title: SB16 audio playback freezes emulation in Windows 95 guest Status in QEMU: Expired Bug description: - QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10 - Launched using "qemu-system-i386.exe -drive format=raw,file=hdd- 2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c" - I have attached video screen capture of the issue --- I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1873769/+subscriptions
[Bug 1878501] Re: qemu-i386 does not define AT_SYSINFO
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878501
Title:
qemu-i386 does not define AT_SYSINFO
Status in QEMU:
Expired
Bug description:
qemu-i386 does not define the AT_SYSINFO auxval when running i386
Linux binaries.
On most libcs, this is properly handled, but this is mandatory for the
i686 Bionic (Android) libc or it will segfault.
This is due to a blind assumption that getauxval(AT_SYSINFO) will
return a valid function pointer:
The code varies from version to version, but it looks like this:
void *__libc_sysinfo;
// mangled as _Z19__libc_init_sysinfov
void __libc_init_sysinfo() {
bool dummy;
// __bionic_getauxval = getauxval
__libc_sysinfo = reinterpret_cast(__bionic_getauxval(AT_SYSINFO,
dummy));
}
A simple way to reproduce is to compile a basic C program against the
NDK:
int main(void) { return 0; }
$ i686-linux-android-clang -static empty.c -o empty
$ qemu-i386 -cpu max ./empty
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
The place where it segfaults is misleading: It will, at least on the
current NDK, crash on __set_thread_area, this is due to it calling a
function pointer to __libc_sysinfo returned by __kernel_syscall.
QEMU 4.1.1 (aarch64)
Pixel 2 XL via Termux
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1878501/+subscriptions
[Bug 1904490] Re: intel-hda: valid registers are unknown
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1904490 Title: intel-hda: valid registers are unknown Status in QEMU: Expired Bug description: According to HDA specification, "3.1.2 General Register Behaviors and Access Requirements": "All controller registers must be addressable as byte, Word, and Dword quantities." But e.g. if you try the following to reset and enable the CORB, assuming es:esi contains the base MMIO address of the controller, es or [esi+4bh], byte 80h ; reset CORB corbresetloop: es test [esi+4bh], byte 80h ; is HW done resetting yet? jnz corbreset1ok; yes, bit is now 1 hlt ; wait a little bit jmp corbresetloop ; and check again corbreset1ok: es and [esi+4bh], byte 7fh ; clear the bit It will hang indefinitely because the bit never gets set, and if you enable debug output of the controller with "-device intel- hda,debug=1", you will see infinitely the line "unknown register, addr 0x4b" output. The same code on a real hardware (I tried with ICH7M) works fine, as it should according to the spec. Host/guest/version does not matter (I am writing own drivers) --- as of right now, latest version still has this code: https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c which seems to emit "unknown register" message in intel_hda_reg_find(), and this function does not take into account range of addresses that each register occupies. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1904490/+subscriptions
[Bug 1904317] Re: cpu feature selection is not affected to guest 's cpuid with whpx
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1904317 Title: cpu feature selection is not affected to guest 's cpuid with whpx Status in QEMU: Expired Bug description: On windows with -accel whpx, "-cpu" is ignored without any messages. Guest recognizes features as same as host's. Confirmed on v5.2.0-rc1. I suggest qemu may do, - Warn with incompatible -cpu options were given. - Enhance cpuid handling. Background: I was investigated mmio and block copy issue in Linux kernel. I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) I suspect erms(enhanced rep movs) might trigger. I tried to mask erms on qemu with -feature,erms, but it was ineffective. At last, I disabled erms manually, to tweak whpx-all.c to mask erms in cpuid. FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1904317/+subscriptions
[Bug 1904315] Re: CTRL+ALT is ignored on gtk window (configured with gtk and sdl)
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1904315 Title: CTRL+ALT is ignored on gtk window (configured with gtk and sdl) Status in QEMU: Expired Bug description: I am building and using qemu on Windows 10 via git. Building for targeting windows, on debian. Since meson is introduced, my executable, qemu-system-x86_64.exe, tends to ignore hotkeys (like CTRL+ATL+G, CTRL+ALT+2) As far as I have been investigating the issue, I am suspicious that gtk and sdl might be incompatible. With configure --disable-sdl, my executable works fine. My application doesn't require sdl. Possibly due to link order, especially SDLmain, I guess. I suggest; - Clarify that gtk and sdl are incompatible. - Tweak built script or startup not to prevent gtk and sdl each other. Excuse me, the issue has not been reproduced at home yet. I met it at work. (My manager said it's fine to report issues by me at home) I will construct reproducible environment at home, if my further investigation would be required. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1904315/+subscriptions
[Bug 1906181] Re: Mouse starts jumping wildly on guest desktop
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906181 Title: Mouse starts jumping wildly on guest desktop Status in QEMU: Expired Bug description: Sometimes mouse goes completely crazy and starts jumping around the guest desktop by itself and becomes completely unusable. This does not happen on every boot, only sometimes. It may be caused by some input combination but I haven't yet found any specific cause. It happens soon after the desktop has been loaded and rebooting seems to be the only way to resolve the situation. Guest: Kubuntu 20.04 64-bit (live), with KDE desktop Host: Arch Linux, with KDE desktop QEMU version: 5.1.0 QEMU start command: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906181/+subscriptions
[Bug 1874888] Re: certain programs make QEMU crash with "tcg fatal error"
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1874888
Title:
certain programs make QEMU crash with "tcg fatal error"
Status in QEMU:
Expired
Bug description:
The following code snippet crashes qemu with
.../tcg/tcg.c:3279: tcg fatal error
qemu-x86_64:
/usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int
cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed.
int main() {
/*
<.data>:
0: 2e 45 71 ff cs rex.RB jno 0x3
4: e9 00 00 f0 00 jmp0xf9
9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14]
e: c4 a3 7d 08 64 82 44vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0
15: 00
16: 0f 1e 0anopDWORD PTR [rdx]
19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8]
1d: 66 47 0f 3a 0c 3d 00rex.RXB blendps xmm15,XMMWORD PTR
[rip+0x8000],0x0# 0x8028
24: 80 00 00 00
28: c4 e3 f9 df 5f 86 0dvaeskeygenassist xmm3,XMMWORD PTR
[rdi-0x7a],0xd
2f: c4 e2 55 92 74 fc 0avgatherdps ymm6,DWORD PTR
[rsp+ymm7*8+0xa],ymm5
36: c4 e2 f9 17 9a 01 00vptest xmm3,XMMWORD PTR [rdx+0x1]
3d: 00 00
*/
char buf[] = {
0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D,
0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A,
0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00,
0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92,
0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00
};
void (*f)(void) = (void (*) (void))buf;
f();
return 0;
}
Steps to reproduce:
1) clang -static repro.c -o repro
2) qemu-x86_64-static repro
Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are
affected.
A few more snippets that cause the same sort of behavior:
1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00,
0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF,
0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A
2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00,
0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45,
0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C,
0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1874888/+subscriptions
[Bug 1906184] Re: Lots of stuttering/crackling in guest sound
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906184 Title: Lots of stuttering/crackling in guest sound Status in QEMU: Expired Bug description: When listening to music (e.g. with VLC) or watching Youtube on the guest, there's lots of stuttering and crackling in the sound. Tested with the following QEMU start commands: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk If I use the following command (QXL graphics, "remote" access via SPICE over unix socket), stuttering is not completely gone but MUCH less annoying: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing and this command for accessing the VM: remote-viewer spice+unix:///tmp/vm_spice.socket Guest: Kubuntu 20.04 64-bit (live), but occurs with many other as well Host: Arch Linux, with KDE desktop CPU: Intel Xeon E3-1230v2 (4 cores + hyperthreading) RAM: 16 GB GPU: Nvidia GTX 980 Ti To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906184/+subscriptions
[Bug 1905226] Re: intel-hda: stream reset bits are broken
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905226
Title:
intel-hda: stream reset bits are broken
Status in QEMU:
Expired
Bug description:
From HD audio spec, section 3.3.35:
"Stream Reset (SRST): Writing a 1 causes the corresponding stream to
be reset. [...] After the stream hardware has completed sequencing
into the reset state, it will report a 1 in this bit. Software must
read a 1 from this bit to verify that the stream is in reset. Writing
a 0 causes the corresponding stream to exit reset. When the stream
hardware is ready to begin operation, it will report a 0 in this bit.
Software must read a 0 from this bit before accessing any of the
stream registers."
So to reset a stream I set the bit, but it never reads back as 1 so
the driver either times out or will hang forever waiting for it to
become 1. I looked into why this happens and found that as of the
latest version (8110fa1), in function intel_hda_set_st_ctl() of the
https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c,
if (st->ctl & 0x01) {
/* reset */
dprint(d, 1, "st #%d: reset\n", reg->stream);
st->ctl = SD_STS_FIFO_READY << 24;
}
This causes the bit to immediately become set to 0 even if I write a
1, and clearly does not meet the spec. I checked behaviour of real
hardware and it works as expected, i.e. I see the bit will become 1
and 0 when I write to it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905226/+subscriptions
[Bug 1904652] Re: Assertion failure in usb-ohci
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1904652 Title: Assertion failure in usb-ohci Status in QEMU: Expired Bug description: Hello, Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ohci. A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. This was found in version 5.2.0 (master) ``` Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. [Current thread is 1 (Thread 0x7f34d0411440 (LWP 9418))] gdb-peda$ bt #0 0x7f34c8d4ef47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7f34c8d508b1 in __GI_abort () at abort.c:79 #2 0x55d3a2081844 in ohci_frame_boundary (opaque=0x55d3a4ecdaf0) at ../hw/usb/hcd-ohci.c:1297 #3 0x55d3a25be155 in timerlist_run_timers (timer_list=0x55d3a3fd9840) at ../util/qemu-timer.c:574 #4 0x55d3a25beaba in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 #5 0x55d3a25beaba in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 #6 0x55d3a25e69a1 in main_loop_wait (nonblocking=) at ../util/main-loop.c:531 #7 0x55d3a2433972 in qemu_main_loop () at ../softmmu/vl.c:1678 #8 0x55d3a1d0969b in main (argc=, argc@entry=0x15, argv=, argv@entry=0x7ffc6de722a8, envp=) at ../softmmu/main.c:50 #9 0x7f34c8d31b97 in __libc_start_main (main= 0x55d3a1d09690 , argc=0x15, argv=0x7ffc6de722a8, init=, fini=, rtld_fini=, stack_end=0x7ffc6de72298) at ../csu/libc-start.c:310 #10 0x55d3a1d095aa in _start () ``` To reproduce the assertion failure, please run the QEMU with the following command line. ``` [Terminal 1] $ qemu-system-i386 -m 512 -drive file=./fs.img,index=1,media=disk,format=raw -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device pci-ohci,id=usb -device usb-storage,bus=usb.0,drive=stick [Terminal 2] $ ./repro_log ./fs.img ./pci-ohci ``` Please let me know if I can provide any further info. -Cheolwoo, Myung (Seoul National University) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1904652/+subscriptions
[Bug 1906185] Re: Guest display resolution cannot be changed when using certain graphics/interface combinations
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906185 Title: Guest display resolution cannot be changed when using certain graphics/interface combinations Status in QEMU: Expired Bug description: Guest display resolution cannot be changed with certain virtual graphics card (-vga) and interface (-display) combinations. For example, resolution changing doesn't work with the following QEMU start commands, it resets to the default resolution immediately: QXL with SDL interface: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl QXL with GTK interface: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk QXL with "remote" SPICE interface via unix socket: qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing for "remote" access: remote-viewer spice+unix:///tmp/vm_spice.socket Other tested combinations: -- virtio + SDL (GL on): works! -- virtio + GTK (GL on): does not work properly. The resolution is changed but window size is not so the guest screen will look like garbage. -- vmware: The initial Kubuntu setup screen is visible but booting does not progress to the desktop -- std + GTK: works! -- std + SDL: works! QEMU version: 5.1.0 Guest: Kubuntu 20.04 64-bit (live) with 5.4.0-26 kernel; may occur with other guests as well Host: Arch Linux, with KDE desktop To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906185/+subscriptions
[Bug 1905297] Re: Zynq7000 UART clock reset initialization
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1905297 Title: Zynq7000 UART clock reset initialization Status in QEMU: Expired Bug description: Hello, we have come across a strange behavior in the Zynq7000 model of Qemu that seems to have been introduced between 5.0.0 and 5.1.0. The reset values of the SLCR register, in particular those for UART_CLK_CTRL, are such that the UARTs should find functional clocks. Up to 5.0.0 this was also the behavior that was implemented in QEMU. Starting in 5.1.0, we found that - despite correct reset values [1] - the UARTs are non-functional upon reset. Some investigation revealed that the cause for that is that the corresponding clocks are not properly initialized. Between 5.0.0 and 5.1.0, there are three commits that touch the Zynq UART clocks [2]. The last of them [3] triggers the faulty behavior. Attached is a patch that applies 5.2.0-rc2 and yields a functional UART. We surmise that the underlying device release issue runs much deeper, so it is only meant to identify the issue. [1] hw/misc/zynq_slcr.c static void zynq_slcr_reset_init(Object *obj, ResetType type) s->regs[R_UART_CLK_CTRL] = 0x3F03; [2] 38867cb7ec90..5b49a34c6800 [3] commit 5b49a34c6800d0cb917f959d8e75e5775f0fac3f (refs/bisect/bad) Author: Damien Hedde Date: Mon Apr 6 15:52:50 2020 +0200 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1905297/+subscriptions
[Bug 1907061] Re: qemu-system-x86_64 minimizing window causes keyboard input lag globally
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907061 Title: qemu-system-x86_64 minimizing window causes keyboard input lag globally Status in QEMU: Expired Bug description: After qemu window is minimized, it causes keyboard lag on the host for all applications, pressed keys will be delayed and very laggy, typing to notepad or any other text extremely slowly appear on the screen, queue is slowly processed. If qemu window is open back to normal size, keyboard is back to normal, everything is back to normal and stable, this behavior i have been testing since several months of qemu releases, i am reporting a bit late here, not breaking but it seems important and everytime i accidently minimize qemu, i remember it later and take qemu window to normal size back always, i try never minimize it anymore. This problem does not occur if using -display none Guest OS doesn't matter for this behavior, result is always same I am using: qemu 5.1.0.0 qemu-system-x86_64w.exe Windows 10 build 2004 4K screen dpi scaling set to 150% If requested, i can record a video to see the problem clearly, but i think all information i give already clear now. Thanks for making quality software, hope all bugs fixed To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907061/+subscriptions
[Bug 1905562] Re: Guest seems suspended after host freed memory for it using oom-killer
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905562
Title:
Guest seems suspended after host freed memory for it using oom-killer
Status in QEMU:
Expired
Bug description:
Host: qemu 5.1.0, linux 5.5.13
Guest: Windows 7 64-bit
This guest ran a memory intensive process, and triggered oom-killer on
host. Luckily, it killed chromium. My understanding is this should
mean qemu should have continued running unharmed. But, the spice
connection shows the host system clock is stuck at the exact time oom-
killer was triggered. The host is completely unresponsive.
I can telnet to the qemu monitor. "info status" shows "running".
But, multiple times running "info registers -a" and saving the output
to text files shows the registers are 100% unchanged, so it's not
really running.
On the host, top shows around 4% CPU usage by qemu. strace shows
about 1,000 times a second, these 6 lines repeat:
0.000698 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c10) = 0 <0.10>
0.34 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c60) = 0 <0.09>
0.31 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c20) = 0 <0.07>
0.28 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c70) = 0 <0.07>
0.30 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events
=POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34,
events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41,
events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN},
{fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=0},
NULL, 8) = 0 (Timeout) <0.09>
0.43 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events
=POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34,
events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41,
events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN},
{fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0,
tv_nsec=769662}, NULL, 8) = 0 (Tim eout) <0.000788>
In the monitor, "info irq" shows IRQ 0 is increasing about 1,000 times
a second. IRQ 0 seems to be for the system clock, and 1,000 times a
second seems to be the frequency a windows 7 guest might have the
clock at.
Those fd's are for: (9) [eventfd]; [signalfd], type=STREAM, 4 x the
spice socket file, and "TCP localhost:ftnmtp->localhost:36566
(ESTABLISHED)".
Because the guest's registers aren't changing, it seems to me like
monitor thinks the VM is running, but it's actually effectively in a
paused state. I think all the strace activity shown above must be
generated by the host. Perhaps it's repeatedly trying to contact the
guest to inject a new clock, and communicate with it on the various
eventfd's, spice socket, etc. So, I'm thinking the strace doesn't
give any information about the real reason why the VM is acting as if
it's paused.
I've checked "info block", and there's nothing showing that a device
is paused, or that there's any issues with them. (Can't remember what
term can be there, but a paused/blocked/etc block device I think
caused a VM to act like this for me in the past.)
Is there something I can provide to help fix the bug here?
Is there something I can do, to try to get the VM running again? (I
sadly have unsaved work in it.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905562/+subscriptions
[Bug 1906516] Re: [RISCV] sfence.vma need to end the translation block
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906516 Title: [RISCV] sfence.vma need to end the translation block Status in QEMU: Expired Bug description: QEMU emulator version 5.0.0 sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: ``` relocate: li a0, OFFSET la t0, 1f add t0, t0, a0 csrw stvec, t0 la t0, early_pgtbl srl t0, t0, PAGE_SHIFT li t1, SATP_SV39 or t0, t1, t0 csrw satp, t0 1: sfence.vma la t0, trap_s csrw stvec, t0 ret ``` In this code, I want to relocate pc to virtual address with the OFFSET prefix. Before writing to satp, pc run at physic address, stvec has been set to label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, qemu will throw a page fault, and pc will set to virtual address of label 1. The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, ``` IN: Priv: 1; Virt: 0 0x80dc: 00a080b3 add ra,ra,a0 0x80e0: 7297 auipc t0,28672# 0x800070e0 0x80e4: f2028293 addit0,t0,-224 0x80e8: 00c2d293 srlit0,t0,12 0x80ec: fff0031b addiw t1,zero,-1 0x80f0: 03f31313 sllit1,t1,63 0x80f4: 005362b3 or t0,t1,t0 0x80f8: 18029073 csrrw zero,satp,t0 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero 0x8100: 0297 auipc t0,0# 0x8100 0x8104: 1c828293 addit0,t0,456 0x8108: 10529073 csrrw zero,stvec,t0 riscv_raise_exception: 12 riscv_raise_exception: 12 riscv_raise_exception: 12 riscv_raise_exception: 12 ... ``` So, the program will crash, and the program will work in single step mode: ``` IN: Priv: 1; Virt: 0 0x80f8: 18029073 csrrw zero,satp,t0 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero riscv_raise_exception: 12 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero IN: Priv: 1; Virt: 0 0x8100: 0297 auipc t0,0# 0x8100 ``` The pc will set to label 1, instead of trap_s. I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: ``` tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); exit_tb(ctx); ctx->base.is_jmp = DISAS_NORETURN; ``` This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906516/+subscriptions
[Bug 1907926] Re: Implement TPM2 configuration for emulators that provide TCP interface
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907926 Title: Implement TPM2 configuration for emulators that provide TCP interface Status in QEMU: Expired Bug description: swtpm provides several interfaces for its emulated device: unix socket (can be used by qemu), chardev. swtpm also provides TCP interface for the device which is very convenient for testing as it does not require root permissions. It would be very useful to have QEMU to work with TPM devices emulated via TCP. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907926/+subscriptions
[Bug 1907210] Re: QEMU gdbstub command "?" issue
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907210 Title: QEMU gdbstub command "?" issue Status in QEMU: Expired Bug description: I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. Here is documentation from official gdb: ‘?’ Indicate the reason the target halted. The reply is the same as for step and continue. This packet has a special interpretation when the target is in non-stop mode; see Section E.10 [Remote Non-Stop], page 733. Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). Function that handles "?" command has this comment in it: /* * Remove all the breakpoints when this query is issued, * because gdb is doing an initial connect and the state * should be cleaned up. */ From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. In my opinion initial connect should be detected in some other way, and not with "?" command. Also note that official gdbserver does not remove the BPs when this command is send, this issue is present in QEMU and apparently also on kgdb(I was told that on irc, have not tested it myself) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907210/+subscriptions
[Bug 1905651] Re: Tests cannot call g_error
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1905651
Title:
Tests cannot call g_error
Status in QEMU:
Expired
Bug description:
I stumbled on this writing a new test, using tests/qtest/e1000e-test.c
as a template.
g_error() causes SIGTRAP, not SIGABRT, and thus the abort handler doesn't get
run.
This in turn means qemu is not killed, which hangs the test because the
tap-driver.pl script hangs waiting for more input.
There are a few tests that call g_error().
The SIGABRT handler explicitly kills qemu, e.g.:
qos-test.c:
qtest_add_abrt_handler(kill_qemu_hook_func, s);
ref:
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/qtest/libqtest.c;h=e49f3a1e45f4cd96279241fdb2bbe231029ab922;hb=HEAD#l272
But not unexpectedly there's no such handler for SIGTRAP.
Apply this patch to trigger a repro:
diff --git a/tests/qtest/e1000e-test.c b/tests/qtest/e1000e-test.c
index fc226fdfeb..e83ace1b5c 100644
--- a/tests/qtest/e1000e-test.c
+++ b/tests/qtest/e1000e-test.c
@@ -87,6 +87,9 @@ static void e1000e_send_verify(QE1000E *d, int
*test_sockets, QGuestAllocator *a
/* Wait for TX WB interrupt */
e1000e_wait_isr(d, E1000E_TX0_MSG_ID);
+g_message("Test g_error hang ...");
+g_error("Pretend something timed out");
+
/* Check DD bit */
g_assert_cmphex(le32_to_cpu(descr.upper.data) & dsta_dd, ==, dsta_dd);
Then:
configure
make
make check-qtest-i386
check-qtest-i386 will take awhile. To repro faster:
$ grep qtest-i386/qos-test Makefile.mtest
.test.name.229 := qtest-i386/qos-test
$ make run-test-229
Running test qtest-i386/qos-test
** Message: 18:40:49.821: Test g_error hang ...
** (tests/qtest/qos-test:3820728): ERROR **: 18:40:49.821: Pretend something
timed out
ERROR qtest-i386/qos-test - Bail out! FATAL-ERROR: Pretend something timed out
At this point things are hung because tap-driver.pl is still waiting
for input because qemu is still running.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1905651/+subscriptions
[Bug 1906536] Re: Unable to set SVE VL to 1024 bits or above since 7b6a2198
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906536 Title: Unable to set SVE VL to 1024 bits or above since 7b6a2198 Status in QEMU: Expired Bug description: Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. To reproduce the issue: $ cat rdvl.s .global _start _start: rdvl x0, #1 asr x0, x0, #4 mov x8, #93 // exit svc #0 $ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o $ aarch64-linux-gnu-ld rdvl.o $ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done 1 2 4 4 4 For a QEMU built prior to the above revision, we get the output: 1 2 4 8 16 as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906536/+subscriptions
[Bug 1907776] Re: Mounting VFat drive yields error messages.
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1907776 Title: Mounting VFat drive yields error messages. Status in QEMU: Expired Bug description: Mounting a virtual Fat drive results in error messages (see attached image). * https://www.qemu.org/docs/master/system/images.html#virtual-fat- disk-images The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. Archlinux 5.9.11-arch2-1 (64-bit) qemu-headless 5.1.0-3 qemu-system-x86_64 -boot order=d -name test \ -enable-kvm -m 2G -cpu host -k sv \ -daemonize \ -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ -vnc :1 \ -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907776/+subscriptions
[Bug 1906608] Re: [Feature request]For some ehci controller, qemu should implement using portsc[26-27] to detect the speed of device.
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906608
Title:
[Feature request]For some ehci controller, qemu should implement
using portsc[26-27] to detect the speed of device.
Status in QEMU:
Expired
Bug description:
for some ehci controller ,for example ehci controller on fsl_imx6,it
using portsc[26-27] to decide a full speed device or high speed device
was connected, hub-ehci.c should set the portsc[26-27] to return the
right speed.
line:1001 in hub-ehci.c
if (dev && dev->attached && (dev->speedmask & USB_SPEED_MASK_HIGH)) {
val |= PORTSC_PED;
}
below is the spec for fsl_imx6 USB PART.
PORTSC:27–26 :PSPD
Port Speed - Read Only.
This register field indicates the speed at which the port is operating.
00 Full Speed
01 Low Speed
10 High Speed
11 Undefined
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906608/+subscriptions
[Bug 1741718] Re: qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1741718 Title: qemu-system-sparc64: "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" with tribblix-sparc-0m16.iso Status in QEMU: Expired Bug description: qemu-system-sparc64 Niagara VM running Tribblix crashes with "panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found" on QEMU 2.11.0. Happens also with 1 GB, 4 GB, and 8 GB of RAM. $ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive if=pflash,readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 2048 cpu Probing I/O buses Sun Fire T2000, No Keyboard Copyright 2005 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. [mo23723 obp4.20.0 #0] Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. ok boot Boot device: vdisk File and args: hsfs-file-system Loading: /platform/sun4v/boot_archive ramdisk-root ufs-file-system Loading: /platform/sun4v/kernel/sparcv9/unix \ panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found Warning - stack not written to the dumpbuf 0180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 81010100, ff00) %l0-3: 01876c00 010d6c00 %l4-7: 80008f000740 80008fc54750 f0254cc4 010dedd0 0180b800 unix:plat_lgrp_init+14 (4, 180e000, 4, 0, 180b950, 1) %l0-3: fff32000 fff340e0 fff34590 010d5f28 %l4-7: 0016 0016 0011 0180b8b0 unix:lgrp_plat_init+74 (0, 0, 0, 180ba08, 180ba00, 91) %l0-3: 2000 fff34000 01874c00 01874c00 %l4-7: 01874c00 0180b950 010de048 0180b960 unix:lgrp_init+4 (0, 2000, 70002000, 0, 180c0e8, 0) %l0-3: 0180e380 0183c678 0180ba08 010d4f90 %l4-7: 010d4fa0 010d1c00 4000 80001070 0180ba10 unix:mlsetup+2f4 (180bb80, 180bec0, 0, 0, f025496c, 0) %l0-3: 018ee000 70002000 70002000 0180bad0 %l4-7: 0190c4d8 0001001f56e0 80001070 ERROR: Last Trap: Level 14 Interrupt [Exception handlers interrupted, please file a bug] [type 'resume' to attempt a normal recovery] Without "if=pflash" VM hangs: $ qemu-system-sparc64 -nographic -M niagara -L /home/newman/Downloads/OpenSPARCT1_Arch.1.5/S10image/ -drive readonly=on,file=/home/newman/Downloads/tribblix-sparc-0m16.iso -m 4096 cpu Probing I/O buses Sun Fire T2000, No Keyboard Copyright 2005 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.20.0, 256 MB memory available, Serial #1122867. [mo23723 obp4.20.0 #0] Ethernet address 0:80:3:de:ad:3, Host ID: 80112233. ok boot Boot device: vdisk File and args: qemu: fatal: Trap 0x0032 while trap level (6) >= MAXTL (6), Error state pc: 0040f01c npc: 0040f020 %g0-3: 00970280 %g4-7: 1000 %o0-3: 8ffd6000 8000 %o4-7: 00f0 fff55701 f020d78c %l0-3: 0002fd10 7ffe 8000 %l4-7: 000b 80008fffa750 f026fbf0 f022a0d8 %i0-3: 8000 1000 %i4-7: %f00: %f08: %f16: %f24: %f32: %f40: %f48: %f56: pstate: 0014 ccr: 11 (icc: ---C xcc: ---C) asi: 20 tl: 6 pil: d gl: 6 tbr: f020 hpstate: 0004 htba: 0040 cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 0 fsr: y: fprs: 0004 To manage notifications about this bug go to:
[Bug 1895602] Re: older OS's do not detect CD change
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1895602 Title: older OS's do not detect CD change Status in QEMU: Expired Bug description: There are at least two older operating systems, being FreeBSD 2.2 and FreeDOS 1.2, that misbehave when the change command is used on the IDE CD drive, and work fine on a real machine. In both cases, changing the CD causes the guest to either refuse to read the disc or appear to read bad data, and in both cases the guest read the disc without issue after a system_reset. A HD image that demonstrates this behavior can be produced if necessary, however the FreeDOS 1.2 CD can be booted directly and used to test: http://freedos.org/download/download/FD12CD.iso (choose install then abort and you get a prompt in which you can type "dir D:", say) note, running eject before the change command does nothing to help. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1895602/+subscriptions
[Bug 1839807] Re: Snapshots freeze guest Sabrelite IMX.6 board
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1839807 Title: Snapshots freeze guest Sabrelite IMX.6 board Status in QEMU: Expired Bug description: Hello, I'm trying to take and restore a snapshot with the whole system state of the Sabrelite IMX.6 board running on QEMU with commands savevm/loadvm. It seems that I am able to take a snapshot but loading the snapshot fails. For comparison I checked out snapshots on 32bit ARM Virt with Debian as well as on the Versatilepb board with a bare metal application and it works fine. The problem occurs only with that one particular board. My environment is: Ubuntu 18.04 QEMU 3.0.1 (I see the same issue in QEMU 4.0.0 as well) The kernel and device tree used for the board was 5.1.14 version from kernel.org The file system was build from imx_v6_v7_defconfig config in buildroot as and sd card image. Problem: Loading snapshot stops the whole machine and it's impossible to resume it. Steps to reproduce problem: 1. I converted the sdcard.img built from the buildroot to qcow2 using command qemu-img convert -f raw -O qcow2 sdcard.img sdcard.qcow2, since the raw doesn't support snapshots. 2. I start QEMU with a command ./arm-softmmu/qemu-system-arm -m 512 -M sabrelite -kernel zImage -append "rootfstype=ext4 root=/dev/mmcblk2p2 rw rootwait" -rtc base=localtime,clock=vm -dtb imx6dl-sabresd.dtb -drive file=sdcard.qcow2,index=2,format=qcow2,id=mycard -device sd-card,drive=mycard -nographic -net nic -net user 3. I run a simple program which print characters to the console in the background and add some files in user directory, to differ from original image. 4. I switch to QEMU monitor, and type “savevm ”. When I type “info snapshots”, the snapshot is listed. So I assume it was saved correctly. 5. Then I switch back to Linux console from monitor, remove the added files and stop the background printing process. 6. I switch back to monitor and I'm trying now to load the snapshot by “loadvm ” command. That’s where the problem occurs. QEMU stops and I can't switch back from monitor to Linux. Typing “cont” doesn’t help. It seems like the simulation has freezed. CPU usage on my Laptop machine equals 100% until I exit QEMU. What’s interesting when I exit the QEMU and then start it again the Linux boots and after it reaches the command prompt I can see the files which were removed after saving the snapshot. It looks like loading the snapshots works for restoring disk space but it fails for restoring the running processes. Due to the answer on QEMU mailing list (https://lists.nongnu.org/archive/html/qemu- discuss/2019-08/msg00016.html) it is QEMUs bug. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1839807/+subscriptions
[Bug 1849894] Re: hw/scsi/scsi-disk.c line 2554 allocation overflow
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1849894 Title: hw/scsi/scsi-disk.c line 2554 allocation overflow Status in QEMU: Expired Bug description: When compiling qemu from git master (at commit 03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9 9.2.1 , and using `-march=native -flto`, during linking of most target binaries, compiler does detect an issue with allocation in scsi_disk_new_request_dump and aborts compilation. make[1]: Entering directory '/home/user/qemu/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/user/qemu/slirp' nm: stats64.o: no symbols LINKaarch64-softmmu/qemu-system-aarch64 In function ‘scsi_disk_new_request_dump’, inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9, inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21: hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] hw/scsi/scsi-disk.c: In function ‘scsi_new_request’: /usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function ‘g_malloc’ declared here 78 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1); | ^ lto1: all warnings being treated as errors lto-wrapper: fatal error: c++ returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status same happens for most other targets: alpha-softmmu/qemu-system-alpha arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu /qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu- system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu- system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu- system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu- system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu- system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system- sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system- sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system- xtensa xtensaeb-softmmu/qemu-system-xtensaeb Notice -softmmu being a common factor here. The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so. The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5. However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0]. I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_alloc_req calling these alloc_req callbacks, but it is itself called from scsi_req_new, which is called in get_scsi_requests , just after buf is filled from QEMUFile using qemu_get_buffer, which ultimately goes even further into read paths, which there might be many AFAIK. glib2 version 2.62.1-1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1849894/+subscriptions
[Bug 1861161] Re: qemu-arm-static stuck with 100% CPU when cross-compiling emacs
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1861161 Title: qemu-arm-static stuck with 100% CPU when cross-compiling emacs Status in QEMU: Expired Bug description: Hello, I'm trying to build multi-arch docker images for https://hub.docker.com/r/silex/emacs. Here is the machine I'm building on (hetzner cloud machine): root@ubuntu-4gb-fsn1-1:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.3 LTS Release:18.04 Codename: bionic root@ubuntu-4gb-fsn1-1:~# uname -a Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Whenever I try to build the following alpine Dockerfile https://gitlab.com/Silex777/docker- emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile like this: $ sysctl kernel.randomize_va_space=0 $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes $ docker build --pull -t test --platform arm . It builds fine until this: root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu root 26473 26465 99 14:26 pts/001:59:58 /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el This is supposed to take a few seconds, but here it takes 100% CPU and never ends. When I strace the process I see a never ending loop like this: getdents64(5, /* 0 entries */, 2048)= 0 lseek(5, 0, SEEK_SET) = 0 getdents64(5, /* 5 entries */, 2048)= 120 tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) getdents64(5, /* 0 entries */, 2048)= 0 lseek(5, 0, SEEK_SET) = 0 getdents64(5, /* 5 entries */, 2048)= 120 tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) getdents64(5, /* 0 entries */, 2048)= 0 lseek(5, 0, SEEK_SET) = 0 getdents64(5, /* 5 entries */, 2048)= 120 tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) getdents64(5, /* 0 entries */, 2048)= 0 lseek(5, 0, SEEK_SET) = 0 getdents64(5, /* 5 entries */, 2048)= 120 tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) getdents64(5, /* 0 entries */, 2048)= 0 lseek(5, 0, SEEK_SET) = 0 getdents64(5, /* 5 entries */, 2048)= 120 tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) It happens with all the QEMU versions I tested: - 2.11.1 (OS version) - 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1) - 4.2.0-2 (from multiarch/qemu-user-static) Any ideas of what I could do to debug it further? Kind regards, Philippe p.s: Everything builds fine when the base image is ubuntu. I also had similar hangs with basic commands like "apt-get install foo" sometimes. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1861161/+subscriptions
