Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp60293ybr; Fri, 22 May 2020 00:38:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLWDOqIuIev7RLJoxsbJ6WMBu7mKnfLGpyFt2nUDaPmX0zdgWK/HS6RC3pz190XQJfAiBV X-Received: by 2002:a17:906:934e:: with SMTP id p14mr6930734ejw.498.1590133131462; Fri, 22 May 2020 00:38:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590133131; cv=none; d=google.com; s=arc-20160816; b=rqb1/YhnI8t2XVG9PvGWrOxeyBEIn3Xob8Iko/Z96fVZLmewTILoyg+Cr3Kjk6360T RrATMoMUEYD67scXPsSJn70lSi38xxGGfaiB6yINcjwzt+3kR0BulN+RweJWMqXxfDlv HH8ZNpzXxZRPhZq+H2JBBNwvDuRnJ1eVF2O/ZxSKPiqmoUsFiqKKV+L9yJi0oXGn16e5 DpKObCG8qDjs2/HsQqysBj6/SnZSCCRexGVEy6mIFvAj8ACiILmZLw128vsGG+wIWNih 0aMqG+39ljiRGu18e915+RlgNe2n+orhmpOCfQlgEWW98C+XV5A0l4Wuakx7kC0BA3gc T0EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=6dqo2I27SUqShcwm9SmAh2VYfVhWy/Suab9vppKivzI=; b=vzwrsjpQuL5VC1wmw+JydyYDTanTXScbBw2vu0MwjEFa4GjYF/53H4Uvm8VRFlT5Wq TEv1A3lovZkgFw1YI102PlIQO/1wf5L/Q/F7LtyIvZrpM3OF0N62uRydZYbyGMJzpfxX EvALJxhIMMYeLQxuCZg50u2zFomOkb+u0cedAfOzldm9mCcB66cQ7Wk6PwWhUd5L7C44 LvL4Vy0oxBQxJBDW0YzNceGVYnCc77BsabURPMByVajYG02lf8i1NuzpbqYNM/RQ7y8g lqgVC+gnbn/+7D3NpAH1DJKbDI20wCL+RIF/kUGbw3pboQQW0iDIQhgInOYuNhjZ2KNZ 0omQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=citrix.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oe20si4832727ejb.135.2020.05.22.00.38.27; Fri, 22 May 2020 00:38:51 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=citrix.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728468AbgEVHgd (ORCPT + 99 others); Fri, 22 May 2020 03:36:33 -0400 Received: from ppsw-31.csi.cam.ac.uk ([131.111.8.131]:52194 "EHLO ppsw-31.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728189AbgEVHgd (ORCPT ); Fri, 22 May 2020 03:36:33 -0400 X-Greylist: delayed 930 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 May 2020 03:36:32 EDT X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:33852 helo=[192.168.1.219]) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jc1ya-000pAW-LG (Exim 4.92.3) (return-path ); Fri, 22 May 2020 08:20:16 +0100 Subject: Re: [patch V9 00/39] x86/entry: Rework leftovers (was part V) To: Thomas Gleixner , LKML Cc: Andy Lutomirski , 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)" References: <20200521200513.656533920@linutronix.de> From: Andrew Cooper Message-ID: <5e68aa83-feac-2aa7-10ee-aebebc60c83e@citrix.com> Date: Fri, 22 May 2020 08:20:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200521200513.656533920@linutronix.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/05/2020 21:05, Thomas Gleixner wrote: > Folks! > > This is V9 of the rework series. V7 and V8 were never posted but I used the > version numbers for tags while fixing up 0day complaints. The last posted > version was V6 which can be found here: > > https://lore.kernel.org/r/20200515234547.710474468@linutronix.de > > The V9 leftover series is based on: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry > > That branch contains the merged part 1-4 of the original 5 part series. > > V9 has the following changes vs. V6: > > - Rebase on tip x86/entry Apologies for opening a related can of worms. The new debug_enter() has propagated a pre-existing issue forward, ultimately caused by bad advice in the SDM. Because the RTM status bit in DR6 has inverted polarity, writing DR6 to 0 causes RTM to appear asserted to any logic which cares, despite RTM debugging not being enabled.  The same is true in principle for what is handed to userspace via u_debugreg[DR_STATUS]. On the subject of DR6, the SDM now reads: "Certain debug exceptions may clear bits 0-3. The remaining contents of the DR6 register are never cleared by the processor. To avoid confusion in identifying debug exceptions, debug handlers should clear the register (except bit 16, which they should set) before returning to the interrupted task." First of all, that should read "are never de-asserted by the processor" rather than "cleared", but the advice has still failed to learn from its first mistake.  The forward-compatible way to fix this is to set DR6_DEFAULT (0xffff0ff0) which also covers future inverted polarity bits. As for what to do about userspace, that is harder.  One approach is to express everything in terms of positive polarity (i.e. pass on dr6 ^ DR6_DEFAULT), so DR6_RTM only appears set when RTM debugging is enabled.  This approach is already taken with the VMCS PENDING_DBG field, so there is at least previous form. I realise that "do nothing" might be acceptable at this point, given the lack of support for RTM debugging. Thanks, ~Andrew