All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: Crash in update microcode changes - change set 18475
Date: Tue, 16 Sep 2008 07:38:19 +0100	[thread overview]
Message-ID: <C4F512EB.1D396%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <409D32C55C48D34DB5E31C8AB29EB15B066C70C4@FTLPEXCH05.citrite.net>


[-- Attachment #1.1: Type: text/plain, Size: 1907 bytes --]

I¹ll take a look. Probably not hard to fix.

 -- Keir

On 15/9/08 22:34, "Ross Philipson" <Ross.Philipson@citrix.com> 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:
>  
> do_microcode_update_one()
>      microcode_update_cpu()
>             cpu_request_microcode()
>                 get_next_ucode_from_buffer()
>  
> 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.
>  
> Thanks
> Ross
>  
> Ross Philipson
> Senior Software Engineer
> Citrix Systems, Inc
> 14 Crosby Drive
> Bedford, MA 01730
> 781-301-7949
> ross.philipson@citrix.com <mailto:ross.philipson@citrix.com>
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 2912 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  reply	other threads:[~2008-09-16  6:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-15 21:34 Crash in update microcode changes - change set 18475 Ross Philipson
2008-09-16  6:38 ` Keir Fraser [this message]
2008-09-16 12:37 ` Ross Philipson
2008-09-16 12:44   ` Keir Fraser
2008-09-16 12:51     ` Ross Philipson
2008-09-16 14:15     ` Ross Philipson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C4F512EB.1D396%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Ross.Philipson@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.