> Am 18.08.2015 um 17:25 schrieb Radim Krčmář :
>
> 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:
Am 14.08.2015 um 22:01 schrieb Alex Bennée:
Peter Lieven 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 after some live
Am 14.08.2015 um 22:01 schrieb Alex Bennée:
Peter Lieven 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 after some live
Am 14.08.2015 um 15:01 schrieb Paolo Bonzini:
>
> - Original Message -
>> From: "Peter Lieven"
>> To: qemu-de...@nongnu.org, kvm@vger.kernel.org
>> Cc: "Paolo Bonzini"
>> Sent: Friday, August 14, 2015 1:11:34 PM
>> Subject: Help d
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 my
Am 12.01.2014 um 13:08 schrieb Vadim Rozenfeld :
> 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:
>
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 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
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 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
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:38P
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
>>> Signed-off: Gleb Natapov
>>> Signed-off: Vad
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
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
>> Signed-off: Gleb Natapov
>> Signed-off: Vadim Rozenfeld
>>
>> v1 -> v2
>> 1. mark TSC page dirty as sugges
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 lik
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 in
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 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"
To: "Paolo Bonzini"
Cc: "Vadim Roze
On 23.05.2013 15:18, Paolo Bonzini wrote:
Il 23/05/2013 14:25, Vadim Rozenfeld ha scritto:
- Original Message -
From: "Peter Lieven"
To: "Paolo Bonzini"
Cc: "Vadim Rozenfeld" , "Marcelo Tosatti"
, kvm@vger.kernel.org, g...@redhat.com, p...@d
On 23.05.2013 14:33, Vadim Rozenfeld wrote:
- Original Message -
From: "Peter Lieven"
To: "Marcelo Tosatti"
Cc: "Vadim Rozenfeld" , kvm@vger.kernel.org,
g...@redhat.com, p...@dlh.net
Sent: Thursday, May 23, 2013 4:18:55 PM
Subject: Re: [RFC PATCH v
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)
if
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"
To: "Vadim Rozenfeld"
Cc: kvm@vger.kernel.org, g...@redhat.com, p...@dlh.net
Sent: Wednesday, May 22, 2013 10:50:46 AM
Subject: Re
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;
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
Signed-off: Gleb Natapov
Signed-off: Vadim Rozenfeld
The following patch allows to activate Hyper-V
reference time counter
---
arch/x86/include/asm/kvm_host.h| 2 ++
arch/x86/include/uapi/asm/hyperv.h | 3
On 19.11.2012 18:20, Stefan Hajnoczi wrote:
On Thu, Nov 8, 2012 at 4:26 PM, Peter Lieven 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 else is able
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 wrote:
>> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
>> wrote:
>>> About half a year there was an issue where re
Am 31.10.2012 um 15:08 schrieb ronnie sahlberg:
> On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi wrote:
>> On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg
>> wrote:
>>> About half a year there was an issue where recent kernels had added
>>> support to start using new scsi opcodes, but the
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven 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 is a
different
Am 30.10.2012 19:27, schrieb Stefan Hajnoczi:
On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven 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 is a
different
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
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
Hi,
kvm-kmod 3.6 fails to compile against a 3.2.0 kernel with the following error:
/usr/src/kvm-kmod-3.6/x86/x86.c: In function ‘get_msr_mce’:
/usr/src/kvm-kmod-3.6/x86/x86.c:1908:27: error: ‘kvm’ undeclared (first use in
this function)
/usr/src/kvm-kmod-3.6/x86/x86.c:1908:27: note: each undecla
Am 02.10.2012 um 12:40 schrieb Orit Wasserman:
> On 10/02/2012 11:30 AM, Peter Lieven wrote:
>>
>> 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:
>>>>&
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 i
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
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 with
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_
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
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
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?
T
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: 0xc1
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 "unsu
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 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 wh
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 if
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 if
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 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/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 be
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 08/21/12 10:23, Stefan Hajnoczi wrote:
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka 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 that env->stop is evaluate
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 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 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 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 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
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 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)
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
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 th
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 in
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
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 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 that
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 that
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.201
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
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
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-0.13.0).
Has anyone a clue which new KVM feature could cause this if a vcpu is in
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
tap,vlan=141,script=no,downscript=no,ifname=tap15,vn
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 Lieven wrote:
On 11.02.2012 09:55, Corentin Chary wrote:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
Hi,
is anyone aware if there are still problems
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 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])) -
__builtin_of
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 majord...@vger.kernel.
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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 add to cpu
definition in XML and check command line
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 add to cpu
definition in XML and check command line.
ok I try this but I can't use to map the host cpu
(my libvirt is 0.9.8) so I use :
Opt
On 11.02.2012 09:55, Corentin Chary wrote:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven 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]: segfault at
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 is
On 28.02.2012 13:05, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 11:46 AM, Peter Lieven wrote:
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi
wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi
wrote:
On Thu, Feb 23, 2012 at 7:08 PM
On 28.02.2012 09:37, Corentin Chary wrote:
On Mon, Feb 13, 2012 at 10:24 AM, Peter Lieven wrote:
Am 11.02.2012 um 09:55 schrieb Corentin Chary:
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
Hi,
is anyone aware if there are still problems when enabling the threaded vnc
server?
I saw
On 24.02.2012 08:23, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi wrote:
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
Stefan Hajnoczi schrieb:
On Thu, Feb 23, 2012 at 3:40 PM, Peter
noczi schrieb:
>>>>
>>>>> On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
>>>>>> However, in a virtual machine I have not observed the above slow down
>>>>> to
>>>>>> that extend
>>>>>> while the b
1 - 100 of 216 matches
Mail list logo
