From: "Raj, Ashok" <ashok.raj@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.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>, Jan Beulich <JBeulich@suse.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Ashok Raj <ashok.raj@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>,
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: Thu, 14 Mar 2019 11:57:12 -0700 [thread overview]
Message-ID: <20190314185712.GA20889@araj-mobl1.jf.intel.com> (raw)
In-Reply-To: <d55bb90e-5ca4-0544-be5f-bbd0168c060a@citrix.com>
Hi Andrew
Sorry it took a while, since I had to check with couple others.
+ Asit
On Thu, Mar 14, 2019 at 12:39:46PM +0000, Andrew Cooper wrote:
[snip]
>
> 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.
Cheers,
Ashok
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-03-14 18:57 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-11 7:57 [PATCH v6 00/12] improve late microcode loading Chao Gao
2019-03-11 7:57 ` [PATCH v6 01/12] misc/xenmicrocode: Upload a microcode blob to the hypervisor Chao Gao
2019-03-12 15:27 ` Roger Pau Monné
2019-03-13 5:05 ` Chao Gao
2019-03-13 9:24 ` Wei Liu
2019-03-25 9:38 ` Sergey Dyasli
2019-04-02 2:26 ` Chao Gao
2019-03-11 7:57 ` [PATCH v6 02/12] microcode/intel: use union to get fields without shifting and masking Chao Gao
2019-03-12 15:33 ` Roger Pau Monné
2019-03-12 16:43 ` Jan Beulich
2019-03-12 18:23 ` Wei Liu
2019-03-11 7:57 ` [PATCH v6 03/12] microcode/intel: extend microcode_update_match() Chao Gao
2019-03-11 7:57 ` [PATCH v6 04/12] microcode: introduce a global cache of ucode patch Chao Gao
2019-03-12 16:53 ` Roger Pau Monné
2019-03-12 23:31 ` Raj, Ashok
2019-03-13 5:28 ` Chao Gao
2019-03-13 7:39 ` Jan Beulich
2019-03-13 10:30 ` Andrew Cooper
2019-03-13 17:04 ` Andrew Cooper
2019-03-14 7:42 ` Jan Beulich
2019-03-13 16:36 ` Sergey Dyasli
2019-03-14 1:39 ` Chao Gao
2019-03-11 7:57 ` [PATCH v6 05/12] microcode: only save compatible ucode patches Chao Gao
2019-03-12 17:03 ` Roger Pau Monné
2019-03-13 7:45 ` Jan Beulich
2019-03-11 7:57 ` [PATCH v6 06/12] microcode: remove struct ucode_cpu_info Chao Gao
2019-03-11 7:57 ` [PATCH v6 07/12] microcode: remove pointless 'cpu' parameter Chao Gao
2019-03-11 7:57 ` [PATCH v6 08/12] microcode: split out apply_microcode() from cpu_request_microcode() Chao Gao
2019-03-11 7:57 ` [PATCH v6 09/12] microcode: remove struct microcode_info Chao Gao
2019-03-11 7:57 ` [PATCH v6 10/12] microcode/intel: Writeback and invalidate caches before updating microcode Chao Gao
2019-03-21 11:08 ` Sergey Dyasli
2019-03-11 7:57 ` [PATCH v6 11/12] x86/microcode: Synchronize late microcode loading Chao Gao
2019-03-13 0:07 ` Raj, Ashok
2019-03-13 5:02 ` Chao Gao
2019-03-13 7:54 ` Jan Beulich
2019-03-13 8:02 ` Jan Beulich
2019-03-14 12:39 ` Andrew Cooper
2019-03-14 18:57 ` Raj, Ashok [this message]
2019-03-14 20:25 ` Thomas Gleixner
2019-03-15 9:40 ` Andrew Cooper
2019-03-15 10:44 ` Thomas Gleixner
2019-03-14 13:01 ` Chao Gao
2019-03-14 13:08 ` Jan Beulich
2019-03-11 7:57 ` [PATCH v6 12/12] microcode: update microcode on cores in parallel Chao Gao
2019-03-21 12:24 ` [RFC PATCH v6 13/12] microcode: add sequential application policy Sergey Dyasli
2019-03-21 14:25 ` Chao Gao
2019-03-26 16:23 ` Jan Beulich
2019-03-19 20:22 ` [PATCH v6 00/12] improve late microcode loading Woods, Brian
2019-03-19 21:39 ` Woods, Brian
2019-03-20 8:58 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190314185712.GA20889@araj-mobl1.jf.intel.com \
--to=ashok.raj@intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=asit.k.mallick@intel.com \
--cc=bp@suse.de \
--cc=chao.gao@intel.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=roger.pau@citrix.com \
--cc=sergey.dyasli@citrix.com \
--cc=tglx@linutronix.de \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.