Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-intel

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Sun, Dec 22, 2019 at 08:52:02PM +0000, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-qemuu-nested-intel
> testid debian-hvm-install/l1/l2
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  b1710040ca9628a6517bfc06f87dcbb670f8743e
>   Bug not present: 3d05407025ed1f83f492f81ba8175fa26b1e2fb3
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145120/
> 
> 
>   commit b1710040ca9628a6517bfc06f87dcbb670f8743e
>   Author: Roger Pau Monn?? <roger.pau@xxxxxxxxxx>
>   Date:   Fri Dec 20 16:29:22 2019 +0100
>   
>       x86/apic: allow enabling x2APIC mode regardless of interrupt remapping
>       
>       x2APIC mode doesn't mandate interrupt remapping, and hence can be
>       enabled independently. This patch enables x2APIC when available,
>       regardless of whether there's interrupt remapping support.
>       
>       This is beneficial specially when running on virtualized environments,
>       since it reduces the amount of vmexits. For example when sending an
>       IPI in xAPIC mode Xen performs at least 3 different accesses to the
>       APIC MMIO region, while when using x2APIC mode a single wrmsr is used.
>       
>       The following numbers are from a lock profiling of a Xen PV shim
>       running a Linux PV kernel with 32 vCPUs and xAPIC mode:
>       
>       (XEN) Global lock flush_lock: addr=ffff82d0804af1c0, lockval=03190319, 
> not locked
>       (XEN)   lock:656153(892606463454), block:602183(9495067321843)
>       
>       Average lock time:   1360363ns
>       Average block time: 15767743ns
>       
>       While the following are from the same configuration but with the shim
>       using x2APIC mode:
>       
>       (XEN) Global lock flush_lock: addr=ffff82d0804b01c0, lockval=1adb1adb, 
> not locked
>       (XEN)   lock:1841883(1375128998543), block:1658716(10193054890781)
>       
>       Average lock time:   746588ns
>       Average block time: 6145147ns
>       
>       Enabling x2APIC has halved the average lock time, thus reducing
>       contention.
>       
>       Signed-off-by: Roger Pau Monn?? <roger.pau@xxxxxxxxxx>
>       Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

This change causes a vmlaunch failure on debina* boxes, but not
others (ie: tried to reproduce it on albana0 and failed). Here is the
relevant trace:

