On 05/12/2017 10:03, Andrew Cooper wrote: > On 05/12/2017 09:30, Jan Beulich wrote: >>>>> On 05.12.17 at 09:49, <osstest-ad...@xenproject.org> 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 > Dec 5 04:21:49.555130 (XEN) stdvga.c:173:d1v0 entering stdvga mode > > which I expect is the root of the problem.
Yes - that is the cause of the problem. The BSOD is a 0x3D (exception not handled) referencing the same %rip as the CR emulation failure. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
