From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753778AbZKLRe0 (ORCPT ); Thu, 12 Nov 2009 12:34:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753757AbZKLReY (ORCPT ); Thu, 12 Nov 2009 12:34:24 -0500 Received: from mail-va3.bigfish.com ([216.32.180.113]:58850 "EHLO mail110-va3-R.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753633AbZKLReX convert rfc822-to-8bit (ORCPT ); Thu, 12 Nov 2009 12:34:23 -0500 X-Greylist: delayed 1503 seconds by postgrey-1.27 at vger.kernel.org; Thu, 12 Nov 2009 12:34:23 EST X-SpamScore: -7 X-BigFish: VPS-7(z34a4jz98dN179dNzz1202hzzz32i6bh43j62h) X-Spam-TCS-SCL: 1:0 X-MS-Exchange-Organization-Antispam-Report: OrigIP: 139.95.251.8;Service: EHS X-WSS-ID: 0KT0ABB-03-9X4-02 X-M-MSG: Date: Thu, 12 Nov 2009 18:09:39 +0100 From: Borislav Petkov To: Dmitry Adamushko CC: Andreas Herrmann , Ingo Molnar , linux-kernel@vger.kernel.org, "H. Peter Anvin" , Mike Travis , Tigran Aivazian , Thomas Gleixner , Andreas Mohr , Jack Steiner Subject: Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages Message-ID: <20091112170939.GA31660@aftab> References: <20091106194626.GC18592@alberich.amd.com> <20091111193832.GG18592@alberich.amd.com> <20091112113343.GA1386@elte.hu> <20091112152026.GI18592@alberich.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8BIT X-OriginalArrivalTime: 12 Nov 2009 17:09:11.0272 (UTC) FILETIME=[DA66D680:01CA63BA] X-Reverse-DNS: unknown Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2009 at 04:48:34PM +0100, Dmitry Adamushko wrote: > request_firmware_nowait() sends an async request which can be > preserved (and this is an assumption -- I haven't really verified it > yet) until some latter stage when user-space has been started and is > capable of handling (cached) firmware-load requests. I may be (and > perhaps I'm) wrong with the above assumption and the solution is > either never build such a module into the kernel or only do it with > built-in firmware blobs. I don't think built-in blobs is the way we want to go here - in that case updating the microcode would require rebuilding the kernel, which is a clear overkill and exactly the opposite of what we should be doing. Imagine a big supercomputer consisting of several thousand nodes, all with identical CPUs. Now, everytime there's microcode patch available, you have to reboot all those machines after having distributed the updated kernel images just so that all nodes have their microcode updated. Many admins would go: "Hmm, no!" What actually got somehow dropped from Andreas' patch and which we talked about and agreed upon earlier is that the best thing to do would be to do $ rmmod microcode $ modprobe microcode after having copied the new ucode patch to /lib/firmware without disturbing the machine execution. The async _nowait() version sounds good but in that case you're still going to need to trigger the microcode update somehow (and AFAIK there's no mechanism for that yet.) So reloading the module is the easiest thing and it doesn't need any code changes except the Kconfig oneliner. Hmm... -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632