Dec 23 20:06:54.444025 (XEN) d3v0 VMLAUNCH error: 0x7
Dec 23 20:08:32.848081 (XEN) *** Guest State ***
Dec 23 20:08:32.848091 (XEN) CR0: actual=0x0000000000000031, 
shadow=0x0000000000000011, gh_mask=ffffffffffffffff
Dec 23 20:08:32.860079 (XEN) CR4: actual=0x0000000000002050, 
shadow=0x0000000000000000, gh_mask=fffffffffff8f870
Dec 23 20:08:32.860091 (XEN) CR3 = 0x0000000000000000
Dec 23 20:08:32.872075 (XEN) RSP = 0x0000000000000000 (0x0000000000000000)  RIP 
= 0x0000000000100036 (0x0000000000100036)
Dec 23 20:08:32.872086 (XEN) RFLAGS=0x00000002 (0x00000002)  DR7 = 
0x0000000000000400
Dec 23 20:08:32.884078 (XEN) Sysenter RSP=0000000000000000 
CS:RIP=0000:0000000000000000
Dec 23 20:08:32.884088 (XEN)        sel  attr  limit   base
Dec 23 20:08:32.884094 (XEN)   CS: 0000 0c09b ffffffff 0000000000000000
Dec 23 20:08:32.896078 (XEN)   DS: 0000 0c093 ffffffff 0000000000000000
Dec 23 20:08:32.896087 (XEN)   SS: 0000 0c093 ffffffff 0000000000000000
Dec 23 20:08:32.908080 (XEN)   ES: 0000 10000 00000000 0000000000000000
Dec 23 20:08:32.908088 (XEN)   FS: 0000 10000 00000000 0000000000000000
Dec 23 20:08:32.908094 (XEN)   GS: 0000 10000 00000000 0000000000000000
Dec 23 20:08:32.920077 (XEN) GDTR:            00000000 0000000000000000
Dec 23 20:08:32.920086 (XEN) LDTR: 0000 10000 00000000 0000000000000000
Dec 23 20:08:32.920091 (XEN) IDTR:            00000000 0000000000000000
Dec 23 20:08:32.932106 (XEN)   TR: 0000 0008b 00000067 0000000000000000
Dec 23 20:08:32.932115 (XEN) EFER(VMCS) = 0x0000000000000000  PAT = 
0x0007040600070406
Dec 23 20:08:32.944076 (XEN) PreemptionTimer = 0x00000000  SM Base = 0x00000000
Dec 23 20:08:32.944086 (XEN) DebugCtl = 0x0000000000000000  DebugExceptions = 
0x0000000000000000
Dec 23 20:08:32.956075 (XEN) Interruptibility = 00000000  ActivityState = 
00000000
Dec 23 20:08:32.956085 (XEN) InterruptStatus = 0000
Dec 23 20:08:32.956090 (XEN) *** Host State ***
Dec 23 20:08:32.956095 (XEN) RIP = 0xffff82d08033ba20 (vmx_asm_vmexit_handler)  
RSP = 0xffff83047c637f70
Dec 23 20:08:32.968082 (XEN) CS=e008 SS=0000 DS=0000 ES=0000 FS=0000 GS=0000 
TR=e040
Dec 23 20:08:32.968091 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 
TRBase=ffff83047c640000
Dec 23 20:08:32.980107 (XEN) GDTBase=ffff83047c630000 IDTBase=ffff83047c63c000
Dec 23 20:08:32.980116 (XEN) CR0=0000000080050033 CR3=000000045a98b000 
CR4=00000000003526e0
Dec 23 20:08:32.992080 (XEN) Sysenter RSP=ffff83047c637fa0 
CS:RIP=e008:ffff82d08038d440
Dec 23 20:08:32.992090 (XEN) EFER = 0x0000000000000d01  PAT = 0x0000050100070406
Dec 23 20:08:33.004078 (XEN) *** Control State ***
Dec 23 20:08:33.004086 (XEN) PinBased=0000003f CPUBased=b6a075fe 
SecondaryExec=000014fb
Dec 23 20:08:33.016077 (XEN) EntryControls=000011ff ExitControls=002fefff
Dec 23 20:08:33.016086 (XEN) ExceptionBitmap=00060002 PFECmask=00000000 
PFECmatch=00000000
Dec 23 20:08:33.016093 (XEN) VMEntry: intr_info=00000000 errcode=00000000 
ilen=00000000
Dec 23 20:08:33.028084 (XEN) VMExit: intr_info=00000000 errcode=00000000 
ilen=00000004
Dec 23 20:08:33.028093 (XEN)         reason=0000001b 
qualification=0000000000000000
Dec 23 20:08:33.040081 (XEN) IDTVectoring: info=00000000 errcode=00000000
Dec 23 20:08:33.040090 (XEN) TSC Offset = 0xffff297781d67b60  TSC Multiplier = 
0x0000000000000000
Dec 23 20:08:33.052076 (XEN) TPR Threshold = 0x00  PostedIntrVec = 0xf4
Dec 23 20:08:33.052085 (XEN) EPT pointer = 0x000000047f72301e  EPTP index = 
0x0000
Dec 23 20:08:33.064087 (XEN) PLE Gap=00000080 Window=00001000
Dec 23 20:08:33.064096 (XEN) Virtual processor ID = 0x8f0f VMfunc controls = 
0000000000000000
Dec 23 20:08:33.064103 (XEN) domain_crash called from vmcs.c:1830
Dec 23 20:08:33.076076 (XEN) Domain 3 (vcpu#0) crashed on cpu#6:
Dec 23 20:08:33.076085 (XEN) ----[ Xen-4.14-unstable  x86_64  debug=y   Not 
tainted ]----
Dec 23 20:08:33.076092 (XEN) CPU:    6
Dec 23 20:08:33.088079 (XEN) RIP:    0000:[<0000000000100036>]
Dec 23 20:08:33.088087 (XEN) RFLAGS: 0000000000000002   CONTEXT: hvm guest 
(d3v0)
Dec 23 20:08:33.088094 (XEN) rax: 0000000000000000   rbx: 00000000001aa000   
rcx: 0000000000000000
Dec 23 20:08:33.100078 (XEN) rdx: 0000000000000000   rsi: 0000000000000000   
rdi: 0000000000000000
Dec 23 20:08:33.100087 (XEN) rbp: 0000000000000000   rsp: 0000000000000000   
r8:  0000000000000000
Dec 23 20:08:33.112039 (XEN) r9:  0000000000000000   r10: 0000000000000000   
r11: 0000000000000000
Dec 23 20:08:33.124074 (XEN) r12: 0000000000000000   r13: 0000000000000000   
r14: 0000000000000000
Dec 23 20:08:33.124084 (XEN) r15: 0000000000000000   cr0: 0000000000000031   
cr4: 0000000000002050
Dec 23 20:08:33.136075 (XEN) cr3: 0000000000000000   cr2: 0000000000000000
Dec 23 20:08:33.136084 (XEN) fsb: 0000000000000000   gsb: 0000000000000000   
gss: 0000000000000000
Dec 23 20:08:33.148050 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 
0000   cs: 0000

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