On Sun, Apr 28, 2013 at 12:20:38PM +0200, Jan Kiszka wrote: > On 2013-02-23 22:35, Jan Kiszka wrote: > > From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > > > > Likely a typo, but a fatal one as kvm_set_cr0 performs checks on the > > state transition that may prevent loading L1's cr0. > > > > Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > > --- > > arch/x86/kvm/vmx.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > > index 26d47e9..94f3b66 100644 > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -7429,7 +7429,7 @@ static void load_vmcs12_host_state(struct kvm_vcpu *vcpu, > > * fpu_active (which may have changed). > > * Note that vmx_set_cr0 refers to efer set above. > > */ > > - kvm_set_cr0(vcpu, vmcs12->host_cr0); > > + vmx_set_cr0(vcpu, vmcs12->host_cr0); > > /* > > * If we did fpu_activate()/fpu_deactivate() during L2's run, we need > > * to apply the same changes to L1's vmcs. We just set cr0 correctly, > > > > This one still applies, is necessary for nested unrestricted guest mode, > and I'm still convinced it's an appropriate way to fix the bug. How to > proceed? > What check that is done by kvm_set_cr0() fails? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
