From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from us-smtp-1.mimecast.com ([205.139.110.61] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iN97o-0000pQ-7L for kexec@lists.infradead.org; Wed, 23 Oct 2019 05:24:02 +0000 Subject: Re: [PATCH 1/3 v4] x86/kdump: always reserve the low 1MiB when the crashkernel option is specified References: <20191017094347.20327-1-lijiang@redhat.com> <20191017094347.20327-2-lijiang@redhat.com> <20191022083015.GB31700@zn.tnic> From: lijiang Message-ID: <0e657965-6f97-84ce-e51d-42d4978c4d88@redhat.com> Date: Wed, 23 Oct 2019 13:23:33 +0800 MIME-Version: 1.0 In-Reply-To: <20191022083015.GB31700@zn.tnic> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Borislav Petkov Cc: jgross@suse.com, Thomas.Lendacky@amd.com, bhe@redhat.com, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, mingo@redhat.com, ebiederm@xmission.com, hpa@zytor.com, tglx@linutronix.de, dyoung@redhat.com, vgoyal@redhat.com 5ZyoIDIwMTnlubQxMOaciDIy5pelIDE2OjMwLCBCb3Jpc2xhdiBQZXRrb3Yg5YaZ6YGTOgo+IE9u IFRodSwgT2N0IDE3LCAyMDE5IGF0IDA1OjQzOjQ1UE0gKzA4MDAsIExpYW5ibyBKaWFuZyB3cm90 ZToKPj4gQnVnemlsbGE6IGh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/ aWQ9MjA0NzkzCj4gClRoYW5rcyBmb3IgeW91ciBjb21tZW50LgoKPiBQdXQgdGhhdCBhcyBhIExp bms6IGJlbG93Lgo+IApMb29rcyBiZXR0ZXIuIE9LLgoKPj4gS2R1bXAga2VybmVsIHdpbGwgcmV1 c2UgdGhlIGZpcnN0IDY0MGsgcmVnaW9uIGJlY2F1c2Ugb2Ygc29tZSByZWFzb25zLAo+IAo+IHMv IG9mIHNvbWUgcmVhc29ucy8vCj4gCj4+IGZvciBleGFtcGxlOiB0aGUgdHJhbXBsaW5lIGFuZCBj b252ZW50aW9uYWwgUEMgc3lzdGVtIEJJT1MgcmVnaW9uIG1heQo+IAo+IHNwZWxsY2hlY2s6IHMv dHJhbXBsaW5lL3RyYW1wb2xpbmUvCj4gCj4gSSBzZWUgdHdvIG1vcmUgdHlwb3MgaW4gaGVyZSBh bmQgaWYgeW91IGhhZCBhIHNwZWxsY2hlY2tlciBlbmFibGVkIGluCj4geW91ciBlZGl0b3Igd2hl cmUgeW91IHdyaXRlIHRoZSBjb21taXQgbWVzc2FnZSwgeW91J2xsIHNlZSB0aGVtIHRvby4KPiBQ bGVhc2UgdXNlIG9uZS4KPiAKR29vZCBwb2ludC4gSSBqdXN0IHRyaWVkIHRvIGVuYWJsZSB0aGUg c3BlbGxjaGVja2VyIGluIHRoZSB2aW0gYW5kIG5vdyBpdApoYXMgd29ya2VkIHdlbGwuIFRoYW5r cy4gOi0pIAoKPj4gcmVxdWlyZSB0byBhbGxvY2F0ZSBtZW1vcnkgaW4gdGhpcyBhcmVhLiBPYnZp b3VzbHksIGtkdW1wIGtlcm5lbCB3aWxsCj4+IGFsc28gb3ZlcndyaXRlIHRoZSBmaXJzdCA2NDBr IHJlZ2lvbiwKPiAKPiBXZWxsLCBpdCBpcyBub3Qgb2J2aW91cyB0byBtZS4gUGxlYXNlIGJlIG1v cmUgc3BlY2lmaWM6IHdoeSB3b3VsZCB0aGUKPiBrZHVtcCBrZXJuZWwgZG8gdGhhdD8KPiAKS2R1 bXAga2VybmVsIHdpbGwgcmV1c2UgdGhlIGZpcnN0IDY0MGsgcmVnaW9uIGJlY2F1c2UgdGhlIHJl YWwgbW9kZQp0cmFtcG9saW5lIGhhcyB0byB3b3JrIGluIHRoaXMgYXJlYS4gV2hlbiB0aGUgdm1j b3JlIGlzIGR1bXBlZCwgdGhlCm9sZCBtZW1vcnkgaW4gdGhpcyBhcmVhIG1heSBiZSBhY2Nlc3Nl ZCwgdGhlcmVmb3JlLCBrZXJuZWwgaGFzIHRvCmNvcHkgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJz dCA2NDBrIGFyZWEgdG8gYSBiYWNrdXAgcmVnaW9uIHNvIHRoYXQKa2R1bXAga2VybmVsIGNhbiBy ZWFkIHRoZSBvbGQgbWVtb3J5IGZyb20gdGhlIGJhY2t1cCBhcmVhIG9mIHRoZQpmaXJzdCA2NDBr IGFyZWEsIHdoaWNoIGlzIGRvbmUgaW4gdGhlIHB1cmdhdG9yeSgpLgoKPj4gdGhlcmVmb3JlLCBr ZXJuZWwgaGFzIHRvIGNvcHkKPj4gdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCA2NDBrIGFyZWEg dG8gYSBiYWNrdXAgYXJlYSwgd2hpY2ggaXMgZG9uZSBpbgo+PiBwdXJnYXRvcnkoKSwgYmVjYXVz ZSB2bWNvcmUgbWF5IG5lZWQgdGhlIG9sZCBtZW1vcnkuIFdoZW4gdm1jb3JlIGlzCj4+IGR1bXBl ZCwga2R1bXAga2VybmVsIHdpbGwgcmVhZCB0aGUgb2xkIG1lbW9yeSBmcm9tIHRoZSBiYWNrdXAg YXJlYSBvZgo+PiB0aGUgZmlyc3QgNjQwayBhcmVhLgo+Pgo+PiBCYXNpY2FsbHksIHRoZSBtYWlu IHJlYXNvbiBzaG91bGQgYmUgY2xlYXIsIGtlcm5lbCBkb2VzIG5vdCBjb3JyZWN0bHkKPj4gaGFu ZGxlIHRoZSBmaXJzdCA2NDBrIHJlZ2lvbiB3aGVuIFNNRSBpcyBhY3RpdmUsCj4gCj4gSWYgeW91 IG1lbnRpb24gdGhlIGFjdHVhbCByZWFzb24gaGVyZSwgdGhhdCBzZW50ZW5jZSB3b3VsZCBiZSBj bGVhcmVyOgo+IAo+ICJXaGVuIFNNRSBpcyBlbmFibGVkIGluIHRoZSBmaXJzdCBrZXJuZWwsIHRo ZSBrZHVtcCBrZXJuZWwgbXVzdCBhY2Nlc3MKPiB0aGUgZmlyc3Qga2VybmVsJ3MgbWVtb3J5IHdp dGggdGhlIGVuY3J5cHRpb24gYml0IHNldC4iCj4gCj4gU29tZXRoaW5nIGxpa2UgdGhhdC4gCj4g Ckxvb2tzIGdvb2QuCgo+PiB3aGljaCBjYXVzZXMgdGhhdAo+PiBrZXJuZWwgZG9lcyBub3QgcHJv cGVybHkgY29weSB0aGVzZSBvbGQgbWVtb3J5IHRvIHRoZSBiYWNrdXAgYXJlYSBpbgo+PiBwdXJn YXRvcnkoKS4gVGhlcmVmb3JlLCBrZHVtcCBrZXJuZWwgcmVhZHMgb3V0IHRoZSBpbmNvcnJlY3Qg Y29udGVudHMKPiAKPiBzL2luY29ycmVjdC9lbmNyeXB0ZWQvCj4gCkV4YWN0bHkuCgo+PiBmcm9t IHRoZSBiYWNrdXAgYXJlYSB3aGVuIGR1bXBpbmcgdm1jb3JlLiBGaW5hbGx5LCB0aGUgcGhlbm9t ZW5vbiBpcwo+IAo+IHBoZW5vbWVub24/Cj4gCkZpbmFsbHksIGl0IGNhdXNlZCB0aGUgZm9sbG93 aW5nIGVycm9ycy4KCj4+IGFzIGZvbGxvdzoKPj4KPj4gW3Jvb3QgbGludXhdJCBjcmFzaCB2bWxp bnV4IC92YXIvY3Jhc2gvMTI3LjAuMC4xLTIwMTktMDktMTktMDhcOjMxXDoyNy92bWNvcmUKPj4g V0FSTklORzoga2VybmVsIHJlbG9jYXRlZCBbMjQwTUJdOiBwYXRjaGluZyA5NzExMCBnZGIgbWlu aW1hbF9zeW1ib2wgdmFsdWVzCj4+Cj4+ICAgICAgIEtFUk5FTDogL3Zhci9jcmFzaC8xMjcuMC4w LjEtMjAxOS0wOS0xOS0wODozMToyNy92bWxpbnV4Cj4+ICAgICBEVU1QRklMRTogL3Zhci9jcmFz aC8xMjcuMC4wLjEtMjAxOS0wOS0xOS0wODozMToyNy92bWNvcmUgIFtQQVJUSUFMIERVTVBdCj4+ ICAgICAgICAgQ1BVUzogMTI4Cj4+ICAgICAgICAgREFURTogVGh1IFNlcCAxOSAwODozMToxOCAy MDE5Cj4+ICAgICAgIFVQVElNRTogMDA6MDE6MjEKPj4gTE9BRCBBVkVSQUdFOiAwLjE2LCAwLjA3 LCAwLjAyCj4+ICAgICAgICBUQVNLUzogMTM0Mwo+PiAgICAgTk9ERU5BTUU6IGFtZC1ldGhhbm9s Cj4+ICAgICAgUkVMRUFTRTogNS4zLjAtcmM3Kwo+PiAgICAgIFZFUlNJT046ICM0IFNNUCBUaHUg U2VwIDE5IDA4OjE0OjAwIEVEVCAyMDE5Cj4+ICAgICAgTUFDSElORTogeDg2XzY0ICAoMjE5NSBN aHopCj4+ICAgICAgIE1FTU9SWTogMTI3LjkgR0IKPj4gICAgICAgIFBBTklDOiAiS2VybmVsIHBh bmljIC0gbm90IHN5bmNpbmc6IHN5c3JxIHRyaWdnZXJlZCBjcmFzaCIKPj4gICAgICAgICAgUElE OiA5Nzg5Cj4+ICAgICAgQ09NTUFORDogImJhc2giCj4+ICAgICAgICAgVEFTSzogImZmZmY4OTcx MTg5NGFlODAgIFtUSFJFQURfSU5GTzogZmZmZjg5NzExODk0YWU4MF0iCj4+ICAgICAgICAgIENQ VTogODMKPj4gICAgICAgIFNUQVRFOiBUQVNLX1JVTk5JTkcgKFBBTklDKQo+Pgo+PiBjcmFzaD4g a21lbSAtc3xncmVwIC1pIGludmFsaWQKPj4ga21lbTogZG1hLWttYWxsb2MtNTEyOiBzbGFiOmZm ZmZkNzc2ODAwMDFjMDAgaW52YWxpZCBmcmVlcG9pbnRlcjphNjA4NmFjMDk5ZjBjNWE0Cj4+IGtt ZW06IGRtYS1rbWFsbG9jLTUxMjogc2xhYjpmZmZmZDc3NjgwMDAxYzAwIGludmFsaWQgZnJlZXBv aW50ZXI6YTYwODZhYzA5OWYwYzVhNAo+PiBjcmFzaD4KPiAKPiBJIGZhaWwgdG8gc2VlIHdoYXQg dGhhdCdzIHRyeWluZyB0byB0ZWxsIG1lPyBZb3UgaGF2ZSBpbnZhbGlkIHBvaW50ZXJzPwo+IApZ ZXMsIHdoZW4gcGFyc2luZyB0aGUgdm1jb3JlIHZpYSBjcmFzaCB0b29sLCBpdCBvY2N1cnMgdGhl IGFib3ZlIGVycm9ycywKdGhlIGNyYXNoIHRvb2wgZ2V0cyBpbnZhbGlkIHBvaW50ZXJzLiAKCj4+ IEJUVzogSSBhbHNvIHRyaWVkIHRvIGZpeCB0aGUgYWJvdmUgcHJvYmxlbSBpbiBwdXJnYXRvcnko KSwgYnV0IHRoZXJlCj4+IGFyZSB0b28gbWFueSByZXN0cmljdHMgaW4gcHVyZ2F0b3J5KCkgY29u dGV4dCwgZm9yIGV4YW1wbGU6IGkgY2FuJ3QKPj4gYWxsb2NhdGUgbmV3IG1lbW9yeSB0byBjcmVh dGUgdGhlIGlkZW50aXR5IG1hcHBpbmcgcGFnZSB0YWJsZSBmb3IgU01FCj4+IHNpdHVhdGlvbi4K PiAKPiBUaGlzIHBhcmFncmFwaCBiZWxvbmdzIHVuZGVyIHRoZSAiLS0tIiBsaW5lIGJlbG93Lgo+ IApPSy4gVGhhbmtzLgoKPj4gQ3VycmVudGx5LCB0aGVyZSBhcmUgdHdvIHBsYWNlcyB3aGVyZSB0 aGUgZmlyc3QgNjQwayBhcmVhIGlzIG5lZWRlZCwKPj4gdGhlIGZpcnN0IG9uZSBpcyBpbiB0aGUg ZmluZF90cmFtcG9saW5lX3BsYWNlbWVudCgpLCBhbm90aGVyIG9uZSBpcwo+PiBpbiB0aGUgcmVz ZXJ2ZV9yZWFsX21vZGUoKSwgYW5kIHRoZWlyIGNvbnRlbnQgZG9lc24ndCBtYXR0ZXIuCj4+Cj4+ IFRvIGF2b2lkIHRoZSBhYm92ZSBlcnJvciwgd2hlbiB0aGUgY3Jhc2hrZXJuZWwga2VybmVsIGNv bW1hbmQgbGluZQo+PiBvcHRpb24gaXMgc3BlY2lmaWVkLCBsZXRzIHJlc2VydmUgdGhlIHJlbWFp bmluZyBsb3cgMU1pQiBtZW1vcnkoCj4+IGFmdGVyIHJlc2VydmluZyByZWFsIG1vZGUgbWVtcm95 KSBzbyB0aGF0IHRoZSBhbGxvY2F0ZWQgbWVtb3J5IGRvZXMKPj4gbm90IGZhbGwgaW50byB0aGUg bG93IDFNaUIgYXJlYSwgd2hpY2ggbWFrZXMgdXMgbm90IHRvIGNvcHkgdGhlIGZpcnN0Cj4+IDY0 MGsgY29udGVudCB0byBhIGJhY2t1cCByZWdpb24gaW4gcHVyZ2F0b3J5KCkuIFRoaXMgaW5kaWNh dGVzIHRoYXQKPj4gaXQgZG9lcyBub3QgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiBjcmFzaCBkdW1w cyBvciB1c2VkIGZvciBhbnl0aGluZwo+PiBleGVjZXB0IHRoZSBwcm9jZXNzb3IgdHJhbXBvbGlu ZXMgdGhhdCBtdXN0IGxpdmUgaW4gdGhlIGxvdyAxTWlCLgo+Pgo+PiBJbiBhZGRpdGlvbiwgYWxz byBuZWVkIHRvIGNsZWFuIGFsbCB0aGUgY29kZSByZWxhdGVkIHRvIHRoZSBiYWNrdXAKPj4gcmVn aW9uIGxhdGVyLgo+IAo+IERpdHRvLgo+IAo+PiBTaWduZWQtb2ZmLWJ5OiBMaWFuYm8gSmlhbmcg PGxpamlhbmdAcmVkaGF0LmNvbT4KPj4gLS0tCj4+ICBhcmNoL3g4Ni9yZWFsbW9kZS9pbml0LmMg fCAxMSArKysrKysrKysrKwo+PiAgMSBmaWxlIGNoYW5nZWQsIDExIGluc2VydGlvbnMoKykKPj4K Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L3JlYWxtb2RlL2luaXQuYyBiL2FyY2gveDg2L3JlYWxt b2RlL2luaXQuYwo+PiBpbmRleCA3ZGNlMzljOGMwMzQuLjFmMDQ5MjgzMGYyYyAxMDA2NDQKPj4g LS0tIGEvYXJjaC94ODYvcmVhbG1vZGUvaW5pdC5jCj4+ICsrKyBiL2FyY2gveDg2L3JlYWxtb2Rl L2luaXQuYwo+PiBAQCAtMzQsNiArMzQsMTcgQEAgdm9pZCBfX2luaXQgcmVzZXJ2ZV9yZWFsX21v ZGUodm9pZCkKPj4gIAo+PiAgCW1lbWJsb2NrX3Jlc2VydmUobWVtLCBzaXplKTsKPj4gIAlzZXRf cmVhbF9tb2RlX21lbShtZW0pOwo+PiArCj4+ICsjaWZkZWYgQ09ORklHX0tFWEVDX0NPUkUKPj4g KwkvKgo+PiArCSAqIFdoZW4gdGhlIGNyYXNoa2VybmVsIG9wdGlvbiBpcyBzcGVjaWZpZWQsIG9u bHkgdXNlIHRoZSBsb3cKPj4gKwkgKiAxTWlCIGZvciB0aGUgcmVhbCBtb2RlIHRyYW1wb2xpbmUu Cj4+ICsJICovCj4+ICsJaWYgKHN0cnN0cihib290X2NvbW1hbmRfbGluZSwgImNyYXNoa2VybmVs PSIpKSB7Cj4+ICsJCW1lbWJsb2NrX3Jlc2VydmUoMCwgMTw8MjApOwo+PiArCQlwcl9pbmZvKCJS ZXNlcnZpbmcgdGhlIGxvdyAxTWlCIG9mIG1lbW9yeSBmb3IgY3Jhc2hrZXJuZWxcbiIpOwo+PiAr CX0KPj4gKyNlbmRpZiAvKiBDT05GSUdfS0VYRUNfQ09SRSAqLwo+IAo+IFRoaXMgaWZkZWZmZXJ5 IG5lZWRzIHRvIGJlIGEgZnVuY3Rpb24gaW4ga2VybmVsL2tleGVjX2NvcmUuYyB3aGljaCBpcwo+ IGNhbGxlZCBieSByZXNlcnZlX3JlYWxfbW9kZSgpLCBpbnN0ZWFkLgo+IApHb29kIHVuZGVyc3Rh bmRpbmcuIEkgd2lsbCB0cnkgdG8gaW1wcm92ZSBpdCBsYXRlci4KClRoYW5rcy4KTGlhbmJvCj4g VGh4Lgo+IAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACF9ECA9EAE for ; Wed, 23 Oct 2019 05:24:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 744E12084C for ; Wed, 23 Oct 2019 05:24:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WTW+uxNl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388167AbfJWFYA (ORCPT ); Wed, 23 Oct 2019 01:24:00 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:60970 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728697AbfJWFYA (ORCPT ); Wed, 23 Oct 2019 01:24:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571808237; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4JTRDEZOr8Z+dEGVRNplOCYtI8SYRnqHdIVrIZ8f01Y=; b=WTW+uxNl5LtEMc3MgitqoFIkk+XJMR/BZniNud7E5FPNoNY7aj/886AJKUg/NvdMzPRWEJ nRm7P9lHpYoiW+Vv/nEb+DzaWSrrmNR+UBp+Izs2VeUHzKwTTjPrIrCNKXIdTrv8YJJcQp IlIkUEEY940oG3MuTnclsvc1ywoYLwk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-104-ip4noSxtPGGBEgUWUIRgNQ-1; Wed, 23 Oct 2019 01:23:54 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8F56B800D57; Wed, 23 Oct 2019 05:23:52 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-33.pek2.redhat.com [10.72.12.33]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BF2160BE1; Wed, 23 Oct 2019 05:23:36 +0000 (UTC) Subject: Re: [PATCH 1/3 v4] x86/kdump: always reserve the low 1MiB when the crashkernel option is specified To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, bhe@redhat.com, dyoung@redhat.com, jgross@suse.com, dhowells@redhat.com, Thomas.Lendacky@amd.com, ebiederm@xmission.com, vgoyal@redhat.com, kexec@lists.infradead.org References: <20191017094347.20327-1-lijiang@redhat.com> <20191017094347.20327-2-lijiang@redhat.com> <20191022083015.GB31700@zn.tnic> From: lijiang Message-ID: <0e657965-6f97-84ce-e51d-42d4978c4d88@redhat.com> Date: Wed, 23 Oct 2019 13:23:33 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191022083015.GB31700@zn.tnic> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: ip4noSxtPGGBEgUWUIRgNQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =E5=9C=A8 2019=E5=B9=B410=E6=9C=8822=E6=97=A5 16:30, Borislav Petkov =E5=86= =99=E9=81=93: > On Thu, Oct 17, 2019 at 05:43:45PM +0800, Lianbo Jiang wrote: >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=3D204793 >=20 Thanks for your comment. > Put that as a Link: below. >=20 Looks better. OK. >> Kdump kernel will reuse the first 640k region because of some reasons, >=20 > s/ of some reasons// >=20 >> for example: the trampline and conventional PC system BIOS region may >=20 > spellcheck: s/trampline/trampoline/ >=20 > I see two more typos in here and if you had a spellchecker enabled in > your editor where you write the commit message, you'll see them too. > Please use one. >=20 Good point. I just tried to enable the spellchecker in the vim and now it has worked well. Thanks. :-)=20 >> require to allocate memory in this area. Obviously, kdump kernel will >> also overwrite the first 640k region, >=20 > Well, it is not obvious to me. Please be more specific: why would the > kdump kernel do that? >=20 Kdump kernel will reuse the first 640k region because the real mode trampoline has to work in this area. When the vmcore is dumped, the old memory in this area may be accessed, therefore, kernel has to copy the contents of the first 640k area to a backup region so that kdump kernel can read the old memory from the backup area of the first 640k area, which is done in the purgatory(). >> therefore, kernel has to copy >> the contents of the first 640k area to a backup area, which is done in >> purgatory(), because vmcore may need the old memory. When vmcore is >> dumped, kdump kernel will read the old memory from the backup area of >> the first 640k area. >> >> Basically, the main reason should be clear, kernel does not correctly >> handle the first 640k region when SME is active, >=20 > If you mention the actual reason here, that sentence would be clearer: >=20 > "When SME is enabled in the first kernel, the kdump kernel must access > the first kernel's memory with the encryption bit set." >=20 > Something like that.=20 >=20 Looks good. >> which causes that >> kernel does not properly copy these old memory to the backup area in >> purgatory(). Therefore, kdump kernel reads out the incorrect contents >=20 > s/incorrect/encrypted/ >=20 Exactly. >> from the backup area when dumping vmcore. Finally, the phenomenon is >=20 > phenomenon? >=20 Finally, it caused the following errors. >> as follow: >> >> [root linux]$ crash vmlinux /var/crash/127.0.0.1-2019-09-19-08\:31\:27/v= mcore >> WARNING: kernel relocated [240MB]: patching 97110 gdb minimal_symbol val= ues >> >> KERNEL: /var/crash/127.0.0.1-2019-09-19-08:31:27/vmlinux >> DUMPFILE: /var/crash/127.0.0.1-2019-09-19-08:31:27/vmcore [PARTIAL = DUMP] >> CPUS: 128 >> DATE: Thu Sep 19 08:31:18 2019 >> UPTIME: 00:01:21 >> LOAD AVERAGE: 0.16, 0.07, 0.02 >> TASKS: 1343 >> NODENAME: amd-ethanol >> RELEASE: 5.3.0-rc7+ >> VERSION: #4 SMP Thu Sep 19 08:14:00 EDT 2019 >> MACHINE: x86_64 (2195 Mhz) >> MEMORY: 127.9 GB >> PANIC: "Kernel panic - not syncing: sysrq triggered crash" >> PID: 9789 >> COMMAND: "bash" >> TASK: "ffff89711894ae80 [THREAD_INFO: ffff89711894ae80]" >> CPU: 83 >> STATE: TASK_RUNNING (PANIC) >> >> crash> kmem -s|grep -i invalid >> kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac= 099f0c5a4 >> kmem: dma-kmalloc-512: slab:ffffd77680001c00 invalid freepointer:a6086ac= 099f0c5a4 >> crash> >=20 > I fail to see what that's trying to tell me? You have invalid pointers? >=20 Yes, when parsing the vmcore via crash tool, it occurs the above errors, the crash tool gets invalid pointers.=20 >> BTW: I also tried to fix the above problem in purgatory(), but there >> are too many restricts in purgatory() context, for example: i can't >> allocate new memory to create the identity mapping page table for SME >> situation. >=20 > This paragraph belongs under the "---" line below. >=20 OK. Thanks. >> Currently, there are two places where the first 640k area is needed, >> the first one is in the find_trampoline_placement(), another one is >> in the reserve_real_mode(), and their content doesn't matter. >> >> To avoid the above error, when the crashkernel kernel command line >> option is specified, lets reserve the remaining low 1MiB memory( >> after reserving real mode memroy) so that the allocated memory does >> not fall into the low 1MiB area, which makes us not to copy the first >> 640k content to a backup region in purgatory(). This indicates that >> it does not need to be included in crash dumps or used for anything >> execept the processor trampolines that must live in the low 1MiB. >> >> In addition, also need to clean all the code related to the backup >> region later. >=20 > Ditto. >=20 >> Signed-off-by: Lianbo Jiang >> --- >> arch/x86/realmode/init.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c >> index 7dce39c8c034..1f0492830f2c 100644 >> --- a/arch/x86/realmode/init.c >> +++ b/arch/x86/realmode/init.c >> @@ -34,6 +34,17 @@ void __init reserve_real_mode(void) >> =20 >> =09memblock_reserve(mem, size); >> =09set_real_mode_mem(mem); >> + >> +#ifdef CONFIG_KEXEC_CORE >> +=09/* >> +=09 * When the crashkernel option is specified, only use the low >> +=09 * 1MiB for the real mode trampoline. >> +=09 */ >> +=09if (strstr(boot_command_line, "crashkernel=3D")) { >> +=09=09memblock_reserve(0, 1<<20); >> +=09=09pr_info("Reserving the low 1MiB of memory for crashkernel\n"); >> +=09} >> +#endif /* CONFIG_KEXEC_CORE */ >=20 > This ifdeffery needs to be a function in kernel/kexec_core.c which is > called by reserve_real_mode(), instead. >=20 Good understanding. I will try to improve it later. Thanks. Lianbo > Thx. >=20