[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ross Philipson" <Ross.Philipson@xxxxxxxxxx>
  • Date: Tue, 16 Sep 2008 08:37:59 -0400
  • Delivery-date: Tue, 16 Sep 2008 05:38:48 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckXetx3zleGosPxRj231W1T/oylWgAAZG5w
  • Thread-topic: [Xen-devel] Crash in update microcode changes - change set 18475

Actually perhaps it is easy to fix. The copying of chunks out of the larger microcode buffer seems to just be a convenience. Perhaps just returning offset pointers into the original buffer from the get_next_ucode_from_buffer() function would get rid of the vmalloc() call. Just a thought as I looked at it further.

 

Thanks

Ross

 

From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ross Philipson
Sent: Monday, September 15, 2008 5:35 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Crash in update microcode changes - change set 18475

 

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@xxxxxxxxxx

 

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.