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
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.
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
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
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
** 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.
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
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:
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'
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
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
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
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
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
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+
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
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
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
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
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
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
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
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
23 matches
Mail list logo
