This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Crash in update microcode changes - change set 18475

To: Ross Philipson <Ross.Philipson@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Crash in update microcode changes - change set 18475
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 16 Sep 2008 07:38:19 +0100
Delivery-date: Mon, 15 Sep 2008 23:38:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <409D32C55C48D34DB5E31C8AB29EB15B066C70C4@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckXetx3zleGosPxRj231W1T/oylWgAS/Hk6
Thread-topic: [Xen-devel] Crash in update microcode changes - change set 18475
User-agent: Microsoft-Entourage/
I’ll take a look. Probably not hard to fix.

 -- Keir

On 15/9/08 22:34, "Ross Philipson" <Ross.Philipson@xxxxxxxxxx> wrote:

The changes for CPU microcode loading that were done recently (change set 18475 in unstable staging) seem to be causing a crash. I am using an Intel system and I get an assertion in Xen during the DOM0 boot. This is what I believe is going on.
In xen/arch/x86/microcode.c the routine do_microcode_update() is dispatching the update work to each CPU with on_each_cpu() which in turn uses an IPI to dispatch the callback vector on each CPU. The microcode update routine passed in is called in the IPI context on the target CPU (including irq_enter() before calling the ucode function). Within the ucode function the calls eventually get down to the Intel specific calls in microcode_intel.c. Specifically:
Within the last call, vmalloc() is called and eventually _xmalloc() asserts on ASSERT(!in_irq()). I checked and the earlier code, though it dispatched work to different CPUs with IPIs, did not try to dynamically allocate memory. I am not sure how to fix this easily without redoing how the whole new microcode framework works. Also I didn’t look closely at AMD but it may have the same issue. I can take a crack at fixing it but maybe someone will see a simple solution.

Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
ross.philipson@xxxxxxxxxx <mailto:ross.philipson@xxxxxxxxxx>

Xen-devel mailing list

Xen-devel mailing list