Received: by 10.223.176.46 with SMTP id f43csp1917801wra; Thu, 25 Jan 2018 02:02:28 -0800 (PST) X-Google-Smtp-Source: AH8x227XBhfYb0hPYoQ52vBWGpoM552/bNWahveUipoxF1SJ7hv4oRGJYQl4AHFx40cLvMuNbraQ X-Received: by 2002:a17:902:8f86:: with SMTP id z6-v6mr10806787plo.352.1516874548749; Thu, 25 Jan 2018 02:02:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516874548; cv=none; d=google.com; s=arc-20160816; b=XV1iITqZz3r4XS1qFTBD+3ziSsN95au8yurXqJggOZ0+T5wy0t0WEdQpYaGdjCUwEH 3Yj9EZ4RpEZIwGjGVMGcIg/jMBEnsEkFxjLf24r1JlpN4yzNwK1aYohxlVX4xHge0ace qgLooivn8UlJqhgT1q29VYhm0XpFvWFGWSE3lVk8lPncqsVsrrpX/rcghftCwgE7Txo8 DMQhm+dR8SFhOBrkiVauUscD5SVCiM4Fd7wirfM/iWxUmJ4V5mz7JTe6EIbQxVbUm8/l IOf2BcORWUbDZROiJG/gKllCD7SUGhA7F3SOCDaQAvu/cLnrQjGLweCc1vrcAaT34akC +I0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=VvMEO9nPo9ShwkDXm1Z7vlLHuXZ1Gn/TP/dB1hScK5E=; b=uQF82ieYQLPxayo3rgFJCY4qnANdgKcWmI0BPyw793h05PitczJXmbI/GLmnKjd4G+ WJCHRvW0YS8GATxuMYUlW69war11HZv0xvEwYwY8knXNOMfNbO21kTyrm+nynOKI8BPU ledB91GlvXbDXkoLtvKeVn8spATNZaq1Pm0HOKMwWKcD5qcO6ulhi5df0DqCi8zHi7ew mGXplWvOALCvAKgSj6PTx6MsW7T8BDMqvnKdSaPYJYTvM8Lc3vFqlAUX7Pqzm4lVvfya /8SywHT3CBCHT/VGz0A5z8ENoJFvx0A5t7phkgO+XUnoeSZfgq7b29RMTg1Jmq3OND90 kX5w== ARC-Authentication-Results: i=1; mx.google.com; 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 d5si4428609pfm.149.2018.01.25.02.02.14; Thu, 25 Jan 2018 02:02:28 -0800 (PST) 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; 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 S1751571AbeAYKBL (ORCPT + 99 others); Thu, 25 Jan 2018 05:01:11 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:34516 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263AbeAYKBI (ORCPT ); Thu, 25 Jan 2018 05:01:08 -0500 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eeeIW-0008H4-GH; Thu, 25 Jan 2018 10:58:20 +0100 Date: Thu, 25 Jan 2018 11:01:00 +0100 (CET) From: Thomas Gleixner To: David Woodhouse cc: Peter Zijlstra , arjan@linux.intel.com, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, bp@alien8.de, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org, dave.hansen@intel.com, gnomes@lxorguk.ukuu.org.uk, ashok.raj@intel.com, mingo@kernel.org Subject: Re: [PATCH v4 5/7] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown In-Reply-To: <1516874209.30244.38.camel@infradead.org> Message-ID: References: <1516872189-16577-1-git-send-email-dwmw@amazon.co.uk> <1516872189-16577-6-git-send-email-dwmw@amazon.co.uk> <20180125094258.GZ2228@hirez.programming.kicks-ass.net> <1516874209.30244.38.camel@infradead.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-850804649-1516874461=:2020" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-850804649-1516874461=:2020 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 25 Jan 2018, David Woodhouse wrote: > On Thu, 2018-01-25 at 10:42 +0100, Peter Zijlstra wrote: > > On Thu, Jan 25, 2018 at 09:23:07AM +0000, David Woodhouse wrote: > > > +static bool __init early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c) > > > +{ > > > +     u64 ia32_cap = 0; > > > + > > > +     if (x86_match_cpu(cpu_no_meltdown)) > > > +                return false; > > > + > > > +     if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES)) > > > +             rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap); > > > > I think it was suggested a while back to write this like: > > > >         if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES) && > >             !rdmsrl_safe(MSR_IA32_ARCH_CAPABILITIES, ia32_cap)) > > > > to deal with funny virt scenarios where they accidentally advertise the > > CPUID bit but don't in fact provide the MSR. > > It was indeed suggested, but I was a bit confused by that. Because the > CPUID bit exists *purely* to advertise the existence of that MSR; > nothing more. > > If it doesn't exist we'll end up with zero in ia32_cap anyway, which > will mean we *won't* see the RDCL_NO bit, and won't disable the > Meltdown flag. And using rdmsrl() has the benefit of running into the ex_handler_rdmsr_unsafe() exception handler, which emits a warning. The value returned in ia32_cap is 0. Thanks, tglx --8323329-850804649-1516874461=:2020--