Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3533930yba; Tue, 7 May 2019 02:53:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFahqMfHm2NpEd06LYjK/hCTc7Tpy25/ctyxV/8hSvQKaxisL1/04+NPDEZZvvA8+JZuAB X-Received: by 2002:a17:902:6f17:: with SMTP id w23mr37788890plk.29.1557222798408; Tue, 07 May 2019 02:53:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557222798; cv=none; d=google.com; s=arc-20160816; b=LHTRk7Nfox925l827y6A2GswMY4dMUTVyuAE+86oHwJ6N8rRAQPeqPS9EYrthfRURl kZWaXnXptY/LkMoo5PEOrfZFrKTLWRACvIeOtjRzhWMJNE/YAn2JbBUJ/agxMqVWT7Ef GpRs4FF7DerWMNPSPr6zX4fzVgQ0jH4XXXNZxo6kUJMYmCyZAqWIQsL7Xs4aRx50U7dk hWNa65urQjmsYutRQTd3HYfU48DCXD8NdEJwj582Wzj86uZF42oSqHnZ9/d2/Fo+Q9+1 mO+XPj2V1od2G/73I3xPIVcmHrel20Fls6wTG8Bx7zi6FnV9AKIewH8yYlxdWouOdTEG nwNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=WjYr1hVNE4iAw+7Hs4O5qCYhwgcyd/TjnQU+ylXG3fM=; b=AKJk7GY1OTJYBFevFxN6iDpd7PIhqRJCNmHhU+oYVszx7HlRtQ4t7GW4DmFag71oJz tl8OjZBjDcwpg/HdDX1vKH8KRlZ0MGshbuLbZR9Yh10MeDluTA5wY/7kYLRkK/6ULfwG 1iW1jOAlaxxHptuhFfStXSn8np2vm4/z7StOLWAs1pMjK5MCO7Koe4TJp0Z4b5pNmn2h aP6hVYxL84nHPA6nAbsyB6g08NGPWHNFdoticeyW4EPpOQw2TBoFSqHDpK8lDc73e4wy +DwRYg602eJJKFcQ6sUiJJVCKEOlgE0lepXzi8XaVL9zCkFlMwCQ4akboobEj+PWxV5f ngmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=2PrdrVae; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s184si18775813pfs.275.2019.05.07.02.53.02; Tue, 07 May 2019 02:53:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=2PrdrVae; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726708AbfEGJvv (ORCPT + 99 others); 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.