On 05/20/2010 05:46 PM, Mohammed Gamal wrote:
On Thu, May 20, 2010 at 5:37 PM, Chris Lalancette<clalance@xxxxxxxxxx> 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@xxxxxxxxx>
---
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
