From: Jeremy Fitzhardinge Subject: Re: [PATCH 0/3] x86/microcode: support for microcode update in Xen dom0 Date: Wed, 12 Oct 2011 15:27:56 -0700 Message-ID: <4E96146C.5070701@goop.org> References: <4E94E1E5.4070505@goop.org> <20111012101615.GA14966@aftab> <4E95D9E7.6090304@zytor.com> <4E95E7FE.6050302@goop.org> <20111012194543.GD14966@aftab> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20111012194543.GD14966@aftab> Sender: linux-kernel-owner@vger.kernel.org To: Borislav Petkov Cc: "H. Peter Anvin" , the arch/x86 maintainers , Tigran Aivazian , Xen Devel , Linux Kernel Mailing List , Jeremy Fitzhardinge , Ingo Molnar , Thomas Gleixner List-Id: xen-devel@lists.xenproject.org On 10/12/2011 12:45 PM, Borislav Petkov wrote: > On Wed, Oct 12, 2011 at 03:18:22PM -0400, Jeremy Fitzhardinge wrote: >> While doing the whole boot time multiboot thing may offer some small >> hypothetical technical advantages, it has the significant cost of just >> complicating the whole deployment and use story. > You simply can't call the need to apply ucode as early as possible a > "hypothetical techical advantage." The current scheme has worked pretty well so far; there doesn't seem to be a huge concern about it. Have there been actual observed failures with the current mechanism, or is the drive to make it earlier driven by an aesthetic desire to make it "as it should be"? > Other issues like how to handle ucode > images and how to put them together and how distros distribute them > and whether xen minimizes the amount of "specialness" or not are only > secondary. No, they're not. If users end up with a broken setup then they get no microcode updates at all, which makes everything else moot. It has to be deployed correctly for it to be worth anything at all. What is secondary, or rather, completely irrelevant is whether Xen is involved or not. J