Re: [Xen-devel] ACPI-Tables corrupted?

To:	"Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject:	Re: [Xen-devel] ACPI-Tables corrupted?
From:	Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date:	Thu, 29 Jul 2010 11:04:04 +0200
Cc:	"Han, Weidong" <weidong.han@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date:	Thu, 29 Jul 2010 02:06:09 -0700
Dkim-signature:	v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1280394368; x=1311930368; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C514404.3020502@xxxxxxxxxxxxxx>\|Date:=20 Thu,=2029=20Jul=202010=2011:04:04=20+0200\|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>\|MIME-Version: =201.0\|To:=20"Jiang,=20Yunhong"=20<yunhong.jiang@xxxxxxxx m>\|CC:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx>,=20 =0D=0A=20"Kay,=20Allen=20M"=20<allen.m.kay@xxxxxxxxx>,=0D =0A=20Jeremy=20Fitzhardinge=20<jeremy@xxxxxxxx>,=20=0D=0A =20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@xxxxxxxxx source.com>,=0D=0A=20"Han,=20Weidong"=20<weidong.han@inte l.com>\|Subject:=20Re:=20[Xen-devel]=20ACPI-Tables=20corru pted?\|References:=20<C876E0F7.1C041%keir.fraser@xxxxxxxxx .com>=09<C876E2B6.1C047%keir.fraser@xxxxxxxxxxxxx>=20<789 F9655DD1B8F43B48D77C5D30659732874B82C@xxxxxxxxxxxxxxxxxxx intel.com>\|In-Reply-To:=20<789F9655DD1B8F43B48D77C5D30659 732874B82C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> \|Content-Transfer-Encoding:=207bit; bh=9D+EkqKVIAnGiUFTvd0sPbcaa/8YxdM16VppI6lCk3Q=; b=cs6OhnSUGj4KSDTs7Rb5kFoKy82BXORyY9QosvxxyfeBgwvNYOQQBWWv Nfex+3N1H/XyDV1mzvcPsYmVIa21wcsqhB1vfTzNzeQQ0Kc++4YVeNpJu mqbwFTb/KB3hnKnJZpHqm9IN4zqplfXJAacCxjqRpsjzT3KAxx9Dy6dTj 6BX7JJaTMy9zNQVkHGnRKLc/GTkQcjB1/1elcx2/52kSTPLmhGXwzDL70 iudhI8LL3E/zulnoAY2EiNBkDu9Ev;
Domainkey-signature:	s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=r8iIQLdWvSbM29WrOWtTKT2WYY2frQUKTAVD7mQWyCtXv86nrVVQ510b AinmQjkw0+s6DhjS++D6q7x034AxFVbXSxBsdPc7iD2qWbOS60MRqkNDD SDR4AUAGQyKYfnbcgSLv2UatDglCUvLhfeM1EW1ZQejF0BJnfTWpZlVYP zVF8ZNanEvD4paTx1O2PRzhvppdd5O0a6D+dWrVhu00flr37D24mVQJ0r KOHdYxAz9lsNDgwnezd8XauamYQg2;
Envelope-to:	www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to:	<789F9655DD1B8F43B48D77C5D30659732874B82C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization:	Fujitsu Technology Solutions
References:	<C876E0F7.1C041%keir.fraser@xxxxxxxxxxxxx> <C876E2B6.1C047%keir.fraser@xxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659732874B82C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender:	xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent:	Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5

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@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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

WARNING - OLD ARCHIVES

xen-devel

Re: [Xen-devel] ACPI-Tables corrupted?