Re: [Xen-devel] [xen-unstable test] 105966: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.17 at 13:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/02/17 12:24, Jan Beulich wrote:
>>>>> On 23.02.17 at 13:19, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 23/02/17 09:51, Jan Beulich wrote:
>>>>>>> On 22.02.17 at 19:20, <osstest-admin@xxxxxxxxxxxxxx> wrote:
>>>>> flight 105966 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/105966/ 
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>>  test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1         fail REGR. vs. 
>>>>> 105933
>>>> (XEN) d5v0: Invalid EFER update: 0x1d01 -> 0x3901 - LMSLE without support
>>>> (XEN) hvm.c:1616:d3v0 All CPUs offline -- powering off.
>>>>
>>>> Very interesting. Earlier instances of the first of these two messages
>>>> in the log indicate that this previously didn't cause the guest to die.
>>> Looks like a red herring.  It is d5 complaining about EFER, while d3
>>> that dies mysteriously.
>> Oops, I didn't pay enough attention.
> 
> Should we reorder the prink() to put %pv before __FILE__ ? IMO it would
> be helpful to have %pv in a more consistent location in the line.

That's a good idea, I think.

>>>> I can't guess which of the commits under test might be responsible,
>>>> though, so unless someone else has any idea we may need to wait
>>>> for the bisector to give us a clue. The most likely one would seem to
>>>> be 49de10f3c1 ("x86/hvm: Don't raise #GP behind the emulators
>>>> back for MSR accesses") - Andrew, is the much later #GP injection
>>>> (in hvm_do_resume()) perhaps the problem here? Shouldn't this
>>>> be done in svm_do_msr_access() and VMX's EXIT_REASON_MSR_WRITE
>>>> handling, respectively?
>>> I don't think so.  Normal MSR accesses would be via svm_do_msr_access()
>>> which still latches #GP on the way out.
>> But anyway - is the exception injection in hvm_do_resume() really
>> legitimate?
> 
> I have brought that up before.  It is not actually legitimate, because
> %rip has already moved forwards by this point.
> 
> In practice, the current vmevent users of this interface only intercept
> a very small number of MSRs, and they won't fault by the time they get here.

Well, this means effectively you added dead code. Yet in that case
I think it would be better for the dead code to crash the domain,
instead of trying to inject an event after vendor specific resume
code has already run. That would at least make obvious that we
don't expect this path to be taken.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel