From mboxrd@z Thu Jan  1 00:00:00 1970
From: Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH] misc/xenmicrocode: Upload
 /lib/firmware/<some blob> to the hypervisor
Date: Thu, 29 Jan 2015 13:17:07 +0100
Message-ID: <20150129121707.GC25399@pd.tnic>
References: <1422389461-19333-1-git-send-email-mcgrof@do-not-panic.com>
	<54C81078.3070404@citrix.com> <20150127231731.GC3163@pd.tnic>
	<54C82903.60405@citrix.com> <20150128083924.GA6360@pd.tnic>
	<1422531409.591726.220430733.6DE9E92B@webmail.messagingengine.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <bp@suse.de>)
	id 1YGo2G-0001Tw-LA
	for xen-devel@lists.xenproject.org; Thu, 29 Jan 2015 12:17:24 +0000
Content-Disposition: inline
In-Reply-To: <1422531409.591726.220430733.6DE9E92B@webmail.messagingengine.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Henrique de Moraes Holschuh <hmh@debian.org>
Cc: Juergen Gross <jgross@suse.com>, Michal Marek <mmarek@suse.cz>, Jason Douglas <jdouglas@suse.com>, stefano.stabellini@eu.citrix.com, Takashi Iwai <tiwai@suse.de>, Andrew Cooper <andrew.cooper3@citrix.com>, mcgrof@suse.com, "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, david.vrabel@citrix.com, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Olaf Hering <ohering@suse.de>
List-Id: xen-devel@lists.xenproject.org

On Thu, Jan 29, 2015 at 09:36:49AM -0200, Henrique de Moraes Holschuh wrote:
> But the fact that you cannot trust a system with mismatched microcode to
> be stable is the hard truth: neither AMD nor Intel are really enforcing
> that late microcode updates will be always safe in all conditions.

How do you know? Have you talked to anyone?

Can you imagine that someone might have done that and asked exactly that
question and got an assurance that CPU vendors actually do try to make
microcode updates self-contained?

So let me stop you right there with that "hard truth" drama. Just stick
to the facts. If you don't have any facts, don't create them out of thin
air. Ok?

The HSW TSX stuff had to be done that way and I'm sure Intel had their
good reasons. And I'm sure they bought the pain of the late update
explosions.

And software should support even the use case of late updates. And that
use case is very simple - if a microcode patch is self-contained, then
it should get applied. If not - and here we rely on the CPU vendors to
let us know; if they don't, we learn it the hard way anyway - we warn
the user and disallow the update. This is a very simple thing to solve.

> What we can do about it in the Linux kernel late microcode driver is to
> shorten that window as much as possible, and try to quiesce the system
> as much as possible during the microcode update until all cores have
> been updated.
> 
> It still looks like Xen should *never* trigger a late microcode update,
> unless it freezes all VMs first.

Now this is better.

> For example, on Intel you must *never* have two CPUs attempt to update
> the same "microcode store" at the same time, which requires that you

Interesting - this is the first time I hear about such restriction.
Details?

> actually know how the microcode is partitioned relative to
> packages/cores/threads (so far, this is easy: HT siblings share
> microcode, nothing else does.  But what about future processors?).

What about it? Software gets adjusted like for anything else.

> ... so they're actually quite fine with the idea of a reboot being
> required to update processor microcode.

And then there's the other group who can't afford to reboot long running
machines for whatever reason. As long as we can support both, we should
support both.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--