From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
To: Igor Mammedov <imammedo@redhat.com>, linux-kernel@vger.kernel.org
Cc: joro@8bytes.org, pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH] kvm: svm: reset mmu on VCPU reset
Date: Mon, 21 Sep 2015 10:14:56 +0800 [thread overview]
Message-ID: <55FF6820.5040406@linux.intel.com> (raw)
In-Reply-To: <1442583545-266967-1-git-send-email-imammedo@redhat.com>
On 09/18/2015 09:39 PM, Igor Mammedov wrote:
> When INIT/SIPI sequence is sent to VCPU which before that
> was in use by OS, VMRUN might fail with:
>
> KVM: entry failed, hardware error 0xffffffff
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=000006d3
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =9a00 0009a000 0000ffff 00009a00
> [...]
> CR0=60000010 CR2=b6f3e000 CR3=01942000 CR4=000007e0
> [...]
> EFER=0000000000000000
>
> with corresponding SVM error:
> KVM: FAILED VMRUN WITH VMCB:
> [...]
> cpl: 0 efer: 0000000000001000
> cr0: 0000000080010010 cr2: 00007fd7fe85bf90
> cr3: 0000000187d0c000 cr4: 0000000000000020
> [...]
>
> What happens is that VCPU state right after offlinig:
> CR0: 0x80050033 EFER: 0xd01 CR4: 0x7e0
> -> long mode with CR3 pointing to longmode page tables
>
> and when VCPU gets INIT/SIPI following transition happens
> CR0: 0 -> 0x60000010 EFER: 0x0 CR4: 0x7e0
> -> paging disabled with stale CR3
>
> However SVM under the hood puts VCPU in Paged Real Mode*
> which effectively translates CR0 0x60000010 -> 80010010 after
>
> svm_vcpu_reset()
> -> init_vmcb()
> -> kvm_set_cr0()
> -> svm_set_cr0()
>
> but from kvm_set_cr0() perspective CR0: 0 -> 0x60000010
> only caching bits are changed and
> commit d81135a57aa6
> ("KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed")'
> regressed svm_vcpu_reset() which relied on MMU being reset.
>
> As result VMRUN after svm_vcpu_reset() tries to run
> VCPU in Paged Real Mode with stale MMU context (longmode page tables),
> which causes some AMD CPUs** to bail out with VMEXIT_INVALID.
>
> Fix issue by unconditionally resetting MMU context
> at init_vmcb() time.
>
> --
> * AMD64 Architecture Programmer’s Manual,
> Volume 2: System Programming, rev: 3.25
> 15.19 Paged Real Mode
> ** Opteron 1216
>
Good catch and nice analysis. Thanks for your fix, Igor!
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
prev parent reply other threads:[~2015-09-21 2:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 13:39 [PATCH] kvm: svm: reset mmu on VCPU reset Igor Mammedov
2015-09-18 14:50 ` Paolo Bonzini
2015-09-21 2:14 ` Xiao Guangrong [this message]
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=55FF6820.5040406@linux.intel.com \
--to=guangrong.xiao@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=joro@8bytes.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.