From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [RFC PATCH] Scan initramfs for microcode cpio
	archive. (v1)
Date: Mon, 15 Jul 2013 10:34:56 -0400
Message-ID: <20130715143456.GA4817@phenom.dumpdata.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: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <51E3BE7B02000078000E4D0A@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Mon, Jul 15, 2013 at 08:18:51AM +0100, Jan Beulich wrote:
> >>> On 12.07.13 at 16:25, Konrad Rzeszutek Wilk <konrad@kernel.org> 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 if compiled without EARLY_INITRAMFS.. and an initramfs
_with_ the uncompressed cpio containing the ucode blob followed
by compressed cpio containing the normal stuff boots. I tested this
with a v3.9 and v3.11 kernel and both booted without trouble.

> Jan
> 
>