From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: kvm: emulation failure Date: Mon, 22 Jun 2009 15:11:14 +0800 Message-ID: <200906221511.15404.sheng@linux.intel.com> References: <1245439420.6262.349.camel@localhost> <200906221312.36795.sheng@linux.intel.com> <1245653746.6262.365.camel@localhost> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Anthony Liguori , Ryan Harper To: linuxram@us.ibm.com Return-path: Received: from mga05.intel.com ([192.55.52.89]:57836 "EHLO fmsmga101.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750872AbZFVHLe (ORCPT ); Mon, 22 Jun 2009 03:11:34 -0400 In-Reply-To: <1245653746.6262.365.camel@localhost> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Monday 22 June 2009 14:55:46 Ram Pai wrote: > On Mon, 2009-06-22 at 13:12 +0800, Sheng Yang wrote: > > On Saturday 20 June 2009 03:23:40 Ram Pai wrote: > > > I see this problem with a x86 sles10 guest running on x86_64 intel > > > host. If the guest is reset abruptly and rebooted, some where > > > before grub sequence it hangs and the following message is seen in the > > > logs > > > > > > emulation failed (pagetable) rip 7ed5 66 60 ac 20. > > > > > > I located this instruction sequence in isolinux.bin on the iso ;if that > > > is relevant. > > > > > > > > > I did some analysis and find that there is an ept violation, which is > > > handled and then the next instruction '66 60' is attempted to decode > > > and emulate. But decode fails. kvm continues loops in the kernel > > > in __vcpu_run(). > > > > > > the code path is > > > > > > kvm_run() -> __vcpu_run() -> vcpu_enter_guest() -> kvm_handle_exit() -> > > > handle_ept_violation() -> kvm_mmu_page_fault() -> emulate_instruction() > > > -> x86_decode_insn() > > > > Hi Ram > > > > Seems KVM failed to emulate a unknown instruction. > > > > 00000000 6660 pushad > > 00000002 AC lodsb > > > > And PUSHAD have not implemented in x86_emulate.c. > > Thanks Sheng for your response, > > Good. that was the conclusion i had reached reading the code. However > was not sure whether the (a) the code path should have never reached > there or (b) the code must have learnt to emulate pushad. > > Sounds like (b) is the case. > > > But I am a little curious about why this code path was only triggered > > when reset. Maybe other issue exists. > > What do you want me to check? I have seen ept violation code getting > triggered a few number of times at various stages. But the one reported > above is the only case where the instruction being emulated is 66 60. Don't have clue now. I think the only thing we can do now is to have instruction emulated, then wait to see what would happen next. EPT violation is common, for set up EPT pagetable and handle MMIO. > one more observation: > seen only if the /boot partition is reiserfs. I have been unable to > reproduce this with /boot being ext3. Maybe reiserfs did extra thing to do the cleanup after a abruptly reset? Sounds reasonable. :) -- regards Yang, Sheng > thanks and let me know, > RP