diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1658 | 75 | ||||
| -rw-r--r-- | results/classifier/108/other/1658120 | 225 | ||||
| -rw-r--r-- | results/classifier/108/other/1658141 | 87 | ||||
| -rw-r--r-- | results/classifier/108/other/1658506 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/1658634 | 415 |
5 files changed, 835 insertions, 0 deletions
diff --git a/results/classifier/108/other/1658 b/results/classifier/108/other/1658 new file mode 100644 index 00000000..bdd28fb9 --- /dev/null +++ b/results/classifier/108/other/1658 @@ -0,0 +1,75 @@ +permissions: 0.753 +graphic: 0.736 +files: 0.732 +other: 0.731 +device: 0.728 +performance: 0.711 +network: 0.709 +vnc: 0.709 +semantic: 0.705 +debug: 0.685 +boot: 0.678 +PID: 0.657 +socket: 0.640 +KVM: 0.542 + +Zephyr TF-M IPC example triggers failed assertion !arm_feature(env, ARM_FEATURE_M) on recent Qemu +Description of problem: +I can't run the TrustedFirmware-M IPC example in the Zephyr repo with recent Qemu (in particular v8.0.0). + +By bisecting, I got the last commit OK : v7.2.0-351-gfaa1451e7b + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +The version of the PSA Framework API is 257. +The PSA Crypto service minor version is 1. +Generating 256 bytes of random data: +71 03 DD 50 8E E5 00 C7 E0 61 7B EB 77 15 E9 38 +E9 A8 7D 0C 51 23 76 9F C3 61 E9 8B 8A 67 BD 14 +73 A3 2C 6E E5 8C E3 19 53 6B 50 55 A8 A7 F4 7B +56 03 60 AA 48 B6 DF 04 33 56 BE 84 43 FA 4E AC +D7 6E 2E 2E 1D 7E 46 69 D5 9B B0 42 5C 54 E4 09 +73 9E 4F 55 F8 3E 05 9E A3 DE 46 D3 E4 02 B0 9C +F3 21 9F 20 85 74 34 07 19 79 07 B8 02 B5 0E 90 +74 21 BE B5 09 4C D7 20 D8 43 F7 72 23 1C F0 3E +77 7B D3 70 29 72 69 D3 7F 1F 61 16 12 73 D5 89 +C5 8B D1 A3 7B 4B FD F5 11 C2 B1 9A C0 A5 F9 7B +16 3D 98 17 66 FE E9 F4 FE 37 76 62 E0 E6 83 99 +69 26 41 CD FF 0C 44 AC F9 F4 91 B8 CA 63 5E 1D +B9 C4 38 D6 0C 11 19 1B 94 BE C9 4F EC 2E 5A 05 +3F 72 5F 41 44 3C 91 39 AC 2D 50 75 DF FD D3 11 +39 F2 43 18 D7 69 B0 A3 99 0C C0 6E 83 84 1A A8 +B0 37 6C 8E 32 B2 8E 4F AA 12 97 09 09 87 D3 FD +qemu-system-arm: terminating on signal 2 +``` + +But after 452c67a427, for example v8.0.0-918-g6972ef1440, I get : + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +Aborted +``` +Steps to reproduce: +1. Build the Zephyr tfm_merged.hex file from Zephyr 7ba5ecf451 https://github.com/zephyrproject-rtos/zephyr/commit/7ba5ecf451ef29f96b30dbe5f0e54c1865839093 : ``west -v build -p -b mps2_an521_ns ./samples/tfm_integration/tfm_ipc`` +2. Build qemu-system-arm and run : ``qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio`` +Additional information: +More info to build Zephyr TF-M IPC example on the official repo https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/tfm_integration/tfm_ipc diff --git a/results/classifier/108/other/1658120 b/results/classifier/108/other/1658120 new file mode 100644 index 00000000..ffbe6791 --- /dev/null +++ b/results/classifier/108/other/1658120 @@ -0,0 +1,225 @@ +permissions: 0.856 +graphic: 0.838 +other: 0.825 +semantic: 0.823 +performance: 0.778 +device: 0.766 +PID: 0.757 +debug: 0.724 +boot: 0.719 +KVM: 0.711 +vnc: 0.679 +files: 0.678 +socket: 0.666 +network: 0.660 + +building with gcc-aarch64-linux-gnu + +Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross-compiler I'm getting the following : + + +In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, + from /root/qemu/util/compatfd.c:21: +/root/qemu/util/compatfd.c: In function 'qemu_signalfd': +/root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) + ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); + ^ +/root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +/root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +make: *** [util/compatfd.o] Error 1 + + +I had configured it with : + +../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +And I'm on : + +Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Thanks + +On 20 January 2017 at 15:21, Bilal Amarni <email address hidden> wrote: +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 + +You can see from the error message that the compile has +pulled in the include file /usr/include/x86_64-linux-gnu/sys/syscall.h +from the host, which is the x86-64 version. This is an +indication that either your cross compiler is broken, or +you're not using it at all. + +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +You haven't told configure to use a cross compiler at all, +so it is building with the x86 system compiler, which +doesn't work. You shouldn't need to use the --cpu argument +at all, because if you get the build to use the right +compiler it can figure that out itself. (Passing --cpu=aarch64 +tells configure "ignore the fact this is an x86 compiler +and assume it's aarch64 instead", which just results in +things breaking because that assumption is wrong.) + +You need to pass configure --cross-prefix=aarch64-linux-gnu- +You'll also need to ensure you have an aarch64-linux-gnu-pkg-config +and that you have cross versions of all QEMU's library +dependencies (notably zlib and glib) in the right place that +your cross-compiler can find them, and that your cross +pkg-config is set up to point to them. + +On Ubuntu, you may find it easier to set up a cross-architecture +chroot and do the build in that (where it looks like a native +build). Cross-compilation of software with non-trivial +dependencies is always an enormous pain in the neck. + +thanks +-- PMM + + + +Bilal Amarni <email address hidden> writes: + +> Public bug reported: +> +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 +> +> +> I had configured it with : +> +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 +> +> And I'm on : +> +> Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 +> 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Do you have: + +/usr/include/aarch64-linux-gnu/bits/syscall.h + +In your system? + +When cross compiling it is these sort of problems come from not having +the architecture specific development files. On Ubuntu you want +something like: + + apt-get build-dep -a arm64 qemu + +-- +Alex Bennée + + +Thanks for your replies, + +I've managed to compile it using a chroot as suggested by Peter. I just grabbed a pre-built rootfs from here : https://wiki.debian.org/Arm64Port#Pre-built_Rootfses, then installed qemu-user-static with apt-get and run the build from the chroot. + +Somehow "apt-get build-dep -a arm64 qemu" didn't work, I had tried to do "dpkg --add-architecture arm64 && apt-get update" before running this command but it couldn't find the needed packages, not sure why. + +In any case thanks for your help :) + +this was an issue in my setup + +Hello everyone!! + +I am having a issue when build qemu using gcc aarch64-linux-gnu-* on ubuntu 16.04: + +dong02@dong:~/qemu$ ./configure \ +> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +> --target-list=aarch64-softmmu \ +> --enable-attr --enable-fdt --enable-kvm \ +> --enable-sdl --enable-system --enable-tools \ +> --audio-drv-list= \ +> --disable-bluez --disable-brlapi --disable-bsd-user \ +> --disable-cap-ng --disable-curl --disable-curses \ +> --disable-docs --disable-libiscsi --disable-linux-aio \ +> --disable-rbd --disable-seccomp --disable-slirp \ +> --disable-sparse --disable-spice --disable-strip \ +> --disable-usb-redir --disable-vde --disable-virtfs \ +> --disable-vnc --disable-werror --disable-xen + +ERROR: zlib check failed + Make sure to have the zlib libs and headers installed. + +I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +Please help me!! + + +Hi Cao Van Dong, + +you need to install zlib1g-dev:arm64, see: + +https://github.com/qemu/qemu/blob/master/tests/docker/dockerfiles/debian-arm64-cross.docker + +Regards, + +Phil. + + +Cao Van Dong <email address hidden> writes: + +> Hello everyone!! +> +> I am having a issue when build qemu using gcc aarch64-linux-gnu-* on +> ubuntu 16.04: +> +> dong02@dong:~/qemu$ ./configure \ +>> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +>> --target-list=aarch64-softmmu \ +>> --enable-attr --enable-fdt --enable-kvm \ +>> --enable-sdl --enable-system --enable-tools \ +>> --audio-drv-list= \ +>> --disable-bluez --disable-brlapi --disable-bsd-user \ +>> --disable-cap-ng --disable-curl --disable-curses \ +>> --disable-docs --disable-libiscsi --disable-linux-aio \ +>> --disable-rbd --disable-seccomp --disable-slirp \ +>> --disable-sparse --disable-spice --disable-strip \ +>> --disable-usb-redir --disable-vde --disable-virtfs \ +>> --disable-vnc --disable-werror --disable-xen +> +> ERROR: zlib check failed +> Make sure to have the zlib libs and headers installed. +> +> I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +> Please help me!! + +You will have installed the x86 version of the zlib1g-dev libraries. +Unfortunately headers are not uniform across all architectures. + +If you want to ensure you have all the appropriate headers for cross +compiling QEMU do: + + apt-get build-dep -a arm64 qemu + +But you may well run into problems if the distribution isn't fully +multi-arch clean. This is one of the reasons we use docker to isolate +our various cross build environments: + + make docker-test-build@debian-arm64-cross J=9 TARGET_LIST=aarch64-softmmu + +-- +Alex Bennée + + diff --git a/results/classifier/108/other/1658141 b/results/classifier/108/other/1658141 new file mode 100644 index 00000000..8777f074 --- /dev/null +++ b/results/classifier/108/other/1658141 @@ -0,0 +1,87 @@ +other: 0.701 +semantic: 0.690 +device: 0.661 +KVM: 0.654 +permissions: 0.642 +boot: 0.617 +debug: 0.597 +graphic: 0.580 +PID: 0.558 +socket: 0.532 +performance: 0.520 +network: 0.495 +files: 0.477 +vnc: 0.358 + +QEMU's default msrs handling causes Windows 10 64 bit to crash + +Wine uses QEMU to run its conformance test suite on Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. + +One such test checks handling of exceptions down. When run on Windows 10 64 bit in QEMU it triggers a "KMOD_EXCEPTION_NOT_HANDLED" BSOD in the VM. See: +https://bugs.winehq.org/show_bug.cgi?id=40240 + + +To reproduce this bug: +* Pick a Windows 10 64 bit VM on an Intel host. + +* Start the VM. I'm pretty sure any qemu command will do but here's what I used: + qemu-system-x86_64 -machine pc-i440fx-2.1,accel=kvm -cpu core2duo,+nx -m 2048 -hda /var/lib/libvirt/images/wtbw1064.qcow2 + +* Grab the attached source code. The tar file is a bit big at 85KB because I had to include some Wine headers. However the source file proper, exception.c, is only 85 lines, including the LGPL header. + +* Compile the source code with MinGW by typing 'make'. This produces a 32 bit exception.exe executable. I'll attach it for good measure. + +* Put exception.exe on the VM and run it. + + +After investigation it turns out this happens: + * Only for Windows 10 64 bit guests. Windows 10 32 bit and older Windows versions are unaffected. + + * Only on Intel hosts. At least both my Xeon E3-1226 v3 and i7-4790K hosts are impacted but not my Opteron 6128 one. + + * It does not seem to depend on the emulated CPU type: on the Intel hosts this happened with both +core2duo,nx and 'copy the host configuration' and did not depend on the number of emulated cpus/cores. + + * This happened with both QEMU 2.1 and 2.7, and both the 3.16.0 and 4.8.11 Linux kernels, both on Debian 8.6 and Debian Testing. + + +After searching for quite some time I discovered that the kvm kernel module was sneaking the following messages into /var/log/syslog precisely when the BSOD happens: + +Dec 16 13:43:48 vm3 kernel: [ 191.624802] kvm [2064]: vcpu0, guest rIP: 0xfffff803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop +Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xfffff803cb3c0c5c unhandled rdmsr: 0x1c9 + +A search on the Internet turned up a post suggesting to change kvm's ignore_msrs setting: + + echo 1 >/sys/module/kvm/parameters/ignore_msrs + +https://www.reddit.com/r/VFIO/comments/42dj7n/some_games_crash_to_biosboot_on_launch/ + +This does actually work and provides a workaround at least. + + + + + +It appears this bug affects me too with very similar symptons, but this time, it's while launching the recently released game "Puyo Poyo Tetris" using Steam in the guest VM. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +This bug is still present. +However the "ignore_msrs=1" workaround does not work with QEmu 3.1 anymore. To prevent Windows 10 from crashing one must upgrade QEmu to 5.0.14. + + +The bug is still present so changing the status back to New. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/131 + + diff --git a/results/classifier/108/other/1658506 b/results/classifier/108/other/1658506 new file mode 100644 index 00000000..5247473a --- /dev/null +++ b/results/classifier/108/other/1658506 @@ -0,0 +1,33 @@ +device: 0.718 +network: 0.641 +vnc: 0.580 +files: 0.573 +graphic: 0.487 +socket: 0.471 +other: 0.383 +performance: 0.362 +semantic: 0.298 +boot: 0.293 +PID: 0.283 +KVM: 0.221 +permissions: 0.165 +debug: 0.164 + +qemu/hw/intc/arm_gicv3_cpuif.c:2433: bad expression ? + +qemu/hw/intc/arm_gicv3_cpuif.c:2433]: (style) Expression '(X & 0x2000000000000000) == 0x1' is always false. + +Source code is + + ((lr & ICH_LR_EL2_HW) == 1 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Maybe better code + + ((lr & ICH_LR_EL2_HW) != 0 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Thanks for this bug report -- I have sent a patch making the proposed change: http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg05030.html + + +Now fixed in git master, commit d87576e38df7. + + diff --git a/results/classifier/108/other/1658634 b/results/classifier/108/other/1658634 new file mode 100644 index 00000000..8e591c70 --- /dev/null +++ b/results/classifier/108/other/1658634 @@ -0,0 +1,415 @@ +graphic: 0.851 +network: 0.832 +other: 0.821 +debug: 0.818 +semantic: 0.805 +PID: 0.798 +permissions: 0.795 +device: 0.783 +performance: 0.770 +files: 0.756 +boot: 0.753 +socket: 0.746 +KVM: 0.734 +vnc: 0.669 + +Can't get correct display with latest QEMU and OVMF BIOS + +I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: +1. "-vga cirrus" + "-bios OVMF.fd": works +2. "-vga std" + non-UEFI bios: works + +The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. + +(1) What phase of the guest do you get invalid video output in? Do you see the TianoCore splash screen? Does the grub2 menu appear? + +(2) I cannot reproduce the issue (with a different guest OS anyway); I just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at 7cf59c854f35), with stdvga; this combo works fine. + +(3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF binary? + +(4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips instead. Libvirt (strongly recommended) will do this for you. + +Thanks. + +Splash screen and UEFI shell were displayed correctly. Grub2 menu and +Ubuntu login screen also appeared, however the display didn't seem right. I +got very blurry output. + +[image: Inline image 1] + +With QEMU 2.7.0 and the same OVMF.fd, everything works well. + +Please let me know if anything is not clear. + +Thanks, +Kai + +On Mon, Jan 23, 2017 at 4:50 AM, Laszlo Ersek (Red Hat) <email address hidden> +wrote: + +> (1) What phase of the guest do you get invalid video output in? Do you +> see the TianoCore splash screen? Does the grub2 menu appear? +> +> (2) I cannot reproduce the issue (with a different guest OS anyway); I +> just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at +> 7cf59c854f35), with stdvga; this combo works fine. +> +> (3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF +> binary? +> +> (4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips +> instead. Libvirt (strongly recommended) will do this for you. +> +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> Status in QEMU: +> New +> +> Bug description: +> I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and +> OVMF UEFI BIOS, however I can't get correct display output with default vga +> configuration (-vga std). However, qemu works with a couple of different +> configurations: +> 1. "-vga cirrus" + "-bios OVMF.fd": works +> 2. "-vga std" + non-UEFI bios: works +> +> The same error with QEMU 2.8.0 release. Everything works well on +> 2.7.0/1. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> + + +I downloaded "ubuntu-16.04.1-desktop-amd64.iso" (MD5: 17643c29e3c4609818f26becf76d29a3), and I can reproduce the issue -- the grub2 display is corrupt. (I didn't even look further than that.) I also confirm that it works fine with the same firmware, but using QEMU 2.7. + +Here's the result of the bisection: + +cd958edb1fae85d0c7d1e1acbff82d22724e8d64 is the first bad commit +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +If I revert this commit on top of current master -- it reverts cleanly -- then the grub2 screen displays fine again. + +For reference, this is my script: + +ISO=ubuntu-16.04.1-desktop-amd64.iso +CODE=OVMF_CODE.fd +TMPL=OVMF_VARS.fd + +cp $TMPL vars.fd + +qemu-system-x86_64 \ + -m 1024 \ + -M pc,accel=kvm \ + -device VGA \ + -drive if=pflash,readonly,format=raw,file=$CODE \ + -drive if=pflash,format=raw,file=vars.fd \ + -drive id=cdrom,if=none,readonly,format=raw,file=$ISO \ + -device virtio-scsi-pci,id=scsi0 \ + -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \ + -debugcon file:debug.log \ + -global isa-debugcon.iobase=0x402 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline,default \ + -serial chardev:char0 + + +Added Marc-André and Gerd to the CC list. + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Cc: Marc-André Lureau <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..67c65b7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Hi + +On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +wrote: + +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Cc: Marc-André Lureau <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..67c65b7 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +> int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +You are missing the 's->' ! + +with that, +Reviewed-by: Marc-André Lureau <email address hidden> + + +-- +> 1.8.3.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> +-- +Marc-André Lureau + + +> > - if (s->surface && +> > + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> > pixman_image_get_width(s->surface->image) == width && +> > pixman_image_get_height(s->surface->image) == height) { +> > return; +> > +> +> You are missing the 's->' ! + +Good catch. /me wonders why gcc didn't throw a warning on that one. + +Fixed. + +thanks, + Gerd + + + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..d573351 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +On 01/24/17 11:37, elmarco wrote: +> Hi +> +> On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +> wrote: +> +>> Only skip surface reallocation in case the old surface was created using +>> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +>> might end up with a DisplaySurface with the wrong backing storage. +>> +>> Cc: <email address hidden> +>> Cc: Marc-André Lureau <email address hidden> +>> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> --- +>> ui/console.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/ui/console.c b/ui/console.c +>> index b9575f2..67c65b7 100644 +>> --- a/ui/console.c +>> +++ b/ui/console.c +>> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +>> int height) +>> +>> assert(s->console_type == GRAPHIC_CONSOLE); +>> +>> - if (s->surface && +>> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +>> pixman_image_get_width(s->surface->image) == width && +>> pixman_image_get_height(s->surface->image) == height) { +>> return; +>> +> +> You are missing the 's->' ! +> +> with that, +> Reviewed-by: Marc-André Lureau <email address hidden> + +With that change: + +Tested-by: Laszlo Ersek <email address hidden> + +Also, + +Cc: <email address hidden> + +Thanks +Laszlo + + +> -- +>> 1.8.3.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1658634 +>> +>> Title: +>> Can't get correct display with latest QEMU and OVMF BIOS +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +>> + + + +On 01/24/17 12:10, Gerd Hoffmann wrote: +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> Reviewed-by: Marc-André Lureau <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..d573351 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +Tested-by: Laszlo Ersek <email address hidden> +Cc: <email address hidden> + +Thanks +Laszlo + + +It works well on my side with the patch. Thanks! + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Tested-by: Laszlo Ersek <email address hidden> +Message-id: <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index fe03a66..e353c85 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2116,7 +2116,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Fixed in commit 3ef0c573d37b ("console: fix console resize", 2017-01-31), released in v2.9.0. + + |