Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1127041ybi; Fri, 31 May 2019 14:23:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcphH9mMTxklhP6+AWVrSX0np0MJt+2RsgzBTK8XF8AhBrg/9yWE1IF6t4wfrronEQeq1A X-Received: by 2002:aa7:9217:: with SMTP id 23mr12926621pfo.80.1559337831749; Fri, 31 May 2019 14:23:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559337831; cv=none; d=google.com; s=arc-20160816; b=t8YIs14rCbob104Te9irYRL8uUSrCst6Aop044/hfyImPiqgFA4kxL2L1ZqPBKq+Xw jbPt8IKNN/TOlhI/Au6i/3ZIT+Y6BFuyd4aFBs6jotyMO+AKr5A+qwxAE39JPs01urWV EDKSHN/FpB8ErUAoP8UnD6pmT/Y/b6vCU0pnimDWfxhw1WWvbHQa2tm3fGtbOQMw/zH/ hr+sU8Po9JWpowVL/2t4UXCAeKlpFdS80rUCkA0eRhJL23+6T9K4Mg6vrAZji7JtVPg7 ANP/NLPiPCmT9wPk9d2d2zCbPggo6ptklvx5bUvXXCwqMnCmL+mKCAFUGDzqssegvNGY 1rRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=iTNgN4/VlCA0W95p4CulhjftDWk81O+IK05qnHflrIM=; b=HBV0dGY/zRZVGyuzNAskWBhzpQggiNOlKJxiNa/PkaCK2/+fv0q6W/R4SSlSEIqrlX 4LstyRMaA1prKJmjKR1KiqRyVU989WQs8U6rbnrCVe59225nrB3asfjmhUy9K43ts/tX Y0+VPo22xzzGfEoeqbvbR1ekBVQTLBSIP8mRRPuiA7ya7UzsWvgmGOD/t+6lWOihtn6N Fnjyx8R76PLHma9FV8fgf9EWBZntna/r9SCaeEST038zbOlHu6cvaPSRdukqa737iLOO n/SFVRNUBw6Uw1Wiy0tZkUaZnssT7Od2O2bujxp14TQwWDfIkOIhRDtjPMWrVt/Foh9v G0lQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=idTUrPhs; 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 l6si6595431pgp.382.2019.05.31.14.23.35; Fri, 31 May 2019 14:23:51 -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=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=idTUrPhs; 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 S1727589AbfEaVWa (ORCPT + 99 others); Fri, 31 May 2019 17:22:30 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:45214 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726719AbfEaVW3 (ORCPT ); Fri, 31 May 2019 17:22:29 -0400 Received: by mail-pl1-f193.google.com with SMTP id x7so3498411plr.12 for ; Fri, 31 May 2019 14:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iTNgN4/VlCA0W95p4CulhjftDWk81O+IK05qnHflrIM=; b=idTUrPhsF9TpGZuUC1bRliLtS9ZWiTNSaCygW1w6J9GYZ9sBUWoI1634c5cj666MdG /s8FpT52XrHQrww/RVeQSf/syKZ9IP0++PTL85nuPSv0tvIaXTr3Ee/fk5J9A+DoE56c mIMSH1DACQYI647Ge6mUabpeMvJt4mm+Py7wue4fTB34zLM6M8S7KyjAY3pMkLS8nCzz E+mbg7oy8VaHQjEtYHfX+mgD1Eu6WzB+bb2Z8Ny8sqCsNl9Aq2Uzuo1XGjwWZN5MVEQy f0uc3ulIjQBgsEVeGVPEgoEdhGI0q5gqqockeCbcHkCV/7F9BTHOoSJnZp8dwpgo6LSv Mfig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iTNgN4/VlCA0W95p4CulhjftDWk81O+IK05qnHflrIM=; b=kCCnYTs8sTJNNhDRGEex3FIvf4orchv/im8fdYuxypGdUJyTQs3frrhvHISUtdMCKr Wy6qRbUuckiRHUW9acahGTTHRf+ZaVqXA+8pEtNqf0E6Z8eHwChlepgJxBV9Y2k0Gdei E5cKQH9qXLWJ/tjRzlqYQEQ53lmecufjEIlR1T5zLmpCfmUnDa6lvEImKU263ebLbInH 54sccHpC1pHlUxakoXd8MQqz4SQdcvfsjYWqg+MM0NHEpnja0UvbJAjcV0eXJvIclZmm 3/+yLskR+YaLkesbOo3jQKaGm3RjKR8eimYj260rFilzbyaVzF334NP15u638q+p5hnF Yi5w== X-Gm-Message-State: APjAAAXSL4RRVMFwja6C1DT11QQyb5u+nhFzS9ggbz7b+Rx7Vx2jCGC0 6BOdOBqrL9Nxi1KHrpZX1hFQBA== X-Received: by 2002:a17:902:7581:: with SMTP id j1mr12044213pll.23.1559337749091; Fri, 31 May 2019 14:22:29 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:ec0c:2d9e:92:467e? ([2601:646:c200:1ef2:ec0c:2d9e:92:467e]) by smtp.gmail.com with ESMTPSA id d24sm5678812pjv.24.2019.05.31.14.22.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 May 2019 14:22:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v4] x86/power: Fix 'nosmt' vs. hibernation triple fault during resume From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Fri, 31 May 2019 14:22:27 -0700 Cc: Andy Lutomirski , "Rafael J. Wysocki" , Josh Poimboeuf , "Rafael J. Wysocki" , Thomas Gleixner , the arch/x86 maintainers , Pavel Machek , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Peter Zijlstra , Linux PM , Linux Kernel Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <98E57C7E-24E2-4EB8-A14E-FCA80316F812@amacapital.net> References: <20190531051456.fzkvn62qlkf6wqra@treble> <5564116.e9OFvgDRbB@kreacher> To: Jiri Kosina Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 31, 2019, at 2:05 PM, Jiri Kosina wrote: >=20 >> On Fri, 31 May 2019, Andy Lutomirski wrote: >>=20 >> The Intel SDM Vol 3 34.10 says: >>=20 >> If the HLT instruction is restarted, the processor will generate a >> memory access to fetch the HLT instruction (if it is >> not in the internal cache), and execute a HLT bus transaction. This >> behavior results in multiple HLT bus transactions >> for the same HLT instruction. >=20 > Which basically means that both hibernation and kexec have been broken in=20= > this respect for gazillions of years, and seems like noone noticed. Makes=20= > one wonder what the reason for that might be. >=20 > Either SDM is not precise and the refetch actually never happens for real=20= > (or is always in these cases satisfied from I$ perhaps?), or ... ? >=20 > So my patch basically puts things back where they have been for ages=20 > (while mwait is obviously much worse, as that gets woken up by the write=20= > to the monitored address, which inevitably does happen during resume), but= =20 > seems like SDM is suggesting that we've been in a grey zone wrt RSM at=20 > least for all those ages. >=20 > So perhaps we really should ditch resume_play_dead() altogether=20 > eventually, and replace it with sending INIT IPI around instead (and then=20= > waking the CPUs properly via INIT INIT START). I'd still like to do that=20= > for 5.3 though, as that'd be slightly bigger surgery, and conservatively=20= > put things basically back to state they have been up to now for 5.2. >=20 Seems reasonable to me. I would guess that it mostly works because SMI isn=E2= =80=99t all that common and the window where it matters is short. Or maybe t= he SDM is misleading.=