From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [RFC PATCH] Scan initramfs for microcode cpio archive. (v1) Date: Mon, 15 Jul 2013 13:31:24 +0100 Message-ID: <51E3EB9C.6030701@citrix.com> References: <1373639127-29467-1-git-send-email-konrad.wilk@oracle.com> <51E3BE7B02000078000E4D0A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51E3BE7B02000078000E4D0A@nat28.tlf.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: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 15/07/13 08:18, Jan Beulich wrote: >>>> On 12.07.13 at 16:25, Konrad Rzeszutek Wilk wrote: >> Greetings, >> >> Please see the following patch which implements a mechanism to scan >> the initramfs for the format of an microcode files. This is a feature >> that the Linux kernel has since v3.10 - where it searches in the >> initramfs for an archive of the microcode blob. The format is documented >> in the Linux tree and the commit description contains it. >> >> The tool to make this work is the initramfs creator. The author has >> provided an RFC patch: >> http://article.gmane.org/gmane.linux.kernel.initramfs/3318 >> which does that. > > Looking at that script change I'm getting the impression that the > representation is as uncompressed cpio containing the ucode > blobs followed by compressed cpio containing all the "normal" > stuff. Which iiuc means that an unaware kernel can't deal with > such an image (as the consumer needs to know that it has to > skip the initial portion). Unless that understanding of mine is > wrong - isn't that a rather bad design? The kernel unpacks all cpio archives it finds in the initramfs image so the kernel doesn't have to be aware of the way tools have packed the filesystem into different cpio archive. David