From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0 of 6] Fix kexec in Xen (take 3) Date: Thu, 26 May 2011 10:19:59 +0100 Message-ID: References: <4DDE1961.80303@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DDE1961.80303@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Cooper Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 26/05/2011 10:12, "Andrew Cooper" wrote: >> A better reference for APIC behaviour is Chapter 10 of Volume 3A of the >> Intel Software Developer Manual. See 10.4.7.1 particularly. The APIC is >> software disabled on startup -- meaning that the enable bit in the SPIV >> register is clear. That is quite different from *hardware* disable (via the >> APICBASE MSR) which your patch attempts to deal with. In this latter case >> the APIC would be totally shut down and it would not be possible to >> INIT-SIPI the secondary processor. The software disable (via SPIV) is very >> much a semi-disabled state (and disable_local_APIC() already returns an APIC >> to that state). >> >> -- Keir >> > Ok - I will read up on this more, and then I guess I have some code to > change. Yes, please do. Also if you can please try to avoid making crash-specific versions of cleanup/shutdown functions. I would actually rather have a global variable indicating I-am-crashing-on-cpu-x, and have at that from the existing shutdown functions to modify their behaviour. If you can fix that plus curb your impulse to do more to the APIC code than necessary then we have a starting point for further review. -- Keir