From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516704264; cv=none; d=google.com; s=arc-20160816; b=PC5SIzYMjOnnsmcWEYUfUg/lPzUVBCxik89ORaNSlDX3tIAUytnqYlgCsu4NojpKeN 8GKImX8rINU7fa8Ap6buqrjh872z9VJ/eSyufsnKOGcPRHUm6Msn8k9UQibYG9hObOrs 9zAHwoyqE5Hm7FZYaB03dmqC9ZNCPxgDmYXJ4Kp3W1Q69xIWqBbBX57WDh8BSc3AqKpQ iJvO/uC0y6nhApSgPm416b3NkAGAP3fpg9iqHPKkhzdghCpB7CFaMz79yMwbKUZIJzF7 fn4Ll+6Kjx7eyIRqk7+VwhenZn/8xfl69ClaZJWXahuL/VD/HPMtQVW2fT8wUA7opxuI SwHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:sender:dkim-signature:arc-authentication-results; bh=YAWYFMhQX+vTnERCew9XnisUEGI7ZOXkHi7BtPsRVls=; b=irbNJ6iNEg96CzUjGgyZbrDWrfTO3d1cj4c9i6VjbqdrMDa7hgKVOQX7AXHbMjdlIj 6wy/sqC+epSyAwXam08i/BjD+bczJjqSMb2Fmrxe36Wp8zDrHBCGI35wohdG+pQ1SfDZ 0xH/pdiK+Ne9Sh0MmVnLUKKqokDesJ2n6dUy8XFEuh3QlM55yMaX9NcLq8BrMOuvl3PW oZRFHNe2/fUg2Ss5tVYpRjZFhtUIwU27DgMCWcn/dJVBT2Ob8JryhJ2rp8TDXKP47kX4 NuAbBlrnxc/cgH4v9mZjM2+LRyIKFjXHv38Wfn9qARePUfm2XQPIN4PvJ+5ncXWDlqWd 6LYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=W1h9nTWq; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=W1h9nTWq; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com X-Google-Smtp-Source: AH8x22744CFou8J7k0AckoFfV94NGnyADQ8Gz69XQol6DktFcELCiISgvez9XRZX06WvaKcV5h9szg== Sender: Ingo Molnar Date: Tue, 23 Jan 2018 11:44:20 +0100 From: Ingo Molnar To: David Woodhouse Cc: Linus Torvalds , KarimAllah Ahmed , Linux Kernel Mailing List , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , the arch/x86 maintainers , Arjan Van De Ven Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Message-ID: <20180123104420.nnuugvqrm7tx7ta7@gmail.com> References: <1516566497.9814.78.camel@infradead.org> <1516572013.9814.109.camel@infradead.org> <1516638426.9521.20.camel@infradead.org> <20180123072930.soz25cyky3u4hpgv@gmail.com> <20180123075358.nztpyxympwfkyi2a@gmail.com> <1516699832.9521.123.camel@infradead.org> <20180123101532.obioudsu3ecm4rez@gmail.com> <1516703244.9521.132.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516703244.9521.132.camel@infradead.org> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590379690749812136?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * David Woodhouse wrote: > On Tue, 2018-01-23 at 11:15 +0100, Ingo Molnar wrote: > > > > BTW., the reason this is enabled on all distro kernels is because the overhead > > is  a single patched-in NOP instruction in the function epilogue, when tracing > > is  disabled. So it's not even a CALL+RET - it's a patched in NOP. > > Hm? We still have GCC emitting 'call __fentry__' don't we? Would be nice to get > to the point where we can patch *that* out into a NOP... or are you saying we > already can? Yes, we already can and do patch the 'call __fentry__/ mcount' call site into a NOP today - all 50,000+ call sites on a typical distro kernel. We did so for a long time - this is all a well established, working mechanism. > But this is a digression. I was being pedantic about the "0 cycles" but sure, > this would be perfectly tolerable. It's not a digression in two ways: - I wanted to make it clear that for distro kernels it _is_ a zero cycles overhead mechanism for non-SkyLake CPUs, literally. - I noticed that Meltdown and the CR3 writes for PTI appears to have established a kind of ... insensitivity and numbness to kernel micro-costs, which peaked with the per-syscall MSR write nonsense patch of the SkyLake workaround. That attitude is totally unacceptable to me as x86 maintainer and yes, still every cycle counts. Thanks, Ingo