From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2120.oracle.com ([141.146.126.78]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fK9xN-0004aB-9D for speck@linutronix.de; Sun, 20 May 2018 00:04:07 +0200 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4JM0a17148773 for ; Sat, 19 May 2018 22:03:57 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2j2bw811gh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 19 May 2018 22:03:57 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4JM3uwa025457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 19 May 2018 22:03:57 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4JM3uV3018263 for ; Sat, 19 May 2018 22:03:56 GMT Date: Sat, 19 May 2018 18:03:46 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] [boris.ostrovsky@oracle.com: Re: [speck@linutronix.de: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2]] Message-ID: <20180519220136.GA8859@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: Figured it out. We have in our 4.14 kernel (aka UEK5) backports of this _and_ the IBRS pile that never got accepted upstream. One of those patches is the: printk("FEATURE SPEC_CTRL Present\n") which is called from 'init_speculation_control' and we end up with this disaster as the infrastructure is not yet setup. I confused which tree test results we had and ended coming to the wrong conclusion. My apologies for wasting your folks time. ----- Forwarded message from Boris Ostrovsky ---= -- Date: Sat, 19 May 2018 13:49:29 -0400 From: Boris Ostrovsky To: Konrad Rzeszutek Wilk Subject: Re: [speck@linutronix.de: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SS= B Fix #2] On 05/19/2018 01:45 PM, Boris Ostrovsky wrote: >=20 >=20 > On 05/19/2018 11:13 AM, Konrad Rzeszutek Wilk wrote: > > You wouldn't have a call chain from your X6? >=20 >=20 > I don't have upstream build but on uek5 port: >=20 > xen_start_kernel > =C2=A0get_cpu_cap > =C2=A0 init_speculation_control Unless, of course, upstream code does not call init_speculation_control() from get_cpu_cap()? -boris > =C2=A0=C2=A0 pr_info > =C2=A0=C2=A0=C2=A0 printk > =C2=A0=C2=A0=C2=A0=C2=A0 vprintk_func > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vprintk_default > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vprintk_emit > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 logbuf_lock_irqsave > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 printk_safe_enter_irqsave > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local_irq_save >=20 >=20 > I manually unwrapped Xen splat but it is certainly a cli: >=20 > (XEN) RIP:=C2=A0=C2=A0=C2=A0 e033:[] >=20 > [root@bur-virt-x6-2-100 linux-osv]# grep ffffffff8106fcf4 vmlinux.s > ffffffff8106fcf4:=C2=A0=C2=A0=C2=A0 fa=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 cli > [root@bur-virt-x6-2-100 linux-osv]# >=20 > [root@bur-virt-x6-2-100 linux-osv]# addr2line -e vmlinux ffffffff8106fcf4 > /data/linux-osv/./arch/x86/include/asm/irqflags.h:44 > [root@bur-virt-x6-2-100 linux-osv]# >=20 > I can try upsteam tree is you can point me to it. >=20 > But again, the point here is not cli. It's that we are essentially calling > printk before *anything* is set up. >=20 >=20 > -boris >=20 >=20 >=20 >=20 > >=20 > > ----- Forwarded message from speck for Thomas Gleixner > > ----- > >=20 > > Date: Sat, 19 May 2018 10:33:48 +0200 (CEST) > > From: speck for Thomas Gleixner > > To: konrad.wilk@oracle.com > > Subject: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 > >=20 > > On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote: > > > On Fri, May 18, 2018 at 09:57:47PM +0200, speck for Thomas > > > Gleixner wrote: > > > > > (XEN)=C2=A0=C2=A0=C2=A0 0000000000000000 0000000000000000 > > > > > 0000000000000000 0000000000000000 > > > > > (XEN)=C2=A0=C2=A0=C2=A0 0000000000000000 0000000000000000 > > > > > 0000000000000000 0000000000000000 > > > > > (XEN)=C2=A0=C2=A0=C2=A0 0f00000060c0c748 ccccccccccccc305 > > > > > cccccccccccccccc cccccccccccccccc > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > > > > (XEN) APIC error on CPU0: 40(00) > > > >=20 > > > > The above is pretty useless and undecodable. So what makes > > > > Dom0 crash in a > > > > way that the machine needs to be rebooted? The call to get_cpu_cap()? > > >=20 > > > Yup. B/c there is no early callback installed yet and it ends up > > > using 'cli' > >=20 > > Sigh, 'using CLI' is not helpful either. The callchain and where the > > CLI is > > invoked, is the interesting information. > >=20 > > But well, as you say its get_cpu_cap() I went and stared at it for while, > > but there is absolutely NOTHING which might invoke CLI. It was nothing > > before SSB and SSB did not add anything either. > >=20 > > So this patch is voodoo and makes exactly zero sense, unless you come up > > with some sensible explanation. > >=20 > > Thanks, > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0tglx > >=20 > >=20 > >=20 > > ----- End forwarded message ----- > >=20 ----- End forwarded message -----