From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Print a user-friendly message on failed vmentry Date: Thu, 20 May 2010 18:53:01 +0300 Message-ID: <4BF55ADD.7000104@redhat.com> References: <1274303782-21497-1-git-send-email-m.gamal005@gmail.com> <4BF54915.7070201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Lalancette , mtosatti@redhat.com, anthony@codemonkey.ws, kvm@vger.kernel.org To: Mohammed Gamal Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39081 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753405Ab0ETPxI (ORCPT ); Thu, 20 May 2010 11:53:08 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/20/2010 05:46 PM, Mohammed Gamal wrote: > On Thu, May 20, 2010 at 5:37 PM, Chris Lalancette wrote: > >> On 05/19/2010 05:16 PM, Mohammed Gamal wrote: >> >>> This patch address bug report in https://bugs.launchpad.net/qemu/+bug/530077. >>> >>> Failed vmentries were handled with handle_unhandled() which prints a rather >>> unfriendly message to the user. This patch separates handling vmentry failures >>> from unknown exit reasons and prints a friendly message to the user. >>> >>> Signed-off-by: Mohammed Gamal >>> --- >>> qemu-kvm.c | 16 +++++++++++++++- >>> 1 files changed, 15 insertions(+), 1 deletions(-) >>> >>> diff --git a/qemu-kvm.c b/qemu-kvm.c >>> index 35a4c8a..deb4df8 100644 >>> --- a/qemu-kvm.c >>> +++ b/qemu-kvm.c >>> @@ -106,6 +106,20 @@ static int handle_unhandled(uint64_t reason) >>> return -EINVAL; >>> } >>> >>> +static int handle_failed_vmentry(uint64_t reason) >>> +{ >>> + fprintf(stderr, "kvm: vm entry failed with error 0x%" PRIx64 "\n\n", reason); >>> + fprintf(stderr, "If you're runnning a guest on an Intel machine, it can be\n"); >>> + fprintf(stderr, "most-likely due to the guest going into an invalid state\n"); >>> + fprintf(stderr, "for Intel VT. For example, the guest maybe running in big\n"); >>> + fprintf(stderr, "real mode which is not supported by Intel VT.\n\n"); >>> + fprintf(stderr, "You may want to try enabling real mode emulation in KVM.\n"); >>> + fprintf(stderr, "To Enable it, you may run the following commands as root:\n"); >>> + fprintf(stderr, "# rmmod kvm_intel\n"); >>> + fprintf(stderr, "# rmmod kvm\n"); >>> + fprintf(stderr, "# modprobe kvm_intel emulate_invalid_guest_state=1\n"); >>> + return -EINVAL; >>> +} >>> >> The thing is, there are other valid reasons for vmentry failure. A while ago I tracked >> down a bug in the Linux kernel that was causing us to vmenter with invalid segments; >> this message would have been very misleading in that case. I think you'd have to do >> more complete analysis of the vmentry failure code to be more certain about the reason >> for failure. >> >> > Your point is definitely valid, yet big real mode is usually the most > likely case, and that's why this message is shown. Note also that it > says it's _most likely_ a failure caused by an invalid guest state, > but it doesn't rule out all other reasons. And in any case, it'd be > better than just printing something along the lines of: > " kvm: unhandled exit 80000021 > kvm_run returned -22" > However, we're still giving bad advice. Currently emulate_invalid_guest_state=1 is not going to work well (right?). Once it does, we'll simply make it the default and the message will never appear. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.