i Avi,
we currently try to integrate this patch for an update into a 2.6.32 based
system (amongst other kvm updates). But as soon as this patch gets added kvm
will die on startup in kvm_leave_lazy_mmu. This has been documented here:
Avi Kivity wrote:
On 03/06/2010 03:53 PM, Stefan Bader wrote:
i Avi,
we currently try to integrate this patch for an update into a 2.6.32
based
system (amongst other kvm updates). But as soon as this patch gets
added kvm
will die on startup in kvm_leave_lazy_mmu. This has been documented
Avi Kivity wrote:
On 03/08/2010 04:10 PM, Stefan Bader wrote:
Avi Kivity wrote:
On 03/06/2010 03:53 PM, Stefan Bader wrote:
i Avi,
we currently try to integrate this patch for an update into a 2.6.32
based
system (amongst other kvm updates). But as soon as this patch gets
added
Avi Kivity wrote:
On 03/08/2010 04:10 PM, Stefan Bader wrote:
Avi Kivity wrote:
On 03/06/2010 03:53 PM, Stefan Bader wrote:
i Avi,
we currently try to integrate this patch for an update into a 2.6.32
based
system (amongst other kvm updates). But as soon as this patch gets
added
CC: sta...@kernel.org
Reported-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Tested-by: Stefan Bader stefan.ba...@canonical.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 703f637..bf5c83f 100644
--- a/arch/x86/kvm/x86.c
+++ b
On 06.08.2012 16:40, Stefan Bader wrote:
On 05.08.2012 11:18, Avi Kivity wrote:
On 08/03/2012 01:57 PM, Stefan Bader wrote:
No, you're backporting the entire feature. All we need is to expose
RDPMC intercept to the guest.
Oh well, I thought that was the thing you asked for...
Sorry
I have been looking at a report[1] about the kvm_intel module failing to load on
linux v3.3 and newer guests when running on a v3.2 host. Bisection turned up the
following patch:
commit fee84b079d5ddee2247b5c1f53162c330c622902
Author: Avi Kivity a...@redhat.com
Date: Thu Nov 10 14:57:25 2011
On 01.08.2012 16:08, Avi Kivity wrote:
On 08/01/2012 04:39 PM, Gleb Natapov wrote:
On Wed, Aug 01, 2012 at 01:29:11PM +0200, Stefan Bader wrote:
I have been looking at a report[1] about the kvm_intel module failing to
load on
linux v3.3 and newer guests when running on a v3.2 host. Bisection
I started to pick #7 (#6 is in to have things in-sync between
SVM and VMX). Most other patches then were needed as dependencies.
The only difference here is #2 which I found being applied together
with #1 (which is a dependency). Since #2 is rather change to add
support than to fix a bug it was
From: Avi Kivity a...@redhat.com
commit 00b27a3efb116062ca5a276ad5cb01ea1b80b5f6 upstream
The cpuid code has grown; put it into a separate file.
Signed-off-by: Avi Kivity a...@redhat.com
BugLink: http://bugs.launchpad.net/bugs/960466
(cherry picked from commit
From: Liu, Jinsong jinsong@intel.com
commit fb215366b3c7320ac25dca766a0152df16534932 upstream
Intel latest cpu add 6 new features, refer http://software.intel.com/file/36945
The new feature cpuid listed as below:
1. FMA CPUID.EAX=01H:ECX.FMA[bit 12]
2. MOVBE
://bugs.launchpad.net/bugs/1031090
(cherry-picked from commit 332b56e4841ef62db4dbf1b4b92195575e1c7338 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/kvm/svm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
: http://bugs.launchpad.net/bugs/1031090
(cherry-picked from commit 022cd0e84020eec8b589bc119699c935c7b29584 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/x86.c | 15 +++
2 files changed, 16
://bugs.launchpad.net/bugs/1031090
(cherry-picked from fee84b079d5ddee2247b5c1f53162c330c622902 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/kvm/vmx.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm
-by: Gleb Natapov g...@redhat.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity a...@redhat.com
BugLink: http://bugs.launchpad.net/bugs/1031090
(backported from commit f5132b01386b5a67f1ff673bb2b96a507a3f7e41 upstream)
Signed-off-by: Stefan Bader stefan.ba
://bugs.launchpad.net/bugs/1031090
(cherry-picked from commit 893420822192f717af6fde927c9e78c9b82f8327 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/kvm/lapic.c |2 +-
arch/x86/kvm/lapic.h |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm
2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 10 Nov 2011 14:57:25 +0200
Subject: [PATCH] KVM: VMX: Fake intercept RDPMC
Based on commit fee84b079d5ddee2247b5c1f53162c330c622902 upstream.
Intercept RDPMC and forward it to the PMU emulation code.
But drop the requirement
that? It is probably wrong again, but at least it
allows to load the kvm-intel module from within a nested guest
and not having the feature pretend to fail seems the closest
thing to do...
---
From 0aeb99348363b7aeb2b0bd92428cb212159fa468 Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
On 05.08.2012 11:18, Avi Kivity wrote:
On 08/03/2012 01:57 PM, Stefan Bader wrote:
No, you're backporting the entire feature. All we need is to expose
RDPMC intercept to the guest.
Oh well, I thought that was the thing you asked for...
Sorry for being unclear.
It should be sufficient
-by: Marcelo Tosatti mtosa...@redhat.com
(backported from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h |2 ++
arch/x86/kvm/x86.c | 22 ++
2 files
Resubmitting with more of the proper maintainers
subscribed (note that Marcelo is one of them)...
---
The following patches fix a KVM guest hang/crash on 32bit guests
which is present sicne 2.6.32. It was fixed upstream (v3.3) and
for 3.2.y the upstream versions do apply. Moving back in history
-by: Marcelo Tosatti mtosa...@redhat.com
(cherry-picked from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h |3 +++
arch/x86/kvm/x86.c | 23 +++
2 files
c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h | 13 +
arch/x86/kvm/emulate.c | 51
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/x86
c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h | 13 +
arch/x86/kvm/emulate.c | 51
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include
-by: Marcelo Tosatti mtosa...@redhat.com
(cherry-picked from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h |3 +++
arch/x86/kvm/x86.c | 23 +++
2 files
c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/include/asm/kvm_emulate.h | 13
arch/x86/kvm/emulate.c | 57 ++-
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 23.03.2012 01:07, Marcelo Tosatti wrote:
On Thu, Mar 22, 2012 at 09:50:42AM +0100, Stefan Bader wrote:
From 69712f0c7cbb6363f7b2170fba93945a72d77712 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stephan=20B=C3=A4rwolf?=
stephan.baerw...@tu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 23.03.2012 18:22, Greg KH wrote:
On Thu, Mar 22, 2012 at 09:50:43AM +0100, Stefan Bader wrote:
From eaee58e1433e1b16e686cfcdcbc207d4310a239f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stephan=20B=C3=A4rwolf?=
stephan.baerw...@tu-ilmenau.de Date
With current 3.11 kernels we got reports of nested qemu failing in weird ways. I
believe 3.10 also had issues before. Not sure whether those were the same.
With 3.8 based kernels (close to current stable) I found no such issues.
It is possible to reproduce things with the following setup:
Host
On 03.09.2013 20:13, Gleb Natapov wrote:
On Tue, Sep 03, 2013 at 03:19:27PM +0200, Stefan Bader wrote:
With current 3.11 kernels we got reports of nested qemu failing in weird
ways. I
believe 3.10 also had issues before. Not sure whether those were the same.
With 3.8 based kernels (close
Hi Peter,
I am currently looking at a weird issue that manifest itself when trying to run
kvm enabled qemu on a i386 host (v3.13 kernel, oh and potentially important the
cpu is 64bit capable, so qemu-system-x86_64 is called). Sooner or later this
causes softlockup messages on the host. I tracked
On 11.02.2014 20:45, Peter Zijlstra wrote:
On Tue, Feb 11, 2014 at 07:34:51PM +0100, Stefan Bader wrote:
Hi Peter,
I am currently looking at a weird issue that manifest itself when trying to
run
kvm enabled qemu on a i386 host (v3.13 kernel, oh and potentially important
the
cpu is 64bit
On 12.02.2014 11:40, Borislav Petkov wrote:
On Wed, Feb 12, 2014 at 11:37:13AM +0100, Peter Zijlstra wrote:
Another reporter also saw this on an AMD and said it could not be
reproduced on
the same hardware and the same software versions when using 64bit instead
of 32.
In my case on a
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited to 8 (for the 32bit kernel). So the default apic driver is used.
Since
default_send_IPI_mask_logical
On 13.02.2014 19:25, Peter Zijlstra wrote:
On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited
On 13.02.2014 19:25, Peter Zijlstra wrote:
On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited
On 14.02.2014 16:21, Borislav Petkov wrote:
Oh, and just in case this is relatively easy to reproduce and in case we
don't have any other idea, bisection might be another option. I'm not
saying you should do it right away - I'm just putting it on the table...
:-)
:-)
Oh yeah, bisection
On 14.02.2014 15:47, Borislav Petkov wrote:
On Fri, Feb 14, 2014 at 03:24:09PM +0100, Stefan Bader wrote:
Actually, this code just makes so much more sense if I let objdump do
relocation info...
Ok, we're pretty sure you have an MFENCE there in resched_task but can
you confirm it please
On 14.02.2014 18:33, Borislav Petkov wrote:
On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu info.
And
there is a mfence in the disassembly:
Btw, I just realized booting the kernel in the guest was a dumb
On 14.02.2014 19:23, Stefan Bader wrote:
On 14.02.2014 18:33, Borislav Petkov wrote:
On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu
info. And
there is a mfence in the disassembly:
Btw, I just realized
On 14.02.2014 18:21, Peter Zijlstra wrote:
On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
One thing I likely should do is to reinstall the exact same laptop with 64bit
kernel and userspace... maybe only 64bit kernel first... and make sure on my
side that this does not show up
Hi,
I was looking at a bug report[1] about a regression on nested VMX that started
with kernel v3.13 (same issue still existed with v3.14-rc4). The problem shows
up when running a v3.13 kernel in L0 and then trying to launch a L2 (L1 was
either a v3.2 kernel or v3.13, so seemed to have no
On 26.02.2014 21:25, Paolo Bonzini wrote:
Il 26/02/2014 20:43, Stefan Bader ha scritto:
Hi,
I was looking at a bug report[1] about a regression on nested VMX that
started
with kernel v3.13 (same issue still existed with v3.14-rc4). The problem
shows
up when running a v3.13 kernel in L0
On 24.03.2014 18:39, Paolo Bonzini wrote:
Il 20/02/2014 16:50, Peter Zijlstra ha scritto:
One thing I likely should do is to reinstall the exact same laptop
with 64bit
kernel and userspace... maybe only 64bit kernel first... and make
sure
on my
side that this does not show up on
On 18.03.2015 11:27, Paolo Bonzini wrote:
On 18/03/2015 10:59, Stefan Bader wrote:
@@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct
vmcs_config *vmcs_conf) vmx_capability.ept,
vmx_capability.vpid); }
- min = 0; + min = VM_EXIT_SAVE_DEBUG_CONTROLS; #ifdef
Someone reported[1] that some of their L1 guests fail to load the kvm-intel
module (without much details). Turns out that this was (at least) caused by
KVM: vmx: Allow the guest to run with dirty debug registers
as this adds VM_EXIT_SAVE_DEBUG_CONTROLS to the required MSR_IA32_VMX_EXIT_CTLS
On 18.03.2015 10:18, Paolo Bonzini wrote:
On 18/03/2015 09:46, Stefan Bader wrote:
Regardless of that, I wonder whether the below (this version untested) sound
acceptable for upstream? At least it would make debugging much simpler. :)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
On 18.03.2015 10:18, Paolo Bonzini wrote:
On 18/03/2015 09:46, Stefan Bader wrote:
Regardless of that, I wonder whether the below (this version untested) sound
acceptable for upstream? At least it would make debugging much simpler. :)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
48 matches
Mail list logo
