diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/105 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1050 | 87 | ||||
| -rw-r--r-- | results/classifier/108/other/1050694 | 99 | ||||
| -rw-r--r-- | results/classifier/108/other/1052 | 94 | ||||
| -rw-r--r-- | results/classifier/108/other/1052857 | 63 | ||||
| -rw-r--r-- | results/classifier/108/other/1054558 | 53 |
6 files changed, 412 insertions, 0 deletions
diff --git a/results/classifier/108/other/105 b/results/classifier/108/other/105 new file mode 100644 index 00000000..cd7cfc30 --- /dev/null +++ b/results/classifier/108/other/105 @@ -0,0 +1,16 @@ +performance: 0.879 +device: 0.874 +debug: 0.522 +graphic: 0.483 +network: 0.454 +other: 0.361 +PID: 0.323 +socket: 0.312 +permissions: 0.238 +vnc: 0.234 +semantic: 0.209 +boot: 0.186 +files: 0.132 +KVM: 0.011 + +Gdb hangs when trying to single-step after an invalid instruction diff --git a/results/classifier/108/other/1050 b/results/classifier/108/other/1050 new file mode 100644 index 00000000..4593e523 --- /dev/null +++ b/results/classifier/108/other/1050 @@ -0,0 +1,87 @@ +graphic: 0.857 +other: 0.843 +performance: 0.839 +device: 0.805 +debug: 0.787 +semantic: 0.770 +permissions: 0.767 +network: 0.736 +PID: 0.734 +KVM: 0.707 +files: 0.702 +socket: 0.701 +vnc: 0.669 +boot: 0.651 + +[BUG] heap-buffer-overflow in sifive_plic_create +Description of problem: +I run check-qtest-riscv64 in ubuntu20.04, and got a heap-buffer-overflow report with address sanitizer +HEAD: 7077fcb9b68f058809c9dd9fd1dacae1881e886c +Steps to reproduce: +run +`G_TEST_DBUS_DAEMON=/root/o/sources/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=58 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_BINARY=./qemu-system-riscv64 /root/o/sources/qemu/build/tests/qtest/test-hmp --tap -k` +Additional information: +I think is because on some conditions when after `j++(hw/intc/sifive_plic.c:458)`, it accesses `plic->addr_config[j](hw/intc/sifive_plic.c:463)` and results in heap-overflow. +I tried to modify `hw/intc/sifive_plic.c:463` to else-if, then the report gone. +Could you please have a check. +``` +==63425==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000031624 at pc 0x561afe157d54 bp 0x7ffcd8aef510 sp 0x7ffcd8aef500 +READ of size 4 at 0x602000031624 thread T0 + #0 0x561afe157d53 in sifive_plic_create ../hw/intc/sifive_plic.c:463 + #1 0x561afdc0ac7f in sifive_e_soc_realize ../hw/riscv/sifive_e.c:207 + #2 0x561afe6698fb in device_set_realized ../hw/core/qdev.c:531 + #3 0x561afe679b90 in property_set_bool ../qom/object.c:2273 + #4 0x561afe681c7f in object_property_set ../qom/object.c:1408 + #5 0x561afe68b763 in object_property_set_qobject ../qom/qom-qobject.c:28 + #6 0x561afe682535 in object_property_set_bool ../qom/object.c:1477 + #7 0x561afdc0a601 in sifive_e_machine_init ../hw/riscv/sifive_e.c:91 + #8 0x561afd34d608 in machine_run_board_init ../hw/core/machine.c:1427 + #9 0x561afda49697 in qemu_init_board ../softmmu/vl.c:2610 + #10 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2706 + #11 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2699 + #12 0x561afda504ee in qemu_init ../softmmu/vl.c:3737 + #13 0x561afd1cf4ae in qemu_main ../softmmu/main.c:35 + #14 0x561afd1cf4ae in main ../softmmu/main.c:45 + #15 0x7f9d13bf3082 in __libc_start_main ../csu/libc-start.c:308 + #16 0x561afd1de78d in _start (/root/o/sources/qemu/build/qemu-system-riscv64+0x271378d) + +0x602000031624 is located 8 bytes to the right of 12-byte region [0x602000031610,0x60200003161c) +allocated by thread T0 here: + #0 0x7f9d15026808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 + #1 0x7f9d14a84e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + +SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/intc/sifive_plic.c:463 in sifive_plic_create +Shadow bytes around the buggy address: + 0x0c047fffe270: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa + 0x0c047fffe280: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa 02 fa + 0x0c047fffe290: fa fa 00 01 fa fa fd fd fa fa fd fa fa fa fd fd + 0x0c047fffe2a0: fa fa 00 02 fa fa 00 02 fa fa 05 fa fa fa 07 fa + 0x0c047fffe2b0: fa fa 00 01 fa fa 07 fa fa fa 05 fa fa fa 07 fa +=>0x0c047fffe2c0: fa fa 00 04[fa]fa 04 fa fa fa 00 00 fa fa 00 00 + 0x0c047fffe2d0: fa fa 00 00 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2e0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2f0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe300: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fa + 0x0c047fffe310: fa fa fd fd fa fa 00 03 fa fa fd fd fa fa 00 03 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==63425==ABORTING +``` diff --git a/results/classifier/108/other/1050694 b/results/classifier/108/other/1050694 new file mode 100644 index 00000000..ea2c4ecd --- /dev/null +++ b/results/classifier/108/other/1050694 @@ -0,0 +1,99 @@ +debug: 0.884 +permissions: 0.870 +PID: 0.865 +performance: 0.864 +semantic: 0.864 +graphic: 0.863 +device: 0.857 +other: 0.854 +boot: 0.843 +socket: 0.843 +files: 0.836 +vnc: 0.833 +KVM: 0.818 +network: 0.807 + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. + + + +Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795 + +Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1052 b/results/classifier/108/other/1052 new file mode 100644 index 00000000..424684ff --- /dev/null +++ b/results/classifier/108/other/1052 @@ -0,0 +1,94 @@ +other: 0.898 +permissions: 0.891 +graphic: 0.888 +debug: 0.886 +performance: 0.881 +vnc: 0.874 +semantic: 0.863 +KVM: 0.862 +device: 0.854 +PID: 0.809 +socket: 0.785 +network: 0.773 +boot: 0.762 +files: 0.754 + +QEMU monitor hangs after "stop" QMP command called in postcopy-paused migration state +Description of problem: +QEMU monitor hangs when I try to pause virtual CPUs using "stop" QMP command +on the destination host once migration enters postcopy-paused (after it was +paused using "migrate-pause" QMP command on the source host). QEMU just does +not send any reply to the "stop" command. +Steps to reproduce: +1. start migration +2. wait for the first iteration to finish +3. switch to post-copy using "migrate-start-postcopy" +3. break migration with "migrate-pause" +4. send "stop" to the destination monitor +Additional information: +Unfortunately I haven't been able to get a stack trace as gdb just hangs when +I try to attach it to QEMU after step 4. I can see threads getting SIGUSR1 +after the "stop" command, but I cannot get to gdb prompt afterwards: + +``` +(gdb) c +Continuing. +[New Thread 0x7f41ec9be640 (LWP 1112)] +[New Thread 0x7f41d7fff640 (LWP 1113)] +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +``` + +I was able to attach strace to it though (in case it is at least a bit +useful). The first line corresponds to the final '}' of the +{"execute":"stop","id":"libvirt-413"} QMP comamnd: + +``` +[pid 72970] recvmsg(20, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="}", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1 +[pid 72970] write(4, "\1\0\0\0\0\0\0\0", 8) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=4, revents=POLLIN}], left {tv_sec=0, tv_nsec=513181335}) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] read(4, <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... read resumed>"\1\0\0\0\0\0\0\0", 512) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 0 (Timeout) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] write(8, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... write resumed>) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0}) +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], <unfinished ...> +[pid 72970] <... poll resumed>) = 1 ([{fd=19, revents=POLLIN}]) +[pid 72949] <... rt_sigprocmask resumed>[BUS USR1 ALRM IO], 8) = 0 +[pid 72970] read(19, <unfinished ...> +[pid 72949] getpid() = 72949 +[pid 72970] <... read resumed>"\5\0\0\0\0\0\0\0", 16) = 8 +[pid 72949] tgkill(72949, 72971, SIGUSR1 <unfinished ...> +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] <... tgkill resumed>) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], [BUS USR1 ALRM IO], 8) = 0 +[pid 72949] getpid() = 72949 +[pid 72949] tgkill(72949, 72972, SIGUSR1) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] futex(0x5606f6cb73a8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY +``` + +And that's it, the last futex never returns. diff --git a/results/classifier/108/other/1052857 b/results/classifier/108/other/1052857 new file mode 100644 index 00000000..6295692d --- /dev/null +++ b/results/classifier/108/other/1052857 @@ -0,0 +1,63 @@ +device: 0.801 +other: 0.794 +PID: 0.789 +permissions: 0.780 +socket: 0.765 +files: 0.753 +performance: 0.752 +debug: 0.742 +graphic: 0.735 +semantic: 0.695 +network: 0.690 +boot: 0.679 +vnc: 0.650 +KVM: 0.432 + +qemu-user compiled static for ppc fails on 64bit hosts + +On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce: + +host$ mkdir powerpc +host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian +host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/ +host$ LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash +I have no name!@guest:/# pwd +/ +I have no name!@guest:/# cd home/ +I have no name!@guest:/home# ls +qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed. + +I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result. + +I ran into this issue also and did a bit of investigating. This is only an issue when ran on a 64bit host. The actual problem line is + +err |= __put_user(h2g(ka->_sa_handler), &sc->handler); + +inside of linux_user/signal.c. What I am unsure of is when the h2g() macro, the cause of the assert, is valid to be used. In this case, under 64bit, GUEST_BASE has a value (32bit it is 0) but ka->_sa_handler has a low value. Assuming that the low value is a direct result of being a guest address and not a host address then the h2g() shouldn't be called. + +I removed the macro from that line which kept the assert from appearing but qemu still died after running 'ls'. I am attempting to fix this bug but I have limited understanding of qemu itself so no promises of me doing a fix, let alone a proper fix. + +On 1 January 2013 06:56, Samuel Seay <email address hidden> wrote: +> I ran into this issue also and did a bit of investigating. This is only +> an issue when ran on a 64bit host. The actual problem line is +> +> err |= __put_user(h2g(ka->_sa_handler), &sc->handler); +> +> inside of linux_user/signal.c. What I am unsure of is when the h2g() +> macro, the cause of the assert, is valid to be used. + +Strongly suspect that (PPC-specific) code is just busted -- no other guest +architecture's signal handling code does an h2g on ka->_sa_handler, +because it's a guest address already. + +cc'ing our PPC maintainer :-) + +-- PMM + + +I just submitted a patch to the dev mailing list. Just in case there is an issue with the submitted patch, or if Erik wants it sooner, I attached the patch I submitted. + +As far as I can see, the fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=beb526b12134a6b674 +... so closing this ticket now. + diff --git a/results/classifier/108/other/1054558 b/results/classifier/108/other/1054558 new file mode 100644 index 00000000..25907ca9 --- /dev/null +++ b/results/classifier/108/other/1054558 @@ -0,0 +1,53 @@ +other: 0.718 +permissions: 0.677 +vnc: 0.661 +files: 0.648 +graphic: 0.625 +debug: 0.624 +boot: 0.618 +device: 0.617 +performance: 0.608 +KVM: 0.598 +network: 0.596 +socket: 0.592 +PID: 0.561 +semantic: 0.514 + +1366x768 resolution missing + +I use ArchLinux with QEMU 1.2.0. +I found that 1366x768 resolution is missing, even if I use -vga std or -vga vmware. +I think that it is necessary to patch it into the source. +Also, why not add a command-line option to specify custom resolutions without patching the source? (I know that VirtualBox has a hidden option to add any resolution.) + +Is there any workaround ? + +Thanks + +QXL and http://www.spice-space.org/download.html + +I tried it , but did not get the correct resolution. It takes 1280x768 (black space on both sides) + +Thank you! + +I'm using winXP and win7 as guest with this setup and i have 1366x768, but i run it with virt-manager and this is in ps. + +qemu-system-x86_64 -enable-kvm -name Windows7 -S -machine pc-i440fx-2.0,accel=kvm,usb=off -cpu Westmere,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+rdtscp,+pdpe1gb,+rdrand,+f16c,+avx,+osxsave,+xsave,+tsc-deadline,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid c074b8c6-9baa-49e4-b09d-553cc75e3345 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=24,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:2d:e1:e5,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=o + +Thanks you, I will test with virt-manager. + +I'm using a windows 8.1 installation. Seems like it need wqhl drivers, and The driver I found [1] did not work for this resolution. + +Maybe I should test compiling seabios as commented on that blog + +Thanks you + +[1] https://supervacuo.com/2014/sep/28/windows-81-qemu-custom-resolutions-qxl/ + +I noticed that we have multiple tickets for more resolutions opened. Let's consolidate all in https://bugs.launchpad.net/qemu/+bug/1022023 and close this one here as duplicate. + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + |