On Thu, May 20, 2010 at 6:53 PM, Avi Kivity <avi@xxxxxxxxxx> wrote: > 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. > I already added a warning in the second patch I sent. > -- > 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
