Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9098158ybi; Wed, 10 Jul 2019 04:41:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTNsSA5EDAIdMeZ1DqHsqdcc605R3pE0NIpKk8dSiYzhVKzFgpHCV8pVF/7PXDAndSWq67 X-Received: by 2002:a63:1658:: with SMTP id 24mr37715431pgw.167.1562758881841; Wed, 10 Jul 2019 04:41:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562758881; cv=none; d=google.com; s=arc-20160816; b=MwVOt+D67BagyYvUM+tYu0KgF+qhBLQ4lFx+OaT9wkwnaqDY9hcc6HYdCOZJg35/cZ ROgW9hssyebir8GEjqCr65iTy3ThDieqBjCatXZbyiPtYGfxNpHOwSMEc7cqKoeATaLE tCPWbYOrucsNXqkhnmZUtHAFN4F/Bm1h6q8QXDXRmkbHlVXVad5agxjq8B/C+w6bdGKa mLfZP5HlLQ7fnCjZXVfGj/9/3XGQp8ohVmJGcTF42XiBiulNvPuPMJ8i9yPr3ptn0RUG IqsJSOb5Qjx8Ci6KWj5gfI4jqQHiabztGgwx39uK1OJEurtn3mcNsZCJQC3ojZRa7tPE dIrg== 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; bh=UPg3FHXHmWHhleSNSgFgS7pV9yItPUM0RJdjE68VIxU=; b=chFwSn/HkJkTFc/ohGxb2HPMjRAP7sH5Fm//zxoD0YiDKL7BunAPNbQJj82anLEWih lqvK639MN0Wxu2x+LtFQQ1a5/x5gm+JfVzjw+4gvGzZQo4ekXDQRqw+XI8gkR3kfqpvO CWmdPw4RcoL8P8GkfQm8nSV1eBftZPNKxEvuT8Gm7zjMBLbYoESKpqDwrHE0ws6JXTjW rO72a98YV0lbhetq9aYfTKtKRZKQOiNX0fj6/Qo9VY9ipRFhBrZLeyeju7NVYYySOSRo loG+WMDc0uZMat8ktM8AQIulFBnIK0dEpbGyHZsGPIMUdljvRI8fSshbyHq1/7GdspR0 elpg== 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 l4si2058869pjq.69.2019.07.10.04.41.06; Wed, 10 Jul 2019 04:41:21 -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; 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 S1727289AbfGJLd4 (ORCPT + 99 others); Wed, 10 Jul 2019 07:33:56 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:47452 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbfGJLd4 (ORCPT ); Wed, 10 Jul 2019 07:33:56 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hlAr8-0001Cm-7T; Wed, 10 Jul 2019 13:33:50 +0200 Date: Wed, 10 Jul 2019 13:33:48 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini cc: "Lendacky, Thomas" , Josh Poimboeuf , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Andrew Cooper , Pu Wen , Borislav Petkov Subject: Re: [RFC PATCH] x86: Remove X86_FEATURE_MFENCE_RDTSC In-Reply-To: <4a13c6a3-a13e-d3e5-0008-41a6d47a6eff@redhat.com> Message-ID: References: <45f247d2-80f5-6c8c-d11e-965a3da8a88f@amd.com> <4a13c6a3-a13e-d3e5-0008-41a6d47a6eff@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 Jul 2019, Paolo Bonzini wrote: > On 08/07/19 21:32, Lendacky, Thomas wrote: > >> AMD and Intel both have serializing lfence (X86_FEATURE_LFENCE_RDTSC). > >> They've both had it for a long time, and AMD has had it enabled in Linux > >> since Spectre v1 was announced. > >> > >> Back then, there was a proposal to remove the serializing mfence feature > >> bit (X86_FEATURE_MFENCE_RDTSC), since both AMD and Intel have > >> serializing lfence. At the time, it was (ahem) speculated that some > >> hypervisors might not yet support its removal, so it remained for the > >> time being. > >> > >> Now a year-and-a-half later, it should be safe to remove. > > > > I vaguely remember a concern from a migration point of view, maybe? Adding > > Paolo to see if he has any concerns. > > It would be a problem to remove the conditional "if > (boot_cpu_has(X86_FEATURE_LFENCE_RDTSC))" from svm_get_msr_feature. But > removing support for X86_FEATURE_MFENCE_RDTSC essentially amounts to > removing support for hypervisors that haven't been updated pre-Spectre. > That's fair enough, I think. Yes, they have other more interesting problems :)