>>> On 23.02.17 at 13:19, <andrew.coop...@citrix.com> wrote:
> On 23/02/17 09:51, Jan Beulich wrote:
>>>>> On 22.02.17 at 19:20, <osstest-ad...@xenproject.org> 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@lists.xen.org
https://lists.xen.org/xen-devel
