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

2016-05-17 Thread Andrew Cooper 
On 17/05/16 11:57, Jan Beulich wrote:
 On 16.05.16 at 11:24,  wrote:
>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>>> flight 94442 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
>> [...]
>>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>>> 94368
>> The changes in this flight shouldn't cause failure like this. See below.
>>
>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>> master. It seems that previous run didn't discover this.
>>
>> Log file at:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/test-amd64-i386-qemuu-rhel
>>  
>> 6hvm-intel/serial-italia0.log
>>
>> May 15 22:07:44.023500 (XEN) Xen BUG at entry.S:221
>> May 15 22:07:47.455549 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not 
>> tainted ]
>> May 15 22:07:47.463500 (XEN) CPU:0
>> May 15 22:07:47.463531 (XEN) RIP:e008:[] 
>> cr4_pv32_restore+0x37/0x40
>> May 15 22:07:47.463567 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
>> (d0v3)
>> May 15 22:07:47.471503 (XEN) rax:    rbx: cf195e50   
>> rcx: 0001
>> May 15 22:07:47.479496 (XEN) rdx: 8300be907ff8   rsi: 7ff0   
>> rdi: 0022287e
>> May 15 22:07:47.487498 (XEN) rbp: 7cff416f80c7   rsp: 8300be907f08   
>> r8:  83023df8a000
>> May 15 22:07:47.495498 (XEN) r9:  83023df8a000   r10: deadbeef   
>> r11: 0080
>> May 15 22:07:47.503510 (XEN) r12: 8300bed32000   r13: 83023df8a000   
>> r14: 
>> May 15 22:07:47.503549 (XEN) r15: 83023df72000   cr0: 80050033   
>> cr4: 001526e0
>> May 15 22:07:47.511501 (XEN) cr3: 0002383d7000   cr2: b71ff000
>> May 15 22:07:47.519493 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
>>    cs: e008
>> May 15 22:07:47.527520 (XEN) Xen code around  
>> (cr4_pv32_restore+0x37/0x40):
>> May 15 22:07:47.535491 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 
>> 1f 00 f6 42 04 01 0f 84 26
>> May 15 22:07:47.535531 (XEN) Xen stack trace from rsp=8300be907f08:
>> May 15 22:07:47.543502 (XEN) 82d080240f22 
>> 83023df72000 
>> May 15 22:07:47.551559 (XEN)83023df8a000 8300bed32000 
>> cf195e6c cf195e50
>> May 15 22:07:47.559494 (XEN)0080 deadbeef 
>> 83023df8a000 0206
>> May 15 22:07:47.567496 (XEN)0001 0001 
>>  7ff0
>> May 15 22:07:47.575503 (XEN)0022287e 0100 
>> c1001027 0061
>> May 15 22:07:47.575543 (XEN)0246 cf195e44 
>> 0069 beef
>> May 15 22:07:47.583508 (XEN)beef beef 
>> beef 
>> May 15 22:07:47.591503 (XEN)8300bed3  
>> 001526e0
>> May 15 22:07:47.599493 (XEN) Xen call trace:
>> May 15 22:07:47.599522 (XEN)[] 
>> cr4_pv32_restore+0x37/0x40
> I think I see the problem the introduction of caching in v3 introduced:
> In compat_restore_all_guest we have (getting patched in by altinsn
> patching):
>
> .Lcr4_alt:
> testb $3,UREGS_cs(%rsp)
> jpe   .Lcr4_alt_end
> mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> and   $~XEN_CR4_PV32_BITS, %rax
> mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> mov   %rax, %cr4
> .Lcr4_alt_end:
>
> If an NMI occurs between the updating og the cached value and the
> actual CR4 write, the NMI handling will cause the cached value to get
> SMEP+SMAP enabled again (in both cache and CR4), and once we
> get back here, we will clear it in just CR4.
>
> We don't want to undo the caching, as that gave us performance back
> at least for 64-bit PV guests.
>
> We also can't simply swap the two instructions: If we did, an NMI
> between the two would itself trigger the BUG in cr4_pv32_restore
> (as the check there assumes that CR4 always has no less of the
> bits of interest set than the cached value).
>
> The options I see are:
>
> 1) Ditch the debug check altogether, for being false positive in
> exactly one corner case.
>
> 2) Make the NMI handler recognize the single critical pair of
> instructions.
>
> 3) Change the code sequence above to
>
> .Lcr4_alt:
> testb $3,UREGS_cs(%rsp)
> jpe   .Lcr4_alt_end
> mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
> and   $~XEN_CR4_PV32_BITS, %rax
> 1:
> mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> mov   %rax, %cr4
> /* (suitable comment goes here) */
> cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
> jne   1b
> .Lcr4_alt_end:
>
> (assuming that an insane flood of NMIs not allowing this loop to
> be exited would be sufficiently problematic in other ways).

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

