Re: [PATCH v6 11/12] x86/microcode: Synchronize late microcode loading

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
	Kevin Tian <kevin.tian@intel.com>, Borislav Petkov <bp@suse.de>,
	Wei Liu <wei.liu2@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	"Mallick, Asit K" <asit.k.mallick@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Chao Gao <chao.gao@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v6 11/12] x86/microcode: Synchronize late microcode loading
Date: Fri, 15 Mar 2019 09:40:28 +0000	[thread overview]
Message-ID: <c8c5efb3-2126-dd26-37a5-4dff263842b7@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1903141306180.1948@nanos.tec.linutronix.de>

On 14/03/2019 20:25, Thomas Gleixner wrote:
> Ashok,
>
> On Thu, 14 Mar 2019, Raj, Ashok wrote:
>> On Thu, Mar 14, 2019 at 12:39:46PM +0000, Andrew Cooper wrote:
>>> On late load failure, we should dump enough information to work out
>>> exactly what went on, to determine how best to proceed, but the server
>>> is effectively lost to us.  On late load success, the proposed new
>>> "version" replaces the current "version".
>>>
>>> And again - I reiterate the point that I think it is fine to have a
>>> simplifying assumption that we don't have mixed stepping systems to
>>> start with, presuming this is generally in line with Intel's support
>>> statement.  If in practice we find mixed stepping systems which are
>>> supported by an OEM/Intel, we can see about extending the logic.
>> Checking with Asit he says it is in fact permitted to have 1 step behind
>> even on a multi-socket system. One could be N and other N-1 should be 
>> supported.
> That turns into a total disaster if N has an issue fixed ant N-1 requires
> microcode + software workaround.
>
> So if N is on the boot socket, then we fail to enable the workaround
> because CPU0 has the 'Issue fixed' bit set.
>
> If N-1 is on the boot socket, then we go to do the workaround nevertheless
> on N and that might dependend on the issue just be some pointless exercise
> or even try to access some MSR which is not available.
>
> *Shudder*

Intel: Are you saying that Skylake (06-55-04) is supported in
combination with Cascade Lake B0 (06-55-05) and/or Cascade Lake B1
(06-55-06) ?

The most insidious problem is TSX_FORCE_ABORT between the two Cascade
Lakes.  There really will be an asymmetric existence of an MSR required
for use in one part of the system, and unavailable in the other part of
the system.

To a certain degree, what is technically supported by Intel is also
tempered by what the major OS/VMM vendors are willing to boot on, as
that is ultimately what the customer is paying for.  When the steppings
differed only by the errata fixed, and the silicon was otherwise
identical from software's point of view, supporting a range of adjacent
steppings seems entirely reasonable.

In this case you've got 3 adjacent steppings, *all* of which offer
different architecturally defined features, and will involve software
changes to allow mixed systems to function in a safe way.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel