From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor Date: Wed, 28 Jan 2015 00:10:43 +0000 Message-ID: <54C82903.60405@citrix.com> References: <1422389461-19333-1-git-send-email-mcgrof@do-not-panic.com> <54C81078.3070404@citrix.com> <20150127231731.GC3163@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YGGDR-000606-Kg for xen-devel@lists.xenproject.org; Wed, 28 Jan 2015 00:10:41 +0000 In-Reply-To: <20150127231731.GC3163@pd.tnic> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Borislav Petkov Cc: Juergen Gross , Michal Marek , Jason Douglas , stefano.stabellini@eu.citrix.com, Takashi Iwai , mcgrof@suse.com, "Luis R. Rodriguez" , Henrique de Moraes Holschuh , david.vrabel@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Olaf Hering List-Id: xen-devel@lists.xenproject.org On 27/01/2015 23:17, Borislav Petkov wrote: > On Tue, Jan 27, 2015 at 10:26:00PM +0000, Andrew Cooper wrote: >> I am not convinced of the safely of permitting microcode updates at >> runtime. We have seen in the past that having mismatched microcode on >> different halfs of an AMD cluster causes system crashes when non-root > What kind of CPU mix are we talking about here? > > And how is microcode on those machines supposed to be updated, > regardless of OS, i.e. how does the platform vendor do those updates? > There was a thread on xen-devel but I cant currently find it in the archives. To the best of my memory, it was a 4 core APU system where the BIOS had updated the microcode on cpu 0 but left 1-3 at a lower patch level. Every time the reporter tried creating an HVM guest (i.e. entering SVM non-root mode), the system reset. The instability was sorted by ensuring each core was at the same microcode level. As Xen updates microcode one cpu at a time from 0, it could easily create a similar situation if microcode is updated after VMs have been started. Come to think of it, this is also an impending problem for PVH dom0 systems. ~Andrew