2016-05-17 Thread Jan Beulich 
>>> On 16.05.16 at 11:24,  wrote:
> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>> flight 94442 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
> [...]
>> 
>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>> 94368
> 
> The changes in this flight shouldn't cause failure like this. See below.
> 
> It is more likely to be caused by SMEP/SMAP fix, which are now in
> master. It seems that previous run didn't discover this.
> 
> Log file at:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/94442/test-amd64-i386-qemuu-rhel
>  
> 6hvm-intel/serial-italia0.log
> 
> May 15 22:07:44.023500 (XEN) Xen BUG at entry.S:221
> May 15 22:07:47.455549 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not tainted 
> ]
> May 15 22:07:47.463500 (XEN) CPU:0
> May 15 22:07:47.463531 (XEN) RIP:e008:[] 
> cr4_pv32_restore+0x37/0x40
> May 15 22:07:47.463567 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
> (d0v3)
> May 15 22:07:47.471503 (XEN) rax:    rbx: cf195e50   
> rcx: 0001
> May 15 22:07:47.479496 (XEN) rdx: 8300be907ff8   rsi: 7ff0   
> rdi: 0022287e
> May 15 22:07:47.487498 (XEN) rbp: 7cff416f80c7   rsp: 8300be907f08   
> r8:  83023df8a000
> May 15 22:07:47.495498 (XEN) r9:  83023df8a000   r10: deadbeef   
> r11: 0080
> May 15 22:07:47.503510 (XEN) r12: 8300bed32000   r13: 83023df8a000   
> r14: 
> May 15 22:07:47.503549 (XEN) r15: 83023df72000   cr0: 80050033   
> cr4: 001526e0
> May 15 22:07:47.511501 (XEN) cr3: 0002383d7000   cr2: b71ff000
> May 15 22:07:47.519493 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
>    cs: e008
> May 15 22:07:47.527520 (XEN) Xen code around  
> (cr4_pv32_restore+0x37/0x40):
> May 15 22:07:47.535491 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 
> 1f 00 f6 42 04 01 0f 84 26
> May 15 22:07:47.535531 (XEN) Xen stack trace from rsp=8300be907f08:
> May 15 22:07:47.543502 (XEN) 82d080240f22 
> 83023df72000 
> May 15 22:07:47.551559 (XEN)83023df8a000 8300bed32000 
> cf195e6c cf195e50
> May 15 22:07:47.559494 (XEN)0080 deadbeef 
> 83023df8a000 0206
> May 15 22:07:47.567496 (XEN)0001 0001 
>  7ff0
> May 15 22:07:47.575503 (XEN)0022287e 0100 
> c1001027 0061
> May 15 22:07:47.575543 (XEN)0246 cf195e44 
> 0069 beef
> May 15 22:07:47.583508 (XEN)beef beef 
> beef 
> May 15 22:07:47.591503 (XEN)8300bed3  
> 001526e0
> May 15 22:07:47.599493 (XEN) Xen call trace:
> May 15 22:07:47.599522 (XEN)[] 
> cr4_pv32_restore+0x37/0x40

I think I see the problem the introduction of caching in v3 introduced:
In compat_restore_all_guest we have (getting patched in by altinsn
patching):

.Lcr4_alt:
testb $3,UREGS_cs(%rsp)
jpe   .Lcr4_alt_end
mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
and   $~XEN_CR4_PV32_BITS, %rax
mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
mov   %rax, %cr4
.Lcr4_alt_end:

If an NMI occurs between the updating og the cached value and the
actual CR4 write, the NMI handling will cause the cached value to get
SMEP+SMAP enabled again (in both cache and CR4), and once we
get back here, we will clear it in just CR4.

We don't want to undo the caching, as that gave us performance back
at least for 64-bit PV guests.

We also can't simply swap the two instructions: If we did, an NMI
between the two would itself trigger the BUG in cr4_pv32_restore
(as the check there assumes that CR4 always has no less of the
bits of interest set than the cached value).

The options I see are:

