Re: [PATCH] Print a user-friendly message on failed vmentry

Anthony Liguori
2010-05-20T14:46:54Z

On 05/20/2010 09:37 AM, 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<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.
>

We should probably only display this message if reason == 0x80000021.
It may be worth looking at the cpu_state to verify that we're trying to
enter 16-bit mode too.

Then the message can be much more definitive too.

Regards,

Anthony Liguori