All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: osstest service owner <osstest-admin@xenproject.org>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-intel
Date: Tue, 24 Dec 2019 15:23:58 +0100	[thread overview]
Message-ID: <20191224142358.GD11756@Air-de-Roger> (raw)
In-Reply-To: <E1ij8Co-0002VP-1b@osstest.test-lab.xenproject.org>

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@citrix.com>
>   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@citrix.com>
>       Reviewed-by: Jan Beulich <jbeulich@suse.com>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-12-24 14:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-22 20:52 [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-intel osstest service owner
2019-12-24 14:23 ` Roger Pau Monné [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-11-17  9:28 osstest service owner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191224142358.GD11756@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.