1) Ditch the debug check altogether, for being false positive in
exactly one corner case.

2) Make the NMI handler recognize the single critical pair of
instructions.

3) Change the code sequence above to

.Lcr4_alt:
testb $3,UREGS_cs(%rsp)
jpe   .Lcr4_alt_end
mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
and   $~XEN_CR4_PV32_BITS, %rax
1:
mov   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
mov   %rax, %cr4
/* (suitable comment goes here) */
cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
jne   1b
.Lcr4_alt_end:

(assuming that an insane flood of NMIs not allowing this loop to
be exited would be sufficiently problematic in other ways).

I dislike 1, and between 2 and 3 I think I'd prefer the latter, unless
someone else sees something wrong with such an approach.

> May 15 22:07:47.607524 (XEN) Xen BUG at

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

2016-05-17 Thread Jan Beulich 
>>> On 17.05.16 at 11:01,  wrote:
> On 17/05/16 09:59, Jan Beulich wrote:
> On 16.05.16 at 11:29,  wrote:
>>> On 16/05/16 10:24, Wei Liu wrote:
 On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
> flight 94442 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
 [...]
>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
> 94368
 The changes in this flight shouldn't cause failure like this. See below.

 It is more likely to be caused by SMEP/SMAP fix, which are now in
 master. It seems that previous run didn't discover this.
>>> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
>>> italia0?
>> E3-1220V2 according to the copy of the spreadsheet of systems
>> I have. Aiui v2 should have neither SMEP nor SMAP, and hence we
>> shouldn't even get into cr4_pv32_restore(). Suggests an issue with
>> alternative insn patching ...
> 
> v2 is IvyBridge, and has SMEP but not SMAP.

Oh, I wrongly thought only v3 had SMEP.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-17 Thread Jan Beulich 
>>> On 17.05.16 at 10:59,  wrote:
 On 16.05.16 at 11:29,  wrote:
>> On 16/05/16 10:24, Wei Liu wrote:
>>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
 flight 94442 xen-unstable real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
>>> [...]
  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
> 94368
>>> The changes in this flight shouldn't cause failure like this. See below.
>>>
>>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>>> master. It seems that previous run didn't discover this.
>> 
>> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
>> italia0?
> 
> E3-1220V2 according to the copy of the spreadsheet of systems
> I have. Aiui v2 should have neither SMEP nor SMAP, and hence we
> shouldn't even get into cr4_pv32_restore(). Suggests an issue with
> alternative insn patching ...

Otoh the dumped CR4 shows SMEP to be in use.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-17 Thread Andrew Cooper 
On 17/05/16 09:59, Jan Beulich wrote:
 On 16.05.16 at 11:29,  wrote:
>> On 16/05/16 10:24, Wei Liu wrote:
>>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
 flight 94442 xen-unstable real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
>>> [...]
  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
 94368
>>> The changes in this flight shouldn't cause failure like this. See below.
>>>
>>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>>> master. It seems that previous run didn't discover this.
>> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
>> italia0?
> E3-1220V2 according to the copy of the spreadsheet of systems
> I have. Aiui v2 should have neither SMEP nor SMAP, and hence we
> shouldn't even get into cr4_pv32_restore(). Suggests an issue with
> alternative insn patching ...

v2 is IvyBridge, and has SMEP but not SMAP.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-17 Thread Jan Beulich 
>>> On 16.05.16 at 11:29,  wrote:
> On 16/05/16 10:24, Wei Liu wrote:
>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>>> flight 94442 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/94442/ 
>> [...]
>>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>>> 94368
>> The changes in this flight shouldn't cause failure like this. See below.
>>
>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>> master. It seems that previous run didn't discover this.
> 
> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
> italia0?

E3-1220V2 according to the copy of the spreadsheet of systems
I have. Aiui v2 should have neither SMEP nor SMAP, and hence we
shouldn't even get into cr4_pv32_restore(). Suggests an issue with
alternative insn patching ...

Jan

> In the meantime, I need to fix stack traces to prevent them assuming the
> presence of a frame pointer in debug builds.  This isn't true for some
> of the hand rolled assembly (or for calls through the EFI firmware).
> 
> ~Andrew




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-16 Thread Andrew Cooper 
On 16/05/16 10:39, Wei Liu wrote:
> On Mon, May 16, 2016 at 10:29:41AM +0100, Andrew Cooper wrote:
>> On 16/05/16 10:24, Wei Liu wrote:
>>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
 flight 94442 xen-unstable real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/94442/
