diff options
Diffstat (limited to 'results/classifier/zero-shot/105/other/1714331')
| -rw-r--r-- | results/classifier/zero-shot/105/other/1714331 | 598 |
1 files changed, 598 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/other/1714331 b/results/classifier/zero-shot/105/other/1714331 new file mode 100644 index 000000000..a93c11990 --- /dev/null +++ b/results/classifier/zero-shot/105/other/1714331 @@ -0,0 +1,598 @@ +other: 0.816 +mistranslation: 0.732 +KVM: 0.691 +semantic: 0.675 +instruction: 0.661 +graphic: 0.650 +device: 0.648 +assembly: 0.643 +vnc: 0.624 +network: 0.622 +boot: 0.586 +socket: 0.549 + +Virtual machines not working anymore on 2.10 + +Using 2.10, my virtual machine(s) don't work anymore. This happens 100% of the times. + +----- + +I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is the configure command: + + configure --target-list=x86_64-softmmu --enable-debug --enable-gtk --enable-spice --audio-drv-list=pa + +I have one virtual disk, with a Windows 10 64-bit, which I launch in two different ways; both work perfectly on 2.9 (and used to do on 2.8, but I haven't used it for a long time). + +This is the first way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 4096 + -display gtk + -vga qxl + -rtc base=localtime + -serial none + -parallel none + -usb + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be repaired` windows screen; on 2.9, it boots regularly. + +This is the second way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 10240 + -vga none + -rtc base=localtime + -serial none + -parallel none + -usb + -device vfio-pci,host=01:00.0,multifunction=on + -device vfio-pci,host=01:00.1 + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. +On 2.9, this works perfectly. + +----- + +I am able to perform a git bisect, if that helps, but if this is the case, I'd need this issue to be reviewed, since bisecting is going to take me a lot of time. + +Please try: -machine pc-q35-2.9,accel=kvm,mem-merge=off + +I'm not sure if it will make a difference in this case but it presents exactly the same onboard hardware as QEMU 2.9. The onboard hardware configuration may change unless you specify a precise version in the machine type, so I suggest using it instead of "q35". + +Did you build QEMU 2.9 from source with the same ./configure options? + +> Please try: -machine pc-q35-2.9,accel=kvm,mem-merge=off + +I've tried the first configuration (windowed) with the change you proposed, and I get the same behavior (windows recovery); I didnt' try the second configuration (VFIO). + +> Did you build QEMU 2.9 from source with the same ./configure options? + +Yes, you can see the command at the beginning of the bug report. + +I am also unable to boot Windows 10 64 bit since updating to 2.10.0. I was previously using 2.8.0 which worked perfectly. Windows gets stuck at the big Windows logo with the spinning dots underneath and QEMU uses 100% CPU of 1 core. I am using kernel 4.11.9 and the following command line: + +qemu-system-x86_64 +-serial none +-parallel none +-balloon none +-enable-kvm +-name Windows10 +-display none +-M q35,accel=kvm,mem-merge=off +-m 10240 +-cpu host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_vendor_id=whatever +-smp 4,sockets=1,cores=4,threads=1 +-realtime mlock=on +-vga none +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on +-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 +-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/OVMF_CODE-pure-efi.fd +-drive if=pflash,format=raw,file=/usr/share/ovmf/OVMF_VARS-pure-efi.fd +-drive if=none,id=drive0,cache=directsync,aio=native,format=raw,file=/dev/mint-vg/windows +-object iothread,id=iothread0 +-device virtio-blk-pci,drive=drive0,scsi=off,iothread=iothread0 +-drive if=none,id=drive1,cache=directsync,aio=native,format=raw,file=/dev/evo-vg/windows2 +-object iothread,id=iothread1 -device virtio-blk-pci,drive=drive1,scsi=off,iothread=iothread1 +-net nic,model=virtio +-net bridge,br=br0 +-rtc base=localtime,clock=host +-usb +-device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b22 +-device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b15 + +I have now rolled back to 2.8.0 and it is working again. + + +Mary: If you have time to run a git bisect that would be very helpful, thanks! + + $ git bisect v2.10.0 v2.9.0 + +OK, I'll do that. It will take me a bit of time - I'll timeframe a week. + +Note that I can't know if both VFIO and non-VFIO context suffer the same bug. For simplicity, I'll peform the bisect using the non-VFIO version, then, once we have more information, we can decide how to proceed. + +I think my issue looks like the same. Sometimes I just get spinning dots, and sometimes there is the message about doing an automatic repair below the spinning dots before it stops and uses 100% cpu. I just did a git bisect: + +# git bisect log +# bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +# good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for v2.9.0 release +git bisect start 'v2.10.0' 'v2.9.0' +# bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +# bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking branch 'rth/tags/pull-s390-20170512' into staging +git bisect bad eba0161990af8509608332450ee7e338273cf5df +# good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use ARRAY_SIZE from qemu/osdep.h +git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +# bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +# good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +# good: [6c02258e143700314ebf268dae47eb23db17d1cf] qobject-input-visitor: Document full_name_nth() +git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +# bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a vhost-scsi-common abstraction +git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +# bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex lock and unlock trace events +git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +# bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in QEMU_BUILD_BUG_ON +git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +# bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time assertion on pc/q35 reset register being identical. +git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +# bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +# first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. + + + +77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +commit 77af8a2b95b79699de650965d5228772743efe84 +Author: Phil Dennis-Jordan <email address hidden> +Date: Wed Mar 15 19:20:26 2017 +1300 + + hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. + + This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register. + + The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions. + + The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content. + + Signed-off-by: Phil Dennis-Jordan <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +:040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +:040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M tests + + +On Tue, Sep 05, 2017 at 06:42:06PM -0000, Chris Unsworth wrote: +> I think my issue looks like the same. Sometimes I just get spinning +> dots, and sometimes there is the message about doing an automatic repair +> below the spinning dots before it stops and uses 100% cpu. I just did a +> git bisect: + +Perfect, thanks Chris! + +I have CCed Phil and Paolo regarding the commit you identified. + +> +> # git bisect log +> # bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +> # good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for v2.9.0 release +> git bisect start 'v2.10.0' 'v2.9.0' +> # bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +> git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> # bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking branch 'rth/tags/pull-s390-20170512' into staging +> git bisect bad eba0161990af8509608332450ee7e338273cf5df +> # good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use ARRAY_SIZE from qemu/osdep.h +> git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +> # bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +> git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +> # good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +> git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +> # good: [6c02258e143700314ebf268dae47eb23db17d1cf] qobject-input-visitor: Document full_name_nth() +> git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +> # bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a vhost-scsi-common abstraction +> git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +> # bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex lock and unlock trace events +> git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +> # bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in QEMU_BUILD_BUG_ON +> git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +> # bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time assertion on pc/q35 reset register being identical. +> git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +> # bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +> # first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> +> +> 77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +> commit 77af8a2b95b79699de650965d5228772743efe84 +> Author: Phil Dennis-Jordan <email address hidden> +> Date: Wed Mar 15 19:20:26 2017 +1300 +> +> hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest +> OS support. +> +> This updates the FADT generated for x86/64 machine types from +> Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The +> intention is to expose the reset register information to guest operating +> systems which require it, specifically OS X/macOS. Revision 1 FADTs do +> not contain the fields relating to the reset register. +> +> The new layout and contents remains backwards-compatible with +> operating systems which only support ACPI 1.0, as the existing fields +> are not modified by this change, as the 64-bit and 32-bit variants are +> allowed to co-exist according to the ACPI 2.0 standard. No regressions +> became apparent in tests with a range of Windows (XP-10) and Linux +> versions. +> +> The BIOS tables test suite's FADT checksum test has also been +> updated to reflect the new FADT layout and content. +> +> Signed-off-by: Phil Dennis-Jordan <email address hidden> +> Message-Id: <email address hidden> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +> :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +> :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M tests +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1714331 +> +> Title: +> Virtual machines not working anymore on 2.10 +> +> Status in QEMU: +> New +> +> Bug description: +> Using 2.10, my virtual machine(s) don't work anymore. This happens +> 100% of the times. +> +> ----- +> +> I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is +> the configure command: +> +> configure --target-list=x86_64-softmmu --enable-debug --enable-gtk +> --enable-spice --audio-drv-list=pa +> +> I have one virtual disk, with a Windows 10 64-bit, which I launch in +> two different ways; both work perfectly on 2.9 (and used to do on 2.8, +> but I haven't used it for a long time). +> +> This is the first way: +> +> qemu-system-x86_64 +> -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> -enable-kvm +> -machine q35,accel=kvm,mem-merge=off +> -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time +> -smp 4,cores=4,sockets=1,threads=1 +> -m 4096 +> -display gtk +> -vga qxl +> -rtc base=localtime +> -serial none +> -parallel none +> -usb +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device virtio-scsi-pci,id=scsi +> -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback +> -device scsi-hd,drive=hdd1 +> -net nic,model=virtio +> -net user +> +> On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be +> repaired` windows screen; on 2.9, it boots regularly. +> +> This is the second way: +> +> qemu-system-x86_64 +> -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> -enable-kvm +> -machine q35,accel=kvm,mem-merge=off +> -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time +> -smp 4,cores=4,sockets=1,threads=1 +> -m 10240 +> -vga none +> -rtc base=localtime +> -serial none +> -parallel none +> -usb +> -device vfio-pci,host=01:00.0,multifunction=on +> -device vfio-pci,host=01:00.1 +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device virtio-scsi-pci,id=scsi +> -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback +> -device scsi-hd,drive=hdd1 +> -net nic,model=virtio +> -net user +> +> On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. +> On 2.9, this works perfectly. +> +> ----- +> +> I am able to perform a git bisect, if that helps, but if this is the +> case, I'd need this issue to be reviewed, since bisecting is going to +> take me a lot of time. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1714331/+subscriptions +> + + +Hi Stefan, + +What version of OVMF are you using? There were a bunch of bugs related to +FADT in OVMF which were fixed back in March. Specifically, commits +072060a, 78807f6, and 198a46d. If your version of OVMF doesn't include +these fixes, that's a likely source for your problems. + +Hope that helps. + +Phil + + +On 6 September 2017 at 16:34, Stefan Hajnoczi <email address hidden> wrote: + +> On Tue, Sep 05, 2017 at 06:42:06PM -0000, Chris Unsworth wrote: +> > I think my issue looks like the same. Sometimes I just get spinning +> > dots, and sometimes there is the message about doing an automatic repair +> > below the spinning dots before it stops and uses 100% cpu. I just did a +> > git bisect: +> +> Perfect, thanks Chris! +> +> I have CCed Phil and Paolo regarding the commit you identified. +> +> > +> > # git bisect log +> > # bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for +> v2.10.0 release +> > # good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for +> v2.9.0 release +> > git bisect start 'v2.10.0' 'v2.9.0' +> > # bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check +> more get_try_int() cases +> > git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> > # bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking +> branch 'rth/tags/pull-s390-20170512' into staging +> > git bisect bad eba0161990af8509608332450ee7e338273cf5df +> > # good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use +> ARRAY_SIZE from qemu/osdep.h +> > git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +> > # bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking +> branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +> > git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +> > # good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge +> remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +> > git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +> > # good: [6c02258e143700314ebf268dae47eb23db17d1cf] +> qobject-input-visitor: Document full_name_nth() +> > git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +> > # bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a +> vhost-scsi-common abstraction +> > git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +> > # bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex +> lock and unlock trace events +> > git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +> > # bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in +> QEMU_BUILD_BUG_ON +> > git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +> > # bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time +> assertion on pc/q35 reset register being identical. +> > git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +> > # bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 +> FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> > git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +> > # first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: +> Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> > +> > +> > 77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +> > commit 77af8a2b95b79699de650965d5228772743efe84 +> > Author: Phil Dennis-Jordan <email address hidden> +> > Date: Wed Mar 15 19:20:26 2017 +1300 +> > +> > hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest +> > OS support. +> > +> > This updates the FADT generated for x86/64 machine types from +> > Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The +> > intention is to expose the reset register information to guest operating +> > systems which require it, specifically OS X/macOS. Revision 1 FADTs do +> > not contain the fields relating to the reset register. +> > +> > The new layout and contents remains backwards-compatible with +> > operating systems which only support ACPI 1.0, as the existing fields +> > are not modified by this change, as the 64-bit and 32-bit variants are +> > allowed to co-exist according to the ACPI 2.0 standard. No regressions +> > became apparent in tests with a range of Windows (XP-10) and Linux +> > versions. +> > +> > The BIOS tables test suite's FADT checksum test has also been +> > updated to reflect the new FADT layout and content. +> > +> > Signed-off-by: Phil Dennis-Jordan <email address hidden> +> > Message-Id: <email address hidden> +> > Signed-off-by: Paolo Bonzini <email address hidden> +> > +> > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 +> 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +> > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d +> 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +> > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff +> 8ed08cef10fddee7814e38ad62be11371592a75a M tests +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1714331 +> > +> > Title: +> > Virtual machines not working anymore on 2.10 +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Using 2.10, my virtual machine(s) don't work anymore. This happens +> > 100% of the times. +> > +> > ----- +> > +> > I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is +> > the configure command: +> > +> > configure --target-list=x86_64-softmmu --enable-debug --enable-gtk +> > --enable-spice --audio-drv-list=pa +> > +> > I have one virtual disk, with a Windows 10 64-bit, which I launch in +> > two different ways; both work perfectly on 2.9 (and used to do on 2.8, +> > but I haven't used it for a long time). +> > +> > This is the first way: +> > +> > qemu-system-x86_64 +> > -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> > -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> > -enable-kvm +> > -machine q35,accel=kvm,mem-merge=off +> > -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_ +> spinlocks=0x1fff,hv_vapic,hv_time +> > -smp 4,cores=4,sockets=1,threads=1 +> > -m 4096 +> > -display gtk +> > -vga qxl +> > -rtc base=localtime +> > -serial none +> > -parallel none +> > -usb +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device virtio-scsi-pci,id=scsi +> > -drive file=/path/to/image-diff.img, +> id=hdd1,format=qcow2,if=none,cache=writeback +> > -device scsi-hd,drive=hdd1 +> > -net nic,model=virtio +> > -net user +> > +> > On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be +> > repaired` windows screen; on 2.9, it boots regularly. +> > +> > This is the second way: +> > +> > qemu-system-x86_64 +> > -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> > -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> > -enable-kvm +> > -machine q35,accel=kvm,mem-merge=off +> > -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_ +> spinlocks=0x1fff,hv_vapic,hv_time +> > -smp 4,cores=4,sockets=1,threads=1 +> > -m 10240 +> > -vga none +> > -rtc base=localtime +> > -serial none +> > -parallel none +> > -usb +> > -device vfio-pci,host=01:00.0,multifunction=on +> > -device vfio-pci,host=01:00.1 +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device virtio-scsi-pci,id=scsi +> > -drive file=/path/to/image-diff.img, +> id=hdd1,format=qcow2,if=none,cache=writeback +> > -device scsi-hd,drive=hdd1 +> > -net nic,model=virtio +> > -net user +> > +> > On QEMU 2.10, I get the debug window on the linux monitor, and blank +> screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU +> crashes without any message. +> > On 2.9, this works perfectly. +> > +> > ----- +> > +> > I am able to perform a git bisect, if that helps, but if this is the +> > case, I'd need this issue to be reviewed, since bisecting is going to +> > take me a lot of time. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1714331/+subscriptions +> > +> + + +I'm using the Ubuntu artful version (0~20161202.7bbe0b3e-1), so I'll need to build a recent OVMF package to verify the solution. + +I was using a version of OVMF from about a year ago which works fine with QEMU 2.8 and 2.9 but doesn't work with 2.10. I just updated to the latest OVMF from master and everything's working now with QEMU 2.10 and WIndows 10 64 bit, so the old OVMF was the issue. + +Thanks for your help, +Chris + + +Building the OVMF from the `edk2` current master (89796c69d9) fixes both (non/vfio) issues. + +Should this be opened as a bug on the `ovmf` Ubuntu package (xenial/zesty/artful)? I'm very familiar with the Ubuntu version policies. + +See also LP#1725560. + +> Should this be opened as a bug on the `ovmf` Ubuntu package (xenial/zesty/artful)? I'm very familiar with the Ubuntu version policies. + +I've just noticed that I intended to write "I'm *not* very familiar with the Ubuntu version policies". + |