[Qemu-devel] [Bug 1486911] Re: Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian))
** Changed in: qemu Status: New => Incomplete ** Changed in: qemu Assignee: (unassigned) => pranith (bobby-prani) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1486911 Title: Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian)) Status in QEMU: Incomplete Bug description: When compiling from source occurs to me incomprehensible error. Operation ./configure runs without problems, but among the logs make see this: CP i386-softmmu / hw / i386 / acpi-dsdt.hex CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex CP i386-softmmu / hw / i386 / ssdt-tpm.hex CC i386-softmmu / target-i386 / translate.o CC m68k-softmmu / tcg / tcg-op.o CC m68k-softmmu / tcg / optimize.o In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0, from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31, from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44, from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31: /home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ uint64_t' /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «tcg / optimize.o» make [1]: *** [tcg / optimize.o] Error 1 Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu» make: *** [subdir-m68k-softmmu] Error 2 make: *** Waiting for jobs ... When you try to create a package using checkinstall is such error: /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 'helper_msa_copy_s_df': /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: unrecognizable insn: (insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / msa_helper.c: 1253 -1 (nil)) /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal compiler error: in extract_insn, at recog.c: 2109 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to your bugreport. /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «target-mips / msa_helper.o» make [1]: *** [target-mips / msa_helper.o] Error 1 Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu» make: *** [subdir-mips64-softmmu] Error 2 Installation unsuccessful. It cancels the creation of the package. Cleared ... OK Good luck. Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6 cc1quRqL.out applications To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1486911/+subscriptions
[Qemu-devel] [Bug 1531632] Re: Can't compile qemu because of errors in the Xen code
Can you post the `configure` command line you used when you try to compile? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1531632 Title: Can't compile qemu because of errors in the Xen code Status in QEMU: New Bug description: I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: First I have to disable -Werror, because it claims about some uninitialized variables. Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. Output of make: CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4, from /home/leo/qemu/hw/block/xen_disk.c:39: /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here typedef uint32_t ioservid_t; ^ In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); ^ /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); ^ /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed make: *** [hw/block/xen_disk.o] Error 1 [leo@AlphaArch build]$ make CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4, from /home/leo/qemu/hw/block/xen_disk.c:39: /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here typedef uint32_t ioservid_t; ^ In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); ^ /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); ^ /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed make: *** [hw/block/xen_disk.o] Error 1 [leo@AlphaArch build]$ make CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
[Qemu-devel] [Bug 893208] Re: qemu on ARM hosts can't boot i386 image
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893208 Title: qemu on ARM hosts can't boot i386 image Status in QEMU: Confirmed Status in Linaro QEMU: New Bug description: If you apply some workarounds for bug 870990, bug 883133 and bug 883136 QEMU still cannot boot the i386 debian_squeeze_i386_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot but something causes the system to reset just before display of the blue-background grub menu, so we go round in a loop forever. This image boots OK on i386 hosted qemu so this indicates some kind of ARM- host specific bug. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/893208/+subscriptions
[Qemu-devel] [Bug 1470170] Re: Unsupported syscalls 370 and 355
Fix has been committed upstream. ** Changed in: qemu Status: New => 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/1470170 Title: Unsupported syscalls 370 and 355 Status in QEMU: Fix Released Bug description: Qemu seems to be missing syscalls 370 and 355 when running qemu usermode arm. These are used by systemd or some similar new package. This can be detected by creating an debian sid armhf with qemu debootstrap. When the system is launched with "systemd-nspawn -bD sid- arm" this happens (newest git as of today): pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. Press ^] three times within 1s to kill container. Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system /etc/localtime is not a symlink, not updating container timezone. qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 384 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 qemu: Unsupported syscall: 370 systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) Detected virtualization systemd-nspawn. Detected architecture arm. Welcome to Debian GNU/Linux stretch/sid! Set hostname to . qemu: Unsupported syscall: 355 Failed to allocate manager object: Function not implemented [!!] Failed to allocate manager object, freezing. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1470170/+subscriptions
[Qemu-devel] [Bug 1486911] Re: Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian))
Can you try the latest upstream git version from: https://github.com/qemu/qemu? Also can you post your configure command line? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1486911 Title: Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian)) Status in QEMU: New Bug description: When compiling from source occurs to me incomprehensible error. Operation ./configure runs without problems, but among the logs make see this: CP i386-softmmu / hw / i386 / acpi-dsdt.hex CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex CP i386-softmmu / hw / i386 / ssdt-tpm.hex CC i386-softmmu / target-i386 / translate.o CC m68k-softmmu / tcg / tcg-op.o CC m68k-softmmu / tcg / optimize.o In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0, from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31, from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44, from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31: /home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ uint64_t' /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «tcg / optimize.o» make [1]: *** [tcg / optimize.o] Error 1 Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu» make: *** [subdir-m68k-softmmu] Error 2 make: *** Waiting for jobs ... When you try to create a package using checkinstall is such error: /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 'helper_msa_copy_s_df': /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: unrecognizable insn: (insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / msa_helper.c: 1253 -1 (nil)) /home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal compiler error: in extract_insn, at recog.c: 2109 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to your bugreport. /home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «target-mips / msa_helper.o» make [1]: *** [target-mips / msa_helper.o] Error 1 Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu» make: *** [subdir-mips64-softmmu] Error 2 Installation unsuccessful. It cancels the creation of the package. Cleared ... OK Good luck. Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6 cc1quRqL.out applications To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1486911/+subscriptions
[Qemu-devel] [Bug 1481990] Re: 2.3.0 build fails on Ubuntu 12.04
This does not happend anymore with the upstream git. Closing. Please reopen if you still see this. ** Changed in: qemu Status: New => 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/1481990 Title: 2.3.0 build fails on Ubuntu 12.04 Status in QEMU: Fix Released Bug description: Build of 2.3.0 fails on Ubuntu 12.04: sudo make clean sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm-softmmu,x86_64-softmmu sudo make GEN config-host.h GEN qemu-options.def GEN qmp-commands.h GEN qapi-types.h GEN qapi-visit.h GEN qapi-event.h GEN trace/generated-events.h GEN trace/generated-tracers.h ... CCmigration/qemu-file-stdio.o CCmigration/xbzrle.o CCmigration/rdma.o migration/rdma.c: In function ‘qemu_rdma_dump_id’: migration/rdma.c:706:21: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ migration/rdma.c:707:22: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ migration/rdma.c:707:37: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) migration/rdma.c:707:37: note: each undeclared identifier is reported only once for each function it appears in migration/rdma.c:708:24: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ migration/rdma.c:708:39: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) migration/rdma.c: In function ‘qemu_rdma_broken_ipv6_kernel’: migration/rdma.c:800:26: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ migration/rdma.c:800:41: error: ‘IBV_LINK_LAYER_INFINIBAND’ undeclared (first use in this function) migration/rdma.c:802:33: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ migration/rdma.c:802:48: error: ‘IBV_LINK_LAYER_ETHERNET’ undeclared (first use in this function) migration/rdma.c:841:18: error: ‘struct ibv_port_attr’ has no member named ‘link_layer’ make: *** [migration/rdma.o] Error 1 Build succeeds with sudo ./configure --prefix=/usr/local --target-list=i386-softmmu,arm- softmmu,x86_64-softmmu --disable-rdma To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1481990/+subscriptions
[Qemu-devel] [Bug 1478360] Re: Cant compile on ubuntu 14.04 x64
** Changed in: qemu 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/1478360 Title: Cant compile on ubuntu 14.04 x64 Status in QEMU: Fix Released Bug description: ./configure --static Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin library directory /usr/local/lib module directory /usr/local/lib/qemu libexec directory /usr/local/libexec include directory /usr/local/include config directory /usr/local/etc local state directory /usr/local/var Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/slobodan/qemu C compilercc Host C compiler cc C++ compiler c++ Objective-C compiler cc ARFLAGS rv CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g QEMU_CFLAGS -I/usr/include/pixman-1-Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/libpng12 LDFLAGS -Wl,--warn-common -m64 -static -g make make install install pythonpython -B smbd /usr/sbin/smbd module supportno host CPU x86_64 host big endian no target listaarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu aarch64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user sparc64-linux-user unicore32-linux-user x86_64-linux-user tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build yes pixmansystem SDL support no GTK support yes GNUTLS supportyes GNUTLS hash yes GNUTLS gcrypt yes GNUTLS nettle no () VTE support no curses supportno curl support no mingw32 support no Audio drivers oss Block whitelist (rw) Block whitelist (ro) VirtFS supportno VNC support yes VNC TLS support no VNC SASL support no VNC JPEG support yes VNC PNG support yes xen support no brlapi supportno bluez supportyes Documentation no GUEST_BASEyes PIE no vde support no netmap supportno Linux AIO support no ATTR/XATTR support yes Install blobs yes KVM support yes RDMA support no TCG interpreter no fdt support yes preadv supportyes fdatasync yes madvise yes posix_madvise yes sigev_thread_id yes uuid support yes libcap-ng support no vhost-net support yes vhost-scsi support yes Trace backendsnop spice support no rbd support no xfsctl supportno nss used no libusbno usb net redir no OpenGL supportno libiscsi support no libnfs supportno build guest agent yes QGA VSS support no QGA w32 disk info no seccomp support no coroutine backend ucontext coroutine poolyes GlusterFS support no Archipelago support no gcov gcov gcov enabled no TPM support yes libssh2 support no TPM passthrough yes QOM debugging yes vhdx yes lzo support no snappy supportno bzip2 support no NUMA host support no tcmalloc support no :~/qemu$ make GEN config-host.h GEN qemu-options.def GEN qmp-commands.h GEN qapi-types.h GEN qapi-visit.h GEN qapi-event.h GEN trace/generated-events.h GEN trace/generated-tracers.h GEN trace/generated-tcg-tracers.h GEN trace/generated-helpers-wrappers.h GEN tr
[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed
** Changed in: qemu Status: New => 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/1412098 Title: qemu crashes when ctrl-alt-u is pressed Status in QEMU: Fix Released Bug description: Qemu version: 2.2.0 release, compiled from source Host OS: Windows 7 Ultimate x64 Guest OS: not applicable, crash occurs even without OS and occurs with all OSs Executable: qemu-system-i386.exe or qemu-system-i386w.exe To reproduce: Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes. Compilation: Qemu 2.2.0 release compiled from sources under MinGW on the host. Configure options used: '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu' To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions
[Qemu-devel] [Bug 1414222] Re: qemu-system-i386: -vnc localhost:0, to=99, id=default: Invalid parameter 'to'
** Changed in: qemu Status: New => 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/1414222 Title: qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter 'to' Status in QEMU: Fix Released Bug description: git bisect points to: 4db14629c38611061fc19ec6927405923de84f08 is the first bad commit commit 4db14629c38611061fc19ec6927405923de84f08 Author: Gerd Hoffmann Date: Tue Sep 16 12:33:03 2014 +0200 vnc: switch to QemuOpts, allow multiple servers This patch switches vnc over to QemuOpts, and it (more or less as side effect) allows multiple vnc server instances. Signed-off-by: Gerd Hoffmann :04 04 70020c79b463eaff4b91c8c7f985240d1d1914f0 354a3a125e7b82a1699ce4e0cfc5055662bd3466 M include :100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 963305c26917a930f37d916df66b319d6558d281 M qmp.c :04 04 e7933d52124ae48100893eed8e14cbe46f80b936 30fa5966f5c8362d6db6730a7091bbde7780d4d8 M ui :100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 983259bc9f7064b446da358a316a31a31731a223 M vl.c To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1414222/+subscriptions
[Qemu-devel] [Bug 1416988] Re: Wrong signal handling in qemu-aarch64.
** Changed in: qemu Status: New => 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/1416988 Title: Wrong signal handling in qemu-aarch64. Status in QEMU: Fix Released Bug description: Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests connected with stack unwinding fail with: qemu: uncaught target signal 11 (Segmentation fault) - core dumped or run into infinite loop. Here is one example: $ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc- aarch64/gcc/ /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe $ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 -/cleanup-11.exe qemu: uncaught target signal 11 (Segmentation fault) - core dumped. Actually, this caused by ABI incompatibility between Linux Kernel (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux and target_siginfo structure in qemu-aarch64 differ: sizeof (struct target_siginfo) = 136 // QEMU sizeof (struct siginfo) = 128 // Linux Kernel This caused by wrong TARGET_SI_PAD_SIZE defined in linux-user/syscall_defs.h: #define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) In Kernel respective value is: #define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) . #define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) // for Aarch64 Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1416988/+subscriptions
[Qemu-devel] [Bug 1410288] Re: qemu-img conversion to qcow2 hangs with blank image less than 100kiB
** Changed in: qemu Status: New => 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/1410288 Title: qemu-img conversion to qcow2 hangs with blank image less than 100kiB Status in QEMU: Fix Released Status in qemu package in Ubuntu: Triaged Bug description: If you try to convert a blank image to qcow2 that is less than 100kiB in size then qemu-img hangs trying to seek to the end of the file. $ truncate --size 102399 /tmp/temp $ qemu-img convert -p -O qcow2 /tmp/temp /tmp/temp2.qcow2 I'm finding this on all versions of qemu-img v2. strace shows a seek loop. ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4) = 0 _llseek(6, 0, [10], SEEK_END) = 0 ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: qemu-utils 2.0.0+dfsg-2ubuntu1.10 ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11 Uname: Linux 3.13.0-43-generic i686 ApportVersion: 2.14.1-0ubuntu3.6 Architecture: i386 Date: Tue Jan 13 14:30:39 2015 SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1410288/+subscriptions
[Qemu-devel] [Bug 1406016] Re: qemu-system-arm hangs at start on OS X
** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1406016 Title: qemu-system-arm hangs at start on OS X Status in QEMU: Invalid Bug description: Both from release 2.1.2 and built from a recent source, qemu-system- arm seems to hang immediately after starting up, never getting to the point of actually booting. I've tried qemu-system-mipsel with another image and it worked fine, so this seems to be specific to the ARM runtime. I've tried two different ARM kernels, and I also ran into this with QEMU 2.1.2 release, installed from a bottle using homebrew. Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0) QEMU version: built from HEAD@ab0302ee76 Build command: ./configure --enable-cocoa --target-list=arm-softmmu,mipsel-softmmu && make Run command: qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net nic,macaddr=52:54:00:fa:ce:13 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.gz -append "root=/dev/ram" -display vnc=localhost:17 -net user,hostfwd=tcp::5022-:22 -append "console=ttyS0" I also tried this, with a different kernel & root: qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no- reboot -serial stdio -hda rootfs-chromium.ext2 -append "root=/dev/sda" Thread dump: (lldb) thread list Process 34364 stopped * thread #1: tid = 0x135966, 0x7fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP thread #2: tid = 0x13598b, 0x7fff89f4ae6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x13598c, 0x7fff89f4b662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' thread #7: tid = 0x1359b2, 0x7fff89f4acc2 libsystem_kernel.dylib`__sigwait + 10 thread #9: tid = 0x1359c1, 0x0001091bc5d9 thread #11: tid = 0x1359cc, 0x7fff89f4a716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #12: tid = 0x1359da, 0x7fff89f46a1a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client' --- * thread #1: tid = 0x135966, 0x7fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10 frame #1: 0x7fff8e05f779 libsystem_pthread.dylib`_pthread_mutex_lock + 372 frame #2: 0x00010033e8e9 qemu-system-arm`qemu_mutex_lock(mutex=) + 25 at qemu-thread-posix.c:76 frame #3: 0x00010002d742 qemu-system-arm`qemu_mutex_lock_iothread + 98 at cpus.c:1137 frame #4: 0x0001002c84b5 qemu-system-arm`main_loop_wait [inlined] os_host_main_loop_wait(timeout=) + 191 at main-loop.c:242 frame #5: 0x0001002c83f6 qemu-system-arm`main_loop_wait(nonblocking=) + 278 at main-loop.c:494 frame #6: 0x00010014961a qemu-system-arm`qemu_main [inlined] main_loop + 73 at vl.c:1789 frame #7: 0x0001001495d1 qemu-system-arm`qemu_main(argc=, argv=, envp=) + 17057 at vl.c:4353 frame #8: 0x00010029b45e qemu-system-arm`-[QemuCocoaAppController startEmulationWithArgc:argv:](self=, _cmd=, argc=, argv=) + 30 at cocoa.m:897 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1406016/+subscriptions
[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt
** Changed in: qemu Status: Confirmed => 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/697197 Title: Empty password allows access to VNC in libvirt Status in libvirt: Unknown Status in QEMU: Fix Released Status in qemu-kvm: Unknown Status in libvirt package in Ubuntu: Invalid Status in qemu-kvm package in Ubuntu: Fix Released Status in libvirt source package in Lucid: Invalid Status in qemu-kvm source package in Lucid: Fix Released Status in libvirt source package in Maverick: Invalid Status in qemu-kvm source package in Maverick: Fix Released Status in libvirt source package in Natty: Invalid Status in qemu-kvm source package in Natty: Fix Released Status in libvirt source package in Karmic: Invalid Status in qemu-kvm source package in Karmic: Fix Released Status in qemu-kvm package in Debian: Fix Released Bug description: The help in the /etc/libvirt/qemu.conf states "To allow access without passwords, leave this commented out. An empty string will still enable passwords, but be rejected by QEMU effectively preventing any use of VNC." yet setting: vnc_password="" allows access to the vnc console without any password prompt just as if it is hashed out completely. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: libvirt-bin 0.8.3-1ubuntu14 ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 Uname: Linux 2.6.35-24-server x86_64 Architecture: amd64 Date: Tue Jan 4 12:18:35 2011 InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libvirt To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/697197/+subscriptions
[Qemu-devel] [Bug 1508405] Re: qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU
*** This bug is a duplicate of bug 1505062 ***
https://bugs.launchpad.net/bugs/1505062
** This bug has been marked a duplicate of bug 1505062
Regression: QEMU 2.4 on Linux 4.2 fails to init display with SMM enabled
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1508405
Title:
qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU
Status in QEMU:
New
Bug description:
When starting qemu-system-x86_64 from version 2.4.0 with --enable-kvm,
it hangs and takes 100% CPU. The graphical display (SeaBIOS output) is
not initialized.
There have been multiple reports of this issue in the following thread:
https://bbs.archlinux.org/viewtopic.php?pid=1572405
There is no need to load a certain image, it already hangs with the following
command:
qemu-system-x86_64 --enable-kvm
There are three workarounds:
- Downgrading the kernel form 4.2.2 to 4.1.6 (according to the forum thread,
have not tested this myself)
- Downgrading qemu to 2.3 (tested personally, works)
- passing -machine pc-i440fx-2.3 to qemu 2.4 (have not tested this myself, I
will try that shortly)
modules kvm and kvm_intel are loaded and rmmod && modprobing them does
not change the situation
I have an nvidia card and switching from official binary drivers to
nouveau and back does not change the situation.
qemu is installed from Arch package. From the PKGBUILD you can see that is is
built with the following configuration:
export ARFLAGS="rv"
export CFLAGS+=' -fPIC'
./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \
--python=/usr/bin/python2 --smbd=/usr/bin/smbd \
--enable-docs --libexecdir=/usr/lib/qemu \
--disable-gtk --enable-linux-aio --enable-seccomp \
--enable-spice --localstatedir=/var \
--enable-tpm \
--enable-modules --enable-{rbd,glusterfs,libiscsi,curl}
make V=99
cpuinfo on my machine (for the first core only):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz
stepping: 5
microcode : 0x7
cpu MHz : 1333.000
cache size : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16
xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority
ept vpid
bugs:
bogomips: 3459.21
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
Is there more information I can provide you with to help debug this
problem?
Thanks,
cptG
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1508405/+subscriptions
[Qemu-devel] [Bug 1534382] Re: loadvm makes Windows 7 x86 guest crash with some CPUs
What is your host processor? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1534382 Title: loadvm makes Windows 7 x86 guest crash with some CPUs Status in QEMU: New Bug description: Running qemu with kvm enabled and -cpu set to some of the more "modern" CPUs, and having Windows 7 x86 as the guest. After guest OS loads, start some app (I started "cmd"), then do "savevm". After that, do some more activity (I closed cmd window and opened IE), then do "loadvm" of the previously saved snapshot. loadvm shows briefly the state that the system was in at the snapshot time, then guest OS crashes (blue screen). Originally I saw this problem on qemu 1.4.0, then I also tried qemu 2.5.0 and found the same problem. The CPUs that I tried were mostly those that support NX bit (core2duo, qemu64, kvm64, Nehalem, etc.) If I use the default CPU, or some other like qemu32/kvm32, the problem does not occur. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1534382/+subscriptions
[Qemu-devel] [Bug 1531632] Re: Can't compile qemu because of errors in the Xen code
OK. I am closing this then. :) ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1531632 Title: Can't compile qemu because of errors in the Xen code Status in QEMU: Invalid Bug description: I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: First I have to disable -Werror, because it claims about some uninitialized variables. Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. Output of make: CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4, from /home/leo/qemu/hw/block/xen_disk.c:39: /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here typedef uint32_t ioservid_t; ^ In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); ^ /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); ^ /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed make: *** [hw/block/xen_disk.o] Error 1 [leo@AlphaArch build]$ make CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4, from /home/leo/qemu/hw/block/xen_disk.c:39: /usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here typedef uint32_t ioservid_t; ^ In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: /home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); ^ /home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); ^ /home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed make: *** [hw/block/xen_disk.o] Error 1 [leo@AlphaArch build]$ make CChw/block/xen_disk.o In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, from /home/leo/qemu/hw/block/xen_disk.c:39: /home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ typedef uint16_t ioservid_t; ^ In file included from /usr/include/xenctrl.h:37:0, from /home/leo/qemu/include/hw/xen/xen_common.h:9, from /home/leo/qemu/include/hw/xen/xen_backend.h:4,
[Qemu-devel] [Bug 1565395] Re: qemu-2.4.1 fails when compiled against pulseaudio
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1565395
Title:
qemu-2.4.1 fails when compiled against pulseaudio
Status in QEMU:
Confirmed
Bug description:
If I compile qemu-2.4.1 like this:
CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local
--localstatedir=/var --libexecdir=/usr/local/lib/qemu
--interp-prefix=/usr/local/share/qemu --disable-smartcard-nss
--disable-curses --disable-brlapi --audio-drv-list="oss alsa sdl"
--target-list="i386-softmmu i386-linux-user x86_64-softmmu
x86_64-linux-user" --smbd=/usr/local/sbin/smbd
find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \;
make
..it works fine.
If I add pulseaudio dev files and use --audio-drv-list="oss alsa sdl pa",
then "qemu-system-x86_64 -blah-blah" opens a window, displays the bios
message and stops. Strace shows qemu is not hung, but loops continually.
The same happens with qemu-2.2.1 and qemu-2.5.0.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1565395/+subscriptions
[Qemu-devel] [Bug 1574346] Re: TCG: mov to segment register is incorrectly emulated for AMD CPUs
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1574346 Title: TCG: mov to segment register is incorrectly emulated for AMD CPUs Status in QEMU: Confirmed Bug description: In TCG mode, the effect of: xorl %eax, %eax movl %eax, %gs is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1574346/+subscriptions
[Qemu-devel] [Bug 1594069] Re: SIMD instructions translated to scalar host instructions
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1594069 Title: SIMD instructions translated to scalar host instructions Status in QEMU: Confirmed Bug description: SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). [1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 [2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1594069/+subscriptions
[Qemu-devel] [Bug 1581936] Re: Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1)
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1581936 Title: Frozen Windows 7 VMs with VGA CVE-2016-3712 fix (2.6.0 and 2.5.1.1) Status in QEMU: Confirmed Bug description: Hi, As already posted on the QEMU devel list [1] I stumbled upon a problem with QEMU in version 2.5.1.1 and 2.6.0. the VM shows Windows loading files for the installation, then the "Starting Windows" screen appears here it hangs and never continues. Changing the "-vga" option to cirrus solves this, the installation can proceed and finish. When changing back to std (or also qxl, vmware) the installed VM also hangs on the "Starting Windows" screen while qemu showing a little but no excessive load. This phenomena appears also with QEMU 2.6.0 but not with 2.6.0-rc4, a git bisect shows fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 (vga: make sure vga register setup for vbe stays intact (CVE-2016-3712)) as the culprit for this regression, as its a fix for a DoS its not an option to just revert it, I guess. The bisect log is: git bisect start # bad: [bfc766d38e1fae5767d43845c15c79ac8fa6d6af] Update version for v2.6.0 release git bisect bad bfc766d38e1fae5767d43845c15c79ac8fa6d6af # good: [975eb6a547f809608ccb08c221552f11af25] Update version for v2.6.0-rc4 release git bisect good 975eb6a547f809608ccb08c221552f11af25 # good: [2068192dcccd8a80dddfcc8df6164cf9c26e0fc4] vga: update vga register setup on vbe changes git bisect good 2068192dcccd8a80dddfcc8df6164cf9c26e0fc4 # bad: [53db932604dfa7bb9241d132e0173894cf54261c] Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging git bisect bad 53db932604dfa7bb9241d132e0173894cf54261c # bad: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). git bisect bad fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 # first bad commit: [fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7] vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). I could reproduce that with QEMU 2.5.1 and QEMU 2.6 on a Debian derivate (Promox VE) with 4.4 Kernel and also with QEMU 2.6 on an Arch Linux System with a 4.5 Kernel, so it should not be host distro depended. Both machines have Intel x86_64 processors. The problem should be reproducible with said Versions or a build from git including the above mentioned commit (fd3c136) by starting a VM with an Windows 7 ISO, e.g.: Freezing installation (as vga defaults to std I marked it as optional): ./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 [-vga (std|qxl|vmware)] Working installation: ./x86_64-softmmu/qemu-system-x86_64 -boot d -cdrom win7.iso -m 1024 -vga cirrus If someone has already an installed Windows 7 VM this behaviour should be also observable when trying to start it with the new versions of QEMU. Noteworthy may be that Windows 10 is working, I do not had time to get other Windows versions and test them, I'll do that as soon as possible. Various Linux system also seems do work fine, at least I did not ran into an issue there yet. I also tried testing with SeaBIOS and OVMF as firmware, as initially I had no idea what broke, both lead to the same result - without the CVE-2016-3712 fix they both work, with not. Further, KVM enabled and disabled does not make any difference. [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg02416.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1581936/+subscriptions
[Qemu-devel] [Bug 568228] Re: /home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error
** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/568228 Title: /home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error Status in QEMU: Invalid Bug description: I get the following error each time I start emulation in QEMU 0.12.3 on a Sun SunFire 280R running Debian Lenny 5.03 for Sparc64: /home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error I had the same problem in Qemu 0.11.1. Here are informations about my system, I am not a programmer so I don't know what information to give, if you need more info just ask me: sunfire:/home# uname -a Linux sunfire 2.6.26 #1 Thu Apr 8 17:09:17 EDT 2010 sparc64 GNU/Linux sunfire:/home# dmesg nges: [0.00] Normal 0 -> 130933 [0.00] Movable zone start PFN for each node [0.00] early_node_map[7] active PFN ranges [0.00] 0:0 -> 129023 [0.00] 0: 129024 -> 130666 [0.00] 0: 130796 -> 130803 [0.00] 0: 130805 -> 130815 [0.00] 0: 130818 -> 130826 [0.00] 0: 130828 -> 130916 [0.00] 0: 130919 -> 130933 [0.00] On node 0 totalpages: 130792 [0.00] Normal zone: 896 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 129896 pages, LIFO batch:15 [0.00] Movable zone: 0 pages used for memmap [0.00] Booting Linux... [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129896 [0.00] Kernel command line: root=/dev/sdb2 ro [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] clocksource: mult[c8] shift[16] [0.00] clockevent: mult[147ae14] shift[32] [ 380.165881] Console: colour dummy device 80x25 [ 380.183520] console handover: boot [earlyprom0] -> real [tty0] [ 380.208131] Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) [ 380.210503] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) [ 380.235415] Memory: 1022064k available (4952k kernel code, 2064k data, 192k init) [f800,3feea000] [ 380.312667] Calibrating delay using timer specific routine.. 9.99 BogoMIPS (lpj=19990) [ 380.312839] Security Framework initialized [ 380.312870] SELinux: Disabled at boot. [ 380.312889] Capability LSM initialized [ 380.312935] Mount-cache hash table entries: 512 [ 380.313505] Initializing cgroup subsys ns [ 380.313524] Initializing cgroup subsys cpuacct [ 380.313536] Initializing cgroup subsys devices [ 380.314346] net_namespace: 1208 bytes [ 380.314892] NET: Registered protocol family 16 [ 380.325288] PCI: Probing for controllers. [ 380.325332] /pci@8,70: SCHIZO PCI Bus Module ver[4:0] [ 380.325349] /pci@8,70: PCI IO[7ffef00] MEM[7fe] [ 380.329864] /pci@8,60: SCHIZO PCI Bus Module ver[4:0] [ 380.329881] /pci@8,60: PCI IO[7ffed00] MEM[7fd] [ 380.334466] PCI: Scanning PBM /pci@8,60 [ 380.334976] PCI: Scanning PBM /pci@8,70 [ 380.336347] ebus0: [flashprom] [bbc] [ppm] [i2c -> (dimm-fru) (dimm-fru) (dimm-fru) (dimm-fru) (nvram) (idprom)] [i2c -> (cpu-fru) (temperature) (fan-control) (motherboard-fru) (i2c-bridge)] [beep] [rtc] [gpio] [pmc] [floppy] [parallel] [serial] [ 380.349031] usbcore: registered new interface driver usbfs [ 380.349274] usbcore: registered new interface driver hub [ 380.349452] usbcore: registered new device driver usb [ 380.353275] /pci@8,70/ebus@5/rtc@1,300070: Clock regs at 07fe7e300070 [ 380.354631] NET: Registered protocol family 2 [ 380.356677] Switched to high resolution mode on CPU 0 [ 380.388803] IP route cache hash table entries: 8192 (order: 3, 65536 bytes) [ 380.389510] TCP established hash table entries: 32768 (order: 6, 524288 bytes) [ 380.391238] TCP bind hash table entries: 32768 (order: 5, 262144 bytes) [ 380.392036] TCP: Hash tables configured (established 32768 bind 32768) [ 380.392052] TCP reno registered [ 380.400796] NET: Registered protocol family 1 [ 380.401078] checking if image is initramfs... it is [ 381.658428] Freeing initrd memory: 5829k freed [ 381.659077] Mini RTC Driver [ 381.659365] /memory-controller@0,40: US3 memory controller at 0440 [ACTIVE] [ 381.660085] audit: initializing netlink socket (disabled) [ 381.660134] type=2000 audit(1271905721.644:1): initialized [ 381.660454] Total HugeTLB memory allocated, 0 [ 381.660756] VFS: Disk quotas dquot_6.5.1 [ 381.660865] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) [ 381.661363] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 381.662280] NTFS driver 2.1.29 [Flags: R/W]. [ 381.662397] msgmni has been set
[Qemu-devel] [Bug 1591611] Re: chroot using qemu-x86_64-static fails on ppc64el
** Changed in: qemu
Status: In Progress => Fix Committed
** Changed in: qemu
Assignee: Timothy Pearson (kb9vqf) => pranith (bobby-prani)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1591611
Title:
chroot using qemu-x86_64-static fails on ppc64el
Status in QEMU:
Fix Committed
Bug description:
When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el
host to chroot into an amd64 environment, all commands fail with an
assertion error. /usr/bin/qemu-x86_64-static from the host was copied
into the chroot /usr/bin, and the host has multiformat support in the
kernel.
Sample output illustrating the problem, as well as bash builtins
working:
# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static
/bin/bash
# ls
bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread,
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread,
tid))); } __value; }) != ppid' failed.
setup_frame: not implemented
setup_frame: not implemented
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
setup_frame: not implemented
setup_frame: not implemented
# echo TEST
TEST
# cat test
bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread,
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread,
tid))); } __value; }) != ppid' failed.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
It is currently unknown if other host architectures (e.g. aarch64) are
also affected.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1591611/+subscriptions
[Qemu-devel] [Bug 498035] Re: qemu hangs on shutdown or reboot (XP guest)
Closing since it seems to be fixed in latest release. ** Changed in: qemu Status: Incomplete => 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/498035 Title: qemu hangs on shutdown or reboot (XP guest) Status in QEMU: Fix Released Bug description: When I shut down or reboot my Windows XP guest, about half the time, it hangs at the point where it says "Windows is shutting down...". At that point qemu is using 100% of one host CPU, about 85% user, 15% system. (Core 2 Quad 2.66GHz) This is the command line I use to start qemu: qemu-system-x86_64 -hda winxp.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -boot c -enable-kvm & To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/498035/+subscriptions
[Qemu-devel] [Bug 1605443] Re: QEMU epoll for i386-linux-user on arm host is broken in 2.6
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1605443 Title: QEMU epoll for i386-linux-user on arm host is broken in 2.6 Status in QEMU: Confirmed Bug description: I'm trying to get wine running on qemu-i386 on arm. I found that 2.5.1 is OK, but 2.6 is not. By bisecting, I found commit 928bed6a057cedd6110e634865e021a24029785a is the problem. I reverted this commit, and then epoll is OK now. It seems that the commit broke epoll of qemu-i386 on arm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1605443/+subscriptions
[Qemu-devel] [Bug 485239] Re: Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50
Please try the latest version. The version you reported is too old. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/485239 Title: Windows 2008 datacenter- 64 bit , installation fails with qemu-system- x86_64 0.11.50 Status in QEMU: Invalid Bug description: Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. Version of qemu-system-x86_64 is 0.11.50. The installation source is dvd iso. Just after booting for installation of the Windows guest, it hangs for sometime and then the installation crashes with the error: "A problem has been detected and windows has been shut down to prevent damage to your computer". Below is the command used for creating the guest. /usr/local/bin/qemu-system-x86_64 -cdrom /home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 & Disk info of the guest image is as below: /usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2 image: /var/lib/libvirt/images/win2008_dc_64.qcow2 file format: qcow2 virtual size: 15G (16106127360 bytes) disk size: 136K cluster_size: 65536 This issue is also reproducible with raw image format. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/485239/+subscriptions
[Qemu-devel] [Bug 1682093] Re: aarch64-softmmu "bad ram pointer" crash
** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1682093 Title: aarch64-softmmu "bad ram pointer" crash Status in QEMU: Invalid Bug description: I am developing a piece of software called SimBench which is a benchmarking system for full system simulators. I am currently porting this to aarch64, using QEMU as a test platform. I have encountered a 'bad ram pointer' crash. I've attempted to build a minimum test case, but I haven't managed to replicate the behaviour in isolation, so I've created a branch of my project which exhibits the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu- bug.tar.gz The package can be compiled using: make and then run using: qemu-system-aarch64 -M virt -m 512 -cpu cortex-a57 -kernel out/armv8/virt/simbench -nographic I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on Fedora 23. Please let me know if you need any more information or any logs/core dumps/etc. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1682093/+subscriptions
[Qemu-devel] [Bug 1681688] Re: qemu live migration failed
** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1681688 Title: qemu live migration failed Status in QEMU: Incomplete Bug description: qemu live migration failed the dest qemu report this error. Receiving block device images Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. this bug is caused by this patch: http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a rollback this commit, the problem solved. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1681688/+subscriptions
[Qemu-devel] [Bug 1681688] Re: qemu live migration failed
** Changed in: qemu Status: Incomplete => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1681688 Title: qemu live migration failed Status in QEMU: Confirmed Bug description: qemu live migration failed the dest qemu report this error. Receiving block device images Completed 0 %^Mqemu-system-x86_64: block/io.c:1348: bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed. this bug is caused by this patch: http://git.qemu-project.org/?p=qemu.git;a=commit;h=d35ff5e6b3aa3a706b0aa3bcf11400fac945b67a rollback this commit, the problem solved. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1681688/+subscriptions
[Qemu-devel] [Bug 1653063] Re: qemu-system-arm hangs with -icount and -nodefaults
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1653063 Title: qemu-system-arm hangs with -icount and -nodefaults Status in QEMU: Confirmed Bug description: I tested with release 2.8.0 and the latest git repo, (commit: dbe2b65566e76d3c3a0c3358285c0336ac61e757). My configure options when building QEMU: '../configure' '--prefix=$HOME/local/qemu.git' '--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc' '--disable-user' '--disable-sdl' '--disable-stack-protector' '--disable-attr' '--disable-pie' '--disable-linux-aio' '--disable-tpm' '--without-system-pixman' '--disable-docs' '--disable-guest-agent' '--disable-guest-agent-msi' '--disable-modules' '--disable-sparse' '--disable-gnutls' '--disable-nettle' '--disable-gcrypt' '--disable-gtk' '--disable-vte' '--disable-curses' '--disable-vnc' '--disable-cocoa' '--disable-virtfs' '--disable-xen' '--disable-brlapi' '--disable-curl' '--disable-bluez' '--disable-rdma' '--disable-uuid' '--disable-vde' '--disable-netmap' '--disable-cap-ng' '--disable-attr' '--disable-vhost-net' '--disable-spice' '--disable-rbd' '--disable-libiscsi' '--disable-libnfs' '--disable-smartcard' '--disable-libusb' '--disable-usb-redir' '--disable-lzo' '--disable-snappy' '--disable-bzip2' '--disable-seccomp' '--disable-glusterfs' '--disable-archipelago' '--disable-libssh2' '--disable-vhdx' '--disable-numa' '--disable-werror' '--disable-blobs' '--disable-vhost-scsi' '--enable-debug' '--disable-strip' '--enable-debug-tcg' '--enable-debug-info' '--extra-cflags=-fPIC' My host OS is Redhat RHEL-6.5. uname command gives: Linux rslpc1 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux The test image is downloaded from http://wiki.qemu.org/download/arm- test-0.2.tar.gz The command to re-produce the problem: qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0" After console prints the message below: "Uncompressing Linux.. done, booting the kernel." there's no further action noticed. If "-icount" is not set, namely run as: qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0" or if "-nodefaults" is not set, namely run as: qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0" The Linux boot procedure can finish successfully. Thanks. Hansni To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1653063/+subscriptions
[Qemu-devel] [Bug 1665791] Re: Multiple displays each attached to a separate vnc connection
Questions like this are better directed to the mailing list. Please email qemu-disc...@nongnu.org and/or qemu-devel@nongnu.org. Thanks! ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1665791 Title: Multiple displays each attached to a separate vnc connection Status in QEMU: Invalid Bug description: Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1665791/+subscriptions
[Qemu-devel] [Bug 1785734] Re: movdqu partial write at page boundary
** Changed in: qemu Status: New => Confirmed -- 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: Confirmed 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
[Qemu-devel] [Bug 1653384] Re: Assertion failed with USB pass through with XHCI controller
** Changed in: qemu
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/1653384
Title:
Assertion failed with USB pass through with XHCI controller
Status in QEMU:
Fix Released
Status in qemu package in Debian:
Fix Released
Bug description:
Starting qemu 2.8.0 with XHCI controller and host device passed
through results in an assertion failure:
qemu-system-x86_64: hw/usb/core.c:623: usb_packet_cleanup: Assertion
`!usb_packet_is_inflight(p)' failed.
Can be reproduced with the following command (passing through a Lenovo
keyboard):
qemu-system-x86_64 -usb -device nec-usb-xhci,id=usb -device usb-
host,vendorid=0x04b3,productid=0x3025,id=hostdev0,bus=usb.0,port=1
If nec-usb-xhci is changed to usb-ehci, qemu tries to boot without
assertion failures.
Can be reproduced with the latest master (commit dbe2b65) and v2.8.0.
Bisected the issue to following commit:
first bad commit: [94b037f2a451b3dc855f9f2c346e5049a361bd55] xhci: use linked
list for transfers
Backtrace from commit dbe2b65:
#0 0x7f2eb4657227 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
resultvar = 0
pid = 3453
selftid = 3453
#1 0x7f2eb465867a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4},
sa_mask = {__val = {140734740550528, 93876690035339,
140734740550624, 48833659808, 0, 0, 0, 21474836480,
140734740550792, 139838573009553, 140734740550560, 139838573043008,
139838573024160, 9387665872, 139838702616576,
139838573024160}}, sa_flags = 1528954938,
sa_restorer = 0x55615b2202c0 <__PRETTY_FUNCTION__.38612>}
sigs = {__val = {32, 0 }}
#2 0x7f2eb46502cd in __assert_fail_base (fmt=0x7f2eb47893a0 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x55615b22003a "!usb_packet_is_inflight(p)",
file=file@entry=0x55615b21fdf0 "hw/usb/core.c", line=line@entry=619,
function=function@entry=0x55615b2202c0 <__PRETTY_FUNCTION__.38612>
"usb_packet_cleanup") at assert.c:92
str = 0x55615cfdf510 ""
total = 4096
#3 0x7f2eb4650382 in __GI___assert_fail (assertion=0x55615b22003a
"!usb_packet_is_inflight(p)", file=0x55615b21fdf0 "hw/usb/core.c",
line=619, function=0x55615b2202c0 <__PRETTY_FUNCTION__.38612>
"usb_packet_cleanup") at assert.c:101
No locals.
#4 0x55615afc385e in usb_packet_cleanup ()
No symbol table info available.
#5 0x55615afda555 in xhci_ep_free_xfer ()
No symbol table info available.
#6 0x55615afdc156 in xhci_kick_epctx ()
No symbol table info available.
#7 0x55615afda099 in xhci_ep_kick_timer ()
No symbol table info available.
#8 0x55615b08ceee in timerlist_run_timers ()
No symbol table info available.
#9 0x55615b08cf36 in qemu_clock_run_timers ()
No symbol table info available.
#10 0x55615b08d2df in qemu_clock_run_all_timers ()
No symbol table info available.
#11 0x55615b08be40 in main_loop_wait ()
No symbol table info available.
#12 0x55615ae3870f in main_loop ()
No symbol table info available.
#13 0x55615ae4027b in main ()
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1653384/+subscriptions
[Qemu-devel] Counting barrier instructions in ARM
Hello,
I am trying to count the number of barrier instructions (dmb) which are being
executed in an multi-threaded ARM executable. I am running the executable using
qemu user mode with the following patch applied.
Basically I created two counters in the ARM cpu state and incrementing them by
generating a TCG instruction whenever a barrier instruction is translated. I am
doing something similar even for counting the total instructions executed.
The problem I am facing is that this seems to be crashing when run with a
multi-threaded executable. Also the statistics gathered are not really accurate.
Is there something obviously wrong with what I am trying to do? Any help is
highly appreciated.
Thanks!
---
linux-user/main.c | 10 +-
target-arm/cpu.h | 2 ++
target-arm/translate.c | 9 +
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index b453a39..7984027 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -816,7 +816,15 @@ void cpu_loop(CPUARMState *env)
break;
}
} else {
-env->regs[0] = do_syscall(env,
+// print stats on exit
+if (n == 248) {
+FILE *icount_file = fopen("inscount.out", "w");
+unsigned long total = (unsigned long)env->fence_count;
+unsigned long icount = (unsigned long)env->insn_count;
+fprintf(icount_file, "%lu, %lu, %f\n", icount, total, total *
1000.0/icount);
+fclose(icount_file);
+}
+env->regs[0] = do_syscall(env,
n,
env->regs[0],
env->regs[1],
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 369d472..be38574 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -304,6 +304,8 @@ typedef struct CPUARMState {
uint64_t exclusive_test;
uint32_t exclusive_info;
#endif
+uint32_t fence_count;
+uint32_t insn_count;
/* iwMMXt coprocessor state. */
struct {
diff --git a/target-arm/translate.c b/target-arm/translate.c
index cf4e767..4d4ceb1 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -68,6 +68,8 @@ static TCGv_i64 cpu_exclusive_val;
static TCGv_i64 cpu_exclusive_test;
static TCGv_i32 cpu_exclusive_info;
#endif
+static TCGv_i32 cpu_fence_count;
+static TCGv_i32 cpu_insn_count;
/* FIXME: These should be removed. */
static TCGv_i32 cpu_F0s, cpu_F1s;
@@ -106,6 +108,10 @@ void arm_translate_init(void)
cpu_exclusive_info = tcg_global_mem_new_i32(TCG_AREG0,
offsetof(CPUARMState, exclusive_info), "exclusive_info");
#endif
+cpu_fence_count = tcg_global_mem_new_i32(TCG_AREG0,
+offsetof(CPUARMState, fence_count), "fence_count");
+cpu_insn_count = tcg_global_mem_new_i32(TCG_AREG0,
+offsetof(CPUARMState, insn_count), "insn_count");
a64_translate_init();
}
@@ -7568,6 +7574,7 @@ static void disas_arm_insn(CPUARMState * env,
DisasContext *s)
case 5: /* dmb */
case 6: /* isb */
ARCH(7);
+tcg_gen_add_i32(cpu_fence_count, cpu_fence_count, 1);
/* We don't emulate caches so these are a no-op. */
return;
default:
@@ -9740,6 +9747,7 @@ static int disas_thumb2_insn(CPUARMState *env,
DisasContext *s, uint16_t insn_hw
case 4: /* dsb */
case 5: /* dmb */
case 6: /* isb */
+tcg_gen_add_i32(cpu_fence_count, cpu_fence_count, 1);
/* These execute as NOPs. */
break;
default:
@@ -11022,6 +11030,7 @@ static inline void
gen_intermediate_code_internal(ARMCPU *cpu,
tcg_gen_debug_insn_start(dc->pc);
}
+tcg_gen_add_i32(cpu_insn_count, cpu_insn_count, 1);
if (dc->thumb) {
disas_thumb_insn(env, dc);
if (dc->condexec_mask) {
--
1.9.1
Re: [Qemu-devel] Counting barrier instructions in ARM
Hi Max, On Wed, Oct 15, 2014 at 9:54 PM, Max Filippov wrote: > Hi, > > On Thu, Oct 16, 2014 at 5:45 AM, Pranith Kumar wrote: >> Is there something obviously wrong with what I am trying to do? Any help is >> highly appreciated. >> --- a/target-arm/translate.c >> +++ b/target-arm/translate.c >> @@ -7568,6 +7574,7 @@ static void disas_arm_insn(CPUARMState * env, >> DisasContext *s) >> case 5: /* dmb */ >> case 6: /* isb */ >> ARCH(7); >> +tcg_gen_add_i32(cpu_fence_count, cpu_fence_count, 1); > > tcg_gen_addi_i32, as you're adding an immediate. > Enabling TCG debug would catch such errors. > Not sure if that will fix crashing, but it should improve accuracy (: I had that before the change to tcg_gen_add_i32 and the crashes were still there. But yes, this needs to be changed to use addi. How do I enable the TCG debug build? Thanks! > >> /* We don't emulate caches so these are a no-op. */ >> return; >> default: >> @@ -9740,6 +9747,7 @@ static int disas_thumb2_insn(CPUARMState *env, >> DisasContext *s, uint16_t insn_hw >> case 4: /* dsb */ >> case 5: /* dmb */ >> case 6: /* isb */ >> +tcg_gen_add_i32(cpu_fence_count, cpu_fence_count, 1); > > Here as well. > >> /* These execute as NOPs. */ >> break; >> default: >> @@ -11022,6 +11030,7 @@ static inline void >> gen_intermediate_code_internal(ARMCPU *cpu, >> tcg_gen_debug_insn_start(dc->pc); >> } >> >> +tcg_gen_add_i32(cpu_insn_count, cpu_insn_count, 1); > > And here. > > -- > Thanks. > -- Max -- Pranith
Re: [Qemu-devel] Counting barrier instructions in ARM
Hi Peter, On Thu, Oct 16, 2014 at 4:05 AM, Peter Maydell wrote: > On 16 October 2014 03:45, Pranith Kumar wrote: >> The problem I am facing is that this seems to be crashing when run with a >> multi-threaded executable. > > This is nothing to do with your changes -- user-mode QEMU does not > support multi-threaded guest executables. QEMU may crash, hang, > or stop with an assertion failure, fairly randomly. Don't try > to run multithreaded guests :-) OK, I will try to gather the statistics in system mode. Is there any way to indicate from within the system to qemu to start collecting the stats? I dont want to collect the stats for bootup and other unrelated code paths. > >> Also the statistics gathered are not really accurate. > > This will be because you're using add rather than addi, > so you're adding effectively a random number to the count > every time (whatever TCG's "value in temporary 1" happens > to be, I expect). OK, I updated this when Max Filippov pointed it out. Thanks! -- Pranith
Re: [Qemu-devel] Counting barrier instructions in ARM
On Wed, Oct 15, 2014 at 10:12 PM, Max Filippov wrote: > On Thu, Oct 16, 2014 at 6:00 AM, Pranith Kumar wrote: >>>> +tcg_gen_add_i32(cpu_fence_count, cpu_fence_count, 1); >>> >>> tcg_gen_addi_i32, as you're adding an immediate. >>> Enabling TCG debug would catch such errors. >>> Not sure if that will fix crashing, but it should improve accuracy (: >> >> I had that before the change to tcg_gen_add_i32 and the crashes were >> still there. But yes, this needs to be changed to use addi. > > Got backtraces of your crashes? > These bugs seem to be Heisenbugs. As Peter Maydell pointed out, apparently multi-threaded user mode execution is not supported. I will try to use system mode. Thanks! -- Pranith
Re: [Qemu-devel] Enabling PMU in qemu arm64
On Thu, Oct 1, 2015 at 12:21 PM, Christopher Covington wrote: > > Are you using KVM or TCG (are you running on an x86 host or an arm64 host)? I am using TCG, aarch64-softmmu on x86 host. > > We have published some patches implementing the PMU registers and instruction > counting (but not any other events) for TCG mode [1], but more work is > required to get these changes into shape for inclusion upstream. > > 1. https://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg00567.html Thanks for the pointer. From the patch series I can see that patches 7 and 9 are for enabling PMU in ARM virt. Do you plan on submitting them upstream? I will try these patches locally and see how it goes. > > To guide and justify the changes I'm currently trying to write kvm-unit-tests > that measure > > A) IPC using PMCCNTR_EL0 (implemented upstream, at least when not using > -icount) and code with known length in instructions; PMCCNTR_EL0 always returns 0 for me(in 2.4, will check tip). > B) CPU frequency using PMCCNTR_EL0 and CNTVCT_EL0; and > C) instructions event in the PMU for code with known length in instructions I am guessing these two are not upstream yet, would be great to see it there. Thanks! -- Pranith
[Qemu-devel] qemu fails to build on 4.5-rc1
Hi Dave,
Commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to
FS_IOC_FS[SG]ETXATTR promotion") breaks building latest qemu as
follows:
In file included from /usr/include/xfs/xfs.h:58:0,
from /home/pranith/qemu/block/raw-posix.c:96:
/usr/include/xfs/xfs_fs.h:42:8: error: redefinition of ‘struct fsxattr’
struct fsxattr {
^
In file included from /home/pranith/qemu/block/raw-posix.c:59:0:
/usr/include/linux/fs.h:155:8: note: originally defined here
struct fsxattr {
^
/home/pranith/qemu/rules.mak:57: recipe for target 'block/raw-posix.o' failed
I think this is caused by moving the fsxattr struct around. Any
suggestion on how to fix this?
Thanks,
--
Pranith
Re: [Qemu-devel] CPU Cache simulation
Hi, On Wed, Nov 18, 2015 at 11:48 AM, Hao Bai wrote: > Sorry about the ambiguity. > I am using x86-64 architecture in user mode. Basically, I am trying to log > all the cache activities when I run a guest program with QEMU. That's why I > asked whether QEMU simulated CPU caches. I was assuming if QEMU did not > simulate CPU caches then there would be no way to do this (Correct me if I > am wrong). Is there a way to do this? > > You can try qsim: https://github.com/gtcasl/qsim In particular look at the cache simulator: https://github.com/gtcasl/qsim/blob/master/examples/x86/cachesim.cpp Setup instructions: https://github.com/pranith/qsim-setup -- Pranith
Re: [Qemu-devel] CPU Cache simulation
On Wed, Nov 18, 2015 at 1:06 PM, Eduardo Habkost wrote: > > > Interesting. How much did you change QEMU to make this work? Have > you been rebasing this to recent QEMU versions often? The core of qemu is not changed except for one TCG issue I didn't know how to fix. Rest is just annotating the code to generate appropriate callbacks. You find the patches here: https://github.com/pranith/qemu/commits/aaa8b521187e4ecd1d35914e9b119f9d6eaa8633 I try to rebase once a release comes out. The current version is based on 2.4, so it is pretty current. I will rebase onto 2.5 in the near future since the rc0 is out. -- Pranith
[Qemu-devel] QEMU GSoC 2016: MTTCG project
Hello, I am interested in working on a portion of the MTTCG project as part of GSoC 2016. I am writing to ask for guidance in creating a formal proposal. On IRC, Alex suggested a project to support proper modelling of memory consistency between different host and guest architectures. This, I think is going to based on top of Alvise's work. I am comfortable in working with various memory consistency models and have a decent programming experience. Please let me know if you have any other suggestions for projects or any other related advice. Thanks! -- Pranith
Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch
Hi Alex, On Tue, Jan 12, 2016 at 12:29 PM, Alex Bennée wrote: > https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks > I built this branch and ran an arm64 guest. It seems to be failing similarly to what I reported earlier: #0 0x72211cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x722150d8 in __GI_abort () at abort.c:89 #2 0x5572014c in qemu_ram_addr_from_host_nofail (ptr=0xffc000187863) at /home/pranith/devops/code/qemu/cputlb.c:357 #3 0x557209dd in get_page_addr_code (env1=0x56702058, addr=18446743798833248356) at /home/pranith/devops/code/qemu/cputlb.c:568 #4 0x556db98c in tb_find_physical (cpu=0x566f9dd0, pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at /home/pranith/devops/code/qemu/cpu-exec.c:224 #5 0x556dbaf4 in tb_find_slow (cpu=0x566f9dd0, pc=18446743798833248356, cs_base=0, flags=18446744071830503424) at /home/pranith/devops/code/qemu/cpu-exec.c:268 #6 0x556dbc77 in tb_find_fast (cpu=0x566f9dd0) at /home/pranith/devops/code/qemu/cpu-exec.c:311 #7 0x556dc0f1 in cpu_arm_exec (cpu=0x566f9dd0) at /home/pranith/devops/code/qemu/cpu-exec.c:492 #8 0x557050ee in tcg_cpu_exec (cpu=0x566f9dd0) at /home/pranith/devops/code/qemu/cpus.c:1486 #9 0x557051af in tcg_exec_all (cpu=0x566f9dd0) at /home/pranith/devops/code/qemu/cpus.c:1515 #10 0x55704800 in qemu_tcg_cpu_thread_fn (arg=0x566f9dd0) at /home/pranith/devops/code/qemu/cpus.c:1187 #11 0x725a8182 in start_thread (arg=0x7fffd20c8700) at pthread_create.c:312 #12 0x722d547d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 The arguments I used are as follows: (gdb) show args Argument list to give program being debugged when it is started is "-m 1024M -M virt -cpu cortex-a57 -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=arm64disk.qcow2,id=coreimg,cache=unsafe,if=none -device scsi-hd,drive=coreimg -netdev user,id=unet -device virtio-net-device,netdev=unet -kernel vmlinuz -initrd initrd.img -append root=/dev/sda2 -display sdl -redir tcp:::22 -smp 2". Does something look obviously wrong to you in the arg list? Thanks! -- Pranith
Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch
Hi Alex,
On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée wrote:
> Can you try this branch:
>
>
https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1
>
> I think I've caught all the things likely to screw up addressing.
>
I tried this branch and the boot hangs like follows:
[2.001083] random: systemd-udevd urandom read with 1 bits of entropy
available
main-loop: WARNING: I/O thread spun for 1000 iterations
[ 23.778970] INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected
by 0, t=2102 jiffies, g=-165, c=-166, q=83)
[ 23.780265] All QSes seen, last rcu_sched kthread activity 2101
(4294939656-4294937555), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 23.781228] swapper/0 R running task0 0 0
0x0080
[ 23.781977] Call trace:
[ 23.782375] [] dump_backtrace+0x0/0x170
[ 23.782852] [] show_stack+0x20/0x2c
[ 23.783279] [] sched_show_task+0x9c/0xf0
[ 23.783746] [] rcu_check_callbacks+0x7b8/0x828
[ 23.784230] [] update_process_times+0x40/0x74
[ 23.784723] [] tick_sched_handle.isra.15+0x38/0x7c
[ 23.785247] [] tick_sched_timer+0x48/0x84
[ 23.785705] [] __run_hrtimer+0x90/0x200
[ 23.786148] [] hrtimer_interrupt+0xec/0x268
[ 23.786612] [] arch_timer_handler_virt+0x38/0x48
[ 23.787120] [] handle_percpu_devid_irq+0x90/0x12c
[ 23.787621] [] generic_handle_irq+0x38/0x54
[ 23.788093] [] __handle_domain_irq+0x68/0xc4
[ 23.788578] [] gic_handle_irq+0x38/0x84
[ 23.789035] Exception stack(0xffc00073bde0 to 0xffc00073bf00)
[ 23.789650] bde0: 00738000 ffc0 0073e71c ffc0 0073bf20 ffc0
00086948 ffc0
[ 23.790356] be00: 000d848c ffc0 3ffcdb0c ffc0
0100
[ 23.791030] be20: 38b97100 ffc0 0073bea0 ffc0 67f6e000 0005
567f1c33
[ 23.791744] be40: 00748cf0 ffc0 0073be70 ffc0 c1e2e4a0 ffbd
3a801148 ffc0
[ 23.792406] be60: 0040 0073e000 ffc0 3a801168 ffc0
97bbb588 007f
[ 23.793055] be80: 0021d7e8 ffc0 97b3d6ec 007f c37184d0 007f
00738000 ffc0
[ 23.793720] bea0: 0073e71c ffc0 006ff7e8 ffc0 007c8000 ffc0
0073e680 ffc0
[ 23.794373] bec0: 0072fac0 ffc0 0001 0073bf30 ffc0
0050e9e8 ffc0
[ 23.795025] bee0: 0073bf20 ffc0 00086944 ffc0
0073bf20 ffc0
[ 23.795721] [] el1_irq+0x64/0xc0
[ 23.796131] [] cpu_startup_entry+0x130/0x204
[ 23.796605] [] rest_init+0x78/0x84
[ 23.797028] [] start_kernel+0x3a0/0x3b8
[ 23.797528] rcu_sched kthread starved for 2101 jiffies!
I will try to debug and see where it is hanging.
Thanks!
--
Pranith
[Qemu-devel] [PATCH] icount: possible options for sleep are on or off
icount sleep takes on or off as options. A few places mention sleep=no
which is not accepted. This patch corrects them.
Signed-off-by: Pranith Kumar
---
cpus.c | 4 ++--
qemu-options.hx | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpus.c b/cpus.c
index 9592163..bc774e2 100644
--- a/cpus.c
+++ b/cpus.c
@@ -630,7 +630,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
icount_align_option = qemu_opt_get_bool(opts, "align", false);
if (icount_align_option && !icount_sleep) {
-error_setg(errp, "align=on and sleep=no are incompatible");
+error_setg(errp, "align=on and sleep=off are incompatible");
}
if (strcmp(option, "auto") != 0) {
errno = 0;
@@ -643,7 +643,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
} else if (icount_align_option) {
error_setg(errp, "shift=auto and align=on are incompatible");
} else if (!icount_sleep) {
-error_setg(errp, "shift=auto and sleep=no are incompatible");
+error_setg(errp, "shift=auto and sleep=off are incompatible");
}
use_icount = 2;
diff --git a/qemu-options.hx b/qemu-options.hx
index 599db94..bbe0e51 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3275,7 +3275,7 @@ re-inject them.
ETEXI
DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
-"-icount
[shift=N|auto][,align=on|off][,sleep=no,rr=record|replay,rrfile=]\n" \
+"-icount
[shift=N|auto][,align=on|off][,sleep=on|off,rr=record|replay,rrfile=]\n"
\
"enable virtual instruction counter with 2^N clock ticks
per\n" \
"instruction, enable aligning the host and virtual
clocks\n" \
"or disable real time cpu sleeping\n", QEMU_ARCH_ALL)
@@ -3288,8 +3288,8 @@ then the virtual cpu speed will be automatically adjusted
to keep virtual
time within a few seconds of real time.
When the virtual cpu is sleeping, the virtual time will advance at default
-speed unless @option{sleep=no} is specified.
-With @option{sleep=no}, the virtual time will jump to the next timer deadline
+speed unless @option{sleep=on|off} is specified.
+With @option{sleep=on|off}, the virtual time will jump to the next timer
deadline
instantly whenever the virtual cpu goes to sleep mode and will not advance
if no timer is enabled. This behavior give deterministic execution times from
the guest point of view.
--
2.7.1
[Qemu-devel] [PATCH] icount: possible options for sleep are on or off
icount sleep takes on or off as options. A few places mention sleep=no
which is not accepted. This patch corrects them.
Signed-off-by: Pranith Kumar
---
cpus.c | 4 ++--
qemu-options.hx | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpus.c b/cpus.c
index 9592163..bc774e2 100644
--- a/cpus.c
+++ b/cpus.c
@@ -630,7 +630,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
icount_align_option = qemu_opt_get_bool(opts, "align", false);
if (icount_align_option && !icount_sleep) {
-error_setg(errp, "align=on and sleep=no are incompatible");
+error_setg(errp, "align=on and sleep=off are incompatible");
}
if (strcmp(option, "auto") != 0) {
errno = 0;
@@ -643,7 +643,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
} else if (icount_align_option) {
error_setg(errp, "shift=auto and align=on are incompatible");
} else if (!icount_sleep) {
-error_setg(errp, "shift=auto and sleep=no are incompatible");
+error_setg(errp, "shift=auto and sleep=off are incompatible");
}
use_icount = 2;
diff --git a/qemu-options.hx b/qemu-options.hx
index 599db94..b7a6e65 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3275,7 +3275,7 @@ re-inject them.
ETEXI
DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
-"-icount
[shift=N|auto][,align=on|off][,sleep=no,rr=record|replay,rrfile=]\n" \
+"-icount
[shift=N|auto][,align=on|off][,sleep=on|off,rr=record|replay,rrfile=]\n"
\
"enable virtual instruction counter with 2^N clock ticks
per\n" \
"instruction, enable aligning the host and virtual
clocks\n" \
"or disable real time cpu sleeping\n", QEMU_ARCH_ALL)
@@ -3288,8 +3288,8 @@ then the virtual cpu speed will be automatically adjusted
to keep virtual
time within a few seconds of real time.
When the virtual cpu is sleeping, the virtual time will advance at default
-speed unless @option{sleep=no} is specified.
-With @option{sleep=no}, the virtual time will jump to the next timer deadline
+speed unless @option{sleep=on|off} is specified.
+With @option{sleep=off}, the virtual time will jump to the next timer deadline
instantly whenever the virtual cpu goes to sleep mode and will not advance
if no timer is enabled. This behavior give deterministic execution times from
the guest point of view.
--
2.7.1
[Qemu-devel] [PATCH 1/1] icount: possible options are on or off
Signed-off-by: Pranith Kumar
---
cpus.c | 4 ++--
qemu-options.hx | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpus.c b/cpus.c
index 9592163..bc774e2 100644
--- a/cpus.c
+++ b/cpus.c
@@ -630,7 +630,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
icount_align_option = qemu_opt_get_bool(opts, "align", false);
if (icount_align_option && !icount_sleep) {
-error_setg(errp, "align=on and sleep=no are incompatible");
+error_setg(errp, "align=on and sleep=off are incompatible");
}
if (strcmp(option, "auto") != 0) {
errno = 0;
@@ -643,7 +643,7 @@ void configure_icount(QemuOpts *opts, Error **errp)
} else if (icount_align_option) {
error_setg(errp, "shift=auto and align=on are incompatible");
} else if (!icount_sleep) {
-error_setg(errp, "shift=auto and sleep=no are incompatible");
+error_setg(errp, "shift=auto and sleep=off are incompatible");
}
use_icount = 2;
diff --git a/qemu-options.hx b/qemu-options.hx
index 599db94..b7a6e65 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3275,7 +3275,7 @@ re-inject them.
ETEXI
DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
-"-icount
[shift=N|auto][,align=on|off][,sleep=no,rr=record|replay,rrfile=]\n" \
+"-icount
[shift=N|auto][,align=on|off][,sleep=on|off,rr=record|replay,rrfile=]\n"
\
"enable virtual instruction counter with 2^N clock ticks
per\n" \
"instruction, enable aligning the host and virtual
clocks\n" \
"or disable real time cpu sleeping\n", QEMU_ARCH_ALL)
@@ -3288,8 +3288,8 @@ then the virtual cpu speed will be automatically adjusted
to keep virtual
time within a few seconds of real time.
When the virtual cpu is sleeping, the virtual time will advance at default
-speed unless @option{sleep=no} is specified.
-With @option{sleep=no}, the virtual time will jump to the next timer deadline
+speed unless @option{sleep=on|off} is specified.
+With @option{sleep=off}, the virtual time will jump to the next timer deadline
instantly whenever the virtual cpu goes to sleep mode and will not advance
if no timer is enabled. This behavior give deterministic execution times from
the guest point of view.
--
2.7.1
[Qemu-devel] [RFC PATCH] qemu-log: Open file for logging when specified
qemu-log defaults to stderr when there is no '-D' option mentioned on command
line. When '-D' option is specified, we also need to specify '-d' option for it
to use the specified logfile. When using monitor to enable logging this is
troublesome since there will be no '-d' option because of which monitor dumps
the logs to stderr.
Fix this by opening the log file when '-D' is specified on the command line.
Also fix an ancient comment which does not hold true since changing location and
log level has now been streamlined.
Signed-off-by: Pranith Kumar
CC: Paolo Bonzini
CC: Luiz Capitulino
CC: Markus Armbruster
CC: Peter Maydell
---
vl.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/vl.c b/vl.c
index d4b2d03..5f81ccc 100644
--- a/vl.c
+++ b/vl.c
@@ -3845,17 +3845,14 @@ int main(int argc, char **argv, char **envp)
exit(0);
}
-/* Open the logfile at this point, if necessary. We can't open the logfile
- * when encountering either of the logging options (-d or -D) because the
- * other one may be encountered later on the command line, changing the
- * location or level of logging.
+/* Open the logfile at this point and set the log mask if necessary.
*/
+if (log_file) {
+qemu_set_log_filename(log_file);
+}
+
if (log_mask) {
int mask;
-if (log_file) {
-qemu_set_log_filename(log_file);
-}
-
mask = qemu_str_to_log_mask(log_mask);
if (!mask) {
qemu_print_log_usage(stdout);
--
1.9.1
[Qemu-devel] crash using qemu-aarch64-softmmu
Hi, I occasionally get the following crash while running an AArch64 softmmu on an x86-64 system. I am using version 2.2 and cannot update to the latest version. Did anyone else see this happening? If this is fixed, I would love to get the patch backported. Thanks! Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc3b94700 (LWP 4409)] 0x754b75b9 in tb_phys_invalidate (tb=0x7fffc4679010, page_addr=18446744073709551615) at /mnt/devops/code/qsim/qemu/translate-all.c:965 965 tb2 = tb1->jmp_next[n1]; (gdb) bt #0 0x754b75b9 in tb_phys_invalidate (tb=0x7fffc4679010, page_addr=18446744073709551615) at /mnt/devops/code/qsim/qemu/translate-all.c:965 #1 0x754b7c0e in tb_invalidate_phys_page_range (start=946623904, end=946623905, is_cpu_write_access=1) at /mnt/devops/code/qsim/qemu/translate-all.c:1178 #2 0x754b7d82 in tb_invalidate_phys_page_fast (start=946623904, len=1) at /mnt/devops/code/qsim/qemu/translate-all.c:1236 #3 0x754b301e in notdirty_mem_write (opaque=0x0, ram_addr=946623904, val=0, size=1) at /mnt/devops/code/qsim/qemu/exec.c:1647 #4 0x75500872 in memory_region_write_accessor (mr=0x75e93180 , addr=946623904, value=0x7fffc3b93688, size=1, shift=0, mask=255) at /mnt/devops/code/qsim/qemu/memory.c:443 #5 0x755009ba in access_with_adjusted_size (addr=946623904, value=0x7fffc3b93688, size=1, access_size_min=1, access_size_max=4, access=0x755007da , mr=0x75e93180 ) at /mnt/devops/code/qsim/qemu/memory.c:480 #6 0x755039ec in memory_region_dispatch_write (mr=0x75e93180 , addr=946623904, data=0, size=1) at /mnt/devops/code/qsim/qemu/memory.c:1117 #7 0x755073fc in io_mem_write (mr=0x75e93180 , addr=946623904, val=0, size=1) at /mnt/devops/code/qsim/qemu/memory.c:1973 #8 0x7550dfd5 in io_writeb (env=0x707048, physaddr=946623904, val=0 '\000', addr=18446743799778268576, retaddr=140736744817534) at /mnt/devops/code/qsim/qemu/softmmu_template.h:381 #9 0x7550e319 in helper_ret_stb_mmu (env=0x707048, addr=18446743799778268576, val=0 '\000', mmu_idx=1, retaddr=140736744817534) at /mnt/devops/code/qsim/qemu/softmmu_template.h:420 #10 0x75614550 in helper_dc_zva (env=0x707048, vaddr_in=18446743799778268544) at /mnt/devops/code/qsim/qemu/target-arm/helper.c:5086 #11 0x7fffd3ae8380 in code_gen_buffer () #12 0x754b9c5c in cpu_tb_exec (cpu=0x6fee00, tb_ptr=0x7fffd3ae81f0 "A\213n\374\205\355\017\205*\001") at /mnt/devops/code/qsim/qemu/cpu-exec.c:171 #13 0x754ba6bc in cpu_arm_exec (env=0x707048) at /mnt/devops/code/qsim/qemu/cpu-exec.c:482 #14 0x754e9e66 in tcg_cpu_exec (env=0x707048) at /mnt/devops/code/qsim/qemu/cpus.c:1354 #15 0x754e9f7d in tcg_exec_all () at /mnt/devops/code/qsim/qemu/cpus.c:1387 #16 0x754e926f in qemu_tcg_cpu_thread_fn (arg=0x6fee00) at /mnt/devops/code/qsim/qemu/cpus.c:1033 #17 0x769ee182 in start_thread (arg=0x7fffc3b94700) at pthread_create.c:312 #18 0x7671b47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- Pranith
Re: [Qemu-devel] crash using qemu-aarch64-softmmu
On Wed, Jul 15, 2015 at 4:28 PM, Peter Maydell wrote: > Googling suggests "qsim" is "a project which aims, as part of the > Manifold simulation effort at Georgia Tech, to create a thread safe > multicore emulation library based on the QEMU emulator". > > My immediate guess is that this is buggy and you're causing > QEMU to corrupt some of its data structures by updating > and/or using them from multiple threads at once. > > Can you reproduce the problem with a stock upstream QEMU? > > The qsim changes AFAIU are not causing this. But I understand the apprehension that might be. I will try to reproduce this with an upstream virgin QEMU. Thanks! -- Pranith
[Qemu-devel] TCG question reg. tcg_cpu_exec()
Hello Paolo, I have a question reg. tcg_cpu_exec(cpu) which is called from tcg_exec_all(). tcg_cpu_exec() is called for each cpu in a loop. I observed that this call does not always execute TBs on that particular CPU. It return because the exit_request is set. I am trying to understand what scenarios can result in no TBs executing for that CPU. My understanding is that there is a pending operation which needs to be handled before we can execute TBs from this CPU(I/O?). Can you please explain what is happening or point me to the relevant portions of the code I need to look at to understand why this is happening? Thanks! -- Pranith
Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions
Hi Alex,
I have one question inline below.
Alex Bennée writes:
> The __atomic primitives have been available since GCC 4.7 and provide
> a richer interface for describing memory ordering requirements. As a
> bonus by using the primitives instead of hand-rolled functions we can
> use tools such as the AddressSanitizer which need the use of well
> defined APIs for its analysis.
>
> If we have __ATOMIC defines we exclusively use the __atomic primitives
> for all our atomic access. Otherwise we fall back to the mixture of
> __sync and hand-rolled barrier cases.
>
> +/* For C11 atomic ops */
> +
> +/* Manual memory barriers
> + *
> + *__atomic_thread_fence does not include a compiler barrier; instead,
> + * the barrier is part of __atomic_load/__atomic_store's "volatile-like"
> + * semantics. If smp_wmb() is a no-op, absence of the barrier means that
> + * the compiler is free to reorder stores on each side of the barrier.
> + * Add one here, and similarly in smp_rmb() and smp_read_barrier_depends().
> + */
> +
> +#define smp_mb()({ barrier(); __atomic_thread_fence(__ATOMIC_SEQ_CST);
> barrier(); })
I could not really understand why we need to wrap the fence with
barrier()'s. There are three parts to my confusion. Let me ask one after the
other.
First, these primitives are used in qemu codebase which runs on the host
architecture. Let us consider two example architectures: x86 and ARM.
On x86, __atomic_thread_fence(__ATOMIC_SEQ_CST) will generate an mfence
instruction. On ARM, this will generate the dmb instruction. Both these
serializing instructions also act as compiler barriers. Is there any
architecture which does not generate such a serializing instruction?
> +#define smp_wmb() ({ barrier(); __atomic_thread_fence(__ATOMIC_RELEASE);
> barrier(); })
> +#define smp_rmb() ({ barrier(); __atomic_thread_fence(__ATOMIC_ACQUIRE);
> barrier(); })
Second, why do you need barrier() on both sides? One barrier() seems to be
sufficient to prevent the compiler from reordering across the macro. Am I
missing something?
Finally, I tried looking at the gcc docs but could find nothing regarding
__atomic_thread_fence() not being considered as a memory barrier. What I did
find mentions about it being treated as a function call during the main
optimization stages and not during later stages:
http://www.spinics.net/lists/gcchelp/msg39798.html
AFAIU, in these later stages, even adding a barrier() as we are doing will
have no effect.
Can you point me to any docs which talk more about this?
Thanks!
--
Pranith
Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system
On Sun, Apr 3, 2016 at 9:50 AM, Marwa Hamza wrote: > hello , i tried to run qemu on x64 system , > > those are steps that i followed > i compile the kernel 4.4.1 with arch =i386 > i download busybox 1.21.0 > make ARCH=i386 menuconfig > I checked the option to compile Busybox as a static executable > make ARCH=i386 install > cd _install > mkdir proc sys dev lib etc etc/init.d > gedit etc/inittab > ::sysinit:/etc/init.d/rcS > sudo chmod +x etc/inittab > sudo gedit etc/init.d/rcS > #!/bin/sh Can you try changing this line to: "#!/sbin/ash"? I am not sure busybox has sh shell installed or configured properly. That is what your error message is pointing to atleast. > starting init :/bin/sh exists but couldn’t execute it > kernel panic – not syncing no working init found Thanks! -- Pranith
Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system
On Sun, Apr 3, 2016 at 9:50 AM, Marwa Hamza wrote: > ./i386-softmmu/qemu-system-i386 -M pc -kernel > /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage > -initrd /home/marwa/Bureau/lauterbach/i386_qemu/busybox-1.21.0/rootfs.img.gz > -append “root=/dev/ram rdinit=/sbin/init” > Can you post the output when you run this command? In particular, does the /sbin/init exist in the rootfs? -- Pranith
Re: [Qemu-devel] run qemu on x64 system ( ARCH=i386 or ARCH=x86-64) and on x86 system
On Sun, Apr 3, 2016 at 3:49 PM, Marwa Hamza wrote: > the output of this command > ./i386-softmmu/qemu-system-i386 -M pc -kernel >> >> /home/marwa/Bureau/lauterbach/i386_qemu/linux-4.1.18/arch/i386/boot/bzImage >> -initrd >> /home/marwa/Bureau/lauterbach/i386_qemu/busybox-1.21.0/rootfs.img.gz >> -append “root=/dev/ram rdinit=/sbin/init” >> > starting init :/sbin/init exists but couldn't execute it (error -8) > starting init : /bin/sh exists but couldn't execute it (error -8) > kernel panic not syncing : no working init found , try passing init= option > to kernel > I don't think this is a qemu problem. From the error message it looks like init in your busybox root image is not configured properly. I would focus on finding why the init file is not able to run(permissions, maybe?). -- Pranith
Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions
Hi Paolo, On Mon, Apr 4, 2016 at 4:14 AM, Paolo Bonzini wrote: > > The issue is that atomic_thread_fence() only affects other atomic > operations, while smp_rmb() and smp_wmb() affect normal loads and stores > as well. That is different from what I understand what atomic_thread_fence() does. AFAIK, it should order all loads/stores and not only atomic operations. Quoting http://www.inf.pucrs.br/~flash/progeng2/cppreference/w/cpp/atomic/atomic_thread_fencehtml.html: "Establishes memory synchronization ordering of non-atomic and relaxed atomic accesses" > > In the GCC implementation, atomic operations (even relaxed ones) access > memory as if the pointer was volatile. By doing this, GCC can remove > the acquire and release fences altogether on TSO architectures. We > actually observed a case where the compiler subsequently inverted the > order of two writes around a smp_wmb(). That is a GCC bug in that case. GCC should remove smp_wmb() only after the optimization passes have run in the codegen phase. Can you please point me to the mailing list thread/bug where this was discovered? Or is it easily reproducible with reverting that patch? In that case, the location of the bug will be helpful to analyse this further. > In principle it could do the same on architectures that are sequentially > consistent; even if none exists in practice, keeping the barriers for > smp_mb() is consistent with the other barriers. I understand one barrier(), but having two on both sides seems unnecessary. I would prefer we clean up and have just one. Although, I think it is just an annoyance since performance wise there is no difference. Two consecutive barrier()'s should behave just like one. Thanks! -- Pranith
Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions
On Mon, Apr 4, 2016 at 1:03 PM, Paolo Bonzini wrote: >> >> Quoting >> http://www.inf.pucrs.br/~flash/progeng2/cppreference/w/cpp/atomic/atomic_thread_fencehtml.html: >> >> "Establishes memory synchronization ordering of non-atomic and relaxed >> atomic accesses" > > You can find some information at > https://bugzilla.redhat.com/show_bug.cgi?id=1142857 and This bug seems to be out-of-bounds. I get a message saying that the bug has been restricted for internal development processes. > https://retrace.fedoraproject.org/faf/problems/670281/. > > I've looked at private email from that time and I was pointed to this > sentence in GCC's manual, which says the opposite: > > "Note that in the C++11 memory model, fences (e.g., > ‘__atomic_thread_fence’) take effect in combination with other > atomic operations on specific memory locations (e.g., atomic loads); > operations on specific memory locations do not necessarily affect > other operations in the same way." > > Basically, the __atomic fences are essentially a way to break up a > non-relaxed atomic access into a relaxed atomic access and the > ordering-constraining fence. According to those emails, atomic > load-acquires and store-releases can provide synchronization for plain > loads and stores (not just for relaxed atomic loads and stores). > However, an atomic thread fence cannot do this. Yes, on further research... this looks to be the case. I think I understand the reasoning for this is to separate synchronization variables/objects vs data. > > It depends on the compiler you're using. With some luck, reverting the > patch will cause accesses across smp_wmb() or smp_rmb() to get > reordered. In our case it was in thread-pool.c; Kevin Wolf did the > analysis. If ordering was crucial for those stores, I think it would have been better to use atomics on them to enforce ordering. Also, do you plan to introduce load_acquire/store_release() operations like done in the linux kernel? They would cleanly map to gcc atomics and make the ordering requirements explicit. Thanks! -- Pranith
[Qemu-devel] [PATCH] docs/atomics.txt: Update pointer to linux macro
Add a missing end brace and update doc to point to the latest access macro. ACCESS_ONE() is deprecated. Signed-off-by: Pranith Kumar --- docs/atomics.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/atomics.txt b/docs/atomics.txt index ef285e3..bba771e 100644 --- a/docs/atomics.txt +++ b/docs/atomics.txt @@ -62,7 +62,7 @@ operations: typeof(*ptr) atomic_fetch_sub(ptr, val) typeof(*ptr) atomic_fetch_and(ptr, val) typeof(*ptr) atomic_fetch_or(ptr, val) -typeof(*ptr) atomic_xchg(ptr, val +typeof(*ptr) atomic_xchg(ptr, val) typeof(*ptr) atomic_cmpxchg(ptr, old, new) all of which return the old value of *ptr. These operations are @@ -328,7 +328,7 @@ and memory barriers, and the equivalents in QEMU: - atomic_read and atomic_set in Linux give no guarantee at all; atomic_read and atomic_set in QEMU include a compiler barrier - (similar to the ACCESS_ONCE macro in Linux). + (similar to the READ_ONCE/WRITE_ONCE macros in Linux). - most atomic read-modify-write operations in Linux return void; in QEMU, all of them return the old value of the variable. -- 2.8.1
Re: [Qemu-devel] [PATCH] docs/atomics.txt: Update pointer to linux macro
On Tue, Apr 12, 2016 at 7:42 AM, Marc-André Lureau wrote: > Hi > > On Mon, Apr 11, 2016 at 7:30 PM, Pranith Kumar wrote: >> Add a missing end brace and update doc to point to the latest access >> macro. ACCESS_ONE() is deprecated. > > ONE/ONCE Right, I missed this one. Should I fix and send a new patch? Thanks, -- Pranith
Re: [Qemu-devel] [PATCH] docs/atomics.txt: Update pointer to linux macro
On Tue, Apr 12, 2016 at 5:20 PM, Paolo Bonzini wrote: > FWIW I'll be mostly offline this week and on vacation starting from the > next, so it's probably best if you send the patch at the beginning of > May. It will be fixed _and_ act as a reminder. :) Sure, I will do so in May. -- Pranith
[Qemu-devel] [PATCH] docs/atomics.txt: Update pointer to linux macro
Add a missing end brace and update doc to point to the latest access macro. ACCESS_ONCE() is deprecated. Signed-off-by: Pranith Kumar --- docs/atomics.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/atomics.txt b/docs/atomics.txt index ef285e3..bba771e 100644 --- a/docs/atomics.txt +++ b/docs/atomics.txt @@ -62,7 +62,7 @@ operations: typeof(*ptr) atomic_fetch_sub(ptr, val) typeof(*ptr) atomic_fetch_and(ptr, val) typeof(*ptr) atomic_fetch_or(ptr, val) -typeof(*ptr) atomic_xchg(ptr, val +typeof(*ptr) atomic_xchg(ptr, val) typeof(*ptr) atomic_cmpxchg(ptr, old, new) all of which return the old value of *ptr. These operations are @@ -328,7 +328,7 @@ and memory barriers, and the equivalents in QEMU: - atomic_read and atomic_set in Linux give no guarantee at all; atomic_read and atomic_set in QEMU include a compiler barrier - (similar to the ACCESS_ONCE macro in Linux). + (similar to the READ_ONCE/WRITE_ONCE macros in Linux). - most atomic read-modify-write operations in Linux return void; in QEMU, all of them return the old value of the variable. -- 2.8.1
Re: [Qemu-devel] [RFC PATCH 2/3] tcg: Add support for fence generation in x86 backend
On Wed, May 25, 2016 at 3:25 PM, Alex Bennée wrote: > Should we make the emitting of the function call/TCGop conditional on > MTTCG being enabled? If we are running in round-robin mode there is no > need to issue any fence operations. > Also, we should check if SMP(> 1 processors) is enabled since fences are not necessary on UP systems. -- Pranith
Re: [Qemu-devel] [RFC PATCH 2/3] tcg: Add support for fence generation in x86 backend
On Wed, May 25, 2016 at 3:43 PM, Sergey Fedorov wrote: > > I think it would better not to defer native support for the operation. > It should be relatively simple instruction. Otherwise we could wind up > deferring this indefinitely. > Agreed. I will go with the native generation for now. Thanks, -- Pranith
Re: [Qemu-devel] [RFC PATCH 2/3] tcg: Add support for fence generation in x86 backend
Hi Richard, Thank you for the helpful comments. On Wed, May 25, 2016 at 1:35 PM, Richard Henderson wrote: > On 05/24/2016 10:18 AM, Pranith Kumar wrote: >> diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h >> index 92be341..93ea42e 100644 >> --- a/tcg/i386/tcg-target.h >> +++ b/tcg/i386/tcg-target.h >> @@ -100,6 +100,7 @@ extern bool have_bmi1; >> #define TCG_TARGET_HAS_muls2_i321 >> #define TCG_TARGET_HAS_muluh_i320 >> #define TCG_TARGET_HAS_mulsh_i320 >> +#define TCG_TARGET_HAS_fence1 > > > This has to be defined for all hosts. OK. I will add an entry in tcg.h with default 0 and override in individual architecture once it is implemented. >> @@ -347,6 +347,7 @@ static inline int >> tcg_target_const_match(tcg_target_long val, TCGType type, >> #define OPC_SHRX(0xf7 | P_EXT38 | P_SIMDF2) >> #define OPC_TESTL (0x85) >> #define OPC_XCHG_ax_r32(0x90) >> +#define OPC_MFENCE (0xAE | P_EXT) > > Why define OPC_MFENCE if you're not going to use it? Of course, it's not > exactly a complete and useful definition, so maybe just delete OPC_MFENCE. I want to use OPC_MFENCE instead of hard-coding the value in tcg_out_fence(), but as you said the definition is not complete(it currently generates only 0x0FAE). I am trying to figure out how to generate 0x0FAEF0 using the definition. > > Also, for 32-bit you need to check for sse2 before outputting this. See > also the existing cpuid checks in tcg_target_init and the fallback smp_mb > definition for pre-gcc-4.4. OK, I'll check the current code and do something similar. Thanks, -- Pranith
Re: [Qemu-devel] [PATCH v2 00/12] tcg: Add fence opcode
On Thu, May 26, 2016 at 9:00 PM, Richard Henderson wrote: > This is a reorg of Pranith's first patch set, correcting a few > mistakes and adding backend support for all of the other hosts. > > In addition, I added front-end support for Alpha, since I didn't > actually have any armv7 images handy to test the backends. > Thanks Richard for fixing this up for other archs. You saved me a ton of work :) I'll rebase my work on top of this patch series. Regards, -- Pranith
Re: [Qemu-devel] [PATCH v2 10/12] tcg/tci: Add support for fence
On Fri, May 27, 2016 at 10:20 AM, Sergey Fedorov wrote: >>>> +case INDEX_op_fence: >>>> +smp_mb(); >>>> +break; >>>> default: >>>> TODO(); >>>> break; >>> A bit of bike-shedding. While there's no common ISA term for "memory >>> barrier" (also known as a "membar", "memory fence", etc.), we already >>> refer to it as a "memory barrier" (or "mb") in include/qemu/atomic.h and >>> docs/atomics.txt. Why don't be consistent and avoid introducing yet >>> another term for the same thing? >>> >> Fair point. Do you think tcg_out_mb() is better then? > > Yes, if used together with 'INDEX_op_mb', of course. > OK. I'll make the change. Thanks for the feedback! -- Pranith
Re: [Qemu-devel] [PATCH v2 01/12] Introduce TCGOpcode for fence instruction
Sergey Fedorov writes: > On 27/05/16 04:00, Richard Henderson wrote: >> diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h >> index 6d0410c..b772d90 100644 >> --- a/tcg/tcg-opc.h >> +++ b/tcg/tcg-opc.h >> @@ -42,6 +42,8 @@ DEF(br, 0, 0, 1, TCG_OPF_BB_END) >> # define IMPL64 TCG_OPF_64BIT >> #endif >> >> +DEF(fence, 0, 0, 0, TCG_OPF_SIDE_EFFECTS) >> + > > I still think this TCG op needs to have a constant argument of a barrier > type. So that we can distinguish between full, read and write memory > barriers. > Yes, I have a version with this fixed. I will post my patches(v3) with this changed. Thanks, -- Pranith
Re: [Qemu-devel] [PATCH v2 10/12] tcg/tci: Add support for fence
Hi Sergey, Sergey Fedorov writes: > On 27/05/16 04:00, Richard Henderson wrote: >> diff --git a/tci.c b/tci.c >> index b488c0d..53b3f71 100644 >> --- a/tci.c >> +++ b/tci.c >> @@ -1236,6 +1236,9 @@ uintptr_t tcg_qemu_tb_exec(CPUArchState *env, uint8_t >> *tb_ptr) >> tcg_abort(); >> } >> break; >> +case INDEX_op_fence: >> +smp_mb(); >> +break; >> default: >> TODO(); >> break; > > A bit of bike-shedding. While there's no common ISA term for "memory > barrier" (also known as a "membar", "memory fence", etc.), we already > refer to it as a "memory barrier" (or "mb") in include/qemu/atomic.h and > docs/atomics.txt. Why don't be consistent and avoid introducing yet > another term for the same thing? > Fair point. Do you think tcg_out_mb() is better then? Thanks, -- Pranith
Re: [Qemu-devel] [RFC 01/10] exec: Introduce tcg_exclusive_{lock, unlock}()
Hi Alvise,
On Thu, May 26, 2016 at 12:35 PM, Alvise Rigo
wrote:
> Add tcg_exclusive_{lock,unlock}() functions that will be used for making
> the emulation of LL and SC instructions thread safe.
>
> Signed-off-by: Alvise Rigo
> +__thread bool cpu_have_exclusive_lock;
> +QemuSpin cpu_exclusive_lock;
> +inline void tcg_exclusive_lock(void)
> +{
> +if (!cpu_have_exclusive_lock) {
> +qemu_spin_lock(&cpu_exclusive_lock);
> +cpu_have_exclusive_lock = true;
> +}
> +}
> +
> +inline void tcg_exclusive_unlock(void)
> +{
> +if (cpu_have_exclusive_lock) {
> +cpu_have_exclusive_lock = false;
> +qemu_spin_unlock(&cpu_exclusive_lock);
> +}
> +}
I think the unlock() here should have an assert if
cpu_have_exclusive_lock is false. From what I can see, a thread should
either take the exclusive lock or wait spinning for it in lock(). So
unlock() should always see cpu_have_exclusive_lock as true. It is a
good place to find locking bugs.
--
Pranith
[Qemu-devel] [RFC v2 PATCH 07/13] tcg/ppc: Add support for fence
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/ppc/tcg-target.inc.c | 8
1 file changed, 8 insertions(+)
diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 1039407..45a667f 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -469,6 +469,9 @@ static int tcg_target_const_match(tcg_target_long val,
TCGType type,
#define STHX XO31(407)
#define STWX XO31(151)
+#define HWSYNC XO31(598)
+#define LWSYNC (HWSYNC | (1u << 21))
+
#define SPR(a, b) a)<<5)|(b))<<11)
#define LR SPR(8, 0)
#define CTRSPR(9, 0)
@@ -2425,6 +2428,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
const TCGArg *args,
tcg_out32(s, MULHD | TAB(args[0], args[1], args[2]));
break;
+case INDEX_op_mb:
+/* ??? Do we want SEQ_CST or ACQ_REL memory model. */
+tcg_out32(s, HWSYNC);
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -2572,6 +2579,7 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_st_i64, { "S", "S", "S", "S" } },
#endif
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 06/13] tcg/mips: Add support for fence
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/mips/tcg-target.inc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index b2a839a..fc9c7fb 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -292,6 +292,7 @@ typedef enum {
OPC_JALR = OPC_SPECIAL | 0x09,
OPC_MOVZ = OPC_SPECIAL | 0x0A,
OPC_MOVN = OPC_SPECIAL | 0x0B,
+OPC_SYNC = OPC_SPECIAL | 0x0F,
OPC_MFHI = OPC_SPECIAL | 0x10,
OPC_MFLO = OPC_SPECIAL | 0x12,
OPC_MULT = OPC_SPECIAL | 0x18,
@@ -1636,6 +1637,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
const_args[4], const_args[5], true);
break;
+case INDEX_op_mb:
+tcg_out32(s, OPC_SYNC);
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
case INDEX_op_call: /* Always emitted via tcg_out_call. */
@@ -1716,6 +1720,8 @@ static const TCGTargetOpDef mips_op_defs[] = {
{ INDEX_op_qemu_ld_i64, { "L", "L", "lZ", "lZ" } },
{ INDEX_op_qemu_st_i64, { "SZ", "SZ", "SZ", "SZ" } },
#endif
+
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 00/13] tcg: Add fence gen support
Hello, The following series adds fence instruction generation support to TCG. The current work has been rebased on-top of Richard's patch series. This has been tested and confirmed to fix ordering issues on a x86 host with MTTCG enabled ARMv7 guest using KVM unit tests. Pranith Kumar (13): Introduce TCGOpcode for memory barrier tcg/i386: Add support for fence tcg/aarch64: Add support for fence tcg/arm: Add support for fence tcg/ia64: Add support for fence tcg/mips: Add support for fence tcg/ppc: Add support for fence tcg/s390: Add support for fence tcg/sparc: Add support for fence tcg/tci: Add support for fence target-arm: Generate fences in ARMv7 frontend target-alpha: Generate fence op tcg: Generate fences only for SMP MTTCG guests target-alpha/translate.c | 5 +++-- target-arm/translate.c | 7 +-- tcg/README | 17 + tcg/aarch64/tcg-target.inc.c | 7 +++ tcg/arm/tcg-target.inc.c | 12 tcg/i386/tcg-target.inc.c| 35 +++ tcg/ia64/tcg-target.inc.c| 5 + tcg/mips/tcg-target.inc.c| 6 ++ tcg/ppc/tcg-target.inc.c | 8 tcg/s390/tcg-target.inc.c| 9 + tcg/sparc/tcg-target.inc.c | 8 tcg/tcg-op.c | 9 + tcg/tcg-op.h | 2 ++ tcg/tcg-opc.h| 2 ++ tcg/tcg.h| 8 tcg/tci/tcg-target.inc.c | 3 +++ tci.c| 3 +++ 17 files changed, 142 insertions(+), 4 deletions(-) -- 2.8.3
[Qemu-devel] [RFC v2 PATCH 13/13] tcg: Generate fences only for SMP MTTCG guests
We need to generate fence instructions only for SMP MTTCG guests. This
patch enforces that.
Signed-off-by: Pranith Kumar
---
tcg/tcg-op.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index a6f01a7..eeb0d0c 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -36,6 +36,8 @@ extern TCGv_i32 TCGV_HIGH_link_error(TCGv_i64);
#define TCGV_HIGH TCGV_HIGH_link_error
#endif
+extern int smp_cpus;
+
/* Note that this is optimized for sequential allocation during translate.
Up to and including filling in the forward link immediately. We'll do
proper termination of the end of the list after we finish translation. */
@@ -145,8 +147,9 @@ void tcg_gen_op6(TCGContext *ctx, TCGOpcode opc, TCGArg a1,
TCGArg a2,
void tcg_gen_mb(TCGArg a)
{
-/* ??? Enable only when MTTCG is enabled. */
-tcg_gen_op1(&tcg_ctx, INDEX_op_mb, 0);
+if (qemu_tcg_mttcg_enabled() && smp_cpus > 1) {
+tcg_gen_op1(&tcg_ctx, INDEX_op_mb, 0);
+}
}
/* 32 bit ops */
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 05/13] tcg/ia64: Add support for fence
Cc: Aurelien Jarno
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/ia64/tcg-target.inc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tcg/ia64/tcg-target.inc.c b/tcg/ia64/tcg-target.inc.c
index 261861f..88cc560 100644
--- a/tcg/ia64/tcg-target.inc.c
+++ b/tcg/ia64/tcg-target.inc.c
@@ -247,6 +247,7 @@ enum {
OPC_LD4_M3= 0x0a08000ull,
OPC_LD8_M1= 0x080c000ull,
OPC_LD8_M3= 0x0a0c000ull,
+OPC_MF_M24= 0x0011000ull,
OPC_MUX1_I3 = 0x0eca000ull,
OPC_NOP_B9= 0x0400800ull,
OPC_NOP_F16 = 0x800ull,
@@ -2213,6 +2214,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
tcg_out_qemu_st(s, args);
break;
+case INDEX_op_mb:
+tcg_out_bundle(s, mmI, OPC_MF_M24, INSN_NOP_M, INSN_NOP_I);
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -2326,6 +2330,7 @@ static const TCGTargetOpDef ia64_op_defs[] = {
{ INDEX_op_qemu_st_i32, { "SZ", "r" } },
{ INDEX_op_qemu_st_i64, { "SZ", "r" } },
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
This commit introduces the TCGOpcode for memory barrier instruction.
This opcode takes an argument which is the type of memory barrier
which should be generated.
Signed-off-by: Pranith Kumar
Signed-off-by: Richard Henderson
---
tcg/README| 17 +
tcg/tcg-op.c | 6 ++
tcg/tcg-op.h | 2 ++
tcg/tcg-opc.h | 2 ++
tcg/tcg.h | 8
5 files changed, 35 insertions(+)
diff --git a/tcg/README b/tcg/README
index f4a8ac1..cfe79d7 100644
--- a/tcg/README
+++ b/tcg/README
@@ -402,6 +402,23 @@ double-word product T0. The later is returned in two
single-word outputs.
Similar to mulu2, except the two inputs T1 and T2 are signed.
+* Memory Barrier support
+
+* mb <$arg>
+
+Generate a target memory barrier instruction to ensure memory ordering as being
+enforced by a corresponding guest memory barrier instruction. The ordering
+enforced by the backend may be stricter than the ordering required by the
guest.
+It cannot be weaker. This opcode takes an optional constant argument if
required
+to generate the appropriate barrier instruction. The backend should take care
to
+emit the target barrier instruction only when necessary i.e., for SMP guests
and
+when MTTCG is enabled.
+
+The guest translators should generate this opcode for all guest instructions
+which have ordering side effects.
+
+Please see docs/atomics.txt for more information on memory barriers.
+
* 64-bit guest on 32-bit host support
The following opcodes are internal to TCG. Thus they are to be implemented by
diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index f554b86..a6f01a7 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -143,6 +143,12 @@ void tcg_gen_op6(TCGContext *ctx, TCGOpcode opc, TCGArg
a1, TCGArg a2,
tcg_emit_op(ctx, opc, pi);
}
+void tcg_gen_mb(TCGArg a)
+{
+/* ??? Enable only when MTTCG is enabled. */
+tcg_gen_op1(&tcg_ctx, INDEX_op_mb, 0);
+}
+
/* 32 bit ops */
void tcg_gen_addi_i32(TCGv_i32 ret, TCGv_i32 arg1, int32_t arg2)
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index c446d3d..40920fb 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -261,6 +261,8 @@ static inline void tcg_gen_br(TCGLabel *l)
tcg_gen_op1(&tcg_ctx, INDEX_op_br, label_arg(l));
}
+void tcg_gen_mb(TCGArg a);
+
/* Helper calls. */
/* 32 bit ops */
diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h
index 6d0410c..c0f3e83 100644
--- a/tcg/tcg-opc.h
+++ b/tcg/tcg-opc.h
@@ -42,6 +42,8 @@ DEF(br, 0, 0, 1, TCG_OPF_BB_END)
# define IMPL64 TCG_OPF_64BIT
#endif
+DEF(mb, 0, 1, 0, 0)
+
DEF(mov_i32, 1, 1, 0, TCG_OPF_NOT_PRESENT)
DEF(movi_i32, 1, 0, 1, TCG_OPF_NOT_PRESENT)
DEF(setcond_i32, 1, 2, 1, 0)
diff --git a/tcg/tcg.h b/tcg/tcg.h
index a46d17c..a1d59f7 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -385,6 +385,14 @@ static inline intptr_t QEMU_ARTIFICIAL
GET_TCGV_PTR(TCGv_ptr t)
#define TCG_CALL_DUMMY_TCGV MAKE_TCGV_I32(-1)
#define TCG_CALL_DUMMY_ARG ((TCGArg)(-1))
+/* TCGOpmb args */
+#define TCG_MB_FULL ((TCGArg)(0))
+#define TCG_MB_READ ((TCGArg)(1))
+#define TCG_MB_WRITE((TCGArg)(2))
+#define TCG_MB_ACQUIRE ((TCGArg)(3))
+#define TCG_MB_RELEASE ((TCGArg)(4))
+
+
/* Conditions. Note that these are laid out for easy manipulation by
the functions below:
bit 0 is used for inverting;
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 11/13] target-arm: Generate fences in ARMv7 frontend
Signed-off-by: Pranith Kumar Signed-off-by: Richard Henderson --- target-arm/translate.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/target-arm/translate.c b/target-arm/translate.c index c946c0e..e1b16c0 100644 --- a/target-arm/translate.c +++ b/target-arm/translate.c @@ -7980,9 +7980,11 @@ static void disas_arm_insn(DisasContext *s, unsigned int insn) gen_clrex(s); return; case 4: /* dsb */ +ARCH(7); +return; case 5: /* dmb */ ARCH(7); -/* We don't emulate caches so these are a no-op. */ +tcg_gen_mb(TCG_MB_FULL); return; case 6: /* isb */ /* We need to break the TB after this insn to execute @@ -10330,8 +10332,9 @@ static int disas_thumb2_insn(CPUARMState *env, DisasContext *s, uint16_t insn_hw gen_clrex(s); break; case 4: /* dsb */ +break; case 5: /* dmb */ -/* These execute as NOPs. */ +tcg_gen_mb(TCG_MB_FULL); break; case 6: /* isb */ /* We need to break the TB after this insn -- 2.8.3
[Qemu-devel] [RFC v2 PATCH 04/13] tcg/arm: Add support for fence
Cc: Andrzej Zaborowski
Cc: Peter Maydell
Signed-off-by: Pranith Kumar
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.inc.c | 12
1 file changed, 12 insertions(+)
diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index a914762..e88d8ce 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -305,6 +305,10 @@ typedef enum {
INSN_LDRD_REG = 0x00d0,
INSN_STRD_IMM = 0x004000f0,
INSN_STRD_REG = 0x00f0,
+
+INSN_DMB_ISH = 0x5bf07ff5,
+INSN_DMB_MCR = 0xba0f07ee,
+
} ARMInsn;
#define SHIFT_IMM_LSL(im) (((im) << 7) | 0x00)
@@ -1905,6 +1909,13 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
tcg_out_udiv(s, COND_AL, args[0], args[1], args[2]);
break;
+case INDEX_op_mb:
+if (use_armv7_instructions) {
+tcg_out32(s, INSN_DMB_ISH);
+} else if (use_armv6_instructions) {
+tcg_out32(s, INSN_DMB_MCR);
+}
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
case INDEX_op_call: /* Always emitted via tcg_out_call. */
@@ -1979,6 +1990,7 @@ static const TCGTargetOpDef arm_op_defs[] = {
{ INDEX_op_div_i32, { "r", "r", "r" } },
{ INDEX_op_divu_i32, { "r", "r", "r" } },
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 12/13] target-alpha: Generate fence op
Signed-off-by: Richard Henderson Signed-off-by: Pranith Kumar --- target-alpha/translate.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target-alpha/translate.c b/target-alpha/translate.c index 5b86992..17b68f5 100644 --- a/target-alpha/translate.c +++ b/target-alpha/translate.c @@ -2329,11 +2329,12 @@ static ExitStatus translate_one(DisasContext *ctx, uint32_t insn) break; case 0x4000: /* MB */ -/* No-op */ +tcg_gen_mb(TCG_MB_FULL); break; case 0x4400: /* WMB */ -/* No-op */ +/* TODO: Change this to write barrier */ +tcg_gen_mb(TCG_MB_FULL); break; case 0x8000: /* FETCH */ -- 2.8.3
[Qemu-devel] [RFC v2 PATCH 02/13] tcg/i386: Add support for fence
Generate mfence instruction on SSE2 enabled processors. For older
processors, generate a 'lock orl $0,0(%esp)' instruction which has
similar ordering semantics.
Signed-off-by: Pranith Kumar
[rth: Check for sse2, fallback to locked memory op otherwise.]
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/i386/tcg-target.inc.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index 8fd37f4..1fd5a99 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -121,6 +121,16 @@ static bool have_cmov;
# define have_cmov 0
#endif
+/* For 32-bit, we are going to attempt to determine at runtime whether
+ sse2 support is available. */
+#if TCG_TARGET_REG_BITS == 64 || defined(__SSE2__)
+# define have_sse2 1
+#elif defined(CONFIG_CPUID_H) && defined(bit_SSE2)
+static bool have_sse2;
+#else
+# define have_sse2 0
+#endif
+
/* If bit_MOVBE is defined in cpuid.h (added in GCC version 4.6), we are
going to attempt to determine at runtime whether movbe is available. */
#if defined(CONFIG_CPUID_H) && defined(bit_MOVBE)
@@ -686,6 +696,21 @@ static inline void tcg_out_pushi(TCGContext *s,
tcg_target_long val)
}
}
+static inline void tcg_out_mb(TCGContext *s)
+{
+if (have_sse2) {
+/* mfence */
+tcg_out8(s, 0x0f);
+tcg_out8(s, 0xae);
+tcg_out8(s, 0xf0);
+} else {
+/* lock orl $0,0(%esp) */
+tcg_out8(s, 0xf0);
+tcg_out_modrm_offset(s, OPC_ARITH_EvIb, ARITH_OR, TCG_REG_ESP, 0);
+tcg_out8(s, 0);
+}
+}
+
static inline void tcg_out_push(TCGContext *s, int reg)
{
tcg_out_opc(s, OPC_PUSH_r32 + LOWREGMASK(reg), 0, reg, 0);
@@ -2114,6 +2139,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
}
break;
+case INDEX_op_mb:
+tcg_out_mb(s);
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -2179,6 +2207,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_add2_i32, { "r", "r", "0", "1", "ri", "ri" } },
{ INDEX_op_sub2_i32, { "r", "r", "0", "1", "ri", "ri" } },
+{ INDEX_op_mb, { "r" } },
+
#if TCG_TARGET_REG_BITS == 32
{ INDEX_op_brcond2_i32, { "r", "r", "ri", "ri" } },
{ INDEX_op_setcond2_i32, { "r", "r", "r", "ri", "ri" } },
@@ -2356,6 +2386,11 @@ static void tcg_target_init(TCGContext *s)
available, we'll use a small forward branch. */
have_cmov = (d & bit_CMOV) != 0;
#endif
+#ifndef have_sse2
+/* Likewise, almost all hardware supports SSE2, but we do
+ have a locked memory operation to use as a substitute. */
+have_sse2 = (d & bit_SSE2) != 0;
+#endif
#ifndef have_movbe
/* MOVBE is only available on Intel Atom and Haswell CPUs, so we
need to probe for it. */
--
2.8.3
Re: [Qemu-devel] [RFC v2 PATCH 00/13] tcg: Add fence gen support
Added correct email for Sergey in CC. I apologize for getting Sergey's email wrong. Please drop/correct his email when replying to the patches in this series otherwise you will see an email bounce. On Tue, May 31, 2016 at 2:39 PM, Pranith Kumar wrote: > Hello, > > The following series adds fence instruction generation support to > TCG. The current work has been rebased on-top of Richard's patch > series. > > This has been tested and confirmed to fix ordering issues on a x86 > host with MTTCG enabled ARMv7 guest using KVM unit tests. > > Pranith Kumar (13): > Introduce TCGOpcode for memory barrier > tcg/i386: Add support for fence > tcg/aarch64: Add support for fence > tcg/arm: Add support for fence > tcg/ia64: Add support for fence > tcg/mips: Add support for fence > tcg/ppc: Add support for fence > tcg/s390: Add support for fence > tcg/sparc: Add support for fence > tcg/tci: Add support for fence > target-arm: Generate fences in ARMv7 frontend > target-alpha: Generate fence op > tcg: Generate fences only for SMP MTTCG guests > > target-alpha/translate.c | 5 +++-- > target-arm/translate.c | 7 +-- > tcg/README | 17 + > tcg/aarch64/tcg-target.inc.c | 7 +++ > tcg/arm/tcg-target.inc.c | 12 > tcg/i386/tcg-target.inc.c| 35 +++ > tcg/ia64/tcg-target.inc.c| 5 + > tcg/mips/tcg-target.inc.c| 6 ++ > tcg/ppc/tcg-target.inc.c | 8 > tcg/s390/tcg-target.inc.c| 9 + > tcg/sparc/tcg-target.inc.c | 8 > tcg/tcg-op.c | 9 + > tcg/tcg-op.h | 2 ++ > tcg/tcg-opc.h| 2 ++ > tcg/tcg.h| 8 > tcg/tci/tcg-target.inc.c | 3 +++ > tci.c| 3 +++ > 17 files changed, 142 insertions(+), 4 deletions(-) > > -- > 2.8.3 > -- Pranith
[Qemu-devel] [RFC v2 PATCH 08/13] tcg/s390: Add support for fence
Cc: Alexander Graf
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/s390/tcg-target.inc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tcg/s390/tcg-target.inc.c b/tcg/s390/tcg-target.inc.c
index e95b04b..b4f14bc 100644
--- a/tcg/s390/tcg-target.inc.c
+++ b/tcg/s390/tcg-target.inc.c
@@ -341,6 +341,7 @@ static tcg_insn_unit *tb_ret_addr;
#define FACILITY_EXT_IMM (1ULL << (63 - 21))
#define FACILITY_GEN_INST_EXT (1ULL << (63 - 34))
#define FACILITY_LOAD_ON_COND (1ULL << (63 - 45))
+#define FACILITY_FAST_BCR_SER FACILITY_LOAD_ON_COND
static uint64_t facilities;
@@ -2157,6 +2158,13 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
tgen_deposit(s, args[0], args[2], args[3], args[4]);
break;
+case INDEX_op_mb:
+/* The host memory model is quite strong, we simply need to
+ serialize the instruction stream. */
+tcg_out_insn(s, RR, BCR,
+facilities & FACILITY_FAST_BCR_SER ? 14 : 15, 0);
+break;
+
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -2278,6 +2286,7 @@ static const TCGTargetOpDef s390_op_defs[] = {
{ INDEX_op_movcond_i64, { "r", "r", "rC", "r", "0" } },
{ INDEX_op_deposit_i64, { "r", "0", "r" } },
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 09/13] tcg/sparc: Add support for fence
Cc: Blue Swirl
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/sparc/tcg-target.inc.c | 8
1 file changed, 8 insertions(+)
diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
index a611885..81f263f 100644
--- a/tcg/sparc/tcg-target.inc.c
+++ b/tcg/sparc/tcg-target.inc.c
@@ -249,6 +249,8 @@ static const int tcg_target_call_oarg_regs[] = {
#define STWA (INSN_OP(3) | INSN_OP3(0x14))
#define STXA (INSN_OP(3) | INSN_OP3(0x1e))
+#define MEMBAR (INSN_OP(2) | INSN_OP3(0x28) | INSN_RS1(15) | (1 << 13))
+
#ifndef ASI_PRIMARY_LITTLE
#define ASI_PRIMARY_LITTLE 0x88
#endif
@@ -1450,6 +1452,11 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_arithc(s, a0, TCG_REG_G0, a1, const_args[1], c);
break;
+case INDEX_op_mb:
+/* membar #LoadLoad|#LoadStore|#StoreStore|#StoreLoad */
+tcg_out32(s, MEMBAR | 15);
+break;
+
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -1551,6 +1558,7 @@ static const TCGTargetOpDef sparc_op_defs[] = {
{ INDEX_op_qemu_st_i32, { "sZ", "A" } },
{ INDEX_op_qemu_st_i64, { "SZ", "A" } },
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 10/13] tcg/tci: Add support for fence
Cc: Stefan Weil
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/tci/tcg-target.inc.c | 3 +++
tci.c| 3 +++
2 files changed, 6 insertions(+)
diff --git a/tcg/tci/tcg-target.inc.c b/tcg/tci/tcg-target.inc.c
index 4e91687..a507ceb 100644
--- a/tcg/tci/tcg-target.inc.c
+++ b/tcg/tci/tcg-target.inc.c
@@ -255,6 +255,7 @@ static const TCGTargetOpDef tcg_target_op_defs[] = {
{ INDEX_op_bswap32_i32, { R, R } },
#endif
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
@@ -798,6 +799,8 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, const
TCGArg *args,
}
tcg_out_i(s, *args++);
break;
+case INDEX_op_mb:
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
diff --git a/tci.c b/tci.c
index 7cbb39e..d35b24f 100644
--- a/tci.c
+++ b/tci.c
@@ -1230,6 +1230,9 @@ uintptr_t tcg_qemu_tb_exec(CPUArchState *env, uint8_t
*tb_ptr)
tcg_abort();
}
break;
+case INDEX_op_mb:
+smp_mb();
+break;
default:
TODO();
break;
--
2.8.3
[Qemu-devel] [RFC v2 PATCH 03/13] tcg/aarch64: Add support for fence
Cc: Claudio Fontana
Signed-off-by: Richard Henderson
Signed-off-by: Pranith Kumar
---
tcg/aarch64/tcg-target.inc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tcg/aarch64/tcg-target.inc.c b/tcg/aarch64/tcg-target.inc.c
index 08efdf4..c361a5c 100644
--- a/tcg/aarch64/tcg-target.inc.c
+++ b/tcg/aarch64/tcg-target.inc.c
@@ -360,6 +360,9 @@ typedef enum {
I3510_EOR = 0x4a00,
I3510_EON = 0x4a20,
I3510_ANDS = 0x6a00,
+
+/* System instructions. */
+DMB_ISH = 0xd5033bbf,
} AArch64Insn;
static inline uint32_t tcg_in32(TCGContext *s)
@@ -1625,6 +1628,9 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_insn(s, 3508, SMULH, TCG_TYPE_I64, a0, a1, a2);
break;
+case INDEX_op_mb:
+tcg_out32(s, DMB_ISH);
+break;
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
case INDEX_op_mov_i64:
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
@@ -1749,6 +1755,7 @@ static const TCGTargetOpDef aarch64_op_defs[] = {
{ INDEX_op_muluh_i64, { "r", "r", "r" } },
{ INDEX_op_mulsh_i64, { "r", "r", "r" } },
+{ INDEX_op_mb, { "r" } },
{ -1 },
};
--
2.8.3
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
Hi Richard, Thanks for the review. I will make the changes you pointed out. One point below: On Tue, May 31, 2016 at 4:24 PM, Richard Henderson wrote: > On 05/31/2016 11:39 AM, Pranith Kumar wrote: >> +/* TCGOpmb args */ >> +#define TCG_MB_FULL ((TCGArg)(0)) >> +#define TCG_MB_READ ((TCGArg)(1)) >> +#define TCG_MB_WRITE((TCGArg)(2)) >> +#define TCG_MB_ACQUIRE ((TCGArg)(3)) >> +#define TCG_MB_RELEASE ((TCGArg)(4)) > > > This is, IMO, confused. Either we should use the C++11 barrier types, or > the Linux barrier types, but not both. This part of the design is still being fleshed out. The above listing is all the kinds of barriers we can encounter during translation. May be I am missing something, but C++11 and Linux barrier types have higher level semantics which is difficult to infer at the instruction level. All we want to do here is map a barrier instruction from guest to a barrier instruction on hist. This mapping is 1:1 if the host has barrier instructions with matching semantics. Otherwise we generate a multi-op instruction sequence. Some examples are: load acquire(ldar) on ARM64 guest will map to dmb+load on ARMv7 target, store fence(sfence) on x86 guest will map to dmb on ARMv7 target. So we need to support all kinds of barrier types we expect the guest to have, then map them to the host. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 02/13] tcg/i386: Add support for fence
On Tue, May 31, 2016 at 4:27 PM, Richard Henderson wrote:
> On 05/31/2016 11:39 AM, Pranith Kumar wrote:
>>
>> +case INDEX_op_mb:
>> +tcg_out_mb(s);
>
>
> You need to look at the barrier type and DTRT. In particular, the Linux
> smp_rmb and smp_wmb types need not emit any code.
These are converted to 'lfence' and 'sfence' instructions. Based on
the target backend, I think we still need to emit barrier
instructions. For example, if target backend is ARMv7 we need to emit
'dmb' instruction for both x86 fence instructions. I am not sure why
they do not emit any code?
>
>> +{ INDEX_op_mb, { "r" } },
>
>
> You certainly do *not* need the constant argument loaded into a register.
> This should remain { }.
>
OK, I will fix this.
Thanks,
--
Pranith
Re: [Qemu-devel] [RFC v2 PATCH 02/13] tcg/i386: Add support for fence
On Wed, Jun 1, 2016 at 5:17 PM, Richard Henderson wrote: > > Because x86 has a strong memory model. > > It does not require barriers to keep normal loads and stores in order. The > primary reason for the *fence instructions is to order the "non-temporal" > memory operations that are part of the SSE instruction set, which we're not > using at all. > > This is why you'll find > > /* > * Because of the strongly ordered storage model, wmb() and rmb() are nops > * here (a compiler barrier only). QEMU doesn't do accesses to > write-combining > * qemu memory or non-temporal load/stores from C code. > */ > #define smp_wmb() barrier() > #define smp_rmb() barrier() > > for x86 and s390. OK. For x86 target, that is true. I think I got the context confused. On x86 target, we can elide the read and write barriers. But we still need to generate 'mfence' to prevent store-after-load reordering. I will refine this in the next version. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
Sergey Fedorov writes:
> On 31/05/16 21:39, Pranith Kumar wrote:
>> diff --git a/tcg/README b/tcg/README
>> index f4a8ac1..cfe79d7 100644
>> --- a/tcg/README
>> +++ b/tcg/README
>> @@ -402,6 +402,23 @@ double-word product T0. The later is returned in two
>> single-word outputs.
>>
>> Similar to mulu2, except the two inputs T1 and T2 are signed.
>>
>> +* Memory Barrier support
>> +
>> +* mb <$arg>
>> +
>> +Generate a target memory barrier instruction to ensure memory ordering as
>> being
>> +enforced by a corresponding guest memory barrier instruction. The ordering
>> +enforced by the backend may be stricter than the ordering required by the
>> guest.
>> +It cannot be weaker. This opcode takes an optional constant argument if
>> required
>> +to generate the appropriate barrier instruction. The backend should take
>> care to
>> +emit the target barrier instruction only when necessary i.e., for SMP
>> guests and
>> +when MTTCG is enabled.
>> +
>> +The guest translators should generate this opcode for all guest instructions
>> +which have ordering side effects.
>
> I think we need to extend TCG load/store instruction attributes to
> provide information about guest ordering requirements and leave this TCG
> operation only for explicit barrier instruction translation.
>
Yes, I am working on adding flag argument to the TCG MemOp which indicates
this.
>> +
>> +Please see docs/atomics.txt for more information on memory barriers.
>> +
>> * 64-bit guest on 32-bit host support
>>
>> The following opcodes are internal to TCG. Thus they are to be implemented
>> by
>> diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
>> index f554b86..a6f01a7 100644
>> --- a/tcg/tcg-op.c
>> +++ b/tcg/tcg-op.c
>> @@ -143,6 +143,12 @@ void tcg_gen_op6(TCGContext *ctx, TCGOpcode opc, TCGArg
>> a1, TCGArg a2,
>> tcg_emit_op(ctx, opc, pi);
>> }
>>
>> +void tcg_gen_mb(TCGArg a)
>> +{
>> +/* ??? Enable only when MTTCG is enabled. */
>> +tcg_gen_op1(&tcg_ctx, INDEX_op_mb, 0);
>
> Yes, this could be a right place to check for MTTCG enabled and number
> of CPUs emulated. If we do it here, then we should adjust the
> documentation stating that the backend should take care of it.
>
I added the check in Patch 13. I will update the documentation to reflect this.
Thanks,
--
Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Thu, Jun 2, 2016 at 9:08 PM, Richard Henderson wrote: > On 06/02/2016 02:37 PM, Sergey Fedorov wrote: >> >> >> It would give us three TCG operations for each memory operation instead >> of one. But then we might like to combine these barrier operations back >> with memory operations in each backend. If we propagate memory ordering >> semantics up to the backend, it can decide itself what instructions are >> best to generate. > > > A strongly ordered target would generally only set BEFORE bits or AFTER > bits, but not both (and I suggest we canonicalize on AFTER for all such > targets). Thus a strongly ordered target would produce only 2 opcodes per > memory op. > > I supplied both to make it easier to handle a weakly ordered target with > acquire/release bits. > > I would *not* combine the barrier operations back with memory operations in > the backend. Only armv8 and ia64 can do that, and given the optimization > level at which we generate code, I doubt it would really make much > difference above separate barriers. > On armv8, using load_acquire/store_release instructions makes a significant difference in performance when compared to plain dmb+memory instruction sequence. So I would really like to keep the option of generating acq/rel instructions(by combining barrier and memory or some other way) open. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote: > > Hum. That does seem helpful-ish. But I'm not certain how helpful it is to > complicate the helper functions even further. > > What if we have tcg_canonicalize_memop (or some such) split off the barriers > into separate opcodes. E.g. > > MO_BAR_LD_B = 32// prevent earlier loads from crossing current op > MO_BAR_ST_B = 64// prevent earlier stores from crossing current op > MO_BAR_LD_A = 128 // prevent later loads from crossing current op > MO_BAR_ST_A = 256 // prevent later stores from crossing current op > MO_BAR_LDST_B = MO_BAR_LD_B | MO_BAR_ST_B > MO_BAR_LDST_A = MO_BAR_LD_A | MO_BAR_ST_A > MO_BAR_MASK = MO_BAR_LDST_B | MO_BAR_LDST_A > > // Match Sparc MEMBAR as the most flexible host. > TCG_BAR_LD_LD = 1 // #LoadLoad barrier > TCG_BAR_ST_LD = 2 // #StoreLoad barrier > TCG_BAR_LD_ST = 4 // #LoadStore barrier > TCG_BAR_ST_ST = 8 // #StoreStore barrier > TCG_BAR_SYNC = 64 // SEQ_CST barrier I really like this format. I would also like to add to the frontend: MO_BAR_ACQUIRE MO_BAR_RELEASE and the following to the backend: TCG_BAR_ACQUIRE TCG_BAR_RELEASE since these are one-way barriers and the previous barrier types do not cover them. > > where > > tcg_gen_qemu_ld_i32(x, y, i, m | MO_BAR_LD_BEFORE | MO_BAR_ST_AFTER) > > emits > > mbTCG_BAR_LD_LD > qemu_ld_i32 x, y, i, m > mbTCG_BAR_LD_ST > > We can then add an optimization pass which folds barriers with no memory > operations in between, so that duplicates are eliminated. > Yes, folding/eliding these barriers in an optimization pass sounds like a good idea. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v3 00/19] Base enabling patches for MTTCG
Hi Alex, On Fri, Jun 3, 2016 at 4:40 PM, Alex Bennée wrote: > This is the third iteration of the RFC patch set which aims to provide > the basic framework for MTTCG. There have been some considerable > changes since the last extensive review (thanks to all the reviewers). > >- many updates to docs/multi-thread-tcg.txt design document >- added assertions for all the locking requirements >- split apart the big enable thread-per-vCPU patch >- removed locking from the hot-path > > In general the main thread functions are a lot less messy (especially > the single thread variant). The splitting apart of the big enabling > patch was helped by removing tcg_current_cpu and the global > exit_request as separate patches. Finally the big performance boost of > a lockless hot-path is made possible by Emilio's QHT work which this > is based on. > > The branch can be found at: > > https://github.com/stsquad/qemu/tree/mttcg/base-patches-v3 FYI, I tried booting a debian armv7 image with this branch and it doesn't boot. I'll try to see why it is failing. Thanks, -- Pranith.
Re: [Qemu-devel] [RFC v2 PATCH 11/13] target-arm: Generate fences in ARMv7 frontend
On Thu, Jun 2, 2016 at 3:37 PM, Sergey Fedorov wrote: > On 31/05/16 21:39, Pranith Kumar wrote: >> Signed-off-by: Pranith Kumar >> Signed-off-by: Richard Henderson >> --- >> target-arm/translate.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/target-arm/translate.c b/target-arm/translate.c >> index c946c0e..e1b16c0 100644 >> --- a/target-arm/translate.c >> +++ b/target-arm/translate.c >> @@ -7980,9 +7980,11 @@ static void disas_arm_insn(DisasContext *s, unsigned >> int insn) >> gen_clrex(s); >> return; >> case 4: /* dsb */ >> +ARCH(7); > > ARMv7 ARM says: "A DSB behaves as a DMB with the same arguments, and > also has the additional properties...". > OK. I was just focusing on dmb for now. I will add translation for all other barriers too in the next version. Thanks! -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov wrote: > On 06/06/16 18:47, Pranith Kumar wrote: >> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov wrote: >>> On 03/06/16 21:27, Pranith Kumar wrote: >>>> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote: >>>>> What if we have tcg_canonicalize_memop (or some such) split off the >>>>> barriers >>>>> into separate opcodes. E.g. >>>>> >>>>> MO_BAR_LD_B = 32// prevent earlier loads from crossing current op >>>>> MO_BAR_ST_B = 64// prevent earlier stores from crossing current op >>>>> MO_BAR_LD_A = 128 // prevent later loads from crossing current op >>>>> MO_BAR_ST_A = 256 // prevent later stores from crossing current op >>>>> MO_BAR_LDST_B = MO_BAR_LD_B | MO_BAR_ST_B >>>>> MO_BAR_LDST_A = MO_BAR_LD_A | MO_BAR_ST_A >>>>> MO_BAR_MASK = MO_BAR_LDST_B | MO_BAR_LDST_A >>>>> >>>>> // Match Sparc MEMBAR as the most flexible host. >>>>> TCG_BAR_LD_LD = 1 // #LoadLoad barrier >>>>> TCG_BAR_ST_LD = 2 // #StoreLoad barrier >>>>> TCG_BAR_LD_ST = 4 // #LoadStore barrier >>>>> TCG_BAR_ST_ST = 8 // #StoreStore barrier >>>>> TCG_BAR_SYNC = 64 // SEQ_CST barrier >>>> I really like this format. I would also like to add to the frontend: >>>> >>> Actually, the acquire barrier is a combined load-load + load-store >>> barrier; and the release barrier is a combo of load-store + store-store >>> barriers. >>> >> All the above are two-way barriers. Acquire/Release are one-way >> barriers. So we cannot combine the above to get acquire/release >> semantics without being conservative. > > Do you mean *barriers* or *memory access* operations implying memory > ordering? I meant the latter. I know no arch which has acquire/release barriers. Sorry for the confusion. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov wrote: > On 03/06/16 21:27, Pranith Kumar wrote: >> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote: >>> >>> What if we have tcg_canonicalize_memop (or some such) split off the barriers >>> into separate opcodes. E.g. >>> >>> MO_BAR_LD_B = 32// prevent earlier loads from crossing current op >>> MO_BAR_ST_B = 64// prevent earlier stores from crossing current op >>> MO_BAR_LD_A = 128 // prevent later loads from crossing current op >>> MO_BAR_ST_A = 256 // prevent later stores from crossing current op >>> MO_BAR_LDST_B = MO_BAR_LD_B | MO_BAR_ST_B >>> MO_BAR_LDST_A = MO_BAR_LD_A | MO_BAR_ST_A >>> MO_BAR_MASK = MO_BAR_LDST_B | MO_BAR_LDST_A >>> >>> // Match Sparc MEMBAR as the most flexible host. >>> TCG_BAR_LD_LD = 1 // #LoadLoad barrier >>> TCG_BAR_ST_LD = 2 // #StoreLoad barrier >>> TCG_BAR_LD_ST = 4 // #LoadStore barrier >>> TCG_BAR_ST_ST = 8 // #StoreStore barrier >>> TCG_BAR_SYNC = 64 // SEQ_CST barrier >> I really like this format. I would also like to add to the frontend: >> > > Actually, the acquire barrier is a combined load-load + load-store > barrier; and the release barrier is a combo of load-store + store-store > barriers. > All the above are two-way barriers. Acquire/Release are one-way barriers. So we cannot combine the above to get acquire/release semantics without being conservative. Thanks, -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Mon, Jun 6, 2016 at 12:14 PM, Sergey Fedorov wrote: > On 06/06/16 18:58, Pranith Kumar wrote: >> On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov wrote: >>> On 06/06/16 18:47, Pranith Kumar wrote: >>>> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov >>>> wrote: >>>>> On 03/06/16 21:27, Pranith Kumar wrote: >>>>>> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson >>>>>> wrote: >>>>>>> What if we have tcg_canonicalize_memop (or some such) split off the >>>>>>> barriers >>>>>>> into separate opcodes. E.g. >>>>>>> >>>>>>> MO_BAR_LD_B = 32// prevent earlier loads from crossing current >>>>>>> op >>>>>>> MO_BAR_ST_B = 64// prevent earlier stores from crossing current >>>>>>> op >>>>>>> MO_BAR_LD_A = 128 // prevent later loads from crossing current op >>>>>>> MO_BAR_ST_A = 256 // prevent later stores from crossing current op >>>>>>> MO_BAR_LDST_B = MO_BAR_LD_B | MO_BAR_ST_B >>>>>>> MO_BAR_LDST_A = MO_BAR_LD_A | MO_BAR_ST_A >>>>>>> MO_BAR_MASK = MO_BAR_LDST_B | MO_BAR_LDST_A >>>>>>> >>>>>>> // Match Sparc MEMBAR as the most flexible host. >>>>>>> TCG_BAR_LD_LD = 1 // #LoadLoad barrier >>>>>>> TCG_BAR_ST_LD = 2 // #StoreLoad barrier >>>>>>> TCG_BAR_LD_ST = 4 // #LoadStore barrier >>>>>>> TCG_BAR_ST_ST = 8 // #StoreStore barrier >>>>>>> TCG_BAR_SYNC = 64 // SEQ_CST barrier >>>>>> I really like this format. I would also like to add to the frontend: >>>>>> >>>>> Actually, the acquire barrier is a combined load-load + load-store >>>>> barrier; and the release barrier is a combo of load-store + store-store >>>>> barriers. >>>>> >>>> All the above are two-way barriers. Acquire/Release are one-way >>>> barriers. So we cannot combine the above to get acquire/release >>>> semantics without being conservative. >>> Do you mean *barriers* or *memory access* operations implying memory >>> ordering? >> I meant the latter. I know no arch which has acquire/release barriers. >> Sorry for the confusion. > > So I am. By the way, what's the difference between sequential consistent > *barrier* and a combination of all the other barriers? If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the other four barriers. I am not sure if we can just construct SYNC like this or if we need to define it explicitly though. -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier
On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson wrote: > On 06/06/2016 10:11 AM, Pranith Kumar wrote: >> >> If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the >> other four barriers. I am not sure if we can just construct SYNC like >> this or if we need to define it explicitly though. > > > AFAICS, sparc membar #sync is stronger. I tried looking it up but it's not clear. How is it stronger? And do we need those strong guarantees in our front-end/back-end? Thanks, -- Pranith
[Qemu-devel] Introduces a regression (was: target-arm: Avoid unnecessary TLB flush on TCR_EL2, TCR_EL3 writes)
Hi Peter,
On Tue, May 10, 2016 at 6:11 AM, Peter Maydell wrote:
> The TCR_EL2 and TCR_EL3 regdefs wer incorrectly using the
> vmsa_tcr_el1_write function for writes. Since these registers don't
> have the A1 bit that TCR_EL1 does, we don't need to do a tlb_flush()
> when they are written. Remove the unnecessary .writefn and also the
> harmless but unneeded .raw_writefn and .resetfn definitions.
>
> Signed-off-by: Peter Maydell
This commit is causing a regression where a vexpress-a9 guest refuses
to boot. The guest boots fine with this commit reverted.
Here is the log:
$ qemu-system-arm -M vexpress-a9 -m 1024M -kernel
after-copy/vmlinuz-3.2.0-4-vexpress -initrd
after-copy/initrd.img-3.2.0-4-vexpress -sd armdisk.img -append
"root=/dev/mmcblk0p2 console=tty0" -smp 4 -redir tcp:::22 -d
int,in_asm
qemu-system-arm: -redir tcp:::22: The -redir option is deprecated.
Please use '-netdev user,hostfwd=...' instead.
WARNING: Image format was not specified for 'armdisk.img' and probing
guessed raw.
Automatically detecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
audio: Could not init `oss' audio driver
IN:
0x6000: e3a0 movr0, #0; 0x0
0x6004: e59f1004 ldrr1, [pc, #4]; 0x6010
0x6008: e59f2004 ldrr2, [pc, #4]; 0x6014
0x600c: e59ff004 ldrpc, [pc, #4]; 0x6018
IN:
0x6001: e1a0 nop(mov r0,r0)
0x60010004: e1a0 nop(mov r0,r0)
0x60010008: e1a0 nop(mov r0,r0)
0x6001000c: e1a0 nop(mov r0,r0)
0x60010010: e1a0 nop(mov r0,r0)
0x60010014: e1a0 nop(mov r0,r0)
0x60010018: e1a0 nop(mov r0,r0)
0x6001001c: e1a0 nop(mov r0,r0)
0x60010020: ea02 b0x60010030
IN:
0x60010030: e1a07001 movr7, r1
0x60010034: e1a08002 movr8, r2
0x60010038: e10f2000 mrsr2, CPSR
0x6001003c: e3120003 tstr2, #3; 0x3
0x60010040: 1a01 bne0x6001004c
IN:
0x6001004c: e10f2000 mrsr2, CPSR
0x60010050: e38220c0 orrr2, r2, #192; 0xc0
0x60010054: e121f002 msrCPSR_c, r2
IN:
0x60010058: andeqr0, r0, r0
0x6001005c: andeqr0, r0, r0
0x60010060: e59f4784 ldrr4, [pc, #1924]; 0x600107ec
0x60010064: eb55 bl0x600101c0
IN:
0x600101c0: e3a03008 movr3, #8; 0x8
0x600101c4: ea80 b0x600103cc
IN:
0x600103cc: e28fc01c addip, pc, #28; 0x1c
0x600103d0: ee109f10 mrc15, 0, r9, cr0, cr0, {0}
0x600103d4: e59c1000 ldrr1, [ip]
0x600103d8: e59c2004 ldrr2, [ip, #4]
0x600103dc: e0211009 eorr1, r1, r9
0x600103e0: e1110002 tstr1, r2
0x600103e4: 008cf003 addeqpc, ip, r3
IN:
0x600103e8: e28cc014 addip, ip, #20; 0x14
0x600103ec: eaf8 b0x600103d4
IN:
0x600103d4: e59c1000 ldrr1, [ip]
0x600103d8: e59c2004 ldrr2, [ip, #4]
0x600103dc: e0211009 eorr1, r1, r9
0x600103e0: e1110002 tstr1, r2
0x600103e4: 008cf003 addeqpc, ip, r3
IN:
0x60010560: ea65 b0x600102fc
IN:
0x600102fc: e1a0c00e movip, lr
0x60010300: ee10bf91 mrc15, 0, fp, cr0, cr1, {4}
0x60010304: e31b000f tstfp, #15; 0xf
0x60010308: 1bd3 blne0x6001025c
IN:
0x6001025c: e2443901 subr3, r4, #16384; 0x4000
0x60010260: e3c330ff bicr3, r3, #255; 0xff
0x60010264: e3c33c3f bicr3, r3, #16128; 0x3f00
0x60010268: e1a3 movr0, r3
0x6001026c: e1a09920 lsrr9, r0, #18
0x60010270: e1a09909 lslr9, r9, #18
0x60010274: e289a201 addsl, r9, #268435456; 0x1000
0x60010278: e3a01012 movr1, #18; 0x12
0x6001027c: e3811b03 orrr1, r1, #3072; 0xc00
0x60010280: e2832901 addr2, r3, #16384; 0x4000
0x60010284: e1510009 cmpr1, r9
0x60010288: 2381100c orrcsr1, r1, #12; 0xc
0x6001028c: e151000a cmpr1, sl
0x60010290: 23c1100c biccsr1, r1, #12; 0xc
0x60010294: e4801004 strr1, [r0], #4
0x60010298: e2811601 addr1, r1, #1048576; 0x10
0x6001029c: e132 teqr0, r2
0x600102a0: 1af7 bne0x60010284
IN:
0x60010284: e1510009 cmpr1, r9
0x60010288: 2381100c orrcsr1, r1, #12; 0xc
0x6001028c: e151000a cmpr1, sl
0x60010290: 23c1100c biccsr1, r1, #12; 0xc
0x60010294: e4801004 strr1, [r0], #
[Qemu-devel] [PATCH] alpha: Fix build error for linux-user
Using gcc 6.1 for alpha-linux-user target we see the following build error: /mnt/devops/code/qemu/target-alpha/translate.c: In function ‘in_superpage’: /mnt/devops/code/qemu/target-alpha/translate.c:454:52: error: self-comparison always evaluates to true [-Werror=tautological-compare] && addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63); Fix it by replacing (addr >> 63) by '1' which is what it evaluates to since addr is negative. Signed-off-by: Pranith Kumar --- target-alpha/translate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target-alpha/translate.c b/target-alpha/translate.c index f9b2426..31da6ea 100644 --- a/target-alpha/translate.c +++ b/target-alpha/translate.c @@ -451,7 +451,7 @@ static bool in_superpage(DisasContext *ctx, int64_t addr) return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0 && addr < 0 && ((addr >> 41) & 3) == 2 -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63); +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1); } static bool use_goto_tb(DisasContext *ctx, uint64_t dest) -- 2.9.0
Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user
On Thu, Jun 16, 2016 at 3:07 PM, Richard Henderson wrote: > On 06/16/2016 11:56 AM, Pranith Kumar wrote: >> Using gcc 6.1 for alpha-linux-user target we see the following build >> error: >> >> /mnt/devops/code/qemu/target-alpha/translate.c: In function ‘in_superpage’: >> /mnt/devops/code/qemu/target-alpha/translate.c:454:52: error: >> self-comparison always evaluates to true [-Werror=tautological-compare] >> && addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63); >> >> Fix it by replacing (addr >> 63) by '1' which is what it evaluates to >> since addr is negative. >> >> Signed-off-by: Pranith Kumar >> --- >> target-alpha/translate.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/target-alpha/translate.c b/target-alpha/translate.c >> index f9b2426..31da6ea 100644 >> --- a/target-alpha/translate.c >> +++ b/target-alpha/translate.c >> @@ -451,7 +451,7 @@ static bool in_superpage(DisasContext *ctx, int64_t addr) >> return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0 >> && addr < 0 >> && ((addr >> 41) & 3) == 2 >> -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63); >> +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1); >> } > > This fix is incorrect. > > (1) addr is not always negative. > (2) in_superpage is only relevant for alpha-softmmu, where > TARGET_VIRT_ADDR_SPACE_BITS is not 63. If you see line 2 of the condition you check for (addr < 0). Only if this evaluates to true do you check the right shift value of addr. Reg. (2), I think that is what gcc is erroring out for. TARGET_VIRT_ADDR_SPACE_BITS is 63 for linux-user and we are comparing (addr >> 63) with itself. GCC rightly says that it is a tautological compare and errors out. May be we can have a better work around. Thanks! -- Pranith
Re: [Qemu-devel] [RFC v2 PATCH 03/13] tcg/aarch64: Add support for fence
Hi Richard,
On Tue, May 31, 2016 at 4:34 PM, Richard Henderson wrote:
> On 05/31/2016 11:39 AM, Pranith Kumar wrote:
>>
>> +/* System instructions. */
>> +DMB_ISH = 0xd5033bbf,
>
> ...
>>
>> +case INDEX_op_mb:
>> +tcg_out32(s, DMB_ISH);
>> +break;
>
>
> With the flags argument, this needs to be split.
>
> DMB_ISH = 0xd5033b8f
I just checked this. Shouldn't this be as follows:
DMB_ISH = 0xd50338bf
DMB_RD = 0x0100
DMB_WR = 0x0200
The logic seems to be ok.
Thanks!
> DMB_RD = 0x0010
> DMB_WR = 0x0020
>
> if (a0 == TCG_MB_READ) {
> a0 = DMB_RD;
> } else if (a0 == TCG_MB_WRITE) {
> a0 = DMB_WR;
> } else {
> a0 = DMB_RD | DMB_WR;
> }
> tcg_out32(s, DMB_ISH | a0);
>
>
>
> r~
--
Pranith
Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user
On Thu, Jun 16, 2016 at 8:43 PM, Laurent Vivier wrote:
>
>
> Le 16/06/2016 à 21:15, Pranith Kumar a écrit :
>> On Thu, Jun 16, 2016 at 3:07 PM, Richard Henderson wrote:
>>> On 06/16/2016 11:56 AM, Pranith Kumar wrote:
>>>> Using gcc 6.1 for alpha-linux-user target we see the following build
>>>> error:
>>>>
>>>> /mnt/devops/code/qemu/target-alpha/translate.c: In function ‘in_superpage’:
>>>> /mnt/devops/code/qemu/target-alpha/translate.c:454:52: error:
>>>> self-comparison always evaluates to true [-Werror=tautological-compare]
>>>> && addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
>>>>
>>>> Fix it by replacing (addr >> 63) by '1' which is what it evaluates to
>>>> since addr is negative.
>>>>
>>>> Signed-off-by: Pranith Kumar
>>>> ---
>>>> target-alpha/translate.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/target-alpha/translate.c b/target-alpha/translate.c
>>>> index f9b2426..31da6ea 100644
>>>> --- a/target-alpha/translate.c
>>>> +++ b/target-alpha/translate.c
>>>> @@ -451,7 +451,7 @@ static bool in_superpage(DisasContext *ctx, int64_t
>>>> addr)
>>>> return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0
>>>> && addr < 0
>>>> && ((addr >> 41) & 3) == 2
>>>> -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
>>>> +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);
>>>> }
>>>
>>> This fix is incorrect.
>>>
>>> (1) addr is not always negative.
>>> (2) in_superpage is only relevant for alpha-softmmu, where
>>> TARGET_VIRT_ADDR_SPACE_BITS is not 63.
>>
>> If you see line 2 of the condition you check for (addr < 0). Only if
>> this evaluates to true do you check the right shift value of addr.
>>
>> Reg. (2), I think that is what gcc is erroring out for.
>> TARGET_VIRT_ADDR_SPACE_BITS is 63 for linux-user and we are comparing
>> (addr >> 63) with itself. GCC rightly says that it is a tautological
>> compare and errors out. May be we can have a better work around.
>
> Perhaps something like:
>
> #ifndef CONFIG_USER_ONLY
> static bool in_superpage(DisasContext *ctx, int64_t addr)
> {
> ...
> }
> #endif
> ...
>
> #ifdef CONFIG_USER_ONLY
> pc_mask = ~TARGET_PAGE_MASK;
> #else
> if (in_superpage(&ctx, pc_start)) {
> pc_mask = (1ULL << 41) - 1;
> } else {
>pc_mask = ~TARGET_PAGE_MASK;
> }
> #endif
>
OK, I will use this.
Thanks!
--
Pranith
