From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][RESEND] Print a user-friendly message on failed vmentry Date: Tue, 01 Jun 2010 15:40:36 +0300 Message-ID: <4C04FFC4.7070304@redhat.com> References: <1275334818-6064-1-git-send-email-m.gamal005@gmail.com> <4C04CC07.1000707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, anthony@codemonkey.ws, ryanh@us.ibm.com, kvm@vger.kernel.org To: Mohammed Gamal Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51725 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754623Ab0FAMkm (ORCPT ); Tue, 1 Jun 2010 08:40:42 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/01/2010 01:55 PM, Mohammed Gamal wrote: > On Tue, Jun 1, 2010 at 11:59 AM, Avi Kivity wrote: > >> On 05/31/2010 10:40 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. >>> >>> >>> >>> +#define VMX_INVALID_GUEST_STATE 0x80000021 >>> + >>> +static int handle_failed_vmentry(uint64_t reason) >>> +{ >>> + fprintf(stderr, "kvm: vm entry failed with error 0x%" PRIx64 "\n\n", >>> reason); >>> + >>> + /* Perhaps we will need to check if this machine is intel since exit >>> reason 0x21 >>> + has a different interpretation on SVM */ >>> + if (reason == VMX_INVALID_GUEST_STATE) { >>> + fprintf(stderr, "If you're runnning a guest on an Intel machine >>> without\n"); >>> + fprintf(stderr, "unrestricted mode support, the failure can be >>> most likely\n"); >>> + fprintf(stderr, "due to the guest entering an invalid state for >>> Intel VT.\n"); >>> + fprintf(stderr, "For example, the guest maybe running in big real >>> mode\n"); >>> + fprintf(stderr, "which is not supported on less recent Intel >>> processors.\n\n"); >>> + fprintf(stderr, "You may want to try enabling KVM real mode >>> emulation. To\n"); >>> + fprintf(stderr, "enable it, you can 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\n"); >>> + fprintf(stderr, "WARNING: Real mode emulation is still >>> work-in-progress\n"); >>> + fprintf(stderr, "and thus it is not always guaranteed to >>> work.\n\n"); >>> + } >>> + >>> + return -EINVAL; >>> +} >>> >>> >>> >> It's almost guaranteed to fail, isn't it? Is there any guest which fails >> with emulated_invalid_guest_state=0 but works with e_i_g_s=1? >> >> > You're right! Perhaps I should remove the e_i_g_s bit from the > message. What do you think? > Sure. Better than the current message. -- error compiling committee.c: too many arguments to function