From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63E32C04AAD for ; Tue, 7 May 2019 09:51:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37076204FD for ; Tue, 7 May 2019 09:51:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="2PrdrVae" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726889AbfEGJvv (ORCPT ); Tue, 7 May 2019 05:51:51 -0400 Received: from merlin.infradead.org ([205.233.59.134]:37100 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726063AbfEGJvv (ORCPT ); Tue, 7 May 2019 05:51:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WjYr1hVNE4iAw+7Hs4O5qCYhwgcyd/TjnQU+ylXG3fM=; b=2PrdrVaeBWK5E/7b/rRbhiuH/ GqK++COdKlCtPkcX95fgrq2I6Q64ZR8LsSFu8ifvUL65m3x9EUrbgQ8mwJfHdOJFcP6p7Csh/sQg7 BYp5B7mtEoPWCaUjRmNbDS5cHedj5cUB3Zi5M4RDPIQr7Q4SDbsB1haee3elg/NwXNU5TIcDEmGCc KYsf7ikSD5F1IHYJnF59ly4uHlMnNhUteGUIZopd3cN8Ht97Dkl5cbfaGzJG6Z8PRf2V+K7gwSKix gPsXj26qVM2fzQLkLc/ejAjJtLq0PC5vEPG4BQz+4hUEsxVoTWkqvP+MbifhCWRAOiKS57g0owZJp GTS8ReStg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hNwkb-0005Mq-0z; Tue, 07 May 2019 09:51:05 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 709F72023ADB7; Tue, 7 May 2019 11:51:03 +0200 (CEST) Date: Tue, 7 May 2019 11:51:03 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: Steven Rostedt , Andy Lutomirski , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , Andy Lutomirski , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , the arch/x86 maintainers , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , "open list:KERNEL SELFTEST FRAMEWORK" , stable , Masami Hiramatsu Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Message-ID: <20190507095103.GP2606@hirez.programming.kicks-ass.net> References: <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 06, 2019 at 07:22:06PM -0700, Linus Torvalds wrote: > We do *not* have very strict guarantees for D$-vs-I$ coherency on x86, > but we *do* have very strict guarantees for D$-vs-D$ coherency. And so > we could use the D$ coherency to give us atomicity guarantees for > loading and storing the instruction offset for instruction emulation, > in ways we can *not* use the D$-to-I$ guarantees and just executing it > directly. > > So while we still need those nasty IPI's to guarantee the D$-vs-I$ > coherency in the "big picture" model and to get the serialization with > the actual 'int3' exception right, we *could* just do all the other > parts of the instruction emulation using the D$ coherency. > > So we could do the actual "call offset" write with a single atomic > 4-byte locked cycle (just use "xchg" to write - it's always locked). > And similarly we could do the call offset *read* with a single locked > cycle (cmpxchg with a 0 value, for example). It would be atomic even > if it crosses a cacheline boundary. Very 'soon', x86 will start to #AC if you do unaligned LOCK prefixed instructions. The problem is that while aligned LOCK instructions can do the atomicity with the coherency protocol, unaligned (esp, line or page boundary crossing ones) needs that bus-lock thing the SDM talks about. For giggles, write yourself a while(1) loop that XCHGs across a page-boundary and see what it does to the rest of the system. So _please_, do not rely on unaligned atomic ops. We really want them to do the way of the Dodo.