From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from [222.73.24.84] (helo=song.cn.fujitsu.com) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SYsV4-0008J2-Bk for kexec@lists.infradead.org; Mon, 28 May 2012 05:28:16 +0000 Message-ID: <4FC30C40.80500@cn.fujitsu.com> Date: Mon, 28 May 2012 13:25:20 +0800 From: Yanfei Zhang MIME-Version: 1.0 Subject: Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump References: <4FB35C48.30708@cn.fujitsu.com> <4FB92D5A.3060507@redhat.com> <4FB9A92D.7050108@cn.fujitsu.com> <4FB9FE08.4050905@redhat.com> <4FBA05F6.8070804@cn.fujitsu.com> <4FBA0C8A.2050003@redhat.com> <4FBB0ACA.2040907@cn.fujitsu.com> In-Reply-To: <4FBB0ACA.2040907@cn.fujitsu.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Avi Kivity Cc: dzickus@redhat.com, luto@mit.edu, kvm@vger.kernel.org, Joerg Roedel , mtosatti@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com, ludwig.nussel@suse.de, ebiederm@xmission.com, Greg KH SGVsbG8gQXZpLAoK09ogMjAxMsTqMDXUwjIyyNUgMTE6NDAsIFlhbmZlaSBaaGFuZyDQtLXAOgo+ INPaIDIwMTLE6jA11MIyMcjVIDE3OjM2LCBBdmkgS2l2aXR5INC0tcA6Cj4+IE9uIDA1LzIxLzIw MTIgMTI6MDggUE0sIFlhbmZlaSBaaGFuZyB3cm90ZToKPj4+INPaIDIwMTLE6jA11MIyMcjVIDE2 OjM0LCBBdmkgS2l2aXR5INC0tcA6Cj4+Pj4gT24gMDUvMjEvMjAxMiAwNTozMiBBTSwgWWFuZmVp IFpoYW5nIHdyb3RlOgo+Pj4+PiDT2iAyMDEyxOowNdTCMjHI1SAwMTo0MywgQXZpIEtpdml0eSDQ tLXAOgo+Pj4+Pj4gT24gMDUvMTYvMjAxMiAxMDo1MCBBTSwgemhhbmd5YW5mZWkgd3JvdGU6Cj4+ Pj4+Pj4gVGhpcyBwYXRjaCBzZXQgZXhwb3J0cyBvZmZzZXRzIG9mIFZNQ1MgZmllbGRzIGFzIG5v dGUgaW5mb3JtYXRpb24gZm9yCj4+Pj4+Pj4ga2R1bXAuIFdlIGNhbGwgaXQgVk1DU0lORk8uIFRo ZSBwdXJwb3NlIG9mIFZNQ1NJTkZPIGlzIHRvIHJldHJpZXZlCj4+Pj4+Pj4gcnVudGltZSBzdGF0 ZSBvZiBndWVzdCBtYWNoaW5lIGltYWdlLCBzdWNoIGFzIHJlZ2lzdGVycywgaW4gaG9zdAo+Pj4+ Pj4+IG1hY2hpbmUncyBjcmFzaCBkdW1wIGFzIFZNQ1MgZm9ybWF0LiBUaGUgcHJvYmxlbSBpcyB0 aGF0IFZNQ1MgaW50ZXJuYWwKPj4+Pj4+PiBpcyBoaWRkZW4gYnkgSW50ZWwgaW4gaXRzIHNwZWNp ZmljYXRpb24uIFNvLCB3ZSBzbG92ZSB0aGlzIHByb2JsZW0KPj4+Pj4+PiBieSByZXZlcnNlIGVu Z2luZWVyaW5nIGltcGxlbWVudGVkIGluIHRoaXMgcGF0Y2ggc2V0LiBUaGUgVk1DU0lORk8KPj4+ Pj4+PiBpcyBleHBvcnRlZCB2aWEgc3lzZnMgdG8ga2V4ZWMtdG9vbHMganVzdCBsaWtlIFZNQ09S RUlORk8uCj4+Pj4+Pj4KPj4+Pj4+PiBIZXJlIGFyZSB0d28gdXNlcmNhc2VzIGZvciB0d28gZmVh dHVyZXMgdGhhdCB3ZSB3YW50Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gMSkgQ3JlYXRlIGd1ZXN0IG1hY2hp bmUncyBjcmFzaCBkdW1wZmlsZSBmcm9tIGhvc3QgbWFjaGluZSdzIGNyYXNoIGR1bXBmaWxlCj4+ Pj4+Pj4KPj4+Pj4+PiBJbiBnZW5lcmFsLCB3ZSB3YW50IHRvIHVzZSB0aGlzIGZlYXR1cmUgb24g ZmFpbHVyZSBhbmFseXNpcyBmb3IgdGhlIHN5c3RlbQo+Pj4+Pj4+IHdoZXJlIHRoZSBwcm9jZXNz aW5nIGRlcGVuZHMgb24gdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBob3N0IGFuZCBndWVzdAo+ Pj4+Pj4+IG1hY2hpbmVzIHRvIGxvb2sgaW50byB0aGUgc3lzdGVtIGZyb20gYm90aCBtYWNoaW5l cydzIHZpZXdwb2ludHMuCj4+Pj4+Pj4KPj4+Pj4+PiBBcyBhIGNvbmNyZXRlIHNpdHVhdGlvbiwg Y29uc2lkZXIgd2hlcmUgdGhlcmUncyBoZWFydGJlYXQgbW9uaXRvcmluZwo+Pj4+Pj4+IGZlYXR1 cmUgb24gdGhlIGd1ZXN0IG1hY2hpbmUncyBzaWRlLCB3aGVyZSB3ZSBuZWVkIHRvIGRldGVybWlu ZSBpbgo+Pj4+Pj4+IHdoaWNoIG1hY2hpbmUgc2lkZSB0aGUgY2F1c2Ugb2YgaGVhcnRiZWF0IHN0 b3AgbGllcy4gSW4gb3VyIGFjdHVhbAo+Pj4+Pj4+IGV4cGVyaW1lbnRzLCB3ZSBlbmNvdW50ZXJl ZCBzdWNoIHNpdHVhdGlvbiBhbmQgd2UgZm91bmQgdGhlIGNhdXNlIG9mCj4+Pj4+Pj4gdGhlIGJ1 ZyB3YXMgaW4gaG9zdCdzIHByb2Nlc3Mgc2NoZWR1bGFyIHNvIGd1ZXN0IG1hY2hpbmUncyB2Y3B1 IHN0b3BwZWQKPj4+Pj4+PiBmb3IgYSBsb25nIHRpbWUgYW5kIHRoZW4gbGVkIHRvIGhlYXJ0YmVh dCBzdG9wLgo+Pj4+Pj4+Cj4+Pj4+Pj4gVGhlIG1vZHVsZSB0aGF0IGp1ZGdlcyBoZWFydGJlYXQg c3RvcCBpcyBvbiBndWVzdCBtYWNoaW5lLCBzbyB3ZSBuZWVkCj4+Pj4+Pj4gdG8gZGVidWcgZ3Vl c3QgbWFjaGluZSdzIGRhdGEuIEJ1dCBpZiB0aGUgY2F1c2UgbGllcyBpbiBob3N0IG1hY2hpbmUK Pj4+Pj4+PiBzaWRlLCB3ZSBuZWVkIHRvIGxvb2sgaW50byBob3N0IG1hY2hpbmUncyBjcmFzaCBk dW1wLgo+Pj4+Pj4KPj4+Pj4+IERvIHlvdSBtZWFuLCB0aGF0IGEgaGVhcnRiZWF0IGZhaWx1cmUg aW4gdGhlIGd1ZXN0IGxlYWQgdG8gaG9zdCBwYW5pYz8KPj4+Pj4+Cj4+Pj4+PiBNeSBleHBlY3Rh dGlvbiBpcyB0aGF0IGEgcHJvYmxlbSBpbiB0aGUgZ3Vlc3Qgd2lsbCBjYXVzZSB0aGUgZ3Vlc3Qg dG8KPj4+Pj4+IHBhbmljIGFuZCBwZXJoYXBzIHByb2R1Y2UgYSBkdW1wOyB0aGUgaG9zdCB3aWxs IHJlbWFpbiB1cC4KPj4+Pj4+Cj4+Pj4+Cj4+Pj4+IFRoZSBwb2ludCBpcyB0aGF0IGJlZm9yZSBv dXIgaW52ZXN0aWdhdGlvbiwgd2UgZGlkbid0IGtub3cgd2hpY2ggc2lkZSAKPj4+Pj4gbGVhZHMg dG8gdGhpcyBidWdneSBzaXR1YXRpb24uIE1heWJlIGEgYnVnIGluIGhvc3QgbWFjaGluZSBvciB0 aGUgZ3Vlc3QKPj4+Pj4gbWFjaGluZSBpdHNlbGYgY2F1c2VzIGEgaGVhcnRiZWF0IGZhaWx1cmUu Cj4+Pj4KPj4+PiBIb3cgY2FuIGEgZ3Vlc3QgYnVnIGNhdXNlIGEgaG9zdCBwYW5pYz8KPj4+Pgo+ Pj4+PiBTbyB3ZSB3YW50IHRvIGdldCBib3RoIGhvc3QgbWFjaGluZSdzIGNyYXNoIGR1bXAgYW5k IGd1ZXN0IG1hY2hpbmUncwo+Pj4+PiBjcmFzaCBkdW1wICphdCB0aGUgc2FtZSB0aW1lKi4gVGhl biB3ZSBjb3VsZCB1c2UgdXNlcnNwYWNlIHRvb2xzIHRvCj4+Pj4+IGdldCBndWVzdCBtYWNoaW5l IGNyYXNoIGR1bXAgZnJvbSBob3N0IG1hY2hpbmUncyBhbmQgYW5hbHlzZSB0aGVtCj4+Pj4+IHNl cGFyYXRlbHkgdG8gZmluZCB3aGljaCBzaWRlIGNhdXNlcyB0aGUgcHJvYmxlbS4KPj4+Pj4KPj4+ Pgo+Pj4+IElmIHRoZSBndWVzdCBjYXVzZWQgdGhlIHByb2JsZW0sIHRoZXJlIHdvdWxkIGJlIG5v IHBhbmljOyB0aGVyZWZvcmUKPj4+PiB0aGVyZSB3YXMgYSBob3N0IGJ1Zy4KPj4+Pgo+Pj4KPj4+ IFllcywgYSBndWVzdCBidWcgY2Fubm90IGNhdXNlIGEgaG9zdCBwYW5pYy4gV2hlbiBoZWFydGJl YXQgc3RvcHMgaW4gZ3Vlc3QKPj4+IG1hY2hpbmUsIHdlIGNvdWxkIHRyaWdnZXIgdGhlIGhvc3Qg ZHVtcCBtZWNoYW5pc20gdG8gd29yay4gVGhpcyBpcyBiZWNhdXNlCj4+PiB3ZSB3YW50IHRvIGdl dCB0aGUgc3RhdHVzIG9mIGJvdGggaG9zdCBhbmQgZ3Vlc3QgbWFjaGluZSBhdCB0aGUgc2FtZSB0 aW1lCj4+PiB3aGVuIGhlYXJ0YmVhdCBzdG9wcyBpbiBndWVzdCBtYWNoaW5lLiBUaGVuIHdlIGNh biBsb29rIGZvciBidWcgcmVhc29ucwo+Pj4gZnJvbSBib3RoIGhvc3QgbWFjaGluZSdzIGFuZCBn dWVzdCBtYWNoaW5lJ3Mgdmlld3MuCj4+Cj4+IFRoYXQgc291bmRzIGxpa2UgYSBiYWQgaWRlYS4g Q2FuIHlvdSBleHBsYWluIGluIHdoYXQgc2l0dWF0aW9uIGl0IG1ha2VzCj4+IHNlbnNlIGZvciBh IGd1ZXN0IHRvIHN0b3AgdGhlIGhvc3QgKGFuZCBhbGwgb3RoZXIgZ3Vlc3RzIHJ1bm5pbmcgb24g aXQpCj4+IHJhdGhlciB0aGFuIGp1c3QgcmVzdGFydGluZyB0aGUgZmFpbGVkIHNlcnZpY2VzIChv biB0aGUgaG9zdCBvciBvdGhlcgo+PiBndWVzdHMpPwo+Pgo+IAo+IFdlIG5ldmVyIGRvIHRoaXMg b24gY3VzdG9tZXIncyBlbnZpcm9ubWVudCB3aGljaCBtYXliZSBhIGhvc3Qgd2l0aCBtYW55IGd1 ZXN0cwo+IHJ1bm5pbmcgb24gaXQuIFdlIGRvIHRoaXMgb24gYW5vdGhlciBlbnZpcm9ubWVudCB0 byByZXByb2R1Y2UgdGhlIGJ1Z2d5Cj4gc2l0dWF0aW9uOyBvciB3ZSBkbyB0aGlzIGluIHRlc3Rp bmcgcGhhc2Ugb24gZGV2ZWxvcG1lbnQgZW52aXJvbm1lbnQgdG93YXJkcwo+IHByb2R1Y3Rpb24g b25lIG9uIHRoZSBjdXN0b21lcidzIHNpdGUuCj4gCj4+Pj4+Pj4gV2l0aG91dCB0aGlzIGZlYXR1 cmUsIHdlIGZpcnN0IGNyZWF0ZSBndWVzdCBtYWNoaW5lJ3MgZHVtcCBhbmQgdGhlbgo+Pj4+Pj4+ IGNyZWF0ZSBob3N0IG1haGluZSdzLCBidXQgdGhlcmUncyBvbmx5IGEgc2hvcnQgdGltZSBiZXR3 ZWVuIHR3bwo+Pj4+Pj4+IHByb2Nlc3NpbmdzLCBkdXJpbmcgd2hpY2ggaXQncyB1bmxpa2VseSB0 aGF0IGJ1Z2d5IHNpdHVhdGlvbiByZW1haW5zLgo+Pj4+Pj4+Cj4+Pj4+Pj4gU28sIHdlIHRoaW5r IHRoZSBmZWF0dXJlIGlzIHVzZWZ1bCB0byBkZWJ1ZyBib3RoIGd1ZXN0IG1hY2hpbmUncyBhbmQK Pj4+Pj4+PiBob3N0IG1hY2hpbmUncyBzaWRlcyBhdCB0aGUgc2FtZSB0aW1lLCBhbmQgZXhwZWN0 IHdlIGNhbiBtYWtlIGZhaWx1cmUKPj4+Pj4+PiBhbmFseXNpcyBlZmZpY2llbnRseS4KPj4+Pj4+ Pgo+Pj4+Pj4+IE9mIGNvdXJzZSwgd2UgYmVsaWV2ZSB0aGlzIGZlYXR1cmUgaXMgY29tbW9ubHkg dXNlZnVsIG9uIHRoZSBzaXR1YXRpb24KPj4+Pj4+PiB3aGVyZSBndWVzdCBtYWNoaW5lIGRvZXNu J3Qgd29yayB3ZWxsIGR1ZSB0byBzb21ldGhpbmcgb2YgaG9zdCBtYWNoaW5lJ3MuCj4+Pj4+Pj4K Pj4+Pj4+PiAyKSBHZXQgb2Zmc2V0cyBvZiBWTUNTIGluZm9ybWF0aW9uIG9uIHRoZSBDUFUgcnVu bmluZyBvbiB0aGUgaG9zdCBtYWNoaW5lCj4+Pj4+Pj4KPj4+Pj4+PiBJZiBrZHVtcCBkb2Vzbid0 IHdvcmsgd2VsbCwgdGhlbiBpdCBtZWFucyB3ZSBjYW5ub3QgdXNlIGt2bSBBUEkgdG8gZ2V0Cj4+ Pj4+Pj4gcmVnaXN0ZXIgdmFsdWVzIG9mIGd1ZXN0IG1hY2hpbmUgYW5kIHRoZXkgYXJlIHN0aWxs IGxlZnQgb24gaXRzIHZtY3MKPj4+Pj4+PiByZWdpb24uIEluIHRoZSBjYXNlLCB3ZSB1c2UgY3Jh c2ggZHVtcCBtZWNoYW5pc20gcnVubmluZyBvdXRzaWRlIG9mCj4+Pj4+Pj4gbGludXgga2VybmVs LCBzdWNoIGFzIHNhZHVtcCwgYSBmaXJtd2FyZS1iYXNlZCBjcmFzaCBkdW1wLiBUaGVuIFZNQ1MK Pj4+Pj4+PiBpbmZvcm1hdGlvbiBpcyB0aGVuIG5lY2Vzc2FyeS4KPj4+Pj4+Cj4+Pj4+PiBTaG91 bGRuJ3Qgc2FkdW1wIHRoZW4gZXhwb3NlIHRoZSBWTUNTIG9mZnNldHM/IFBlcmhhcHMgYnVuZGxp bmcgdGhlbQo+Pj4+Pj4gaW50byBpdHMgZHVtcCBmaWxlPwo+Pj4+Pj4KPj4+Pj4KPj4+Pj4gRmly bXdhcmUtYmFzZWQgY3Jhc2ggZHVtcCBkb2Vzbid0IGNvbmNlcm4gdGhlIG9zIHJ1bm5pbmcgb24g dGhlIG1hY2hpbmUuCj4+Pj4+IFNvIGl0IHdpbGwgbm90IGRvIGFueSBvcyBoYW5kbGluZyB3aGVu IG1hY2hpbmUgY3Jhc2hlcy4KPj4+Pgo+Pj4+IFNlZW1zIHRvIG1lIHRoZSBWTUNTIG9mZnNldHMg YXJlIE9TIGluZGVwZW5kZW50Lgo+Pj4+Cj4+PiBIbW0sIHlvdSBtZWFuIHdlIGNvdWxkIGdldCBW TUNTIG9mZnNldHMgaW4gc2FkdW1wIGl0c2VsZj8KPj4+IEJ1dCBJIHRoaW5rIGlmIHdlIGp1c3Qg ZXhwb3J0IFZNQ1Mgb2Zmc2V0cyBpbiBrZXJuZWwsIHdlIGNvdWxkIHVzZSB0aGUgY3VycmVudAo+ Pj4gZXhpc3RpbmcgZHVtcCB0b29scyB3aXRoIG5vIG9yIGp1c3QgdmVyeSB0aW55IGNoYW5nZS4g SSB0aGluayB0aGlzIGNvdWxkIGJlCj4+PiBhIG1vcmUgZ2VuZXJhbCBtZWNoYW5pc20gdGhhbiBt YWtpbmcgY2hhbmdlcyBpbiBhbGwga2luZHMgb2YgZHVtcCB0b29scy4KPj4KPj4gVGhlIHNhZHVt cCB0b29sIGdlbmVyYXRlcyBhIGNvcmUgZmlsZSB3aXRoIHRoZSBPUyBpbWFnZSwgcmlnaHQ/IENh biBpdAo+PiBub3QgYXR0YWNoIHRoZSBvZmZzZXRzIHRvIGEgbm90ZSwganVzdCBsaWtlIHlvdSBw cm9wb3NlIGZvciBrZHVtcD8KPj4KPiAKPiBCb3RoIGFyZSByaWdodC4KCgpEb3UgeW91IGhhdmUg YW55IGNvbW1lbnRzIGFib3V0IHRoaXMgcGF0Y2ggc2V0PwoKVGhhbmtzClpoYW5nIFlhbmZlaQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Ka2V4ZWMgbWFp bGluZyBsaXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVh ZC5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXhlYwo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yanfei Zhang Subject: Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump Date: Mon, 28 May 2012 13:25:20 +0800 Message-ID: <4FC30C40.80500@cn.fujitsu.com> References: <4FB35C48.30708@cn.fujitsu.com> <4FB92D5A.3060507@redhat.com> <4FB9A92D.7050108@cn.fujitsu.com> <4FB9FE08.4050905@redhat.com> <4FBA05F6.8070804@cn.fujitsu.com> <4FBA0C8A.2050003@redhat.com> <4FBB0ACA.2040907@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: mtosatti@redhat.com, ebiederm@xmission.com, luto@mit.edu, Joerg Roedel , dzickus@redhat.com, paul.gortmaker@windriver.com, ludwig.nussel@suse.de, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kexec@lists.infradead.org, Greg KH To: Avi Kivity Return-path: In-Reply-To: <4FBB0ACA.2040907@cn.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Hello Avi, =D3=DA 2012=C4=EA05=D4=C222=C8=D5 11:40, Yanfei Zhang =D0=B4=B5=C0: > =D3=DA 2012=C4=EA05=D4=C221=C8=D5 17:36, Avi Kivity =D0=B4=B5=C0: >> On 05/21/2012 12:08 PM, Yanfei Zhang wrote: >>> =D3=DA 2012=C4=EA05=D4=C221=C8=D5 16:34, Avi Kivity =D0=B4=B5=C0: >>>> On 05/21/2012 05:32 AM, Yanfei Zhang wrote: >>>>> =D3=DA 2012=C4=EA05=D4=C221=C8=D5 01:43, Avi Kivity =D0=B4=B5=C0: >>>>>> On 05/16/2012 10:50 AM, zhangyanfei wrote: >>>>>>> This patch set exports offsets of VMCS fields as note informati= on for >>>>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retri= eve >>>>>>> runtime state of guest machine image, such as registers, in hos= t >>>>>>> machine's crash dump as VMCS format. The problem is that VMCS i= nternal >>>>>>> is hidden by Intel in its specification. So, we slove this prob= lem >>>>>>> by reverse engineering implemented in this patch set. The VMCSI= NFO >>>>>>> is exported via sysfs to kexec-tools just like VMCOREINFO. >>>>>>> >>>>>>> Here are two usercases for two features that we want. >>>>>>> >>>>>>> 1) Create guest machine's crash dumpfile from host machine's cr= ash dumpfile >>>>>>> >>>>>>> In general, we want to use this feature on failure analysis for= the system >>>>>>> where the processing depends on the communication between host = and guest >>>>>>> machines to look into the system from both machines's viewpoint= s. >>>>>>> >>>>>>> As a concrete situation, consider where there's heartbeat monit= oring >>>>>>> feature on the guest machine's side, where we need to determine= in >>>>>>> which machine side the cause of heartbeat stop lies. In our act= ual >>>>>>> experiments, we encountered such situation and we found the cau= se of >>>>>>> the bug was in host's process schedular so guest machine's vcpu= stopped >>>>>>> for a long time and then led to heartbeat stop. >>>>>>> >>>>>>> The module that judges heartbeat stop is on guest machine, so w= e need >>>>>>> to debug guest machine's data. But if the cause lies in host ma= chine >>>>>>> side, we need to look into host machine's crash dump. >>>>>> >>>>>> Do you mean, that a heartbeat failure in the guest lead to host = panic? >>>>>> >>>>>> My expectation is that a problem in the guest will cause the gue= st to >>>>>> panic and perhaps produce a dump; the host will remain up. >>>>>> >>>>> >>>>> The point is that before our investigation, we didn't know which = side=20 >>>>> leads to this buggy situation. Maybe a bug in host machine or the= guest >>>>> machine itself causes a heartbeat failure. >>>> >>>> How can a guest bug cause a host panic? >>>> >>>>> So we want to get both host machine's crash dump and guest machin= e's >>>>> crash dump *at the same time*. Then we could use userspace tools = to >>>>> get guest machine crash dump from host machine's and analyse them >>>>> separately to find which side causes the problem. >>>>> >>>> >>>> If the guest caused the problem, there would be no panic; therefor= e >>>> there was a host bug. >>>> >>> >>> Yes, a guest bug cannot cause a host panic. When heartbeat stops in= guest >>> machine, we could trigger the host dump mechanism to work. This is = because >>> we want to get the status of both host and guest machine at the sam= e time >>> when heartbeat stops in guest machine. Then we can look for bug rea= sons >>> from both host machine's and guest machine's views. >> >> That sounds like a bad idea. Can you explain in what situation it ma= kes >> sense for a guest to stop the host (and all other guests running on = it) >> rather than just restarting the failed services (on the host or othe= r >> guests)? >> >=20 > We never do this on customer's environment which maybe a host with ma= ny guests > running on it. We do this on another environment to reproduce the bug= gy > situation; or we do this in testing phase on development environment = towards > production one on the customer's site. >=20 >>>>>>> Without this feature, we first create guest machine's dump and = then >>>>>>> create host mahine's, but there's only a short time between two >>>>>>> processings, during which it's unlikely that buggy situation re= mains. >>>>>>> >>>>>>> So, we think the feature is useful to debug both guest machine'= s and >>>>>>> host machine's sides at the same time, and expect we can make f= ailure >>>>>>> analysis efficiently. >>>>>>> >>>>>>> Of course, we believe this feature is commonly useful on the si= tuation >>>>>>> where guest machine doesn't work well due to something of host = machine's. >>>>>>> >>>>>>> 2) Get offsets of VMCS information on the CPU running on the ho= st machine >>>>>>> >>>>>>> If kdump doesn't work well, then it means we cannot use kvm API= to get >>>>>>> register values of guest machine and they are still left on its= vmcs >>>>>>> region. In the case, we use crash dump mechanism running outsid= e of >>>>>>> linux kernel, such as sadump, a firmware-based crash dump. Then= VMCS >>>>>>> information is then necessary. >>>>>> >>>>>> Shouldn't sadump then expose the VMCS offsets? Perhaps bundling = them >>>>>> into its dump file? >>>>>> >>>>> >>>>> Firmware-based crash dump doesn't concern the os running on the m= achine. >>>>> So it will not do any os handling when machine crashes. >>>> >>>> Seems to me the VMCS offsets are OS independent. >>>> >>> Hmm, you mean we could get VMCS offsets in sadump itself? >>> But I think if we just export VMCS offsets in kernel, we could use = the current >>> existing dump tools with no or just very tiny change. I think this = could be >>> a more general mechanism than making changes in all kinds of dump t= ools. >> >> The sadump tool generates a core file with the OS image, right? Can = it >> not attach the offsets to a note, just like you propose for kdump? >> >=20 > Both are right. Dou you have any comments about this patch set? Thanks Zhang Yanfei