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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.12.17 at 11:03, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/12/2017 09:30, Jan Beulich wrote:
>>>>> On 05.12.17 at 09:49, <osstest-admin@xxxxxxxxxxxxxx> wrote:
>>> flight 116832 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/116832/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
> 116744
>> This is a blue screen, recurring, and has first been reported in flight
>> 116779, i.e. was likely introduced in the batch ending in commit
>> 4cd0fad645. Among those the most likely candidates appear to be
>> the SVM changes (the failures are all on AMD hardware). The logs
>> there also have huge amounts of "Unexpected nested vmexit",
>> albeit not directly connected with the failed test afaict.
> 
> The unexpected nested vmexit is from a previous test, (and hopefully the
> nested virt test, as that path shouldn't be reachable elsehow).
> 
> The windows boot which actually failed has:
> 
> Dec  5 04:20:08.735216 (XEN) CR access emulation failed (1): d1v0 64bit @ 
> 0010:fffff8000ce9e4ab -> 66 f3 6d 48 8b 7c 24 08 c3 cc cc cc cc cc cc cc

How did I not spot this? This is a REP INSW, which then makes it
far more likely to be a result of Paul's 9c9384d6d8. Sadly the
windows-install tests of the two 4.10 flights we've had so far all
ran on Intel hardware, so we can't easily tell whether the
problem is present there as well (in which case it would for sure
be that commit).

For the moment I'm struggling to understand how we can end up
on the CR access emulation path here, but I'll take a closer look.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel