public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ben Hutchings <ben@decadent.org.uk>
Subject: Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.10
Date: Thu, 19 Mar 2015 20:58:15 +0100	[thread overview]
Message-ID: <550B2A57.4090406@canonical.com> (raw)
In-Reply-To: <550942ED.4040809@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

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
>> @@ -2953,8 +2953,11 @@ static __init int adjust_vmx_controls(u32 ctl_min, u32 ct
>>         ctl |= vmx_msr_low;  /* bit == 1 in low word  ==> must be one  */
>>
>>         /* Ensure minimum (required) set of control bits are supported. */
>> -       if (ctl_min & ~ctl)
>> +       if (ctl_min & ~ctl) {
>> +               printk(KERN_ERR "vmx: msr(%08x) does not match requirements. "
>> +                               "req=%08x cur=%08x\n", msr, ctl_min, ctl);
>>                 return -EIO;
>> +       }
>>
>>         *result = ctl;
>>         return 0;
> 
> Yes, this is nice.  Maybe -ENODEV.
> 
> Also, a minimal patch for Ubuntu would probably be:
> 
> @@ -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 CONFIG_X86_64
>  	min |= VM_EXIT_HOST_ADDR_SPACE_SIZE;
>  #endif
> 
> but I don't think it's a good idea to add it to stable kernels.

Sorry, I got a bit confused on my assumptions. While the change above causes
guests to fail but the statement to say this is caused by host kernels before
this change was against better knowledge and wrong.

The actual range was hosts running 3.2 which (maybe not perfect but at least
well enough) allowed to use nested vmx for guest kernel <3.15 will break. But
running 3.13 on the host has no issues.

Comparing the rdmsr values of guests between those two host kernels, I found
that on 3.2 the exit control msr was very sparsely initialized. And looking at
the changes between 3.2 and 3.13 I found

commit 33fb20c39e98b90813b5ab2d9a0d6faa6300caca
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Wed Mar 6 15:44:03 2013 +0100

    KVM: nVMX: Fix content of MSR_IA32_VMX_ENTRY/EXIT_CTLS

This was added in 3.10. So the range of kernels affected <3.10 back to when
nested vmx became somewhat usable. For 3.2 Ben (and obviously us) would be
affected. Apart from that, I believe, it is only 3.4 which has an active
longterm. At least that change looks safer for stable as it sounds like
correcting things and not adding a feature. I was able to cherry-pick that into
a 3.2 kernel and then a 3.16 guest successfully can load the kvm-intel module
again, of course with the same shortcomings as before.

-Stefan
> 
> Paolo
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2015-03-19 19:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18  8:46 regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15 Stefan Bader
2015-03-18  9:18 ` Paolo Bonzini
2015-03-18  9:59   ` Stefan Bader
2015-03-18 10:27     ` Paolo Bonzini
2015-03-18 10:30       ` Stefan Bader
2015-03-19 19:58   ` Stefan Bader [this message]
2015-03-19 20:08     ` regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.10 Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550B2A57.4090406@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=ben@decadent.org.uk \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox