>>> On 20.04.17 at 13:01, <andrew.coop...@citrix.com> wrote: > On 20/04/17 11:52, Jan Beulich wrote: >> >>> On 19.04.17 at 17:58, <andrew.coop...@citrix.com> wrote: >>> --- a/xen/arch/x86/hvm/svm/svm.c >>> +++ b/xen/arch/x86/hvm/svm/svm.c >>> @@ -2833,10 +2833,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) >>> >>> default: >>> unexpected_exit_type: >>> - gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", >>> " >>> - "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n", >>> - exit_reason, >>> - (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2); >>> + gprintk(XENLOG_ERR, "Bad vmexit: reason %#"PRIx64", " >>> + "exitinfo1 %#"PRIx64", exitinfo2 %#"PRIx64"\n", >>> + exit_reason, (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2); >> Personally I think "unexpected" was more appropriate than "bad". >> Also I would have wished for you to eliminate the bogus casts as >> you touch these lines anyway. > > Bad was for consistency between VT-x and SVM, and these messages also > include the exit_and_crash cases, meaning that "unexpected" isn't > entirely appropriate. > > I'm happy to take an alternative if you can thing of something better.
Well - "unexpected"? (Many of the exit_and_crash paths are either not fitting "bad" any better or are in the same "unexpected" class" in the VMX case. There's only a single patch coming into SVM's unexpected_exit_type label, which does seem to fit "unexpected".) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
