[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160614191916.GI30015@pd.tnic>
Date: Tue, 14 Jun 2016 21:19:16 +0200
From: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Lukasz Anaczkowski <lukasz.anaczkowski@...el.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
tglx@...utronix.de, mingo@...hat.com, ak@...ux.intel.com,
kirill.shutemov@...ux.intel.com, mhocko@...e.com,
akpm@...ux-foundation.org, hpa@...or.com,
harish.srinivasappa@...el.com, lukasz.odzioba@...el.com,
grzegorz.andrejczuk@...el.com, lukasz.daniluk@...el.com
Subject: Re: [PATCH v2] Linux VM workaround for Knights Landing A/D leak
On Tue, Jun 14, 2016 at 11:54:24AM -0700, Dave Hansen wrote:
> Lukasz, Borislav suggested using static_cpu_has_bug(), which will do the
> alternatives patching. It's definitely the right thing to use here.
Yeah, either that or do an
alternative_call(null_func, fix_pte_peak, X86_BUG_PTE_LEAK, ...)
or so and you'll need a dummy function to call on !X86_BUG_PTE_LEAK
CPUs.
The static_cpu_has_bug() thing should be most likely a penalty
of a single JMP (I have to look at the asm) but then since the
callers are inlined, you'll have to patch all those places where
*ptep_get_and_clear() get inlined.
Shouldn't be a big deal still but...
"debug-alternative" and a kvm guest should help you there to get a quick
idea.
HTH.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists