All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.