[Qemu-devel] [Bug 1119281] [NEW] The virtio network device breaks UuidCreateSequential()
Public bug reported:
UuidCreateSequential() usually creates version 1 UUIDs (1) which means
they contain the main network card's MAC address. However when using a
virtio network card and driver the UUIDs contain random data instead of
the guest's MAC address. Changing the network card to either the default
rtl8139 one or the e1000 one fixes the issue.
Here is the software I have tested this with:
* qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
Experimental respectively)
* The 0.1-49 and 0.1-52 Windows virtio drivers from
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
* Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and
install the corresponding driver.
* Boot the guest and copy the uuidtest.exe file (see attachement) to it
* On the command line, type 'ipconfig /all'. Give you the correct
network card's MAC address on a line like the one below:
Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
* Run uuidtest.exe. It will show the VM returning a UUID with the wrong
MAC address, and quite possibly even a multicast MAC address! (3). In
the example below 'f75292c62787' should have been the MAC address. Note
that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY
for virtio cards but that on Windows 7 it returns 0.
UuidCreateSequential() returned 0
uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
Got a version 1 UUID
The UUID does not contain a non-multicast MAC address
* Reboot and notice uuidtest.exe now reports a different value where the
MAC address should be.
* Shut down the VM and switch the network card to rtl8139, install the
drivers, run uuidtest.exe and notice that the last group of digits
finally contains the correct MAC address.
(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the primary
one.
(3) If the first byte of the address is odd then this is a multicast address.
https://en.wikipedia.org/wiki/MAC_address#Address_details
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "Test executable and source"
https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1119281
Title:
The virtio network device breaks UuidCreateSequential()
Status in QEMU:
New
Bug description:
UuidCreateSequential() usually creates version 1 UUIDs (1) which means
they contain the main network card's MAC address. However when using a
virtio network card and driver the UUIDs contain random data instead
of the guest's MAC address. Changing the network card to either the
default rtl8139 one or the e1000 one fixes the issue.
Here is the software I have tested this with:
* qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
Experimental respectively)
* The 0.1-49 and 0.1-52 Windows virtio drivers from
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
* Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and
install the corresponding driver.
* Boot the guest and copy the uuidtest.exe file (see attachement) to
it
* On the command line, type 'ipconfig /all'. Give you the correct
network card's MAC address on a line like the one below:
Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
* Run uuidtest.exe. It will show the VM returning a UUID with the
wrong MAC address, and quite possibly even a multicast MAC address!
(3). In the example below 'f75292c62787' should have been the MAC
address. Note that on Windows XP UuidCreateSequential() returns
RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it
returns 0.
UuidCreateSequential() returned 0
uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
Got a version 1 UUID
The UUID does not contain a non-multicast MAC address
* Reboot and notice uuidtest.exe now reports a different value where
the MAC address should be.
* Shut down the VM and switch the network card to rtl8139, install the
drivers, run uuidtest.exe and notice that the last group of digits
finally contains the correct MAC address.
(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the
primary one.
(3) If the first byte of the address is odd then this is a multicast address.
https://en.wikipedia.org/wiki/MAC_address#Address_details
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1119281/+subsc
[Qemu-devel] [Bug 1119686] [NEW] Incorrect handling of icebp
Public bug reported: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Test executable and source" https://bugs.launchpad.net/bugs/1119686/+attachment/3521163/+files/exception.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119686 Title: Incorrect handling of icebp Status in QEMU: New Bug description: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
[Qemu-devel] [Bug 1119861] [NEW] Poor console performance in Windows 7
Public bug reported: As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver 147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver 145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Test executable and source" https://bugs.launchpad.net/bugs/1119861/+attachment/3521476/+files/console.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119861 Title: Poor console performance in Windows 7 Status in QEMU: New Bug description: As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver 147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver 145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119861/+subscriptions
[Qemu-devel] [Bug 1123975] [NEW] QEmu 1.3.90 cannot restore a 1.1.2 live snapshot
Public bug reported: I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: virsh # snapshot-revert fgtbbuild wtb error: operation failed: Error -22 while loading VM state I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. ipxe-qemu 1.0.0+git-20120202.f6840ba-3 qemu 1.4.0~rc0+dfsg-1exp qemu-keymaps 1.4.0~rc0+dfsg-1exp qemu-kvm 1.4.0~rc0+dfsg-1exp qemu-system1.4.0~rc0+dfsg-1exp qemu-system-arm1.4.0~rc0+dfsg-1exp qemu-system-common 1.4.0~rc0+dfsg-1exp qemu-system-mips 1.4.0~rc0+dfsg-1exp qemu-system-misc 1.4.0~rc0+dfsg-1exp qemu-system-ppc1.4.0~rc0+dfsg-1exp qemu-system-sparc 1.4.0~rc0+dfsg-1exp qemu-system-x861.4.0~rc0+dfsg-1exp qemu-user 1.4.0~rc0+dfsg-1exp qemu-utils 1.4.0~rc0+dfsg-1exp libvirt-bin1.0.2-1 libvirt-dev1.0.2-1 libvirt-doc1.0.2-1 libvirt-glib-1.0-0 0.1.2-1 libvirt0 1.0.2-1 libvirtodbc0 6.1.4+dfsg1-5 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1123975 Title: QEmu 1.3.90 cannot restore a 1.1.2 live snapshot Status in QEMU: New Bug description: I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: virsh # snapshot-revert fgtbbuild wtb error: operation failed: Error -22 while loading VM state I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. ipxe-qemu 1.0.0+git-20120202.f6840ba-3 qemu 1.4.0~rc0+dfsg-1exp qemu-keymaps 1.4.0~rc0+dfsg-1exp qemu-kvm 1.4.0~rc0+dfsg-1exp qemu-system1.4.0~rc0+dfsg-1exp qemu-system-arm1.4.0~rc0+dfsg-1exp qemu-system-common 1.4.0~rc0+dfsg-1exp qemu-system-mips 1.4.0~rc0+dfsg-1exp qemu-system-misc 1.4.0~rc0+dfsg-1exp qemu-system-ppc1.4.0~rc0+dfsg-1exp qemu-system-sparc 1.4.0~rc0+dfsg-1exp qemu-system-x861.4.0~rc0+dfsg-1exp qemu-user 1.4.0~rc0+dfsg-1exp qemu-utils 1.4.0~rc0+dfsg-1exp libvirt-bin1.0.2-1 libvirt-dev1.0.2-1 libvirt-doc1.0.2-1 libvirt-glib-1.0-0 0.1.2-1 libvirt0 1.0.2-1 libvirtodbc0 6.1.4+dfsg1-5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1123975/+subscriptions
[Qemu-devel] [Bug 1123975] Re: QEmu 1.3.90 cannot restore a 1.1.2 live snapshot
> And one more thing -- from what to what are you trying to migrate? I believe kvm is being used in both cases, though the command is different with QEmu 1.3.90. I have redone tests where I kept libvirt set to 1.0.2 and only switched between QEmu 1.1.2 and 1.3.90 to minimize the changes. So here the only difference is 'apt-get install -t experimental qemu'. Here is what 'ps aux' shows me: libvirt 1.0.2-2 + QEmu 1.1.2 127 12841 92.7 4.6 1078272 189128 ? Sl 00:45 10:46 /usr/bin/kvm -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9 -80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive- ide0-0-0,format=qcow2,cache=writeback -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-1-0,readonly=on,format=raw -device ide- cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga vmware -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 -loadvm wtb With libvirt 1.0.2-2 + QEmu 1.3.90 127 18709 39.7 0.8 1075732 35304 ? Sl 01:39 0:05 qemu-system-x86_64 -machine accel=kvm:tcg -name fgtbwinxp -S -M pc-1.1 -cpu Penryn,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 768 -smp 2,sockets=2,cores=1,threads=1 -uuid e624f2c9-80fd-26c7-a38a-0f0e49b6b719 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbwinxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbwinxp.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -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-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:c7:0e:97,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga vmware -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 -loadvm wtb There's a wrinkle I missed in my original report: the behavior is different depending on whether the VM is already running or not. $ virsh --connect qemu:///system destroy fgtbwinxp $ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? 0 # This command looks like it succeeds but in fact I see the VM booting Windows. So either the live state was not restored at all or it crashed before virt-viewer could connect. $ virsh --connect qemu:///system snapshot-revert fgtbwinxp wtb;echo $? error: operation failed: Error -22 while loading VM state 1 > But at any rate, I never recommended any sort of cross-version migration > as in practice, despite countless efforts spent to make it to work, it > almost always does NOT work. Ouch. I expect to end up with about 50 live snapshots. It would be pretty annoying to have to redo all of them every time I upgrade QEmu / KVM :-( -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1123975 Title: QEmu 1.3.90 cannot restore a 1.1.2 live snapshot Status in QEMU: New Bug description: I have upgraded to QEmu 1.3.90 (Debian 1.4.0~rc0+dfsg-1exp) but now when I try to restore a live snapshot made in QEmu 1.1.2 (Debian 1.1.2+dfsg-5) I get the following message: virsh # snapshot-revert fgtbbuild wtb error: operation failed: Error -22 while loading VM state I have test VMs with live snapshots coreresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu. ipxe-qemu 1.0.0+git-20120202.f6840ba-3 qemu 1.4.0~rc0+dfsg-1exp qemu-keymaps 1.4.0~rc0+dfsg-1exp qemu-kvm 1.4
[Qemu-devel] [Bug 1259499] Re: QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64
Thanks for digging into this. I am indeed getting the same ramblock error. So it's good that there appears to be a fix for it. Also if I understand it correctly this particular issue only affects the 1.6.0 snapshots so given that most of my snapshots are still on 1.3.x a direct upgrade to 1.7+ will hopefully let me avoid the issue. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1259499 Title: QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system- x86_64 Status in QEMU: Confirmed Bug description: I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state. Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message: $ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $? error: operation failed: Error -22 while loading VM state 1 I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again. This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-( Here is the command being run by libvirt: /usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c- 17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no- shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio- disk0,format=qcow2,cache=writeback -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl- vga,id=video0,ram_size=67108864,vram_size=67108864,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=0x6 -loadvm wtb ipxe-qemu 1.0.0+git-20120202.f6840ba-3 qemu 1.7.0+dfsg-2 qemu-keymaps 1.7.0+dfsg-2 qemu-slof 20130430+dfsg-1 qemu-system 1.7.0+dfsg-2 qemu-system-arm 1.7.0+dfsg-2 qemu-system-common 1.7.0+dfsg-2 qemu-system-mips 1.7.0+dfsg-2 qemu-system-misc 1.7.0+dfsg-2 qemu-system-ppc 1.7.0+dfsg-2 qemu-system-sparc 1.7.0+dfsg-2 qemu-system-x86 1.7.0+dfsg-2 qemu-user 1.7.0+dfsg-2 qemu-utils 1.7.0+dfsg-2 libvirt-bin 1.1.4-2 libvirt0 1.1.4-2 libvirtodbc0 6.1.6+dfsg-4 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1259499/+subscriptions
[Qemu-devel] [Bug 1259499] [NEW] QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64
Public bug reported: I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state. Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message: $ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $? error: operation failed: Error -22 while loading VM state 1 I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again. This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-( Here is the command being run by libvirt: /usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c-17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no- shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio- disk0,format=qcow2,cache=writeback -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl- vga,id=video0,ram_size=67108864,vram_size=67108864,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=0x6 -loadvm wtb ipxe-qemu 1.0.0+git-20120202.f6840ba-3 qemu 1.7.0+dfsg-2 qemu-keymaps 1.7.0+dfsg-2 qemu-slof 20130430+dfsg-1 qemu-system 1.7.0+dfsg-2 qemu-system-arm 1.7.0+dfsg-2 qemu-system-common 1.7.0+dfsg-2 qemu-system-mips 1.7.0+dfsg-2 qemu-system-misc 1.7.0+dfsg-2 qemu-system-ppc 1.7.0+dfsg-2 qemu-system-sparc 1.7.0+dfsg-2 qemu-system-x86 1.7.0+dfsg-2 qemu-user 1.7.0+dfsg-2 qemu-utils 1.7.0+dfsg-2 libvirt-bin 1.1.4-2 libvirt0 1.1.4-2 libvirtodbc0 6.1.6+dfsg-4 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1259499 Title: QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system- x86_64 Status in QEMU: New Bug description: I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state. Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message: $ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $? error: operation failed: Error -22 while loading VM state 1 I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again. This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-( Here is the command being run by libvirt: /usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c- 17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no- shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio- disk0,format=qcow2,cache=writeback -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=
[Qemu-devel] [Bug 1119281] Re: The virtio network device breaks UuidCreateSequential()
This bug is still present in QEM 1.6.0 (qemu-system-x86 1.6.0+dfsg-1)
and/or Virtio 0.1-65.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1119281
Title:
The virtio network device breaks UuidCreateSequential()
Status in QEMU:
New
Bug description:
UuidCreateSequential() usually creates version 1 UUIDs (1) which means
they contain the main network card's MAC address. However when using a
virtio network card and driver the UUIDs contain random data instead
of the guest's MAC address. Changing the network card to either the
default rtl8139 one or the e1000 one fixes the issue.
Here is the software I have tested this with:
* qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
Experimental respectively)
* The 0.1-49 and 0.1-52 Windows virtio drivers from
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
* Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and
install the corresponding driver.
* Boot the guest and copy the uuidtest.exe file (see attachement) to
it
* On the command line, type 'ipconfig /all'. Give you the correct
network card's MAC address on a line like the one below:
Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
* Run uuidtest.exe. It will show the VM returning a UUID with the
wrong MAC address, and quite possibly even a multicast MAC address!
(3). In the example below 'f75292c62787' should have been the MAC
address. Note that on Windows XP UuidCreateSequential() returns
RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it
returns 0.
UuidCreateSequential() returned 0
uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
Got a version 1 UUID
The UUID does not contain a non-multicast MAC address
* Reboot and notice uuidtest.exe now reports a different value where
the MAC address should be.
* Shut down the VM and switch the network card to rtl8139, install the
drivers, run uuidtest.exe and notice that the last group of digits
finally contains the correct MAC address.
(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the
primary one.
(3) If the first byte of the address is odd then this is a multicast address.
https://en.wikipedia.org/wiki/MAC_address#Address_details
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1119281/+subscriptions
[Qemu-devel] [Bug 1119686] Re: Incorrect handling of icebp
This bug is still present in QEMU 1.6.0 (as per Debian's qemu-system-x86 1.6.0+dfsg-1 package). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119686 Title: Incorrect handling of icebp Status in QEMU: New Bug description: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
[Qemu-devel] [Bug 1119686] Re: Incorrect handling of icebp
This bug is still present in QEMU 1.7.0 (as per Debian's qemu-system-x86 1.7.0+dfsg-3 package). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119686 Title: Incorrect handling of icebp Status in QEMU: New Bug description: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
[Qemu-devel] [Bug 1499908] [NEW] hda sound capture broken with VNC
Public bug reported:
QEmu is being used to run the Wine conformance tests in Windows virtual
machines. Wine's conformance tests check the behavior of various Windows
APIs and verify that they behave as expected. One of the tests checks
the behavior of the mmdevapi sound capture APIs. This test works fine on
real hardware and also works fine in various QEmu VMs but fails in some
others. Further investigation showed that:
* The mmdevapi:capture tests work on the two Vista VMs. Those use the
ac97 sound card and are configured for VNC access to the VM.
* The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an
hda sound card and are configured for VNC access to the VM (so '-device
intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0').
* Furthermore configuring the VM for Spice access fixes the
mmdevapi:capture test (so replacing -vnc with '-spice
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'), this
even if no client connects to the VM.
So in effect the -spice and -vnc options change the behavior of the
sound device.
To reproduce this bug:
1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt).
2. Set it up for access using VNC.
3. Copy the attached mmdevapi_test.exe file to it. (*)
4. Run the tests as follows:
mmdevapi_test.exe capture
If you see these 'Test Failed' lines then the bug is still present:
capture.c:586: Returned latency: 5.8050 ms
capture.c:178: Test failed: Position 1015 expected 0
capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked: 448
capture.c:228: Test failed: Position 2167 expected 1463
capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames locked:
448
capture.c:256: Test failed: Position 2167 expected 1463
capture.c:292: GetBufferSize 21996 period size 448
capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames locked:
448
capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996
capture.c:313: Test failed: Position 4215 gap 2304
capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames locked:
448
capture.c:333: Test failed: Position 5303 expected 4663
capture.c:334: Test failed: flags 1
capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames locked:
448
capture.c:358: Test failed: Position 7351 expected 5111
capture.c:359: Test failed: flags 1
In case it helps, here is the source of mmdevapi_test.exe:
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178
So far I have confirmed that this bug is present in QEmu as shipped in the
following Debian packages:
* qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 + linux-image-3.16.0-4-amd64
3.16.7-ckt11-1+deb8u3
* qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1
(*) As alternatives to using the attached binary you can:
- Compile it from Wine's source. See:
https://source.winehq.org/git/wine.git/
- Or download the latest WineTest binary from
https://test.winehq.org/builds/winetest-latest.exe
And extract the mmdevapi_test.exe from there:
winetest.exe -x tests
tests\mmdevapi_test.exe capture
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "A test executable to reproduce the bug"
https://bugs.launchpad.net/bugs/1499908/+attachment/4474932/+files/mmdevapi_test.zip
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1499908
Title:
hda sound capture broken with VNC
Status in QEMU:
New
Bug description:
QEmu is being used to run the Wine conformance tests in Windows
virtual machines. Wine's conformance tests check the behavior of
various Windows APIs and verify that they behave as expected. One of
the tests checks the behavior of the mmdevapi sound capture APIs. This
test works fine on real hardware and also works fine in various QEmu
VMs but fails in some others. Further investigation showed that:
* The mmdevapi:capture tests work on the two Vista VMs. Those use the
ac97 sound card and are configured for VNC access to the VM.
* The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an
hda sound card and are configured for VNC access to the VM (so
'-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0').
* Furthermore configuring the VM for Spice access fixes the
mmdevapi:capture test (so replacing -vnc with '-spice
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'),
this even if no client connects to the VM.
So in effect the -spice and -vnc options change the behavior of the
sound device.
To reproduce this bug:
1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt).
2. Set it up for access using VNC.
3. Copy the attached mmdeva
[Qemu-devel] [Bug 1505041] [NEW] Live snapshot revert times increases linearly with snapshot age
Public bug reported: The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following tags: Where the unaffected VMs have the following clock definition instead: Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). To reproduce this problem do the following: * Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. * That VM will have the tags shown above, with the possible addition of an hypervclock timer. * Shut down the VM. * date -s "2014/04/01" * Start the VM. * Take a live snapshot. * Shut down the VM. * date -s "" * Revert to the live snapshot. If the revert takes more than 2 minutes then there is a problem. A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. * It setting track='guest' the revert is fast and the clock in the guest is not updated. I found three past mentions of this issue but as far as I can tell none of them got anywhere: * [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions https://lists.gnu.org/archive/html/qemu-discuss/2013-02/msg0.html * The above post references another one from 2011 wrt qemu 0.14: https://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02645.html * Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However the bug was really about another issue so this was not followed on. https://bugs.launchpad.net/qemu/+bug/1174654/comments/9 I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along. 1:2.1+dfsg-12+deb8u2 qemu-kvm 1:2.1+dfsg-12+deb8u2 qemu-system-common 1:2.1+dfsg-12+deb8u2 qemu-system-x86 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1505041 Title: Live snapshot revert times increases linearly with snapshot age Status in QEMU: New Bug description: The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following tags: Where the unaffected VMs have the following clock definition instead: Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). To reproduce this problem do the following: * Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. * That VM will have the tags shown above, with the possible addition of an hypervclock timer. * Shut down the VM. * date -s "2014/04/01" * Start the VM. * Take a live snapshot. * Shut down the VM. * date -s "" * Revert to the live snapshot. If the revert takes more than 2 minutes then there is a problem. A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. * It setting track='guest' the revert is fast and the clock in the
[Qemu-devel] [Bug 1505041] Re: Live snapshot revert times increases linearly with snapshot age
The timer settings I showed were from a Windows XP VM but a Windows 10 VM I created recently (with qemu 2.1 and libvirt 1.2.9) does have the hypervclock timer and defaults to tickpolicy='catchup' for rtc but it is missing the hyperv features you mentioned. I'll investigate those. I'm wary of tickpolicy='catchup' though. My understanding is that it's needed for the guest's clock to remain accurate over time. However our VMs stay up at most 30 minutes before being reverted so I don't think the clock will have drifted by any amount we care about. Really it can be off by a few days without impacting the tests. One nasty effect of tickpolicy='catchup' is that when we revert to our live snapshot the clock runs 10 times as fast as it tries to catch up to the current date. That would definitely impact our tests, particularly around timing sound play times or checking serial baud rates. We normally manually reset the time from within the guest so maybe that would stop it from running fast. My other concern is that I'm not sure trying to compensate for missing ticks is better for our tests than maintaining the illusion that the VM is running at a normal speed even if it's in reality running at half real time speed. I feel that for our tests agreement between the audio, serial card and various timer devices is more important than staying in sync with the outside world. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1505041 Title: Live snapshot revert times increases linearly with snapshot age Status in QEMU: New Bug description: The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following tags: Where the unaffected VMs have the following clock definition instead: Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). To reproduce this problem do the following: * Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. * That VM will have the tags shown above, with the possible addition of an hypervclock timer. * Shut down the VM. * date -s "2014/04/01" * Start the VM. * Take a live snapshot. * Shut down the VM. * date -s "" * Revert to the live snapshot. If the revert takes more than 2 minutes then there is a problem. A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. * It setting track='guest' the revert is fast and the clock in the guest is not updated. I found three past mentions of this issue but as far as I can tell none of them got anywhere: * [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions https://lists.gnu.org/archive/html/qemu-discuss/2013-02/msg0.html * The above post references another one from 2011 wrt qemu 0.14: https://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02645.html * Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However the bug was really about another issue so this was not followed on. https://bugs.launchpad.net/qemu/+bug/1174654/comments/9 I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along. 1:2.1+dfsg-12+deb8u2 qemu-kvm 1:2.1+dfsg-12+deb8u2 qemu-system-common 1:2.1+dfsg-12+deb8u2 qemu-system-x86 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1505041/+subscriptions
[Qemu-devel] [Bug 1174654] Re: qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram
This sounds sort of like a problem I have with reverting to live snapshots. What I found out is that this is related to restoring the clock in the guest. You can find out more about it there: https://bugs.launchpad.net/qemu/+bug/1505041 The takeaway is that a workaround is to set track='guest' on the rtc timer. For instance: If you have track='catchup' QEMU seems to try to send millions of interrupts so the guest clock will catch up to the current time, which can take minutes during which the guest is unusable. It is possible this no longer happens though as I have had this workaround in place for quite some time but nobody formally said this is fixed or pointed to a commit fixing this. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1174654 Title: qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram Status in QEMU: Confirmed Status in qemu package in Ubuntu: Invalid Bug description: I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself. According to the taskmgr any active process takes 99% CPU. It's not stuck on some single process. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1174654/+subscriptions
[Qemu-devel] [Bug 1505041] Re: Live snapshot revert times increases linearly with snapshot age
See also: https://bugs.launchpad.net/qemu/+bug/1174654 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1505041 Title: Live snapshot revert times increases linearly with snapshot age Status in QEMU: New Bug description: The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following tags: Where the unaffected VMs have the following clock definition instead: Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). To reproduce this problem do the following: * Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. * That VM will have the tags shown above, with the possible addition of an hypervclock timer. * Shut down the VM. * date -s "2014/04/01" * Start the VM. * Take a live snapshot. * Shut down the VM. * date -s "" * Revert to the live snapshot. If the revert takes more than 2 minutes then there is a problem. A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. * It setting track='guest' the revert is fast and the clock in the guest is not updated. I found three past mentions of this issue but as far as I can tell none of them got anywhere: * [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions https://lists.gnu.org/archive/html/qemu-discuss/2013-02/msg0.html * The above post references another one from 2011 wrt qemu 0.14: https://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02645.html * Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However the bug was really about another issue so this was not followed on. https://bugs.launchpad.net/qemu/+bug/1174654/comments/9 I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along. 1:2.1+dfsg-12+deb8u2 qemu-kvm 1:2.1+dfsg-12+deb8u2 qemu-system-common 1:2.1+dfsg-12+deb8u2 qemu-system-x86 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1505041/+subscriptions
[Qemu-devel] [Bug 1658141] [NEW] QEMU's default msrs handling causes Windows 10 64 bit to crash
Public bug reported: 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: 0xf803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xf803cb3c0c5c 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. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Source code to reproduce this bug" https://bugs.launchpad.net/bugs/1658141/+attachment/4806829/+files/exception.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658141 Title: QEMU's default msrs handling causes Windows 10 64 bit to crash Status in QEMU: New Bug description: 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: 0xf803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xf803cb3c0c5c u
[Qemu-devel] [Bug 1658141] Re: QEMU's default msrs handling causes Windows 10 64 bit to crash
** Attachment added: "Executable to reproduce this bug" https://bugs.launchpad.net/qemu/+bug/1658141/+attachment/4806830/+files/exception.exe.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658141 Title: QEMU's default msrs handling causes Windows 10 64 bit to crash Status in QEMU: New Bug description: 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: 0xf803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xf803cb3c0c5c 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658141/+subscriptions
[Qemu-devel] [Bug 1499908] Re: hda sound capture broken with VNC
On Debian this is still present in QEMU 1:2.7+dfsg-3+b1 with the 4.8.11-1 Linux
kernel.
So no change in the past 5 quarters :-(
So I'm attaching a tar file containing standalone and somewhat
minimalist source code for reproducing this issue. Just compile it with
MinGW by typing 'make', send the capture.exe binary to the VM and run
it. Again if you see 'Test failed' messages the bug is still present.
** Attachment added: "Source code to reproduce this bug"
https://bugs.launchpad.net/qemu/+bug/1499908/+attachment/4806839/+files/capture.tar.bz2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1499908
Title:
hda sound capture broken with VNC
Status in QEMU:
New
Bug description:
QEmu is being used to run the Wine conformance tests in Windows
virtual machines. Wine's conformance tests check the behavior of
various Windows APIs and verify that they behave as expected. One of
the tests checks the behavior of the mmdevapi sound capture APIs. This
test works fine on real hardware and also works fine in various QEmu
VMs but fails in some others. Further investigation showed that:
* The mmdevapi:capture tests work on the two Vista VMs. Those use the
ac97 sound card and are configured for VNC access to the VM.
* The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an
hda sound card and are configured for VNC access to the VM (so
'-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0').
* Furthermore configuring the VM for Spice access fixes the
mmdevapi:capture test (so replacing -vnc with '-spice
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'),
this even if no client connects to the VM.
So in effect the -spice and -vnc options change the behavior of the
sound device.
To reproduce this bug:
1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt).
2. Set it up for access using VNC.
3. Copy the attached mmdevapi_test.exe file to it. (*)
4. Run the tests as follows:
mmdevapi_test.exe capture
If you see these 'Test Failed' lines then the bug is still present:
capture.c:586: Returned latency: 5.8050 ms
capture.c:178: Test failed: Position 1015 expected 0
capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked:
448
capture.c:228: Test failed: Position 2167 expected 1463
capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames
locked: 448
capture.c:256: Test failed: Position 2167 expected 1463
capture.c:292: GetBufferSize 21996 period size 448
capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames
locked: 448
capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996
capture.c:313: Test failed: Position 4215 gap 2304
capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames
locked: 448
capture.c:333: Test failed: Position 5303 expected 4663
capture.c:334: Test failed: flags 1
capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames
locked: 448
capture.c:358: Test failed: Position 7351 expected 5111
capture.c:359: Test failed: flags 1
In case it helps, here is the source of mmdevapi_test.exe:
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178
So far I have confirmed that this bug is present in QEmu as shipped in the
following Debian packages:
* qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 +
linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3
* qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1
(*) As alternatives to using the attached binary you can:
- Compile it from Wine's source. See:
https://source.winehq.org/git/wine.git/
- Or download the latest WineTest binary from
https://test.winehq.org/builds/winetest-latest.exe
And extract the mmdevapi_test.exe from there:
winetest.exe -x tests
tests\mmdevapi_test.exe capture
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1499908/+subscriptions
[Qemu-devel] [Bug 1499908] Re: hda sound capture broken with VNC
As an alternative to compiling the source code yourselves, I have
attached the capture.exe binary.
** Attachment added: "Executable to reproduce this bug"
https://bugs.launchpad.net/qemu/+bug/1499908/+attachment/4806840/+files/capture.exe.bz2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1499908
Title:
hda sound capture broken with VNC
Status in QEMU:
New
Bug description:
QEmu is being used to run the Wine conformance tests in Windows
virtual machines. Wine's conformance tests check the behavior of
various Windows APIs and verify that they behave as expected. One of
the tests checks the behavior of the mmdevapi sound capture APIs. This
test works fine on real hardware and also works fine in various QEmu
VMs but fails in some others. Further investigation showed that:
* The mmdevapi:capture tests work on the two Vista VMs. Those use the
ac97 sound card and are configured for VNC access to the VM.
* The mmdevapi:capture tests fail in the Windows 7+ VMs. Those use an
hda sound card and are configured for VNC access to the VM (so
'-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-
duplex,id=sound0-codec0,bus=sound0.0,cad=0' and '-vnc 127.0.0.1:0').
* Furthermore configuring the VM for Spice access fixes the
mmdevapi:capture test (so replacing -vnc with '-spice
port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on'),
this even if no client connects to the VM.
So in effect the -spice and -vnc options change the behavior of the
sound device.
To reproduce this bug:
1. Set up a Windows 7+ VM with an hda sound card ('ich6' in libvirt).
2. Set it up for access using VNC.
3. Copy the attached mmdevapi_test.exe file to it. (*)
4. Run the tests as follows:
mmdevapi_test.exe capture
If you see these 'Test Failed' lines then the bug is still present:
capture.c:586: Returned latency: 5.8050 ms
capture.c:178: Test failed: Position 1015 expected 0
capture.c:186: Wait'ed position 1015 pad 0 flags 1, amount of frames locked:
448
capture.c:228: Test failed: Position 2167 expected 1463
capture.c:248: Sleep.1 position 2167 pad 4032 flags 1, amount of frames
locked: 448
capture.c:256: Test failed: Position 2167 expected 1463
capture.c:292: GetBufferSize 21996 period size 448
capture.c:302: Overrun position 4215 pad 8960 flags 1, amount of frames
locked: 448
capture.c:308: Test failed: GCP 8960 vs. BufferSize 21996
capture.c:313: Test failed: Position 4215 gap 2304
capture.c:329: Cont'ed position 5303 pad 8512 flags 1, amount of frames
locked: 448
capture.c:333: Test failed: Position 5303 expected 4663
capture.c:334: Test failed: flags 1
capture.c:353: Restart position 7351 pad 8064 flags 1, amount of frames
locked: 448
capture.c:358: Test failed: Position 7351 expected 5111
capture.c:359: Test failed: flags 1
In case it helps, here is the source of mmdevapi_test.exe:
https://source.winehq.org/git/wine.git/?a=blob;f=dlls/mmdevapi/tests/capture.c;hb=60d1d6f5952e8b5d6fb0327a28c047058851fa70#l178
So far I have confirmed that this bug is present in QEmu as shipped in the
following Debian packages:
* qemu-kvm + qemu-system-x86 1:2.1+dfsg-12+deb8u2 +
linux-image-3.16.0-4-amd64 3.16.7-ckt11-1+deb8u3
* qemu-system-x86 1:2.3+dfsg-6a + linux-image-4.1.0-1-amd64 4.1.3-1
(*) As alternatives to using the attached binary you can:
- Compile it from Wine's source. See:
https://source.winehq.org/git/wine.git/
- Or download the latest WineTest binary from
https://test.winehq.org/builds/winetest-latest.exe
And extract the mmdevapi_test.exe from there:
winetest.exe -x tests
tests\mmdevapi_test.exe capture
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1499908/+subscriptions
[Qemu-devel] [Bug 1119861] Re: Poor console performance in Windows 7
It does seem to be ok now. The test did get simplified to remove parts that were mostly redundant so it runs faster now. But still it now takes the same time, 7 seconds, on the VMware and QEMU Windows 7 VMs. So as far as I'm concerned this can be closed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119861 Title: Poor console performance in Windows 7 Status in QEMU: Incomplete Bug description: As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver 147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver 145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119861/+subscriptions
[Qemu-devel] [Bug 1119686] Re: Incorrect handling of icebp
Actually this got fixed by the following Linux kernel commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd2a445a94d2ab6b39fb623dc02fee48d01a565a commit fd2a445a94d2ab6b39fb623dc02fee48d01a565a (patch) KVM: VMX: Advance rip to after an ICEBP instruction When entering an exception after an ICEBP, the saved instruction pointer should point to after the instruction. This fixes the bug here: https://bugs.launchpad.net/qemu/+bug/1119686 Signed-off-by: Huw Davies Reviewed-by: Jan Kiszka Signed-off-by: Marcelo Tosatti ** Changed in: qemu Status: Expired => 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/1119686 Title: Incorrect handling of icebp Status in QEMU: Fix Released Bug description: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
[Bug 1658141] Re: QEMU's default msrs handling causes Windows 10 64 bit to crash
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. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658141 Title: QEMU's default msrs handling causes Windows 10 64 bit to crash Status in QEMU: New Bug description: 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: 0xf803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xf803cb3c0c5c 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658141/+subscriptions
[Bug 1658141] Re: QEMU's default msrs handling causes Windows 10 64 bit to crash
The bug is still present so changing the status back to New. ** Changed in: qemu Status: Expired => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658141 Title: QEMU's default msrs handling causes Windows 10 64 bit to crash Status in QEMU: New Bug description: 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: 0xf803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xf803cb3c0c5c 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1658141/+subscriptions
