From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1) Date: Mon, 4 Aug 2014 11:02:48 -0400 Message-ID: <20140804150248.GD19853@laptop.dumpdata.com> References: <20140714212213.GC18075@stro.at> <1405414412.1389.5.camel@kazak.uk.xensource.com> <20140715145934.GM3403@laptop.dumpdata.com> <53CFE9F90200007800025334@mail.emea.novell.com> <20140804140730.GD18425@laptop.dumpdata.com> <53DFB78D020000780002918D@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <53DFB78D020000780002918D@mail.emea.novell.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: Jan Beulich Cc: maximilian attems , debian-kernel@lists.debian.org, xen-devel , David Vrabel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Mon, Aug 04, 2014 at 03:40:45PM +0100, Jan Beulich wrote: > >>> On 04.08.14 at 16:07, wrote: > > On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote: > >> >>> On 15.07.14 at 16:59, wrote: > >> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: > >> >> Adding xen-devel and some of the Linux maints, > >> >> > >> >> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: > >> >> > I will upload tomorrow Tuesday around 22h00 UT to experimental. > >> >> > > >> >> > There are two TODOS concerning the not yet forwarded Debian patches: > >> >> > - cgroups > >> >> > - xen microcode > >> >> > > >> >> > > >> >> > I consider both not a blocker, but would be happy if Xen guys could > >> >> > have a look for what is needed. > >> >> > >> >> The xen microcode patches which maks is referring to are these: > >> >> > >> > > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat > > > >> > ures/all/xen/ > >> >> which are a forward port of Jeremy's old microcode_xen.ko driver. > >> > > >> > They are also at my branch > >> > > > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis > >> > c > >> > > >> > Hm, I should rebase them at some point. > >> >> > >> >> I've not been keeping up on Xen x86 microcode stuff these days but I > >> >> think we don't need this any more with modern Xen since we can parse the > >> >> microcode blob off the front of the initrd, is that right? > >> > > >> > Right. And best of it, the support for that is in dracut so > >> > it automatically can happen (thought you still need to add > >> > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN > >> > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. > >> > >> Except that all this still doesn't take care of updating microcode at > >> runtime. Yet that should - like kexec - be implemented in the > >> respective tools such that no kernel involvement it required. > > > > What are such tools? > > Wasn't there a microcode_ctl tool/package? There was but it is obsolete: *************************************************************************** >>> What it does *************************************************************************** Deploy an Intel and AMD microcode. This tool is obsolete and the microcode is the subject to be distributed via kernel-firmware, however Intel still does not supply the microcode in a form consumable by the Linux's microcode > > > My recollection is that it is matter of > > sticking the files in /lib/firmware and then udev - will try > > at the detection of an CPU becoming online, do: > > - load microcode module > > - echo 1 > to the 'reload' sysfs parameter > > > > Perhaps the solution is simple: > > - write an xen userspace tool that will do this loading via > > the hypercalls. > > - plug said tool in the udev script that comes with xen. > > - distros will install said udev scripts when they install Xen rpms? > > > > That sounds too simple to be true. I must be missing something :-) > > That would be an option too (namely if, say, the microcode_ctl tool > is considered deprecated/dead), and indeed can't be very difficult. Vacation does wonders for ones brain! I shall put it on the TODO list. thank you! > > Jan >