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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew

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