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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/12/17 11:16, Jan Beulich wrote:
>>>> 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.

I am equally perplexed.  The SVM code definitely used to (ab)use the
MMIO path, so I expect there is still some remnants left.

The CR access in the message proves that we started this emulation from
a CR vmexit.  My best guess is that _hvm_emulate_one() reused the
instruction cache rather than starting fresh.  The unhandleable is
probably from a ->validate() failure, and the bytes are probably stale
from the previous emulation.

~Andrew

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