From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
Chao Gao <chao.gao@intel.com>, Wei Liu <wei.liu2@citrix.com>,
Ashok Raj <ashok.raj@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v6 04/12] microcode: introduce a global cache of ucode patch
Date: Wed, 13 Mar 2019 17:04:43 +0000 [thread overview]
Message-ID: <2fc8ac8c-c784-b2d5-d1f3-b25298ea6c89@citrix.com> (raw)
In-Reply-To: <3b84e762-96ff-f1c7-7f37-4af9afb48153@citrix.com>
On 13/03/2019 10:30, Andrew Cooper wrote:
> On 13/03/2019 07:39, Jan Beulich wrote:
>>>>> On 12.03.19 at 17:53, <roger.pau@citrix.com> wrote:
>>> IIRC we agreed that systems with mixed CPU versions are not supported,
>>> hence the same microcode blob should be used to update all the
>>> possible CPUs on the system, so a list should not be needed here.
>> That's not what I recall. We agreed to not store everything, because
>> mixed-family / mixed-model systems are commonly not supported by
>> the hw vendors. But mixed stepping systems may well be.
> The difference between Skylake and CascadeLake server CPUs is only in
> the stepping (4 vs 6). Same for Kaby/Coffee/Whiskey/Amber lake (the
> mobile and desktop lines have a model each, and newer generations are
> just new steppings).
>
> I'll have to defer to Intel as to exactly what is supported, but when I
> asked this before, the answer was that no heterogeneity was supported at
> all, not even at the stepping level or platform ID level.
So, as it turns out, Xen in practice only supports a single files worth
of microcode from /lib/firmware
This is because:
1) That is the only behaviour drakut has, and
2) drakut has been the default initrd-generator in Linux distros for far
longer than Xen has had boot time microcode loading support, and
3) The runtime microcode loading hypercall is currently completely broken
Therefore in practice, the drakut way of doing things is the only way
which has ever seen any testing, and is therefore the only one which works.
So, making a simplifying assumption of "single stepping/plat_id only" in
the Intel case is fine if it useful.
Beyond that, it would be useful to know what is an isn't supported by
Intel, and whether we are likely to find systems in the wild with mixed
cpu packages.
~Andrew
_______________________________________________
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-13 17:17 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 [this message]
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
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=2fc8ac8c-c784-b2d5-d1f3-b25298ea6c89@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=ashok.raj@intel.com \
--cc=chao.gao@intel.com \
--cc=roger.pau@citrix.com \
--cc=sergey.dyasli@citrix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).