From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: [PATCHv2] KVM: inject #UD if instruction emulation fails and exit to userspace Date: Tue, 11 May 2010 11:09:12 +0900 Message-ID: <4BE8BC48.4070201@oss.ntt.co.jp> References: <20100510081656.GJ24787@redhat.com> <20100510102525.GO24787@redhat.com> <20100510173337.GD4497@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mohammed Gamal , avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:53069 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751Ab0EKCFm (ORCPT ); Mon, 10 May 2010 22:05:42 -0400 In-Reply-To: <20100510173337.GD4497@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: (2010/05/11 2:33), Gleb Natapov wrote: > On Mon, May 10, 2010 at 07:06:05PM +0300, Mohammed Gamal wrote: >> On Mon, May 10, 2010 at 1:25 PM, Gleb Natapov wrote: >>> On Mon, May 10, 2010 at 11:16:56AM +0300, Gleb Natapov wrote: >>>> Do not kill VM when instruction emulation fails. Inject #UD and report >>>> failure to userspace instead. Userspace may choose to reenter guest if >>>> vcpu is in userspace (cpl == 3) in which case guest OS will kill >>>> offending process and continue running. >>>> >> >> I am curious to know what'd happen in case the vcpu is in kernel space >> (cpl == 0). Is that case handled? >> > Currently no matter where emulation fails VM is stopped and cpu state is > printed on stderr. After that patch userspace may choose to continue VM > execution after emulation error (#UD will be injected into VM though). The > policy is in userspace, but I don't see the point to continue execution > after emulation failed in kernel. How kernel can recover from the #UD? I don't see what is the recommended(possible) way of trouble shooting yet. If the user is managing both the guest and the host, it's simple: no worth reentering the guest. The user will just see the stderr. But what about if the user can only see the guest? In the case of non-virt, usually the user sees oops log or something and calls to a support staff. Compared to that, if VM is silently stopped, what information can the user see? In such a case, catching up the trouble and calling to a support staff is host side management staff's job? If you give us preferred way of trouble shooting of KVM, from the developer's point of view, it will really help us to prepare for the future use of KVM. What we can do will depend on your development! And this is one of the reasons why I'm interested in the x86's emulation development. :-) Thanks, Takuya > > -- > Gleb. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html