[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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.

>> 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?

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.