From: Avi Kivity <avi@redhat.com>
To: Mohammed Gamal <m.gamal005@gmail.com>
Cc: Chris Lalancette <clalance@redhat.com>,
mtosatti@redhat.com, anthony@codemonkey.ws, kvm@vger.kernel.org
Subject: Re: [PATCH] Print a user-friendly message on failed vmentry
Date: Thu, 20 May 2010 18:53:01 +0300 [thread overview]
Message-ID: <4BF55ADD.7000104@redhat.com> (raw)
In-Reply-To: <AANLkTil5TvwNPw7WdSzlz1QpNtGKXD5l4VLmruDv8eGm@mail.gmail.com>
On 05/20/2010 05:46 PM, Mohammed Gamal wrote:
> On Thu, May 20, 2010 at 5:37 PM, Chris Lalancette<clalance@redhat.com> 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<m.gamal005@gmail.com>
>>> ---
>>> 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.
next prev parent reply other threads:[~2010-05-20 15:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 21:16 [PATCH] Print a user-friendly message on failed vmentry Mohammed Gamal
2010-05-19 21:52 ` Anthony Liguori
2010-05-20 1:28 ` Ryan Harper
2010-05-20 2:06 ` Mohammed Gamal
2010-05-20 14:37 ` Chris Lalancette
2010-05-20 14:46 ` Anthony Liguori
2010-05-20 14:46 ` Mohammed Gamal
2010-05-20 15:53 ` Avi Kivity [this message]
2010-05-20 15:55 ` Mohammed Gamal
-- strict thread matches above, loose matches on Subject: below --
2010-05-20 2:27 Mohammed Gamal
2010-05-23 22:02 Mohammed Gamal
2010-06-06 11:10 Mohammed Gamal
2010-06-07 7:31 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BF55ADD.7000104@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=clalance@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=m.gamal005@gmail.com \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox