Re: [Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.04.17 at 13:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 20/04/17 11:52, Jan Beulich wrote:
>>  >>> On 19.04.17 at 17:58, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel