Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3019322ybk; Mon, 18 May 2020 13:47:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1vRtWCpM86p8+OmRkcacxMYJjWhpBNbxw5OLYzu8qdEDULQlDzq8aZ0JzBpyXbtMWbNV7 X-Received: by 2002:aa7:c4da:: with SMTP id p26mr2002076edr.184.1589834854941; Mon, 18 May 2020 13:47:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589834854; cv=none; d=google.com; s=arc-20160816; b=AqITBE4uiChq1ERsJlutYf+VO3vJsspjEc43gyUDcuiqcDkgbK+84ILxB2MdceftQ0 Tt9REMFAPFf6yAzDVaJHlrllmrG2txVtmEiMcEijTxxiDsvQ7/HRRLmGWtFrQP/I3JkF SCtFs6ZGOs9YXXKuCo4YmeQk8fMHkveoUn7/rby2Z6dC40uHoExWqKu3PlEY/RUwXKMq uUHL3VR5z+zRZAqaTTq1ZMOGEeoon5aYMU4eY7OdVdOGlV/YzkVpf6pJ3F0JiyoMvVpN IbA5caM1p18ZBVBkHVjpoGl459qv7pzAOS8UCg4kSCDX88nkvPv3LbyjVv2cK9D1MmMP LZkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=I/720+I+MPeCh3zgTjAbb7viQr0Z6KCAe8C95X5VJu0=; b=NGUz6KkAY5xcxvqMh+h8QG05Yu1Yad71zyugdjUv4q8OF9YxPBn1tSO8MqwTsvV7BW ywuP5E2N77UhgxkalI3QUqg7EJoJi8hMR6+cI8f289CY9h74wJz3bCVD7Da4a4muTT0A Fk05+viZLbVJmRFpuwFt9MmVPY+yhdsfawMMWB7ZkT+gHm509iDxmv+6dQEIW0P+D766 wFK/YNTxYCyYkxXHfbNs2qEQt1cu0GZkLEDzE6yk4hkoSEaMwl8lsUzlxSM5pcld/FHX b3pTKlVQXlZ11IR/WfiN8krNV0rqL7jJN474eoER0EMR9QQ4OHIh7JqOAethT8DwQN2r bLRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="clKX/hUx"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z5si7090798edi.111.2020.05.18.13.47.12; Mon, 18 May 2020 13:47:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="clKX/hUx"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727944AbgERUnH (ORCPT + 99 others); Mon, 18 May 2020 16:43:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:60166 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727037AbgERUnG (ORCPT ); Mon, 18 May 2020 16:43:06 -0400 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5E1DF20756 for ; Mon, 18 May 2020 20:43:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589834585; bh=DVpqsXwckSCUbAJoI8aDzAaM3G/Kl8m8ZNDDVrz/OeU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=clKX/hUxYgFS2FFs8J3IDHgLC/wBOtPCM7cN4hkBHup2WFFRJBBlFYMS7no6yHv+u kDuqqHtH61NuCg1fqB0rdA9fSWpMcuDa8N/GoCWwVujIqUgLtYysUFvrbsAZPYiI5g mUs76enQ6tuPUrEpsw16/Z4o6M6HAMId3ffPB4Xw= Received: by mail-wm1-f53.google.com with SMTP id m12so862310wmc.0 for ; Mon, 18 May 2020 13:43:05 -0700 (PDT) X-Gm-Message-State: AOAM532X3XwwUVdWxbXl5nW+WB38Z4xtDcWuyaWwMKnW07J8q0qgZCYf yx4nrQ8fwX4OwjyIf/ZxF0C6tfLo2WOSnQZEQskIrg== X-Received: by 2002:a1c:9989:: with SMTP id b131mr1246250wme.176.1589834583789; Mon, 18 May 2020 13:43:03 -0700 (PDT) MIME-Version: 1.0 References: <20200515234547.710474468@linutronix.de> <20200515235124.783722942@linutronix.de> <87zha7c5h5.fsf@nanos.tec.linutronix.de> <877dx9zn47.fsf@nanos.tec.linutronix.de> In-Reply-To: <877dx9zn47.fsf@nanos.tec.linutronix.de> From: Andy Lutomirski Date: Mon, 18 May 2020 13:42:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch V6 04/37] x86: Make hardware latency tracing explicit To: Thomas Gleixner Cc: Andy Lutomirski , LKML , X86 ML , "Paul E. McKenney" , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon , Tom Lendacky , Wei Liu , Michael Kelley , Jason Chen CJ , Zhao Yakui , "Peter Zijlstra (Intel)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 18, 2020 at 1:03 AM Thomas Gleixner wrote: > > Andy Lutomirski writes: > > On Sun, May 17, 2020 at 1:48 AM Thomas Gleixner wrote: > >> Remember this is about ensuring that all the state is properly > >> established before any of this instrumentation muck can happen. > >> > >> DR7 handling is specific to #DB and done even before nmi_enter to > >> prevent recursion. > > > > So why is this change needed? > > We really want nmi_enter() to be the carefully crafted mechanism which > establishes correct state in whatever strange context the exception > hits. Not more, not less. > > Random instrumentation has absolutely no business there and I went a > long way to make sure that this is enforcible by objtool. > > Aside of that the tracing which is contained in nmi_enter() is about > taking timestamps for hardware latency detection. If someone runs > hardware latency detection with active break/watchpoints then I really > can't help it. > Okay. I'll stop looking for the bug you're fixing, then.