Am 14.08.2015 um 22:01 schrieb Alex Bennée:
Peter Lieven p...@kamp.de writes:
Hi,
some time a go I stumbled across a regression in the KVM Module that has been
introduced somewhere
between 3.17 and 3.19.
I have a rather old openSUSE guest with an XFS filesystem which realiably
crashes
Am 18.08.2015 um 17:25 schrieb Radim Krčmář rkrc...@redhat.com:
2015-08-18 16:54+0200, Peter Lieven:
After some experiments I was able to find out the bad commit that introduced
the regression:
commit f30ebc312ca9def25650b4e1d01cdb425c310dca
Author: Radim Krčmář rkrc...@redhat.com
Am 14.08.2015 um 22:01 schrieb Alex Bennée:
Peter Lieven p...@kamp.de writes:
Hi,
some time a go I stumbled across a regression in the KVM Module that has been
introduced somewhere
between 3.17 and 3.19.
I have a rather old openSUSE guest with an XFS filesystem which realiably
crashes
Hi,
some time a go I stumbled across a regression in the KVM Module that has been
introduced somewhere
between 3.17 and 3.19.
I have a rather old openSUSE guest with an XFS filesystem which realiably
crashes after some live migrations.
I originally believed that the issue might be related to
Am 14.08.2015 um 15:01 schrieb Paolo Bonzini:
- Original Message -
From: Peter Lieven p...@kamp.de
To: qemu-de...@nongnu.org, kvm@vger.kernel.org
Cc: Paolo Bonzini pbonz...@redhat.com
Sent: Friday, August 14, 2015 1:11:34 PM
Subject: Help debugging a regression in KVM Module
Hi
Am 12.01.2014 um 13:08 schrieb Vadim Rozenfeld vroze...@redhat.com:
On Wed, 2014-01-08 at 23:20 +0100, Peter Lieven wrote:
Am 08.01.2014 21:08, schrieb Vadim Rozenfeld:
On Wed, 2014-01-08 at 15:54 +0100, Peter Lieven wrote:
On 08.01.2014 13:12, Vadim Rozenfeld wrote:
On Wed, 2014-01-08
On 08.01.2014 10:40, Vadim Rozenfeld wrote:
On Tue, 2014-01-07 at 18:52 +0100, Peter Lieven wrote:
Am 07.01.2014 10:36, schrieb Vadim Rozenfeld:
On Thu, 2014-01-02 at 17:52 +0100, Peter Lieven wrote:
Am 11.12.2013 19:59, schrieb Marcelo Tosatti:
On Wed, Dec 11, 2013 at 04:53:05PM -0200
On 08.01.2014 11:44, Vadim Rozenfeld wrote:
On Wed, 2014-01-08 at 11:15 +0100, Peter Lieven wrote:
On 08.01.2014 10:40, Vadim Rozenfeld wrote:
On Tue, 2014-01-07 at 18:52 +0100, Peter Lieven wrote:
Am 07.01.2014 10:36, schrieb Vadim Rozenfeld:
On Thu, 2014-01-02 at 17:52 +0100, Peter Lieven
On 08.01.2014 13:12, Vadim Rozenfeld wrote:
On Wed, 2014-01-08 at 12:48 +0100, Peter Lieven wrote:
On 08.01.2014 11:44, Vadim Rozenfeld wrote:
On Wed, 2014-01-08 at 11:15 +0100, Peter Lieven wrote:
On 08.01.2014 10:40, Vadim Rozenfeld wrote:
On Tue, 2014-01-07 at 18:52 +0100, Peter Lieven
Am 08.01.2014 21:08, schrieb Vadim Rozenfeld:
On Wed, 2014-01-08 at 15:54 +0100, Peter Lieven wrote:
On 08.01.2014 13:12, Vadim Rozenfeld wrote:
On Wed, 2014-01-08 at 12:48 +0100, Peter Lieven wrote:
On 08.01.2014 11:44, Vadim Rozenfeld wrote:
On Wed, 2014-01-08 at 11:15 +0100, Peter Lieven
Am 07.01.2014 10:36, schrieb Vadim Rozenfeld:
On Thu, 2014-01-02 at 17:52 +0100, Peter Lieven wrote:
Am 11.12.2013 19:59, schrieb Marcelo Tosatti:
On Wed, Dec 11, 2013 at 04:53:05PM -0200, Marcelo Tosatti wrote:
On Sun, Dec 08, 2013 at 10:33:38PM +1100, Vadim Rozenfeld wrote:
Signed-off
Am 11.12.2013 19:53, schrieb Marcelo Tosatti:
On Sun, Dec 08, 2013 at 10:33:38PM +1100, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g...@redhat.com
Signed-off: Vadim Rozenfeld vroze...@redhat.com
v1 - v2
1. mark TSC page dirty as suggested
Am 02.01.2014 14:57, schrieb Marcelo Tosatti:
On Thu, Jan 02, 2014 at 02:15:48PM +0100, Peter Lieven wrote:
Am 11.12.2013 19:53, schrieb Marcelo Tosatti:
On Sun, Dec 08, 2013 at 10:33:38PM +1100, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g
Am 11.12.2013 19:59, schrieb Marcelo Tosatti:
On Wed, Dec 11, 2013 at 04:53:05PM -0200, Marcelo Tosatti wrote:
On Sun, Dec 08, 2013 at 10:33:38PM +1100, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g...@redhat.com
Signed-off: Vadim Rozenfeld vroze
On 07.10.2013 11:55, Paolo Bonzini wrote:
Il 07/10/2013 11:49, Peter Lieven ha scritto:
It's in general not easy to do this if you take non-x86 targets into
account.
What about the dirty way to zero out all non zero pages at the beginning of
ram_load?
I'm not sure I follow?
sth like
On 06.10.2013 15:57, Zhang Haoyu wrote:
From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later in the history this commit was reverted, and again broke
this. The other commit that fixes this
On 07.10.2013 11:37, Paolo Bonzini wrote:
Il 07/10/2013 08:38, Peter Lieven ha scritto:
On 06.10.2013 15:57, Zhang Haoyu wrote:
From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later
On 22.05.2013 23:55, Paolo Bonzini wrote:
Il 22/05/2013 09:32, Vadim Rozenfeld ha scritto:
@@ -1827,6 +1829,29 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32
msr, u64 data)
if (__copy_to_user((void __user *)addr, instructions, 4))
return 1;
On 22.05.2013 23:23, Marcelo Tosatti wrote:
On Wed, May 22, 2013 at 03:22:55AM -0400, Vadim Rozenfeld wrote:
- Original Message -
From: Marcelo Tosatti mtosa...@redhat.com
To: Vadim Rozenfeld vroze...@redhat.com
Cc: kvm@vger.kernel.org, g...@redhat.com, p...@dlh.net
Sent: Wednesday,
On 23.05.2013 11:54, Paolo Bonzini wrote:
Il 23/05/2013 08:17, Peter Lieven ha scritto:
On 22.05.2013 23:55, Paolo Bonzini wrote:
Il 22/05/2013 09:32, Vadim Rozenfeld ha scritto:
@@ -1827,6 +1829,29 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
*vcpu, u32 msr, u64 data
On 23.05.2013 14:33, Vadim Rozenfeld wrote:
- Original Message -
From: Peter Lieven p...@dlhnet.de
To: Marcelo Tosatti mtosa...@redhat.com
Cc: Vadim Rozenfeld vroze...@redhat.com, kvm@vger.kernel.org,
g...@redhat.com, p...@dlh.net
Sent: Thursday, May 23, 2013 4:18:55 PM
Subject: Re
On 23.05.2013 15:18, Paolo Bonzini wrote:
Il 23/05/2013 14:25, Vadim Rozenfeld ha scritto:
- Original Message -
From: Peter Lieven p...@dlhnet.de
To: Paolo Bonzini pbonz...@redhat.com
Cc: Vadim Rozenfeld vroze...@redhat.com, Marcelo Tosatti
mtosa...@redhat.com, kvm@vger.kernel.org, g
On 23.05.2013 15:23, Paolo Bonzini wrote:
Il 23/05/2013 15:20, Peter Lieven ha scritto:
On 23.05.2013 15:18, Paolo Bonzini wrote:
Il 23/05/2013 14:25, Vadim Rozenfeld ha scritto:
- Original Message -
From: Peter Lieven p...@dlhnet.de
To: Paolo Bonzini pbonz...@redhat.com
Cc: Vadim
Hi all,
sorry that I am a bit unresponsive about this series. I have a few days off and
can't spend much time in this.
If I read that the REFERENCE TSC breaks migration I don't think its a good
option to include it at all.
I have this hyperv_refcnt MSR in an internal patch I sent over about 1.5
On 13.05.2013 13:45, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g...@redhat.com
Signed-off: Vadim Rozenfeld vroze...@redhat.com
The following patch allows to activate Hyper-V
reference time counter
---
arch/x86/include/asm/kvm_host.h| 2
On 19.11.2012 18:20, Stefan Hajnoczi wrote:
On Thu, Nov 8, 2012 at 4:26 PM, Peter Lieven p...@dlhnet.de wrote:
Has anyone any other idea what the cause could be or where to start?
Hi Peter,
I suggested posting the source tree you are building. Since you have
applied patches yourself no one
Has anyone any other idea what the cause could be or where to start?
Peter
Am 31.10.2012 um 15:08 schrieb ronnie sahlberg:
On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
About half
Am 31.10.2012 um 15:08 schrieb ronnie sahlberg:
On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
About half a year there was an issue where recent kernels had added
support to start
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
you are right, sorry
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi is a
different virtio device type from virtoi-blk and is not present in the
backtrace you posted.
Sounds pedantic but I
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven p...@dlhnet.de wrote:
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven p...@dlhnet.de wrote:
On 30.10.2012 09:32, Stefan Hajnoczi wrote:
On Mon, Oct 29, 2012 at 03:09:37PM +0100, Peter Lieven wrote:
Hi,
Bug subject should be virtio-blk, not virtio-scsi. virtio-scsi
Am 02.10.2012 um 11:28 schrieb Orit Wasserman:
On 10/02/2012 10:33 AM, lieven-li...@dlh.net wrote:
Orit Wasserman wrote:
On 09/16/2012 01:39 PM, Peter Lieven wrote:
Hi,
I remember that this was broken some time ago and currently with
qemu-kvm 1.2.0 I am still not able to use
block
Am 02.10.2012 um 11:38 schrieb Paolo Bonzini:
Il 16/09/2012 12:39, Peter Lieven ha scritto:
I remember that this was broken some time ago and currently with
qemu-kvm 1.2.0 I am still not able to use
block migration plus xbzrle. The migration fails if both are used
together. XBZRLE without
On 09/17/12 22:12, Peter Lieven wrote:
On 09/17/12 10:41, Kevin Wolf wrote:
Am 16.09.2012 12:13, schrieb Peter Lieven:
Hi,
when trying to block migrate a VM from one node to another, the source
VM crashed with the following assertion:
block.c:3829: bdrv_set_in_use: Assertion `bs-in_use
On 09/18/12 12:31, Kevin Wolf wrote:
Am 18.09.2012 12:28, schrieb Peter Lieven:
On 09/17/12 22:12, Peter Lieven wrote:
On 09/17/12 10:41, Kevin Wolf wrote:
Am 16.09.2012 12:13, schrieb Peter Lieven:
Hi,
when trying to block migrate a VM from one node to another, the source
VM crashed
On 09/17/12 10:41, Kevin Wolf wrote:
Am 16.09.2012 12:13, schrieb Peter Lieven:
Hi,
when trying to block migrate a VM from one node to another, the source
VM crashed with the following assertion:
block.c:3829: bdrv_set_in_use: Assertion `bs-in_use != in_use' failed.
Is this sth already
On 09/17/12 10:41, Kevin Wolf wrote:
Am 16.09.2012 12:13, schrieb Peter Lieven:
Hi,
when trying to block migrate a VM from one node to another, the source
VM crashed with the following assertion:
block.c:3829: bdrv_set_in_use: Assertion `bs-in_use != in_use' failed.
Is this sth already
Hi,
when trying to block migrate a VM from one node to another, the source
VM crashed with the following assertion:
block.c:3829: bdrv_set_in_use: Assertion `bs-in_use != in_use' failed.
Is this sth already addresses/known?
Thanks,
Peter
--
To unsubscribe from this list: send the line
Hi,
i have seen some recent threads about running Xen as guest. For me it is
still not working, but
I have read that Avi is working on some fixes. I have seen in the logs
that the following MSRs
are missing. Maybe this is related:
cpu0 unhandled rdmsr: 0xce
cpu0 disabled perfctr wrmsr:
Hi,
I remember that this was broken some time ago and currently with
qemu-kvm 1.2.0 I am still not able to use
block migration plus xbzrle. The migration fails if both are used
together. XBZRLE without block migration works.
Can someone please advise what is the current expected behaviour?
On 10.09.2012 14:32, Avi Kivity wrote:
On 09/10/2012 03:29 PM, Peter Lieven wrote:
On 09/10/12 14:21, Gleb Natapov wrote:
On Mon, Sep 10, 2012 at 02:15:49PM +0200, Paolo Bonzini wrote:
Il 10/09/2012 13:52, Peter Lieven ha scritto:
dd if=/dev/cpu/0/msr skip=$((0x194)) bs=8 count=1 | xxd
dd
On 13.09.2012 10:05, Gleb Natapov wrote:
On Thu, Sep 13, 2012 at 10:00:26AM +0200, Paolo Bonzini wrote:
Il 13/09/2012 09:57, Gleb Natapov ha scritto:
#rdmsr -0 0x194
00011100
#rdmsr -0 0xce
0c0004011103
Yes, that can help implementing it in KVM. But without a spec to
understand
On 13.09.2012 14:42, Gleb Natapov wrote:
On Thu, Sep 13, 2012 at 02:05:23PM +0200, Peter Lieven wrote:
On 13.09.2012 10:05, Gleb Natapov wrote:
On Thu, Sep 13, 2012 at 10:00:26AM +0200, Paolo Bonzini wrote:
Il 13/09/2012 09:57, Gleb Natapov ha scritto:
#rdmsr -0 0x194
00011100
#rdmsr
On 09/06/12 16:58, Avi Kivity wrote:
On 08/22/2012 06:06 PM, Peter Lieven wrote:
Hi,
has anyone ever tested to run memtest with -cpu host flag passed to
qemu-kvm?
For me it resets when probing the chipset. With -cpu qemu64 it works
just fine.
Maybe this is specific to memtest, but it might
On 09/10/12 13:29, Paolo Bonzini wrote:
Il 10/09/2012 13:06, Peter Lieven ha scritto:
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_entry: vcpu 0
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_exit: reason MSR_READ rip
0x11478 info 0 0
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_msr: msr_read 194
On 09/10/12 13:29, Paolo Bonzini wrote:
Il 10/09/2012 13:06, Peter Lieven ha scritto:
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_entry: vcpu 0
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_exit: reason MSR_READ rip
0x11478 info 0 0
qemu-kvm-1.0.1-5107 [007] 410771.148000: kvm_msr: msr_read 194
On 09/10/12 14:21, Gleb Natapov wrote:
On Mon, Sep 10, 2012 at 02:15:49PM +0200, Paolo Bonzini wrote:
Il 10/09/2012 13:52, Peter Lieven ha scritto:
dd if=/dev/cpu/0/msr skip=$((0x194)) bs=8 count=1 | xxd
dd if=/dev/cpu/0/msr skip=$((0xCE)) bs=8 count=1 | xxd
it only works without the skip
On 09/10/12 14:32, Avi Kivity wrote:
On 09/10/2012 03:29 PM, Peter Lieven wrote:
On 09/10/12 14:21, Gleb Natapov wrote:
On Mon, Sep 10, 2012 at 02:15:49PM +0200, Paolo Bonzini wrote:
Il 10/09/2012 13:52, Peter Lieven ha scritto:
dd if=/dev/cpu/0/msr skip=$((0x194)) bs=8 count=1 | xxd
dd
On 08/21/12 10:23, Stefan Hajnoczi wrote:
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszkajan.kis...@siemens.com wrote:
On 2012-08-19 11:42, Avi Kivity wrote:
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible
Hi,
has anyone ever tested to run memtest with -cpu host flag passed to
qemu-kvm?
For me it resets when probing the chipset. With -cpu qemu64 it works
just fine.
Maybe this is specific to memtest, but it might be sth that can happen
in other
applications to.
Any thoughts?
Thanks,
Peter
On 05.07.2012 10:51, Xiao Guangrong wrote:
On 06/28/2012 05:11 PM, Peter Lieven wrote:
that here is bascially whats going on:
qemu-kvm-1.0-2506 [010] 60996.908000: kvm_mmio: mmio read len 3
gpa 0xa val 0x10ff
qemu-kvm-1.0-2506 [010] 60996.908000: vcpu_match_mmio
On 07/03/12 17:54, Marcelo Tosatti wrote:
On Wed, Jun 27, 2012 at 12:35:22PM +0200, Peter Lieven wrote:
Hi,
we recently came across multiple VMs racing and stopping working. It
seems to happen when the system is at 100% cpu.
One way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
On 07/03/12 15:25, Avi Kivity wrote:
On 07/03/2012 04:15 PM, Peter Lieven wrote:
On 03.07.2012 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working
On 07/03/12 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0
of qemu-kvm 0.12.5, 1.0 or 1.0.1.
It might be that the code was introduced somewhere between 3.0.0
and 3.2.0 in the kvm kernel module and that the flaw is not
in qemu-kvm.
Any hints?
Thanks,
Peter
On 02.07.2012 17:05, Avi Kivity wrote:
On 06/28/2012 12:38 PM, Peter Lieven wrote:
does anyone know
On 03.07.2012 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0
On 02.07.2012 09:05, Jan Kiszka wrote:
On 2012-07-01 21:18, Peter Lieven wrote:
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM
On 02.07.2012 17:05, Avi Kivity wrote:
On 06/28/2012 12:38 PM, Peter Lieven wrote:
does anyone know whats that here in handle_mmio?
/* hack: Red Hat 7.1 generates these weird accesses. */
if ((addr 0xa-4 addr= 0xa) kvm_run-mmio.len == 3)
return 0;
Just what
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.
is there a description
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod-3.4 with an old userspace (qemu-kvm
On 28.06.2012 11:21, Jan Kiszka wrote:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4
does anyone know whats that here in handle_mmio?
/* hack: Red Hat 7.1 generates these weird accesses. */
if ((addr 0xa-4 addr = 0xa) kvm_run-mmio.len == 3)
return 0;
thanks,
peter
On 28.06.2012 11:31, Peter Lieven wrote:
On 28.06.2012 11:21, Jan Kiszka wrote
On 28.06.2012 11:39, Jan Kiszka wrote:
On 2012-06-28 11:31, Peter Lieven wrote:
On 28.06.2012 11:21, Jan Kiszka wrote:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out
On 28.06.2012 11:39, Jan Kiszka wrote:
On 2012-06-28 11:31, Peter Lieven wrote:
On 28.06.2012 11:21, Jan Kiszka wrote:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modify the
condition from while (ret == 0)
to while
On 28.06.2012 15:25, Jan Kiszka wrote:
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while
On 28.06.2012 17:22, Jan Kiszka wrote:
On 2012-06-28 17:02, Peter Lieven wrote:
On 28.06.2012 15:25, Jan Kiszka wrote:
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck
Hi,
we recently came across multiple VMs racing and stopping working. It
seems to happen when the system is at 100% cpu.
One way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
cmdline (or similar):
/usr/bin/qemu-kvm-1.0.1 -net
On 13.03.2012 16:06, Alexander Graf wrote:
On 13.03.2012, at 16:05, Corentin Chary wrote:
On Tue, Mar 13, 2012 at 12:29 PM, Peter Lievenp...@dlh.net wrote:
On 11.02.2012 09:55, Corentin Chary wrote:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lievenp...@dlh.net wrote:
Hi,
is anyone aware if
Hi all,
I saw the following assert after chaning display resolution. This might
be the cause, but i am not sure. Threaded VNC is enabled.
Anyone ever seen this?
qemu-kvm-1.0: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) -
On 24.04.2012 15:34, Alon Levy wrote:
On Tue, Apr 24, 2012 at 03:24:31PM +0200, Peter Lieven wrote:
Hi all,
I saw the following assert after chaning display resolution. This might be
the cause, but i am not sure. Threaded VNC is enabled.
Anyone ever seen this?
qemu-kvm-1.0: malloc.c:3096
Hi,
i was wondering if there will be a qemu-kvm version 1.0.1?
The last tag I see here is 1.0:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary
Any hints?
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 27.03.2012 19:06, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 06:16:11 PM Peter Lieven wrote:
On 27.03.2012 18:12, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 05:58:01 PM Peter Lieven wrote:
On 27.03.2012 17:44, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 04:06:13 PM
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote:
On 26.03.2012 20:36, Vadim Rozenfeld wrote:
On Monday, March 26
On 27.03.2012 12:40, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote:
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26
On 27.03.2012 12:00, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 11:26:29AM +0200, Peter Lieven wrote:
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26
On 27.03.2012 14:26, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote:
On 27.03.2012 12:00, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 11:26:29AM +0200, Peter Lieven wrote:
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM
On 27.03.2012 14:29, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote:
On 27.03.2012 14:26, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote:
On 27.03.2012 12:00, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 11:26:29AM +0200
On 27.03.2012 14:29, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote:
On 27.03.2012 14:26, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:20:23PM +0200, Peter Lieven wrote:
On 27.03.2012 12:00, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 11:26:29AM +0200
On 27.03.2012 13:43, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote:
On 27.03.2012 12:40, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote:
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM
On 27.03.2012 17:37, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 04:44:51 PM Peter Lieven wrote:
On 27.03.2012 13:43, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote:
On 27.03.2012 12:40, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 11:26:29 AM
On 27.03.2012 17:44, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 04:06:13 PM Peter Lieven wrote:
On 27.03.2012 14:29, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:28:04PM +0200, Peter Lieven wrote:
On 27.03.2012 14:26, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:20:23PM +0200
On 27.03.2012 18:12, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 05:58:01 PM Peter Lieven wrote:
On 27.03.2012 17:44, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 04:06:13 PM Peter Lieven wrote:
On 27.03.2012 14:29, Gleb Natapov wrote:
On Tue, Mar 27, 2012 at 02:28:04PM +0200
On 22.03.2012 10:38, Vadim Rozenfeld wrote:
On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote:
On 22.03.2012 09:48, Vadim Rozenfeld wrote:
On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote:
On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote:
On 21.03.2012 12:10
On 26.03.2012 20:36, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote:
On 22.03.2012 10:38, Vadim Rozenfeld wrote:
On Thursday, March 22
On 22.03.2012 08:53, Gleb Natapov wrote:
On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote:
On 21.03.2012 12:10, David Cure wrote:
hello,
Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait :
Try to addfeature policy='disable' name='hypervisor
On 22.03.2012 09:31, David Cure wrote:
Le Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven ecrivait :
please keep in mind, that setting -hypervisor, disabling hpet and only
one vcpu
makes windows use tsc as clocksource. you have to make sure, that your vm
is not switching between physical
On 22.03.2012 09:33, David Cure wrote:
Le Thu, Mar 22, 2012 at 09:53:45AM +0200, Gleb Natapov ecrivait :
All true. I asked to try -hypervisor only to verify where we loose
performance. Since you get good result with it frequent access to PM
timer is probably the reason. I do not recommend using
On 22.03.2012 09:48, Vadim Rozenfeld wrote:
On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote:
On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote:
On 21.03.2012 12:10, David Cure wrote:
hello,
Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait
On 21.03.2012 12:10, David Cure wrote:
hello,
Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait :
Try to addfeature policy='disable' name='hypervisor'/ to cpu
definition in XML and check command line.
ok I try this but I can't usecpu model to map the
On 11.02.2012 09:55, Corentin Chary wrote:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lievenp...@dlh.net wrote:
Hi,
is anyone aware if there are still problems when enabling the threaded vnc
server?
I saw some VMs crashing when using a qemu-kvm build with
--enable-vnc-thread.
qemu-kvm-1.0[22646]:
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczistefa...@gmail.com wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczistefa...@gmail.com wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.comp...@dlh.net wrote:
Stefan
On 28.02.2012 09:37, Corentin Chary wrote:
On Mon, Feb 13, 2012 at 10:24 AM, Peter Lievenp...@dlh.net wrote:
Am 11.02.2012 um 09:55 schrieb Corentin Chary:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lievenp...@dlh.net wrote:
Hi,
is anyone aware if there are still problems when enabling the
On 28.02.2012 13:05, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lievenp...@dlh.net wrote:
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczistefa...@gmail.com
wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan
On 28.02.2012 14:16, Avi Kivity wrote:
On 02/24/2012 08:41 AM, Stefan Hajnoczi wrote:
I dont think that it is cpu intense. All user pages are zeroed anyway, but at
allocation time it shouldnt be a big difference in terms of cpu power.
It's easy to find a scenario where eagerly zeroing pages
Hi,
i have recently been playing with an old idea (originally in grsecurity
for security reasons) to change
the policy from zero on allocate to zero after free in the linux page
allocator. My concern is that linux
leaves a lot of waste in the physical memory unlike Windows which per
default zeros
stefa...@gmail.com schrieb:
On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven p...@dlh.net wrote:
However, in a virtual machine I have not observed the above slow down
to
that extend
while the benefit of zero after free in a virtualisation environment
is
obvious:
1) zero pages can easily
On 20.02.2012 21:45, Gleb Natapov wrote:
On Mon, Feb 20, 2012 at 08:59:38PM +0100, Peter Lieven wrote:
On 20.02.2012 20:04, Gleb Natapov wrote:
On Mon, Feb 20, 2012 at 08:40:08PM +0200, Gleb Natapov wrote:
On Mon, Feb 20, 2012 at 07:17:55PM +0100, Peter Lieven wrote:
Hi,
I came a across
On 21.02.2012 11:56, Gleb Natapov wrote:
On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote:
I hope it will make Windows use TSC instead, but you can't be sure
about anything with Windows :(
Whatever it does now it eates more CPU has almost equal
number of exits and throughput
1 - 100 of 202 matches
Mail list logo
