From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] misc/xenmicrocode: Upload /lib/firmware/ to the hypervisor Date: Fri, 30 Jan 2015 09:11:25 -0500 Message-ID: <20150130141125.GB4506@l.oracle.com> References: <20150127231731.GC3163@pd.tnic> <54C82903.60405@citrix.com> <20150128083924.GA6360@pd.tnic> <1422531409.591726.220430733.6DE9E92B@webmail.messagingengine.com> <20150129121707.GC25399@pd.tnic> <1422550882.704707.220505145.0B3B9942@webmail.messagingengine.com> <20150129173041.GD25399@pd.tnic> <54CA7D2F.4020309@citrix.com> <20150129201245.GD22967@konrad-lan.dumpdata.com> <54CAD05B.8040105@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YHCIY-0008E5-UJ for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 14:11:51 +0000 Content-Disposition: inline In-Reply-To: <54CAD05B.8040105@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper 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, Borislav Petkov , Olaf Hering List-Id: xen-devel@lists.xenproject.org On Fri, Jan 30, 2015 at 12:29:15AM +0000, Andrew Cooper wrote: > On 29/01/2015 20:12, Konrad Rzeszutek Wilk wrote: > > On Thu, Jan 29, 2015 at 06:34:23PM +0000, Andrew Cooper wrote: > >> > >> Getting this conversation back on topic. > >> > >> The current state of play in Xen is this: > >> > >> * Boot time microcode loading exists (by scanning uncompressed cpio > >> multiboot modules) and should be safe to use. > > Please note that it does require passing in 'ucode=scan' on the Xen > > command line and does not do it automatically. It would be nice > > if that was automatic.. > > If there is an efficent way for Xen to identify compressed or non-cpio > boot modules and skip them (I have not inspected the code sufficiently > to know), it is perhaps the kind of option we should consider enabling > by default. It scans only for cpio archive and then searches for a specific string - and if it finds that then it will slurp the binary up and use that as an candidate for microcode patching. In that sense anything that is not not-cpio is skipped (compressed, binary, non-cpio, etc). > > >> * The facility for runtime microcode loading exists (via privileged > >> hypercall), but is unsafe to use at present, especially if virtual > >> machines are running. There are several steps which can be taken to > >> make it safer to use. > >> > >> > >> There is a plausible usecase for runtime microcode loading for people > >> who wish to take that risk, and as such, xenmicrocode is useful utility > >> to have, but it should probably not be available by default until we > >> believe the hypervisor side of the interface avoids the known potholes. > > Aren't these issues the same if we had an runtime microcode > > implementation (I am referring to the xen-microcode driver that > > Jeremy wrote once and some distros have in their kernel). The loading > > of microcode is done the same was as baremetal via 'rescan' interface. > > Correct. Any use of the hypercall mechanism is currently susceptible to > the potholes identified previously in this thread, and therefore unsafe > for use in practice. This includes the classic-xen kernel driver, and > this new userspace utility. Having the dom0 kernel issue the hypercall > as a result of its own boot time microcode patching has fewer potholes > to trip over, than later when domUs have been booted. I am surprised you haven't volunteered to put it on your 'free-time' todo list to fix this :-) > > ~Andrew