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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

ISTR suggesting that this bit of vm_event moves to an X86EMUL_RETRY
model.  However, that will break other areas of the vm_event
infrastructure iirc, so is rather complicated to do.

I was hoping all of these problems could be deferred until I started
looking into the action-emulator plan, to bring together the various
paths we currently have putting the same action into the vm_event ring.

~Andrew

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