Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1705851ybt; Thu, 2 Jul 2020 11:43:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFeH+FDOpf8G+Db/2jhMzVvOo/ZdRFIWjL7mtpRdL3+t4hX8bOQ2RCnwJ10qQuk62J1wnD X-Received: by 2002:a17:906:f20d:: with SMTP id gt13mr4081949ejb.117.1593715383089; Thu, 02 Jul 2020 11:43:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593715383; cv=none; d=google.com; s=arc-20160816; b=poKXOHzQJkrb8JsZVzKGYB7uHSKtla/+oab6yNl9cCYDXTlPbjfLQwLhn8JAdzhTKR 1kfy17dOj+EqdvtZJj4YBJvmje78NT67/IT0+uv8vi+KaTvj4SXYS/BJdnD2eZMxUASS OXymWOuVc30VMgmJ5owfqFrB8WWdBXIykPg4/mwc/fRE4j+uVsafmSvwbaCDdMUzb6bH aqQpaIsW5EJiGC8156SKjERrDSnSBjNpK3O/KYzartAr7I7drxkkT916hoOlcBtSgKHd oeQAQbmEbsKTOhJcZOJjSZCU6bYXu7iMK04pkHBOgodsLCWCDFPFl4310gO63ZSlrWAX DfZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=wK94cCKTFO9HRo512SOC2lGiZ1R/lTmWYdIJAMIKNgI=; b=A300Uxz75I+l91SOdqeNFEQ33lg6umIhOpu4vNjMGqArELrTtRZYBi3zPeg3B1V+n0 NeiBK4VJIOMOvxjwPVUxeWi+jXuqwGD1qniKzqRvuVz66W+p+GR8hphcZaz/GyU3bvrb rA6N/kzJEYH6w0MZA+d62+HxRqXBFI1ze4WaWpcDL0Nh1H9edWZBAg39e6h6CzLFCJ6I 8CXCJxdlPP6a2gHpmQgHmOiTszPv5zgETu4sVLukGUv1PV8bPAtLmWpcM0bLl0uhkEyi mQ4tI1EfR+ADv6l1q4RyXDYdHaHsuVXe8RbJEAUjPOgcgmEWXVSJxUAdFJEJtzWKwzEC slJw== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id da8si6238009edb.564.2020.07.02.11.42.39; Thu, 02 Jul 2020 11:43:03 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726028AbgGBSmS (ORCPT + 99 others); Thu, 2 Jul 2020 14:42:18 -0400 Received: from mga05.intel.com ([192.55.52.43]:30064 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbgGBSmR (ORCPT ); Thu, 2 Jul 2020 14:42:17 -0400 IronPort-SDR: 3/o4F/Twn5gAV0kPeMC2uhMVi6Ni2WUWpPiOB8plk/FV1osQBd/24JMtkJhqxkm5KRjhM0SxaS Z39UBQp6kegA== X-IronPort-AV: E=McAfee;i="6000,8403,9670"; a="231854511" X-IronPort-AV: E=Sophos;i="5.75,305,1589266800"; d="scan'208";a="231854511" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2020 11:42:17 -0700 IronPort-SDR: kSdY8JjTauDyWVvUTV3AZpIJ5/e70QfsIjhUj4vpiG0SOD7OQE+ZhH/i2YOo5icWRknB0LAXny yq8dhSDF7PaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,305,1589266800"; d="scan'208";a="295983459" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga002.jf.intel.com with ESMTP; 02 Jul 2020 11:42:16 -0700 Date: Thu, 2 Jul 2020 11:42:16 -0700 From: Sean Christopherson To: Mihai Carabas Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH RFC 0/7] CPU feature evaluation after microcode late loading Message-ID: <20200702184216.GG3575@linux.intel.com> References: <1593703107-8852-1-git-send-email-mihai.carabas@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1593703107-8852-1-git-send-email-mihai.carabas@oracle.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 02, 2020 at 06:18:20PM +0300, Mihai Carabas wrote: > This RFC patch set aims to provide the ability to re-evaluate all CPU > features and take proper bug mitigation in place after a microcode > late loading. > > This was debated last year and this patch set implements a subset of > point #2 from Thomas Gleixner's idea: > https://lore.kernel.org/lkml/alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de/ > > Point #1 was sent as an RFC some time ago > (https://lkml.org/lkml/2020/4/27/214), but after a discussion with CPU > vendors (Intel), the metadata file is not easily buildable at this > moment so we could not advance with it more. Without #1, I know it is > unlikely to embrace the feature re-evaluation. > > Patches from 1 to 4 bring in changes for functions/variables in order to be > able to use them at runtime. > > Patch 5 re-evaluates CPU features, patch 6 is re-probing bugs and patch 7 > deals with speculation blacklist CPUs/microcode versions. This misses critical functionality in KVM. KVM snapshots boot_cpu_data at module load time (and does further modifications) for ongoing reuse in filtering what features are advertised to the userspace VMM. See kvm_set_cpu_caps() for details. Even if you found a way to reference kvm_cpu_caps, that still leaves the problem of existing guests having been created with stale data. Oh, and KVM also needs to properly handle MSR_IA32_TSX_CTRL. Rather than forcefully tearing down guests, what about adding a way to block updates, e.g. KVM would block updates on module load and unblock on module exit. That puts the onus of coordinating updates on the orchestration layer where it belongs. KVM aside, it wouldn't surprise in the least if there is other code in the kernel that captures bug state locally. This series feels like it needs a fair bit of infrastructure to either detect conflicting usage at build time or actively prevent consuming stale state at runtime. There's also the problem of the flags being exposed to userspace via /proc/cpuinfo, though I suppose that's userspace's problem to not shoot itself in the foot.