From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: ACPI-Tables corrupted? Date: Thu, 29 Jul 2010 11:04:04 +0200 Message-ID: <4C514404.3020502@ts.fujitsu.com> References: <789F9655DD1B8F43B48D77C5D30659732874B82C@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <789F9655DD1B8F43B48D77C5D30659732874B82C@shsmsx501.ccr.corp.intel.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: "Jiang, Yunhong" Cc: "Han, Weidong" , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "Kay, Allen M" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 07/29/2010 09:37 AM, Jiang, Yunhong wrote: > Sorry that I didn't notice it is for crash kernel. In fact, I tried kexec before and never succed to bring it up. > > What do you mean of "stab at disabling x2apic"? You mean we need disable x2apic before transfer control to crash kernel, right? > > Per my understanding, with kexec, when system crash, it will jump directly to new kernel's entry point, no guest destroy (i.e. clean-up), not reset signal to cpu/chipset, right? > If yes, another issue need be considered is VT-d. I didn't find the vt-d disable code in xen's kexec_crash code, if the new kernel has no idea of vt-d (thus does not reset the vt-d engine), it may have trouble. Or, will the kexec kernel not use device assigned to guest? > > Of course it is ok if crash kernel support vt-d too. Seems to be the case here. A patched crash kernel which just took the zapped DMAR entry as a valid one succeeded in writing a vmcore. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html