From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: speck@linutronix.de
Subject: [MODERATED] [boris.ostrovsky@oracle.com: Re: [speck@linutronix.de: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2]]
Date: Sat, 19 May 2018 18:03:46 -0400 [thread overview]
Message-ID: <20180519220136.GA8859@localhost.localdomain> (raw)
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.
<sigh>
My apologies for wasting your folks time.
----- Forwarded message from Boris Ostrovsky <boris.ostrovsky@oracle.com> -----
Date: Sat, 19 May 2018 13:49:29 -0400
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [speck@linutronix.de: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2]
On 05/19/2018 01:45 PM, Boris Ostrovsky wrote:
>
>
> On 05/19/2018 11:13 AM, Konrad Rzeszutek Wilk wrote:
> > You wouldn't have a call chain from your X6?
>
>
> I don't have upstream build but on uek5 port:
>
> xen_start_kernel
> get_cpu_cap
> init_speculation_control
Unless, of course, upstream code does not call init_speculation_control() from
get_cpu_cap()?
-boris
> pr_info
> printk
> vprintk_func
> vprintk_default
> vprintk_emit
> logbuf_lock_irqsave
> printk_safe_enter_irqsave
> local_irq_save
>
>
> I manually unwrapped Xen splat but it is certainly a cli:
>
> (XEN) RIP: e033:[<ffffffff8106fcf4>]
>
> [root@bur-virt-x6-2-100 linux-osv]# grep ffffffff8106fcf4 vmlinux.s
> ffffffff8106fcf4: fa cli
> [root@bur-virt-x6-2-100 linux-osv]#
>
> [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]#
>
> I can try upsteam tree is you can point me to it.
>
> But again, the point here is not cli. It's that we are essentially calling
> printk before *anything* is set up.
>
>
> -boris
>
>
>
>
> >
> > ----- Forwarded message from speck for Thomas Gleixner
> > <speck@linutronix.de> -----
> >
> > Date: Sat, 19 May 2018 10:33:48 +0200 (CEST)
> > From: speck for Thomas Gleixner <speck@linutronix.de>
> > To: konrad.wilk@oracle.com
> > Subject: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
> >
> > 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) 0000000000000000 0000000000000000
> > > > > 0000000000000000 0000000000000000
> > > > > (XEN) 0000000000000000 0000000000000000
> > > > > 0000000000000000 0000000000000000
> > > > > (XEN) 0f00000060c0c748 ccccccccccccc305
> > > > > cccccccccccccccc cccccccccccccccc
> > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > > > (XEN) APIC error on CPU0: 40(00)
> > > >
> > > > 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()?
> > >
> > > Yup. B/c there is no early callback installed yet and it ends up
> > > using 'cli'
> >
> > Sigh, 'using CLI' is not helpful either. The callchain and where the
> > CLI is
> > invoked, is the interesting information.
> >
> > 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.
> >
> > So this patch is voodoo and makes exactly zero sense, unless you come up
> > with some sensible explanation.
> >
> > Thanks,
> >
> > tglx
> >
> >
> >
> > ----- End forwarded message -----
> >
----- End forwarded message -----
next reply other threads:[~2018-05-19 22:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-19 22:03 Konrad Rzeszutek Wilk [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-05-19 3:04 [MODERATED] [boris.ostrovsky@oracle.com: Re: [speck@linutronix.de: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2]] Konrad Rzeszutek Wilk
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=20180519220136.GA8859@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=speck@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).