All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Ashok Raj <ashok.raj@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Chao Gao <chao.gao@intel.com>
Subject: Re: [PATCH v6 05/12] microcode: only save compatible ucode patches
Date: Wed, 13 Mar 2019 01:45:20 -0600	[thread overview]
Message-ID: <5C88B510020000780021DF38@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <20190312170324.2isdrheecdrpo3yp@Air-de-Roger>

>>> On 12.03.19 at 18:03, <roger.pau@citrix.com> wrote:
> On Mon, Mar 11, 2019 at 03:57:29PM +0800, Chao Gao wrote:
>> Intel CPU only allows mixing in stepping or 'pf'. If an ucode patch is
>> for other CPU families or models, it won't be compatible to all CPUs on
>> current system and even hot-plugged CPUs.  Don't save such patch to
>> reduce the size of ucode cache.
> 
> Oh, so we are indeed aiming to support systems that can require CPUs
> to use different microcode blobs in order to update?
> 
> If that's the case, and we are sure this will work, we do indeed need
> a list of microcodes, but you will have to somehow flag applied
> microcodes in order to prevent them from being replaced with new
> microcode versions until Xen knows that such new versions apply
> correctly.
> 
> Maybe I'm being too simplistic here, but does anyone really have a
> system with CPUs with different stepping?

I think the primary scenario is to see a newer stepping CPU added
into a slightly older system (hotplug or not). Whether people
actually do this I don't know, but I suspect there's a reason hw
vendors state what combinations are supported.

> Supporting such scenario adds quite a lot of complexity and even if
> theoretically possible I don't think it makes much sense to support
> unless there are such systems out there.

What complexity are you thinking about? Of course the expectation
is for hotplugged CPUs to have all features already present CPUs
have. And of the ones we find at boot we settle on a common
minimum set of features (or at least we try to), but in mixed-
stepping systems the common situation would anyway be that
they're all equal in terms of software visible features.

Jan



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

  reply	other threads:[~2019-03-13  7:45 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 [this message]
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=5C88B510020000780021DF38@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.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 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.