From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 25 Sep 2019 23:12:59 -0000 Received: from mga18.intel.com ([134.134.136.126]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iDGSu-0003dy-DA for speck@linutronix.de; Thu, 26 Sep 2019 01:12:57 +0200 Subject: [MODERATED] Re: [PATCH v4 03/10] TAAv4 3 References: =?utf-8?q?=3Cfd65e9c9614b1ad51b15c6f0ada5266a5e73235b=2E1567543894=2Egi?= =?utf-8?q?t=2Epawan=2Ekumar=2Egupta=40linux=2Eintel=2Ecom=3E?= <5b6df5ee-a5b7-c281-de29-af6544b8abb6@intel.com> <20190906074645.GE13480@guptapadev.amr> <20190925224817.zcmzswojw5tmymul@treble> From: Dave Hansen Message-ID: Date: Wed, 25 Sep 2019 16:12:51 -0700 MIME-Version: 1.0 In-Reply-To: <20190925224817.zcmzswojw5tmymul@treble> Content-Type: multipart/mixed; boundary="VdWiQYa7a3K9rQxgq3sZor8KwMNmBQTGk"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --VdWiQYa7a3K9rQxgq3sZor8KwMNmBQTGk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/25/19 3:48 PM, speck for Josh Poimboeuf wrote: >>>> +static void tsx_enable(void) >>>> +{ >>>> + u64 tsx; >>>> + >>>> + rdmsrl(MSR_IA32_TSX_CTRL, tsx); >>>> + >>>> + tsx &=3D ~MSR_TSX_CTRL_RTM_DISABLE; >>>> + tsx &=3D ~MSR_TSX_CTRL_CPUID_CLEAR; >>>> + >>>> + wrmsrl(MSR_IA32_TSX_CTRL, tsx); >>>> +} >>> OK, so in the last patch we went through all the steps to enumerate t= his >>> sucker. Is that still being respected here? >> This doesn't affect the enumeration, only adds support for tsx=3Don ca= se. >> >>> Also, how would these bits have gotten set so that we need to clear t= hem >>> here? kexec? >> Yes. > So you're saying we need to support the case where we booted with > tsx=3Doff, but then want to kexec with tsx=3Don? >=20 > I don't know, that sounds a little esoteric to me. Do we actually > support that type of scenario for other cmdline options? I can't think of another case where an earlier kernel's actions change a later kernel's ability to enumerate CPU features. We always start from scratch in our enumeration. I look at it this way: the new MSR_IA32_TSX_CTRL effectively brings new enabling to enable TSX. This patch effectively brings TSX in line with other features, starting the enabling from scratch every time. It's certainly a weird situation, though. --VdWiQYa7a3K9rQxgq3sZor8KwMNmBQTGk--