SSB Fix #2]]

PATCH New Konrad Rzeszutek Wilk 1 participant 1 message May 19, 2018

lore

Share & tools

lore

Konrad Rzeszutek Wilk

author

2018-05-19 22:04 UTC #0 lore raw

PATCH 2/2 SSB Fix #2]]

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 <[email protected]> -----

Date: Sat, 19 May 2018 13:49:29 -0400
From: Boris Ostrovsky <[email protected]>
To: Konrad Rzeszutek Wilk <[email protected]>
Subject: Re: [[email protected]: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2]

Quoted 11 lines · Boris Ostrovsky

Quoted 1 line · Konrad Rzeszutek Wilk
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

Quoted 22 lines

   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]#

Quoted 58 lines

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
Quoted 47 lines
----- Forwarded message from speck for Thomas Gleixner <[email protected]> -----
Date: Sat, 19 May 2018 10:33:48 +0200 (CEST)
From: speck for Thomas Gleixner <[email protected]>
To: [email protected]
Subject: Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
Quoted 11 lines · speck for Konrad Rzeszutek Wilk
Quoted 9 lines · speck for Thomas Gleixner
Quoted 8 lines
(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)
Quoted 6 lines
Quoted 3 lines
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 -----