>>> [...]
  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
 94368
>>> The changes in this flight shouldn't cause failure like this. See below.
>>>
>>> It is more likely to be caused by SMEP/SMAP fix, which are now in
>>> master. It seems that previous run didn't discover this.
>> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
>> italia0?
>>
> I can only tell it is an Intel box from the serial log.
>
> I'm afraid if you need more information we need to wait until Ian comes
> back.
>
>> In the meantime, I need to fix stack traces to prevent them assuming the
>> presence of a frame pointer in debug builds.  This isn't true for some
>> of the hand rolled assembly (or for calls through the EFI firmware).
>>
> Is this related to this bug?

Not specifically, but it is the reason the first call trace has a single
entry rather than the two expected.

>
> Shall we revert the series now? I don't want it to block pushing to
> master for too long.

Let me see if I can come up with a fix soonish.  If not, we should
consider reverting.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-16 Thread Wei Liu 
On Mon, May 16, 2016 at 10:29:41AM +0100, Andrew Cooper wrote:
> On 16/05/16 10:24, Wei Liu wrote:
> > On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
> >> flight 94442 xen-unstable real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/94442/
> > [...]
> >>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
> >> 94368
> > The changes in this flight shouldn't cause failure like this. See below.
> >
> > It is more likely to be caused by SMEP/SMAP fix, which are now in
> > master. It seems that previous run didn't discover this.
> 
> Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
> italia0?
> 

I can only tell it is an Intel box from the serial log.

I'm afraid if you need more information we need to wait until Ian comes
back.

> In the meantime, I need to fix stack traces to prevent them assuming the
> presence of a frame pointer in debug builds.  This isn't true for some
> of the hand rolled assembly (or for calls through the EFI firmware).
>

Is this related to this bug?

Shall we revert the series now? I don't want it to block pushing to
master for too long.

Wei.
 
> ~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-16 Thread Andrew Cooper 
On 16/05/16 10:24, Wei Liu wrote:
> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>> flight 94442 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/
> [...]
>>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
>> 94368
> The changes in this flight shouldn't cause failure like this. See below.
>
> It is more likely to be caused by SMEP/SMAP fix, which are now in
> master. It seems that previous run didn't discover this.

Indeed - definitely from the SMEP/SMAP fix.  What kind of hardware is
italia0?

In the meantime, I need to fix stack traces to prevent them assuming the
presence of a frame pointer in debug builds.  This isn't true for some
of the hand rolled assembly (or for calls through the EFI firmware).

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-16 Thread Wei Liu 
On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
> flight 94442 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94442/
[...]
> 
>  test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 
> 94368

The changes in this flight shouldn't cause failure like this. See below.

It is more likely to be caused by SMEP/SMAP fix, which are now in
master. It seems that previous run didn't discover this.

Log file at:

http://logs.test-lab.xenproject.org/osstest/logs/94442/test-amd64-i386-qemuu-rhel6hvm-intel/serial-italia0.log

May 15 22:07:44.023500 (XEN) Xen BUG at entry.S:221
May 15 22:07:47.455549 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not tainted 
]
May 15 22:07:47.463500 (XEN) CPU:0
May 15 22:07:47.463531 (XEN) RIP:e008:[] 
cr4_pv32_restore+0x37/0x40
May 15 22:07:47.463567 (XEN) RFLAGS: 00010287   CONTEXT: hypervisor 
(d0v3)
May 15 22:07:47.471503 (XEN) rax:    rbx: cf195e50   
rcx: 0001
May 15 22:07:47.479496 (XEN) rdx: 8300be907ff8   rsi: 7ff0   
rdi: 0022287e
May 15 22:07:47.487498 (XEN) rbp: 7cff416f80c7   rsp: 8300be907f08   
r8:  83023df8a000
May 15 22:07:47.495498 (XEN) r9:  83023df8a000   r10: deadbeef   
r11: 0080
May 15 22:07:47.503510 (XEN) r12: 8300bed32000   r13: 83023df8a000   
r14: 
May 15 22:07:47.503549 (XEN) r15: 83023df72000   cr0: 80050033   
cr4: 001526e0
May 15 22:07:47.511501 (XEN) cr3: 0002383d7000   cr2: b71ff000
May 15 22:07:47.519493 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
   cs: e008
