From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: How many patches are missing in upstream Linux? Date: Tue, 11 Mar 2014 13:53:52 -0400 Message-ID: <20140311175352.GC15088@phenom.dumpdata.com> References: <53185E4D0200007800121725@nat28.tlf.novell.com> <20140306192610.GI9852@localhost.localdomain> <531E26DD.5030807@goop.org> <531F4A2C.7020209@web2web.at> 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 1WNQsM-0003t1-Qw for xen-devel@lists.xenproject.org; Tue, 11 Mar 2014 17:54:03 +0000 Content-Disposition: inline In-Reply-To: <531F4A2C.7020209@web2web.at> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Atom2 Cc: Jeremy Fitzhardinge , daniel.kiper@oracle.com, david.vrabel@citrix.com, Jan Beulich , Yang Z Zhang , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote: > > > Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge: > [snip] > >>The maintainer is being : > >> - runtime microcode. What I had been told was to use the 'early > >> microcode' mechanism - which is now implemented and Xen can also scan > >> the initramfs to extract the microcode payload and apply it. > > > >I've never got that to work, but ucode=-1 with a microcode.dat multiboot > >modules works pretty well. > > > >> But it misses the important part of server longevity in that the > >> host might be running for years and the microcode might need to be > >> updated during that time. bpetkov wasn't too thrilled about the > >> runtime microcode and I hadn't come back to this yet to figure out > >> what are his exact technical misgivings. > > > >I think, in the end, he (and Ingo) were advocating just doing a full > >emulation of the Intel/AMD update mechanism in the set/getmsr PV > >callbacks. Which is doable but... well, not pretty. Maybe a new attempt > >with get a new reception. > > I can add my experience from the perspective of a user trying to get > early microcode loading to work with my system: > > First of all I can confirm that it sort of works - but as Jeremy has > pointed out, there seem to be issues with including it into the > initramfs. After many unsuccessful tries I also only got it to work > when I used a separate entry in multiboot (grub2) which referred to > the blob for uploading the payload to the CPU. > > As soon as I had the microcode integrated into the initramfs as > described at > http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html > the system would no longer boot with a message stating that it could > not find the root filesystem - I assume that was at the time when > the initramfs was about to be unpacked and loaded (if I recall > correctly there were no messages from the initramfs on screen). > Therefore I couldn't verify whether the microcode was actually > lodaded before that. Hm, that would imply that Linux couldn't skip past the 'non-gzip' payload of the initramfs. But it does work for me so I am wondering what I am doing differently. Could you send an email with your .config and perhaps your serial log if you still have it? > > My feeling at that time was that the unpacking of the initramfs had > failed and it was probably more a linux issue rather than a XEN > issue - albeit the concatenated file which per the link above should > be created by > > "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img" > > does not resemble a valid cpio archive any longer (you also can't > work with it on the command line - e.g. list its content). I assume > that though the kernel expects a valid cpio format file and > therefore is unable to unpack and subsequently fails. It should skip the bits that it does not understand. > > But in any case, with the additional file in multiboot it works > flawlessly. The only catch is that the file distributed by Intel > (the microcode.dat which is a text file) has to be converted inot a > binary file (I also stripped it down to only contain the parts > necessary for my CPU, but I don't know whether that's strictly > necessary). And it must _NOT_ be a cpio archive in that case. You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob' and that would do it too. > > Searching google there are a few tools available to convert the > Intel distributed microcode.dat to binary format and reduce it to > only the parts required for a specific CPU. > > Regards Atom2