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
Date: Thu Nov 10 14:57:25 2011 +0200
KVM: VM
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
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 app
From: Avi Kivity
commit 00b27a3efb116062ca5a276ad5cb01ea1b80b5f6 upstream
The cpuid code has grown; put it into a separate file.
Signed-off-by: Avi Kivity
BugLink: http://bugs.launchpad.net/bugs/960466
(cherry picked from commit 00b27a3efb116062ca5a276ad5cb01ea1b80b5f6)
Signed-off-by: Tim Gar
From: "Liu, Jinsong"
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. MOVBECPUID.EAX=01H:ECX.MOVBE[bit 22]
3. B
332b56e4841ef62db4dbf1b4b92195575e1c7338 upstream)
Signed-off-by: Stefan Bader
---
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
index 94a4672..e385214 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
commit 022cd0e84020eec8b589bc119699c935c7b29584 upstream)
Signed-off-by: Stefan Bader
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/x86.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm
fee84b079d5ddee2247b5c1f53162c330c622902 upstream)
Signed-off-by: Stefan Bader
---
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/vmx.c
index 114fe29..bcd59a9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
Natapov
Signed-off-by: Jan Kiszka
Signed-off-by: Avi Kivity
BugLink: http://bugs.launchpad.net/bugs/1031090
(backported from commit f5132b01386b5a67f1ff673bb2b96a507a3f7e41 upstream)
Signed-off-by: Stefan Bader
---
arch/x86/include/asm/kvm_host.h | 48
arch/x86/kvm/Kconfig|1
893420822192f717af6fde927c9e78c9b82f8327 upstream)
Signed-off-by: Stefan Bader
---
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/lapic.c b/arch/x86/kvm/lapic.c
index a7f3e65..cfdc6e0 100644
--- a/arch/x86/kvm
9fa468 Mon Sep 17 00:00:00 2001
From: Stefan Bader
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 f
about 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
Da
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...
>
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.
>>>
>>
Signed-off-by: Marcelo Tosatti
(backported from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader
---
arch/x86/include/asm/kvm_emulate.h |2 ++
arch/x86/kvm/x86.c | 22 ++
2 files changed, 24 insertions(+), 0 deletions(-
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
s
igned-off-by: Marcelo Tosatti
(cherry-picked from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader
---
arch/x86/include/asm/kvm_emulate.h |3 +++
arch/x86/kvm/x86.c | 23 +++
2 files changed, 26 insertions(+), 0 deleti
27;s documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf
Signed-off-by: Marcelo Tosatti
(cherry-picked from commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-o
s documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf
Signed-off-by: Marcelo Tosatti
(backported from commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-o
igned-off-by: Marcelo Tosatti
(cherry-picked from commit bdb42f5afebe208eae90406959383856ae2caf2b upstream)
Signed-off-by: Stefan Bader
---
arch/x86/include/asm/kvm_emulate.h |3 +++
arch/x86/kvm/x86.c | 23 +++
2 files changed, 26 insertions(+), 0 deleti
s documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf
Signed-off-by: Marcelo Tosatti
(backported from commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream)
Signed-o
-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?=
>
-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?=
>> D
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:
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/531823
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 d
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 int
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 int
Stefan Bader wrote:
> 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,
>>>>>
>>>>&g
= 00129161
> Oops: 0003 [#1] SMP
>
> CC: sta...@kernel.org
> Reported-by: Stefan Bader
> Signed-off-by: Marcelo Tosatti
Tested-by: Stefan Bader
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 703f637..bf5c83f 100644
> --- a/arch/x86/kvm/x8
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 64b
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.
>
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
bits.
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. :)
>>
>>
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); }
>>>
>>>
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. :)
>>
>>
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 t
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
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
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
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 CONF
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 CONF
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, bi
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_tas
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
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 mfe
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
>> si
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 immediat
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
&g
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
>
49 matches
Mail list logo
