Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5727675imd; Wed, 31 Oct 2018 00:44:13 -0700 (PDT) X-Google-Smtp-Source: AJdET5eLZe7UQMZ7zKPJCpItYhDgOLN/ozf0xRk9wf4OK+f1dXZbQ/T1rZKFWD2P2+2EDLWpVEQt X-Received: by 2002:a62:5881:: with SMTP id m123-v6mr2261837pfb.160.1540971853196; Wed, 31 Oct 2018 00:44:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540971853; cv=none; d=google.com; s=arc-20160816; b=gkGpt8A/1SmkkuaDK5DCkdtHTaVRPEC/7yYd5dDVED83OShlsNUzYc3Cxsau9cdbI6 lNspFuvFDgBAVZpOOpg76cTNZFgDlpzhCakcny7lWJhcODpXPe2SCxzBkuX/pnHMI54+ yn6Bu1HJemB2rbYu63J0K+4ZIw3U1vCFXiZTAX94a92Wq0UuJl8EwmsQJ7b5kbhAngze qjlpHDaMXDWKRC3GUc23+FpC8F3D4MN/tTtzCIIjAjrf9fwcCuaTqBO4CN0RyCXGSb8F Oe5N5q3d6NNHvmuH2lccUJTlvvqVZXElKTEtUOx1Qw+spNMMh/jjpO30r9/L7vLb4FXS HziA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=HkHfl9mWhNSVaLciaktXDrEwuYLvJD1/cHmvxF227uk=; b=Ngq//FxOglsfCN3uKMb09pxq6Bv3Dg/FEd1PKGa/ImssshdNWcbMYE+KoPVpzBs1dn l/mN4vPvsaY6ORg73CODjDO51pOQJHzktIbW9e13wtkp7NifglGP1wzfk27yt0f2EtE1 H3AdaGdVWEoqBlq8ADgvkjbY92AKrHJ6K6zCdYiZbZYZ75AL5+e6awlR8lBTf4tUmCnV nNyvTLKjitGs6O3lYmcjQPpeYDCUikWTFY4DRgBdrrdD3mdkkvxK/KACd0DJ2+vF5ZcT e9zAi/5nzccaiUlt8oLE3lk/6xqAtv1+XvoilkqzbHDuhHWLrpYljrsLAKZOFldlaGWC QXfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d34-v6si26401528pgm.550.2018.10.31.00.43.57; Wed, 31 Oct 2018 00:44:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727115AbeJaQk3 (ORCPT + 99 others); Wed, 31 Oct 2018 12:40:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49474 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbeJaQk3 (ORCPT ); Wed, 31 Oct 2018 12:40:29 -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 mx1.redhat.com (Postfix) with ESMTPS id 71AD0308403E; Wed, 31 Oct 2018 07:43:30 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-109.pek2.redhat.com [10.72.12.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D083960F87; Wed, 31 Oct 2018 07:43:07 +0000 (UTC) Subject: Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo To: Dave Young Cc: Baoquan He , Borislav Petkov , Petr Tesarik , linux-kernel@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, mingo@redhat.com, tglx@linutronix.de, Kazuhito Hagio References: <20181029095738.GB20101@zn.tnic> <15897206-c1a6-ced6-3a1b-f71da8fc9c83@redhat.com> <20181029114414.GA11408@MiWiFi-R3L-srv> <90385882-7fd1-a674-ec5a-19bd42471a5e@redhat.com> <20181029134918.GB32150@zn.tnic> <699ab34e-1373-582d-4e58-e76bd57ec34f@redhat.com> <20181030050900.GA25987@dhcp-128-65.nay.redhat.com> <20181030091542.GD32102@zn.tnic> <20181030092314.GC14493@MiWiFi-R3L-srv> <20181031024748.GA2058@dhcp-128-65.nay.redhat.com> From: lijiang Message-ID: Date: Wed, 31 Oct 2018 15:43:02 +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: <20181031024748.GA2058@dhcp-128-65.nay.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 31 Oct 2018 07:43:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2018年10月31日 10:47, Dave Young 写道: > Add Kazu, the makedumpfile maintainer in cc. > > On 10/31/18 at 10:26am, lijiang wrote: >> 在 2018年10月30日 17:23, Baoquan He 写道: >>> >>> Hi Boris, DaveY and Lianbo, >>> >>> On 10/30/18 at 10:15am, Borislav Petkov wrote: >>>> On Tue, Oct 30, 2018 at 01:09:00PM +0800, Dave Young wrote: >>>>> It is not the content, I think it is a good catch from Boris, it would >>>>> be good to document the exported things in somewhere eg. >>>>> Documentation/kdump/vmcoreinfo.txt >>> >>> For the vmcoreinfo variables document, I personally think it might be >>> not necessary. The reason is that all the old varialbles are exported >>> with the name of themselves. We know what they are or what they >>> represent since they are all kernel symbols or macro. Only this me_mask, >>> it's a local variable and store the value of sme_me_mask for now, may >>> store more info later like Petr mentioned, and also will store the memory >>> encryption information of TME (which is intel's transparent memory encryption). >>> We can add code comment around to tell these. >>> >> Thank you, everyone. >> >> I personally agree with Baoquan's opinion. What do you think about? Boris and other reviewer? >> >> If the vmcoreinfo document is necessary, would you like to help me to provide an outline? >> I can try my best to write the document. > > It is true like what Baoquan said, these information are mainly used by > makedumpfile tool for creating a filtered vmcore. But these vmcoreinfo > hide in a lot of different code paths: > kernel/crash_core.c, printk code, arch code etc. > > It is a mist only a few kdump people know them, documenting them will help > people to understand and review. It will also be clearer instead of > digging into code? > > The document can briefly explain what is vmcoreinfo, why we need it, and > some background info. Then list the exported values with some > classifying by core kernel, arch related, string or number etc. For > most of them like Baoquan said no need more explanation, but add > explanations for something if needed like this sme mask. > > But I think this can be done separately instead of blocking this patch. For this patch, i think that it had been reached an agreement. So i will update my patch log and post v2 if there is no objection. diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 4c8acdfdc5a7..ca9bdf46b8e7 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -352,10 +352,23 @@ void machine_kexec(struct kimage *image) void arch_crash_save_vmcoreinfo(void) { + u64 sme_mask = sme_me_mask; + VMCOREINFO_NUMBER(phys_base); VMCOREINFO_SYMBOL(init_top_pgt); vmcoreinfo_append_str("NUMBER(pgtable_l5_enabled)=%d\n", pgtable_l5_enabled()); + /* + * Currently, the local variable 'sme_mask' stores the value of + * sme_me_mask(bit 47), and also write the value of sme_mask to + * the vmcoreinfo. + * If need, the bit(sme_mask) might be redefined in the future. + * For example: + * [ misc ][ enc bit ][ other misc SME info ] + * 0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000 + * 63 59 55 51 47 43 39 35 31 27 ... 3 + */ + VMCOREINFO_NUMBER(sme_mask); #ifdef CONFIG_NUMA VMCOREINFO_SYMBOL(node_data); > Maybe Kazu knows more about it, so I would like to ask Kazu about his opinion > and if he want to do it. > Ok, thank you, Dave Young. About the vmcoreinfo document issue, once make a decision, i will try my best to do this based on your outline. Regards, Lianbo >> >> Anyway, we should make a choice. >> >> Regards, >> Lianbo >> >>> Personal opinion. >>> >>> Thanks >>> Baoquan >>> > > Thanks > Dave >