From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v4 3/5] KVM: x86: clean up reexecute_instruction Date: Sat, 05 Jan 2013 15:20:24 +0800 Message-ID: <50E7D438.60709@linux.vnet.ibm.com> References: <50E6DEDC.7040800@linux.vnet.ibm.com> <50E6DF5C.2000103@linux.vnet.ibm.com> <20130104222135.GA13481@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , LKML , KVM To: Marcelo Tosatti Return-path: Received: from e28smtp02.in.ibm.com ([122.248.162.2]:43029 "EHLO e28smtp02.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754268Ab3AEHUe (ORCPT ); Sat, 5 Jan 2013 02:20:34 -0500 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 5 Jan 2013 12:49:08 +0530 In-Reply-To: <20130104222135.GA13481@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 01/05/2013 06:21 AM, Marcelo Tosatti wrote: > On Fri, Jan 04, 2013 at 09:55:40PM +0800, Xiao Guangrong wrote: >> Little cleanup for reexecute_instruction, also use gpa_to_gfn in >> retry_instruction >> >> Signed-off-by: Xiao Guangrong >> --- >> arch/x86/kvm/x86.c | 13 ++++++------- >> 1 files changed, 6 insertions(+), 7 deletions(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 1c9c834..ad39018 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -4761,19 +4761,18 @@ static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva) >> if (tdp_enabled) >> return false; >> >> + gpa = kvm_mmu_gva_to_gpa_read(vcpu, gva, NULL); >> + if (gpa == UNMAPPED_GVA) >> + return true; /* let cpu generate fault */ >> + > > Why change from _system to _read here? Purely cleanup patch should > have no logical changes. Ouch, my mistake, will drop this change. > > BTW, there is not much logic in using reexecute_instruction() at > for x86_decode_insn (checks in reexecute_instruction() assume > write to the cr2, for instance). > Fault propagation for x86_decode_insn seems completly broken > (which is perhaps why reexecute_instruction() there survived). Currently, reexecute_instruction can work only if it is called on page fault path where cr2 is valid. On other paths, cr2 is 0 which is always not be mapped on guest since it is NULL pointer, so reexecute_instruction always retry the instruction. Yes, as you point it out, it is better if the fault address can be got from x86_decode_insn. I will consider it later.