May 15 22:07:47.527520 (XEN) Xen code around  
(cr4_pv32_restore+0x37/0x40):
May 15 22:07:47.535491 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 1f 
00 f6 42 04 01 0f 84 26
May 15 22:07:47.535531 (XEN) Xen stack trace from rsp=8300be907f08:
May 15 22:07:47.543502 (XEN) 82d080240f22 
83023df72000 
May 15 22:07:47.551559 (XEN)83023df8a000 8300bed32000 
cf195e6c cf195e50
May 15 22:07:47.559494 (XEN)0080 deadbeef 
83023df8a000 0206
May 15 22:07:47.567496 (XEN)0001 0001 
 7ff0
May 15 22:07:47.575503 (XEN)0022287e 0100 
c1001027 0061
May 15 22:07:47.575543 (XEN)0246 cf195e44 
0069 beef
May 15 22:07:47.583508 (XEN)beef beef 
beef 
May 15 22:07:47.591503 (XEN)8300bed3  
001526e0
May 15 22:07:47.599493 (XEN) Xen call trace:
May 15 22:07:47.599522 (XEN)[] cr4_pv32_restore+0x37/0x40
May 15 22:07:47.607493 (XEN) 
May 15 22:07:47.607524 (XEN) Xen BUG at entry.S:221
May 15 22:07:47.607552 (XEN) [ Xen-4.7.0-rc  x86_64  debug=y  Not tainted 
]
May 15 22:07:47.615544 (XEN) CPU:0
May 15 22:07:47.615573 (XEN) RIP:e008:[] 
cr4_pv32_restore+0x37/0x40
May 15 22:07:47.623503 (XEN) RFLAGS: 00010087   CONTEXT: hypervisor 
(d0v3)
May 15 22:07:47.631502 (XEN) rax:    rbx: 0200   
rcx: 
May 15 22:07:47.631540 (XEN) rdx: 8300be907ff8   rsi: 000a   
rdi: 82d0802fb6d8
May 15 22:07:47.639505 (XEN) rbp: 7cff416f8327   rsp: 8300be907ca8   
r8:  83023df78000
May 15 22:07:47.647508 (XEN) r9:  0002   r10: 0040   
r11: 0002
May 15 22:07:47.655507 (XEN) r12: 0010   r13: 8300be907e58   
r14: 82d0802780e2
May 15 22:07:47.663495 (XEN) r15: 82d0802780de   cr0: 80050033   
cr4: 001526e0
May 15 22:07:47.671487 (XEN) cr3: 0002383d7000   cr2: b71ff000
May 15 22:07:47.671520 (XEN) ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 
   cs: e008
May 15 22:07:47.679565 (XEN) Xen code around  
(cr4_pv32_restore+0x37/0x40):
May 15 22:07:47.687510 (XEN)  3b 05 03 87 0a 00 74 02 <0f> 0b 5a 31 c0 c3 0f 1f 
00 f6 42 04 01 0f 84 26
May 15 22:07:47.695502 (XEN) Xen stack trace from rsp=8300be907ca8:
May 15 22: 07: 47.695536 (XEN) 8300be907fff 82d080241c4f 
82d0802780de 82d0802780e2
May 15 22:07:47.703500 (XEN)8300be907e58 0010 
8300be907d78 0200
May 15 22:07:47.711506 (XEN)0002 0040 
0002 83023df78000
May 15 22:07:47.719538 (XEN)82d08033c0a8  
8300be907fff 000a
May 15 22:07:47.727494 (XEN)82d0802fb6d8 00f1 
82d080145845 e008
May 15 22:07:47.735506 (XEN)0206 8300be907d68 
 0206
May 15 22:07:47.743496 (XEN)82d0802780e2 0010 
8300be907de8 82d080199bab
May 15 22:07:47.743535 (XEN)be907de8

[Xen-devel] [xen-unstable test] 94442: regressions - FAIL

2016-05-15 Thread osstest service owner 
flight 94442 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94442/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 94368
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 94368
 test-armhf-armhf-libvirt  7 host-ping-check-xen   fail REGR. vs. 94368
 test-armhf-armhf-xl-multivcpu  9 debian-install   fail REGR. vs. 94368

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 94368
 build-amd64-rumpuserxen   6 xen-buildfail   like 94368
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94368
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94368
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94368
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94368
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94368

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis94368  2016-05-15 05:56:52 Z0 days
Testing same since94442  2016-05-15 18:46:42 Z0 days1 attempts


People who touched revisions under test:
  Jim Fehlig 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern